Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define a process for resolving disagreements among stakeholders for the RFC process #6

Open
tschneidereit opened this issue Dec 1, 2020 · 1 comment

Comments

@tschneidereit
Copy link
Member

Over in #1, @joshtriplett highlighted that we haven't yet defined a process for resolving conflicts that might otherwise leave RFCs in limbo indefinitely. We shouldn't put this off for too long, and instead aim to have it in place before the first such case occurs.

@joshtriplett
Copy link
Member

Concrete proposal, based on some discussions in the Rust project:

Any one stakeholder may register an objection to a proposal. There is minimum discussion period associated with such an objection, to give people time to discuss and consider. After that discussion period, to continue to maintain the objection, at least one other stakeholder must second the objection; seconding does not imply agreement with the objection itself, only that the objection has some merit and that there's value in continuing to hear it out. (Seconding objections that you don't necessarily agree with is encouraged; declining to second an objection means you believe that it both has been fully heard and discussed, that nothing would be gained by further discussion, and that no resolution seems likely to be possible.) If an objection is not seconded, the objector is encouraged to write a "dissenting opinion", which should be incorporated into RFCs or similar in an appropriate section (e.g. "alternatives" or "open questions"), but is asked to "disagree and commit" to the team consensus. (This does not preclude them from raising other issues in good faith, or from raising related issues if new information comes to light; this should not be used to silence subsequent discussion, only used to allow the process to move forward without repetition.)

In other words, if a stakeholder wishes to block something beyond a reasonable initial period, they need to convince at least one other stakeholder that there's an issue that has not yet been fully heard or discussed or understood. If they can convince at least one other stakeholder, that objection can stand indefinitely; that seems reasonable, as we should strongly aim for full consensus and not override objections lightly. If they cannot convince a single other stakeholder that there's any more to hear out, and everyone believes that there's no consensus to be had, it's possible to move forward.

I'm proposing this based on having experience in all three roles: as the person with the sole objection, as a person arguing that someone else's objection should be heard further, and as a person who has seen objections that did not have any support from the rest of the team.

I would also encourage something like the following, to help people reach consensus:

Before resorting to this process to override an objection, try to reach a consensus if at all possible. In particular, note that many seemingly intractable discussions stop once they reach questions that one or more stakeholders consider related to their values or similarly core considerations. Rather than treating this as the end of a discussion, however, this can be the start of the most critical part of the discussion. Many interesting questions come down to evaluations of such values and the tradeoffs between them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants