Did you mean to make this change or only put it here up for discussion? I am a bit confused now. The RFC still has the old wording, yet your start of the FCP would suggest that you do not intend any further changes?
The reason for the change makes sense to me, and I support it.
Thanks, failed to push this single one, the relevant ones should already have been there.
The following change would make the list of stakeholders purely informational. Concerns can be raised by a foundation member and needs to be seconded by a second foundation member. The technical management of the RFC proposal now lies fully with the editors.
These changes lower the importance of teams and simplifies the logic of the RFC process.
To avoid stalling an RFC due to the absence of the original author or missing experience of the author with the RFC process, there is now a recommendation to specify additional editors.
This is currently only a proposed change and not implemented yet. Please take part in the tentative vote below to obtain an idea where the priorities lie. Further feedback is also very welcome.
-An *editor* is anyone who is allowed to change the content of an RFC. This always includes the author as well as additionally specified editors.
+An *editor* is anyone who is allowed to change the content of an RFC and manage its evolution. This always includes the author as well as additionally specified editors, who might be foundation members or complete teams. It is often advisable to specify additional editors to avoid stalling the process on absence and to allow help from people more experienced with the RFC process.
-Teams that are stakeholders are added as labels to the MR. Team members and others can subscribe to these labels to get notified about new RFCs. Other stakeholders should be `@`-mentioned in the MR description, if technically feasible.
+Teams that are stakeholders are added as labels to the MR. Team members and others can subscribe to these labels to get notified about new RFCs. Other stakeholders should be `@`-mentioned in the MR description, if technically feasible. The list of stakeholders is maintained to notify them about relevant RFCs and for informational purposes.
-Anyone can voice a formal concern if they do not want an RFC to be accepted without addressing their issue. This is clearly marked by creating a reply on the Discourse thread starting with `**Concern:**`. A concern must be accepted by at least one stakeholder or editor that is not the person who raised the concern. The stakeholder or editor will clearly mark the concern as accepted by linking to it in the MR description with a checkbox.
+Any foundation member can voice a formal concern if they do not want an RFC to be accepted without addressing their issue. This is clearly marked by creating a reply on the Discourse thread starting with `**Concern:**`. A concern must be accepted by at least one other foundation member that is not the person who raised the concern. An editor will clearly mark the concern as accepted by linking to it in the MR description with a checkbox.
-A concern is resolved when the stakeholder who originally accepted the concern is satisfied with the provided changes or clarifications. In this case, the checkbox for the concern in the MR description is checked and a short explanation for the resolution is added to the list item.
-
-To avoid stalling the RFC process, any other stakeholder can resolve a concern in this way, if the stakeholder responsible for the concern does not react to an `@`-mention within 14 days.
+A concern is resolved when either an editor, or the person who raised the concern, is satisfied with the provided changes or clarifications. In this case, the checkbox for the concern in the MR description is checked, and a short explanation for the resolution is added to the list item.
-If two members of a team think that their team is a stakeholder, it must be added to the list of stakeholders.
+Editors should consider amending the list of stakeholders based on the request of foundation members, teams, or other groups.
-If a new concern is accepted or an existing concern is marked as unresolved, any stakeholder can declare the final comment period as canceled. In this case, a new final comment period has to be started at a later point. Any modifications to the RFC beyond typo corrections and minor wording changes require an editor to cancel or reset the final comment period.
+If a new concern is accepted or an existing concern is marked as unresolved, an editor must declare the final comment period as canceled. In this case, a new final comment period has to be started at a later point. Any modifications to the RFC beyond typo corrections and minor wording changes require an editor to cancel or reset the final comment period.
-When the final comment period has ended and all concerns have been marked as resolved, the RFC process is finished and the proposed outcome which was specified at the beginning of the final comment period has been reached. The decision can then be implemented by any stakeholder by either merging or closing the MR respectively.
+When the final comment period has ended and all concerns have been marked as resolved, the RFC process is finished and the proposed outcome, which was specified at the beginning of the final comment period, has been reached. The decision can then be implemented by any editor by either merging or closing the MR, respectively.
-* This RFC does not introduce a final mechanism to resolve conflicting opinions among stakeholders about raised concerns. While the wording on concerns in this RFC encourages people to act responsibly and to reach a consensus, there is still the potential to end up with stalled, but important, RFCs.
+* This RFC does not introduce a final mechanism to resolve conflicting opinions about raised concerns. While the wording on concerns in this RFC encourages people to act responsibly and to reach a consensus, there is still the potential to end up with stalled but important RFCs.
I would suggest adding the following safeguard for the case that someone doesn’t follow the RFC process at all. It will still not cover bad-faith actors in general, but it might “draw a line in the sand.”
Again, I’m interested what opinions and tendencies others have:
Emergency Halt for Bad-Faith Actions
An RFC can be subject to an emergency halt if one of the editors violates the rules of the RFC process.
An emergency halt can be triggered by a majority vote of the foundation members. The vote is created by a foundation member as part of the existing Discourse thread for the RFC. If no Discourse thread exists, a new one is created and linked in the GitLab MR. The post must describe which part of the RFC process has been violated. A simple majority of votes cast by foundation members is required to trigger an emergency halt of the proposed RFC. Additionally, there must be at least 10 votes in favor of an emergency halt for the vote to be considered. The vote must run for 7 days.
In addition to creating a vote, the incident should be reported to the Code of Conduct Committee [[CoCC]].
If an emergency halt is approved, the corresponding MR and Discourse thread are closed and must not be engaged with any further.
I think you’re getting too much into the weeds and over engineering/frontloading the process to avoid bad faith actors even before we’ve had an RFC, let alone a case of a discussion going off the rails accidentally, without bad faith involved.
We should assume good faith, and we should also ensure that the RFC mechanism is associated with stakeholders to the project. Newcomers have to be stakeholders first, just like we expect people to have a bit of experience before granting them access to the GNOME group.
I strongly encourage a simpler system, with the ability to be amended in the future, instead of trying to “code defensively” against humans—especially nerds rule-lawyering in bad faith—will always be able to work around rules.