tl;dr: We are going to slightly simplify the permissions on the perl5.git repository. On top of that, we have a simple rule for who needs to agree that a merge commit should get merged.
What follows is broad strokes with some details yet to be refined, and I figure we'll refine them over time. But this is the plan, and you should let us know what needs work. I'll look at updating the pod in the near future.
Questions people sometimes ask:
* how do I get a commit bit?
* how do I get a PR approved?
* can I merge this PR that looks good to me?
The pod about the repo doesn't really answer these questions. The permissions on the repo are confusing to start, because there are a bunch of groups with very little explanation. Here is our plan:
Write access to the repo is either *Committer* or *Releaser* access. Both have write access to the repo. Releasers have access for the limited scope of making one or more releases and doing only the required work to do that. Committers have general-purpose write access, and use it to apply approved changes. Committers *also* do the approving.
When can a merge request be merged?
* If it's doc or test changes, one committer (other than the author) must approve the MR.
* If it's a bugfix or changes to features, two committers (other than the author) must approve the MR.
* When objections are raised, they should be discussed and addressed. "Addressed" doesn't mean "everybody agrees," but that the rationale for making the change in the face of the objection is clearly stated.
* Non-trivial MRs should wait to be merged for a minimum period of time so that discussion can occur. How long? It's proportional to the impact of the change. A few days is a good start. (A trivial MR is something like "fix a typo" or "rebuild perldoc".)
* Subject matter expert committers can issue a veto. If Karl says "this change to how we match Unicode properties will have serious negative impacts," he gets to block the merge at least until the situation is better understood.
* When things seem stuck, contact Neil, Rik, or Sawyer to get things unstuck.
Who is in what teams?
* Rik will be consolidating the too-many teams. Current "full committers" will not be losing access. Some releasers who don't do releases any more may. Let Rik know if you seem to lose access and don't think you should. It is probably a mistake.
* After that, people are added to or removed from the permission groups by the steering council, who are happy to receive suggestions for new additions.
* There may be some future removal of long-unused commit access, but nothing is planned right now.
I plan to start updating GitHub soon. No matter what, our current permissions kind of a mess.
Feedback on this is hereby solicited!
--
rjbs
What follows is broad strokes with some details yet to be refined, and I figure we'll refine them over time. But this is the plan, and you should let us know what needs work. I'll look at updating the pod in the near future.
Questions people sometimes ask:
* how do I get a commit bit?
* how do I get a PR approved?
* can I merge this PR that looks good to me?
The pod about the repo doesn't really answer these questions. The permissions on the repo are confusing to start, because there are a bunch of groups with very little explanation. Here is our plan:
Write access to the repo is either *Committer* or *Releaser* access. Both have write access to the repo. Releasers have access for the limited scope of making one or more releases and doing only the required work to do that. Committers have general-purpose write access, and use it to apply approved changes. Committers *also* do the approving.
When can a merge request be merged?
* If it's doc or test changes, one committer (other than the author) must approve the MR.
* If it's a bugfix or changes to features, two committers (other than the author) must approve the MR.
* When objections are raised, they should be discussed and addressed. "Addressed" doesn't mean "everybody agrees," but that the rationale for making the change in the face of the objection is clearly stated.
* Non-trivial MRs should wait to be merged for a minimum period of time so that discussion can occur. How long? It's proportional to the impact of the change. A few days is a good start. (A trivial MR is something like "fix a typo" or "rebuild perldoc".)
* Subject matter expert committers can issue a veto. If Karl says "this change to how we match Unicode properties will have serious negative impacts," he gets to block the merge at least until the situation is better understood.
* When things seem stuck, contact Neil, Rik, or Sawyer to get things unstuck.
Who is in what teams?
* Rik will be consolidating the too-many teams. Current "full committers" will not be losing access. Some releasers who don't do releases any more may. Let Rik know if you seem to lose access and don't think you should. It is probably a mistake.
* After that, people are added to or removed from the permission groups by the steering council, who are happy to receive suggestions for new additions.
* There may be some future removal of long-unused commit access, but nothing is planned right now.
I plan to start updating GitHub soon. No matter what, our current permissions kind of a mess.
Feedback on this is hereby solicited!
--
rjbs