Overhaul the contributing process

[aaronpowell]

When we first launched Awesome Copilot, the goal was to have as simple a contributing process as possible, upload you prompt or instruction, run a script to update the README, and submit a PR.

As Copilot evolved, so too did our process, we added chat modes, then agents (then combined them), we created collections, along came skills, hooks, and most recently, plugins.

Plugins in particular represents an interesting challenge because a plugin isn't something that exists in isolation, it's a roll-up of other things within this repo that you install via a marketplace. To try and maintain the same level of simplicity I opted to have plugins work using symlinks, so rather than having (potentially) multiple copies of a file within the repo, we use a symlink to add them from, say, the agents folder into the appropriate plugin(s).

This design works great, git stores file modes quite happily, meaning you can commit the symlink. Yes, the browsing experience on a PR review and the website is not great, but it is workable. That is... until you're on Windows. Windows does support symlinks, but it's not quite as simple as Linux, you have to enable them at an OS level and then tell git about it so that it knows to clone with symlinks. All of this is documented in the contributing guide and again, it's workable... until it isn't.

Recently, Awesome Copilot was added as a default plugin marketplace within Copilot CLI, meaning you have easy access to all the plugins we publish. On Windows there is a problem though, as Copilot CLI is cloning the repo behind the scenes for you, so unless you've done the steps in our contributing guide (or just have previously worked with git + symlinks on Windows) you end up with a broken plugin install experience. This is what was reported to me internally from a fellow Microsoft employee, and after a bit of "fun" debugging the above issue was uncovered.

Clearly, the use of symlinks was going to be a problem going forward.

Introducing the staged branch

To resolve this, I'm introducing a bit of a change to our contribution process, we're going to have a new staged branch in which contributions are to target rather than main, and once the contributions are merged into the staged branch and automation will take over to generate the updates to the main branch.

The approach with this is that we no longer commit symlinks for plugins, just the plugin.json and readme.md. The plugin.json will contain all the files that are to be bundled in the plugin, and when the main branch is generated, those files will be copied into the plugin folder. This does mean that the main branch will contain duplicated files, but that's fine, it's generated.

What this means as a contributor

As a contributor, you need to:

• Branch from staged, not main
• Target staged for your PR, not main

For the time being, main is going to be the default branch for this repo, I hope to change that to make the initial fork easier to do but it requires some changes in Copilot CLI first.

As much as possible, I'm creating GitHub Action workflows that will validate the branching strategy and inform contributors on corrections that need to be made, with the hope that this will avoid making it overly burdensome to contribute.

This work has been kicked off with #750 (including aligning the plugin.json file to the latest spec) and I'm going to leave this open for review/feedback for the next ~day.

Thanks everyone for making awesome copilot so awesome!

[wmmc88]

ah. i ran into the ghcp cli plugin install issue in #736

[aaronpowell]

This has been merged in now - I'll work with the authors of the active PR's to align with the new structure.