Chair Theory - cplusplus/LEWG GitHub Wiki
Discussion Drives Decisions
Your role as chair is to ensure that we efficiently use our time to build consensus and make clear, concise and actionable decisions. "Decision" here is a broad term that encompasses design selection, feedback, guidance, requests to investigate or explore.
The goal of discussion is to:
- Identify what decisions need to be made.
- Provide the room with the information needed to confidently make decisions.
You should constantly be evaluating whether the current discussion is achieving one of these two goals. If not, you should move the discussion back on target.
Sometimes, discussion is insufficient to inform the room, because we lack the information. In this case, we still need to make a decision - we need to decide how we will obtain the information needed before the next discussion of the topic.
Determining Consensus
It is the responsibility of the chair of the technical committee or subcommittee, in consultation with the secretary of his/her committee and, if necessary, the project leader, to judge whether there is sufficient support.
ISO/IEC Directives, Part 1, 2.5.6
The responsibility for assessing whether or not consensus has been reached rests entirely with the leadership.
ISO/IEC Directives, Part 1, 2.5.6
The notion of "concerned interest(s)" will vary depending on the dynamics of the committee and shall therefore be determined by the committee leadership on a case by case basis.
ISO/IEC Directives, Part 1, 2.5.6
We operate by consensus, and chairs determine consensus. Chairs often use polls as a mechanism to help them determine consensus, but we do not make decisions by voting, we make decisions by consensus. The chair’s determination of consensus is authoritative, not the poll results.
Always Be Polling
Polls allow you to concretely estimate the consensus decision from the room at a particular point in time with a particular set of information available. Polls help drive us towards decisions. Always be thinking about what you should poll on.
The most common type of poll to take is a direction poll, which provides guidance but is not binding, and may be revisited later, especially if we learn new information. Take direction polls liberally. Some polls make concrete decisions which are hard to unwind, such as forwarding a proposal to another group, adopting a policy, or mandating a particular design direction. We call these decision polls; be more cautious when taking these.
If attendees do not feel that we have information to take a poll, they can vote neutral. It is generally best to not take a poll if you believe the consensus is that the room lacks enough information to take a poll. If it is unclear if the room is sufficiently informed, then just take the poll.
If attendees do not feel that they personally are qualified or attentive enough to participate in a poll, they can choose to note vote.
It is often best for polling to occur right after discussion relevant to the poll, even if there are other matters to discuss on the topic, unless that additional discussion is believed to inform the decision you are polling. You want to poll when the discussion is still in people's mental cache.
Polls Must Be Interpreted
Polls are an imperfect tool, and their numeric results don't always accurately capture the consensus of the group. A chair may have reason to believe the poll is not an accurate representation of the stakeholders in the group for a variety of different reasons:
- Ambiguity or misinterpretation of the poll.
- Lack of participation by certain stakeholders in the group.
- Disproportionate participation by participants who are not regular participants and stakeholders in the group, even if they are stakeholders on the particular matter at hand.
- Disproportionate participation by the authors of the proposal under consideration.
- Large disparities between the positions of regular stakeholders and others participating in the poll.
- Complexities of stakeholder positions that cannot be accurately expressed in a poll.
Therefore, it is important that chairs interpret poll results and explain their meaning to the grup.
If a chair believes the result of a poll does not representation the consensus position of the group, then the poll result are not meaningful.
For example, suppose we had this result:
POLL: C++ is great.
| Strongly Favor | Weakly Favor | Neutral | Weakly Against | Strongly Against |
|---|---|---|---|---|
| 8 | 0 | 5 | 0 | 2 |
This poll result might appear to have weak consensus. But, suppose also that:
- All 8 of the people who voted strongly or weakly for the poll were authors of the proposal who are new to the committee and who are not regulars in the group.
- Most of the 5 people who voted neutral were regular attendees of the group, and noted in their poll comment that they voted neutral because they felt they did not understand the proposal.
- 1 long time regular member of the group voted strongly against because they read the proposal very thoroughly and provided a lot of feedback to the authors, and mentioned in their comment that they felt no steps had been taken to address their feedback.
- Another long time regular member of the group voted strongly against because they are knowledgeable about the subject matter and believe the proposal is a mistake.
In this circumstance, a chair may determine that there is no consensus on this matter. Most importantly, the proposal hasn’t achieved absence of sustained opposition. The chair would inform the authors and the group that the poll was inconclusive and would have to be retaken after another round of discussions. They would also provide the authors with some guidance on what steps they might take to improving understanding and increase consensus.
Field Experience Builds Confidence
Our mandate is to standardize existing practice. There is a long lead time on shipping features in Standard C++, and correcting our mistakes can be difficult, so it is important to ensure we have high confidence in the things we standardize.
To build confidence in a proposed feature, we need to see field experience with the facility. Field experience consists of three components:
- Implementation experience: Are we confident the thing can actually be built? Has someone built the thing? Has someone built a production quality version of the thing? Has someone tested it?
- Usage experience: Are we confident the thing is useful and usable? Do we understand all the possible pitfalls? Have people actually used it? Have people used it in production?
- Deployment experience: How mature is the thing? Have we had implementation experience and usage experience over a long enough period of time to understand the maintenance burden of the thing? Do we have experience making changes and updates to the thing?
Usage experience does not imply implementation experience. Implementation experience doesn't imply usage experience. Implementation experience doesn't imply deployment experience.
Encourage Examples
If participants cannot understand proposals, they cannot evaluate them. One of the best ways to understand a proposal is through examples. Make sure to encourage proposal authors to add examples.
Record and Distribute Outcomes
As chair, it is your job to summarize the discussion, both during the discussion and after the discussion to those who were not present.
It is also your job to summarize the decisions made by the room. This is more nuanced than just writing down poll results; you must look at all the poll results and discussion and combine all the individual decisions into one clear, consistent consensus outcome.
You must also ensure that records are kept. Minutes must be taken, and the identity of the minute taker must be clear. Polls and attendance must be recorded with double-entry bookkeeping (you and the minute taker should separately record each). Summaries and outcomes must be posted on the wiki, on the GitHub for the work item, and if applicable on mailing lists.
Aim for "Approval by Committee" and not "Design by Committee"
Problems should be discovered and explored during meetings, but resist the temptation to spend time solving the problems during the meeting. Ensure the authors and the room have the information needed to make forward progress, but give the author the opportunity to unite the decisions into a cohesive design.