I think it's important to spread the responsibility for updating the master branch. Right now only two of us can do so: wolftune and myself. This can be considered one extreme of the right-to-push spectrum, and it's one that is used by a lot of projects. The other extreme is to give write access to everyone who submits a merge request, which is actually used (and recommended) by some teams.
I think we should sit somewhere between the two, creating a team of
'merge managers' who must agree to a particular Code of Conduct. Here
is some brainstorming about that Code.
1. The Code should address code review, since the new team of merge
managers would probably often be drawn from the same group of people
who do code reviews. We would need to strike a balance between making
sure code is adequately reviewed and making sure that code is merged
in a timely manner.
* Maybe a reviewer could assign the Merge Request to a merge
manager (other than their self) when they think the code is
adequate?
2. The Code should also specify the process for accepting new members
to the team. I suppose it would be a consensus process.
3. The Code would have to say, in rather general terms, that code is
only merged if it meets the project's coding guidelines and
contributes in meaningful (but not necessarily extensive) ways.
4. There should be a clearly documented way for people who submit
merge requests to raise any complaints they may have about the merge
team.
That's all I got now. To summarize, I envision a merge team that
interacts with reviewers and requesters in a timely and collaborative
fashion, merging new code into the project. The purpose is to increase
the speed and decrease the chokepoints of getting code merged.
Anyone else have ideas on how to build that team?
-Bryan
signature.asc
Description: Digital signature
_______________________________________________ Discuss mailing list [email protected] https://lists.snowdrift.coop/mailman/listinfo/discuss
