Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

PR #360 Rationale

This documents the changes made in PR #360:

  • The role of the champion is better defined:
    • Champions are drawn from lang-team and lang-team advisors
    • Champions drive experiments and have the power to make reversible decisions
    • Champions are expected to keep the lang-team abreast of updates and decisions and to bottom out lang-team concerns
  • The formal decision making process is modified:
    • FCP decisions are made by the team
    • Blocking concerns can be raised by lang-team members and advisors
    • Blocking concerns can be resolved in two ways:
      • the person who raised the concern may opt to withdraw it
      • a FCP on a resolution document that proposes a resolution
        • This resolution document can be sponsored by any team member.
        • Blocking this resolution document requires two lang-team members (not advisors). This ensures that a single lang-team member cannot block the rest of the team (but two can).
  • The ideal size of the team is defined as 4-8 members.

Changes from the past include:

  • Older material concerning an alternative rfcbot procedure is removed, as it is has not been enacted (we may reconsider it at a future date).
  • There is now a clearer path for resolving concerns; in the past, the procedure said that concerns had to be “seconded” but the means of doing so was ill-defined.

Motivation

The motivation for these changes was to increase individual autonomomy. We wish for the lang team to retain its role of shaping and vetting language features but we wish to ensure that the champions and owners driving a particular feature feel empowered to make forward progress.

Design axioms

  • Perfection is a process. We do our best to get designs right but also recognize the limits of deliberation. Many design constraints only become apparent (or relevant) once a feature has been adopted. For complex designs, we prefer to ship incrementally, addressing the most important needs first and using the experience gained to inform future design work.
  • Treasure dissent. The best designs arise out of finding a creative way to overcome two seemingly incompatible constraints. When someone raises a concern that blocks your progress, you should look on it as an opportunity to improve your design so it can meet more needs.

Frequently Asked Questions

Why are Champion Decisions “unblockable”?

In the process as written, Champion Decisions (e.g., to start or stop an experiment) cannot be blocked by members of the lang-team. We wish to lean in favor of autonomy and easy experimentation and avoid the perception that champions need to wait for the lang-team to “weigh in” before making lightweight decisions (e.g., how to focus their time). The intended flow is rather that champions document those decisions for periodic review by the lang-team after the fact. Any concerns held my members of the team can be raised there; champions would do well to heed them, as those concerns will simply arise later during the FCP process.

Why do we require two lang-team members to block a concern resolution?

The rationale and discussion was captured in resolution issue #365. That decision framed it as a question of “recursive blocking” – can the same person who raised a concern also block resolving the concern. The decision in the issue was “no, they cannot”, which favors “perfection is a process” over “treasure dissent”. This decision was not unaninmous and one team member opted to include a dissent (included below).

The final language does not describe “recursive blocking” but instead that blocking the resolution of a concern must be seconded. This was intended to allow for the fact that advisors may raise the original blocking concern, at which point the definition of a “recursive blocking” was unclear.

We also added process scaffolding that encourages genuine engagement with concerns, particularly in cases where the concern-raiser does not sign off on the resolution:

  • Template for resolution write-ups, including specific reflection questions (see the FAQ for details)
  • The option for the concern-raiser to explain why they feel the resolution is not sufficient in a design meeting.

Dissent by Josh Triplett

Josh Tripplet did not agree with the decision to remove recursive blocking and wished to record a dissent. This spot is left for him to add the dissent in a future PR.

Why did we consider removing the ability for advisors to raise a blocking concern?

Another option to resolve the inconsistency between recursive blocking and advisors raising the initial concern was to remove the ability for advisors to raise concerns. Initially “able to raise concerns” was the primary power granted to advisors, but in our new design advisors primary role is to serve as champions, and hence it was unclear whether they should continue to be able to raise concerns. Ultimately we opted to allow them to raise concerns but to require that blocking of resolutions be seconded. This is a smaller change to our procedure and allows for the idea that many advisors are deep experts in a particular slice of the language and they should be able to raise concerns in those particular areas.