Council decision making process

# Council decision making process This document details the process and classifications for decisions made by the Council. [RFC 3392] specified the [the decisions the Council may make internally][internal-decisions], [must make publicly][public-decisions], [must make privately][private-decisions], and specified that decisions should be [consent-driven]. However the RFC does not explicitly specify the process for those decisions, which this document covers. This document assumes the reader is familiar with the current Policy governing the Council and its guidelines. [RFC 3392]: https://rust-lang.github.io/rfcs/3392-leadership-council.html [private-decisions]: https://rust-lang.github.io/rfcs/3392-leadership-council.html#decisions-that-the-council-must-necessarily-make-privately [internal-decisions]: https://rust-lang.github.io/rfcs/3392-leadership-council.html#decisions-that-the-council-may-make-internally [consent-driven]: https://rust-lang.github.io/rfcs/3392-leadership-council.html#the-councils-decision-making-process [public-decisions]: https://rust-lang.github.io/rfcs/3392-leadership-council.html#decisions-that-the-council-must-make-via-public-proposal [operational-vs-policy]: https://rust-lang.github.io/rfcs/3392-leadership-council.html#operational-vs-policy-decisions ## Classifications Decisions lie on a continuum across different axes: * Internal vs. external * Whether the decision is about the Council’s own internal operation or whether it has a direct impact on some other part of the Rust Project. * [Operational vs. policy][operational-vs-policy] * Whether the decisions is to carry out the aims of the Council versus establishing general reusable patterns or frameworks for operations. * Small vs large impact * Trivial or small decisions may require less process than larger decisions. * Reversibility * Some decisions can be easily reversed or changed without negative consequences, while others take more effort to change or have permanent consequences. * Urgency * Some decisions may need to be made quickly, some may have a scheduled deadline, some are important (but not imminent), and some can be deferred until time is available. * Specialization * Some decisions may require significant domain knowledge or proficiency versus those that any Council member could be reasonably assumed to be equipped to handle. Processes need to take these into consideration, and also be aware that in some cases the classification is subjective, and some people may see them differently. ## Internal decision process See the [internal decisions][internal-decisions] list for what the Council may decide internally. The process for making an internal decision is: 1. A proposal for an internal operational decision can be put forward at any time by any member of the Council either in a sync meeting, in a public Zulip stream, or in the [leadership-council repo]. * The proposal must be viewable by all members of the Council. * The proposal should be labeled clearly as such. 2. The proposal must then be seconded by at least one other member of the Council. 3. The approval of the decision follows the consent model described below. There are two forums where this process can play out [synchronous meetings](#synchronous-meetings) or [asynchronous decisions](#asynchronous-decisions). ### Synchronous meetings 1. The proposal should be on the agenda with sufficient time for members to see it. * Links to supplementary information, such as background information or a more detailed proposal should be included if available. 2. During the meeting, a quorum of N-2 must be established. * A best effort must be made to establish full quorum. 3. A member involved in the proposal should briefly state what is being proposed and open the floor for discussion. 4. Time should be given for any final questions or discussion. 5. The facilitator should restate the proposed decision and call for any objections. * Sufficient time should be given for members to collect their thoughts and have a chance to voice any objections. * The member must state a short explanation of their objection. * Objections may include a request for more time to deliberate or collect information and defer the decision to a following meeting. 6. If there are objections, discussion may continue to see if those objections can be resolved in a reasonable amount of time. * If the discussion seems like it may take significantly more time, the facilitator should ask the parties to continue outside of the meeting and record in the meeting notes that a decision was not made. 7. If there are no objections, the facilitator should acknowledge what was decided (possibly restating any modifications made due to the discussion) and it should be recorded in the meeting minutes as such. ### Asynchronous large internal decisions Internal decisions may be made asynchronously using [rfcbot]. 1. A proposal must be posted as a GitHub comment with a clear declaration of what is being proposed, possibly with links to any background information a member may need to make the decision. * These proposals are typically done in the [leadership-council repo], but may appear in other repo's such as the forge, the blog, etc. 2. Members may raise concerns which block the decision until they are resolved. 3. The decision is approved if at least N-2 members consent to the decision without any open objections. * At least 10 days must be given for the last two members to respond. * If there is unanimous consent from all members, then the waiting period is not necessary and the decision is immediately approved. Sometimes it can be difficult to get all members to review and provide feedback on a decision in a timely manner....  [rfcbot]: https://github.com/rust-lang/rfcbot-rs [leadership-council repo]: https://github.com/rust-lang/leadership-council ### Small decisions Small decisions are decisions that have very small impact, can easily be changed, and are unlikely to be controversial. #### Criteria - [ ] Is the decision easy to reverse? - [ ] Is the decision unlikely to impact anyone outside the Council or those who pay close attention to Council proceedings? - [ ] Is the magnitude of the impact likely to be small enough that even if others disagree, they are unlikely to be negatively impacted by the decision? #### Decision making process Two Council members are required to make these decisions. These decisions require that they are visible to the rest of the Council for post-facto review. #### Examples - Documenting existing procedure ### Trivial decisions Trivial decisions are decisions that don’t require any pre-facto oversight. They are usually so small that many might not even recognize them as decisions. #### Criteria - [ ] Is the decision trivially reversible? - [ ] Is the decision unlikely to impact anyone outside of the Council - [ ] Is the magnitude of the impact likely to be small enough that a reasonable person might not even notice? #### Examples - Fixing typos in documents ### Urgent decisions https://rust-lang.github.io/rfcs/3392-leadership-council.html#deadlock-resolution  ### Delegation Through the process outlined above, the Council may also delegate the decision making process to another group (including groups composed exclusively of subsets of Council representatives). The process that that group then uses to make the decision that was delegated to them is up to the discretion of that group. However, the delegated to group must make their decision known to the Council who can then place additional requirements on that decision such as where it must be documented, when it must be re-examined in the future, etc. ## Public decision process The [public decision][public-decisions] process is documented in the existing policy documentation to use the existing RFC process. ## Documentation There are several means by which a decision is recorded based on the kind of decision: - Public policy decisions go through the RFC process, which naturally involves public requests for feedback (such as via [TWiR](https://this-week-in-rust.org/)), a public declaration that it is being proposed for approval (the final-comment-period process), and a public notification that it has been approved (the final comment merging the RFC). - For decisions that affect the governance of the Rust project, public policy changes should then be transferred to the Rust Forge governance documentation.  - Decisions that affect the structure of teams should then be reflected in updates to the [team database][team-db]. - Internal decisions that affect Council process should be documented in the [leadership-council repo]. - Decisions made during a synchronous Council meeting should be documented in the [meeting minutes]. The Council should periodically publicly communicate which decisions have been made since their last update, such as via the [Inside Rust blog][inside-rust]. [inside-rust]: https://blog.rust-lang.org/inside-rust/ [team-db]: https://github.com/rust-lang/team [meeting minutes]: https://github.com/rust-lang/leadership-council/tree/main/minutes ## Review and evaluation After a decision is made, the Council should schedule a date to review and evaluate the decision. The duration may be decided based on the kind and gravity of the decision. In larger cases, the Council may consider calling on Project members or the public to collect feedback on the effectiveness of the decision. The outcome of these reviews is to decide how well the decision is working, and whether or not a followup task should be added to the Council's task list to make adjustments to the decision. This is also an opportunity to reflect on how the process went overall, and to provide positive feedback to those involved. Examples: - A new governance policy may be reviewed after 6 months. - The conclusion of a fixed-term project like the Foundation director selection may be reviewed 1 month after the process is complete. - The formation of a Council standing committee may be reviewed 6 months to a year after its formation. ... TODO More examples?  After a policy change is made, a scheduled review of the policy should be added to the [Council schedule](https://github.com/rust-lang/leadership-council/pull/20).  ## Decision process updates Changes to the decision process (that is, changes to this document) must be made by full consensus of the Council. Changes must be compatible with current policy for how the Council must operate, particularly around public disclosure and public policy changes. Trivial changes, such as typos or technical formatting, can be made by any Council member.