Feedback Windows
The Rust RFC process occurs in public on GitHub via PR reviews. RFCs are change proposals for all sorts of things (the language, the API, project governance, etc.).
On a particularly contentious RFC (I forget which), a project member made a comment that has stuck with me for a while. I don’t remember the exact quote, but paraphrasing, the nugget of wisdom went something like this:
It is not the case that all proposals are open to all feedback from all stakeholders at every point of their lifecycle.
Aligning on this as an organizational norm is pretty powerful. The following things flow from it:
- Use a nemawashi-like approach to build consensus.
- Do not share documents, plans, and designs to a wide audience before they are ready to be shared.
- Be explicit about when you expect feedback to be delivered by when shopping around a proposal.
- Be explicit about the type of feedback you are expecting and willing to consider when sharing a proposal.
- Communicate appropriately when a decision has been made and be clear that it is “locked in”.
- Disagree and commit.
- Be intentional about re-visiting a decision. Re-litigation has a very high bar for evidence of changing circumstances.
In my experience, delivering feedback outside of a feedback window is likely to be received poorly and cause lots of friction.