Workstream Management with Branches?

[RishabhMalviya]

I have been going through the repo and would like to build upon some of the work other people have done. Unfortunately, all that work is on separate forks of the repository instead of on branches. I am also noticing that the issues/PRs are scattered and often duplicate each other.

Proposed Branches

I believe it would be more productive to work with branches - one protected branch for each major workstream. For example, we could start with this set of branches:

1. feature/local-use-stability
2. feature/cross-platform-compatibility
3. enhancement/test-suite
4. enhancement/github-actions-cicd
5. feature/og-core-interop
6. enhancement/async-execution
7. scratchpad (for miscellaneous or unclassified work)

This would be a great way to 'codify' high-level organizational analyses like the one @SeaCelo has done in #301 (in fact, when coming up with these branches, I used #301 as a major starting point).

I would love to hear from other about what branches we should keep/remove/add from the above list?

Branch-Based Workflow

We can configure the behavior of these branches with branch protection rules. The target behavior would be:

1. As contributors, we won't be able to push to these branches directly, but we will be able to open PRs against them.
2. Only maintainers will have permissions to merge PRs into these branches.
3. each PR would have linting/unit testing checks run at the end of them.

This will allow people to work more collaboratively; instead of having several parallel implementations of the same feature in different forks, we can all reference a central implementation in these protected branches.

Migration Plan

Right now, almost all work exists in separate forks. Fortunately, it is straightforward to migrate to the above-proposed branch-based workstream management:

1. Create the above protected branches from main
2. Allow contributors to create their own branches (we can enforce branch naming conventions using branch protection rules). In my opinion, we should apply the convention that contributor-created branches must have protected branch names as prefixes. For example, I would be able to create a branch with the name feature/cross-platform-stability/separate-windows-dependencies, but not a branch with the name feature/separate-windows-dependencies. This ensures that all branches are linked to a workstream.
3. As contributors, we would create relevant branches, and then copy over the work from our individual forks into these branches.
4. We can merge changes from the protected branches into our feature branches to make sure we're up-to-date.
5. Now it is straightforward to quickly view all competing implementations/solutions for each workstream, to discuss them, and to collaborate on them.

Does this seem like a reasonable plan? Thoughts? Comments? Alternatives?