Over the past year, we've experimented with GitHub's teams and collaborators feature, where main is a protected branch, and contributors have rights to create new branches and submit PRs to merge to main. The upsides have been:
A sense of team membership, because they are invited and gain some privileges
Simplicity for contributors, since they do not have to learn about or manage their forks
Fewer merge conflicts, because its easier to be notified of changes
Contributors can self-assign issues
The downsides, unfortunately, are many:
Managing team invites is challenging because students have to share their GitHub username, request invitations, do not respond to invites before their expire, and do not start work until they have access
Team members quickly become stale because students rotate off the project in as short as 3 months
Students are not disciplined in their creation of branches, creating a huge mess of branches on the main project that are hard to navigate and understand
I propose we move to a fork model instead. It would work as follows:
Contributors fill out the application, giving us information about who they are
When contributors want to work on an issue, they'd have to tag a maintainer for permission
When they want to develop for an issue, they'd fork the repo, and include a link to it in the issue, showing everyone else who wants to contribute where to contribute, and sync their fork regularly
Developers who want to collaborate would have to contact the person who owns the fork to collaborate with them and contribute to their fork, rather than having maintainers facilitate collaboration
Students who become trusted contributors over time could be invited to the team as maintainers
The wins are here many:
Cleaner branches in the main repo
Eliminates team invite work for maintainers
There are downsides:
Makes every student into an "outside" contributor, eroding sense of team
Increases likelihood of merge conflicts for students
Makes students learn about forks upfront to contribute
To implement this, we need to:
[x] Update the wiki to explain the maintainer status
[x] Explain how someone can become a maintainer, and what commitments that entails
[x] Update the contributor wiki to explain how to fork and sync forks
[x] Update the develop wiki to clarify the new process above
[x] Create pull request template
Who benefits?
This primarily benefits maintainers, but indirectly benefits all stakeholders of the platform by making the project move more quickly and effectively.
What's the maintenance need?
Over the past year, we've experimented with GitHub's teams and collaborators feature, where main is a protected branch, and contributors have rights to create new branches and submit PRs to merge to main. The upsides have been:
The downsides, unfortunately, are many:
I propose we move to a fork model instead. It would work as follows:
The wins are here many:
There are downsides:
To implement this, we need to:
Who benefits?
This primarily benefits maintainers, but indirectly benefits all stakeholders of the platform by making the project move more quickly and effectively.