Champion decisions

Champion decisions do not represent team consensus. Rather, they indicate that somebody on the team is willing to champion an idea. We use them to begin experiments and for other decisions where we want to move quickly and iterate.

When to use champion decisions

• Starting or stopping a lang-team experiment
• Closing an RFC or issue that is clearly not going to be accepted
• Significantly changing an existing experiment’s scope or goals (either cutting or expanding scope)
• Opting to focus on a particular design direction and halt investigations of others
• Adding a new constraint to the design that you’ve learned as part of exploring the design space
• Other lightweight decisions that you’d like the team to be aware of, but that don’t make a durable commitment

Process

For the champion (lang team member or champion)

1. Write up your proposal on a GitHub issue or PR, explaining the decision and context.
2. Nominate it for discussion at a lang-team triage meeting.
3. At the triage meeting, the team will discuss and raise any concerns.
4. Consider the feedback. If team members expressed strong concerns, you should likely address those before proceeding.

Handling concerns

When people raise concerns:

• Treasure dissent. Engage with them and make sure you understand the concern.
• Note concerns on the tracking issue as “unresolved questions” or things to explore—they shouldn’t be forgotten.
• Concerns don’t block you from proceeding, but they may give you pause, particularly if they are shared by multiple team members.

For other team members

• Your approval is not required for champion decisions.
• If you disagree with the decision or think it’s a bad idea, say so (constructively)!
• For experiments, ask yourself: What are the “weak spots” that the experiment ought to probe? What information can we gather?