governance: introduce workflow improvements
Proposal: Improving Development Workflows
Problem Statement
Development discussions in wayland-protocols often get 'stuck', which is to say they go back and forth on a given point for an extended period without progressing or introducing new technical points.
The project needs a formal mechanism for unblocking discussion in these scenarios. A classic option is the tie-breaking vote: after a period of time, whichever idea has the most votes wins.
Additionally, it is sometimes the case that a staging/ protocol is "good enough",
but the author has not continued development. Having a mechanism for automatic promotion
to stable/ ensures that high quality protocols can be promoted to "production"
expectations without undue process constraints.
Some small bonus items:
- specify the starting point for a 30-day discussion period
- unspecify the number of points-of-contact a member project can have
Stalemates
A stalemate occurs in discussion when two competing ideas face off and cannot be resolved one way or the other through discussion. In such cases, the author or any member point-of-contact may request a tie-breaking vote.
When a tie-breaker is invoked, a new public issue is created by a member point-of-contact and linked to from the originating protocol merge request. This issue will have a due date set for seven days from the initial creation.
During this period, member projects will comment on the voting issue.
Abstention is not counted as a vote.
Any member project may elect to extend the voting period by an additional seven days. This option may only be invoked once per member project per tie-breaker and shall not be used without cause.
Each member project with at least one non-recused point-of-contact may cast one vote.
Votes are tallied by members when the voting period expires.
Whichever choice has the most votes is considered the winner, and the discussion will be resolved in that direction.
Non-member Representation
This calls into focus a related issue: protocols proposed by non-members are sometimes perceived to have less weight. Stalemates and tie-breakers may add to this perception.
To address this, each non-member proposal for a non-experimental protocol is eligible to have a Sponsoring Member. The sponsor is an individual from the member points-of-contact list chosen to represent the protocol author in all cases where a member's voice, vote, or responsibility is required.
It is the responsibility of points-of-contact to determine whether they have the capacity to effectively represent a given protocol upon request. The members must provide a sponsor for a given protocol upon request.
A sponsor represents a given protocol at the author's request. If the author is unsatisfied with this representation, they may make a one-time request for a different representative.
If a protocol's sponsor is unable to perform their responsibilities (e.g., vacation, illness), the members will provide an interim sponsor.
Automatic Promotion to stable/
When a staging/ protocol has been in use as a de facto standard for a long period of
time, it can be considered "good enough". At this time, any member may create a merge request
for promotion, triggering a 30 day review period. If the review period elapses without
any NACKs, the protocol is promoted.
30-day Discussion Periods: Official Start Time
GOVERNANCE.md specifies that a 30-day discussion period is invoked for various cases involving merge requests. This is ambigulous, however, as it could mean a 30-day period from the time the discussion is opened or from the time the discussion is formally approved.
Specify that this period begins at the time the issue/MR is opened in order to more expediently resolve problems.
Member Projects / Points-of-Contact
A point-of-contact is a representative for a given member project who is active in protocol discussion and has been entrusted with conveying the official stance of the project. In some cases, however, points-of-contact may be busy, or they may be less interested in certain protocols, or they may be absent on leave, etc. For this reason, the governance model currently allows up to two points-of-contact for a member project.
This cap will be removed, and a project may, through the existing mechanisms for adding new points-of-contact, add new points-of-contact without limit. By changing this, project ecosystems (e.g., wlroots, which is the foundation for many different compositors), have the ability to be represented by more voices from more subprojects. This also enables projects to become even more active in official capacity across more protocols without putting undue strain on any one point-of-contact representative.
This change does not modify existing voting rules. If points-of-contact from a member project express disagreements in votes, the project's vote is considered blank. More points-of-contact carries its benefits, but it also increases the importance of discussion for the project.
Q & A
Can't tie-breakers be abused?
Try it and find out?
If I am chosen as a sponsor, do I have to?
No, but it's a nice thing to do.
If I am chosen as a sponsor, how do I vote during tie-breaks?
In a tie-break, you vote as the proposal author would vote. If this conflicts with your opinion, an interim sponsor should be chosen.
What if the stalemate is between author and sponsor?
The author should request a different sponsor.
What if a non-member wants to exercise the automatic promotion to stable/?
Contact a member.
So what's stopping wlroots from having 100 points-of-contact?
Nothing.
But doesn't this mean GNOME is going to add 500 points-of-contact and take over the voting?!
No. Votes are by member project, not by person.
What if points-of-contact for a given member project are consistently disagreeing?
This may be an indication that some points-of-contact should either be removed or split off into a separate project.
ACKs (6 needed):