# Backlog - (D) establish a timeline so we can hit mid july proposal goal - Update Proposal - Clarify how nominations are gathered - Clarify who decides - resolve open comments - Open PR with proposal against council repo - Draft blog post introducing selection process - gives reps ability to get input from subteams on the process proposal ## Charter ### Membership - Ryan Levick (rylev) - Eric Holk (eholk) - Jane Losare-Lusby (yaahc) ### Aims - Design the election process for the next set of rust foundation project directors (ratified by the leadership council) - Clearly document and communicate the process and support it's execution - Track, review, and document the effectiveness of the process ## 2023-07-06 Proposal Draft https://hackmd.io/NhppYH7HTxGD9hoogVJRaw - Check-in - Consent to agenda - (Explore) Informal review session on draft with technetos (Josh Gould) - Check-out ### Action Item outcomes: * [ ] explicitly suggest batching the selection process ### Feedback from technetos * +1 to having facilitation delegated to an individual via a role * role description is gonna be important to get right * tangent: the current setup for project directors is more unidirectional than it should, does represent project on foundation, doesn't represent foundation back to project effectively * The suggestion for gathering nominations seems similar to representative nomination for the council * I feel like the selection of the council members was a bit of a disaster, can we improve on this experience? Eric * We don't necessarily need every team to provide nominations Josh * I'm not confident we'll have that many candidates Eric * On the topic of iterative selections, one director at a time vs batched, I'm leaning towards batching them * makes it more time efficient * lets us consider demographics to get good diversity of experiences within the selected members, more flexibility Josh * What if we only get two candidates for three spots? Do we just fill two and hope we get three in six months? * Mods can object to council members. Does that extend to project directors as well? * Jane: Council chooses PDs by consent, there's a mod on the council, so mods can already object. #### Outcome & Action Items ## 2023-06-27 Present: eholk, yaahc (facilitator), rylev Proposal Draft https://hackmd.io/NhppYH7HTxGD9hoogVJRaw - Check-in - Consent to agenda - (D) consent to decisions from previous meeting - setup a public stream - aims - (D) Prioritization and planning - clear communication plan for short term work - (E) Start drafting rational section for proposal - Call for clarifications - Check-out ### Completed Action Items - a stream under the council (#council/project-director-election-process-wg?) - determine exact name async - charter with goals - can we inline this at the top of our minutes document? - communicate that we don't need an extension - deadline is Sept 21 ### Minutes - decisions from previous meeting - Work in public - Teams entry? Adds formality but also overhead. Maybe need a new group category for short term project teams. Helping Groups? - #council/project-director-election-wg - Need to say "election" because foundation bylaws say we need to have elections. - What are the legal requirements to call it an election? - End process needs to be election, but it can be like the electoral college where electors vote for who they're told. - Electors are the members of the leadership council. - Group aims - Design process to elect project directors, to be ratified by council. - Clearly communicate / document process and support its execution. - Should we add feedback collection? Yes - Prioritization and planning - Review backlog from last time - Mid July deadline? We can still hit this and getting something out early is good to get feedback. - Round - Jane - Let's go through the current proposal and try to resolve comments. Mark left lots of comments, can we resolve on his behalf? - Eric - like an approach from blog post and working backwards. Short to medium goal: we should get a PR out to the Council repo. - Ryan - Sounds good so far. Two separate things, but might be just one. 1) Documented procedure that will be followed. 2) Justification and explanation of why this is the procedure. What are we trying to solve? What are the constraints. Docs should be separate so it's easy to see process and rationale. Could be one document. - Round - Jane - Justification as separate from policy process feels like a more durable form of the blog. What if we start with justification and that can feed into blog post and documentation. Can do this in the same HackMD for now. - Eric: I like all the ideas. Rational will change less than the implementation. Keeping them separate captures that. - Ryan: Sounds good to start with justification and constraints. Documentation writing follows 80/20 or 95/5 principles. Broad strokes is quick but final process takes lots of effort. Let's not get bogged down on getting things to final form. Need to get policy in hands of others to review ASAP. Making sure justification is consumable by everyone can come after we finish the proposal. - Working on Rationale in [proposal doc](https://hackmd.io/NhppYH7HTxGD9hoogVJRaw?edit), general discussion - Current Aims list should be in priority order. Time efficiency is probably not our highest priority. - Point of group, to pick project directors for the foundation board should be at the top of the list. - We should define criteria or characteristics of an ideal project director. For example, trying to draw out new leaders. - Let's have a goal to incorporate input from the Rust project as a whole. - "Select the best candidate" is not the best wording. The idea of a single best candidate is a counter productive way to think of filling the role. "Who can be successful" is a better framing, and makes it easier to bring in new leadership. Think in terms of success, not best. - "Most successful" could still be exclusive. Emphasize "successful," not "most successful." - Is one of our goals to define the role? - Role description and description of qualities of a person to be successful in the role can be different. - Time check: finish this async - Check out ### Action Items - [ ] Have discussion about name for this team (**owner**: Ryan) - [ ] Create channel once the name is decided (**owner**: Jane) - [ ] Add agenda item to Council meeting to update them on wg progress (**owner**: Eric) #### Outcome & Action Items ## 2023-06-23 Present: eholk, yaahc (facilitator), ~~rylev~~ Proposal Draft https://hackmd.io/NhppYH7HTxGD9hoogVJRaw - Check-in - Consent to agenda - (E) Working group formation processes - (I) update on discussion from last council meeting - (E) current proposal - (D) who ultimately decides who the project directors are? - ultimately council decides, gathering feedback and representing their various branches of the org tree - (D) establish a timeline so we can hit mid july proposal goal - work on this async - Call for clarifications - Check-out ### working group formation process - want to work transparently, build trust in council processes, give people opportunities to participate - have a way to track things - keep the council informed on progress - keep steady progress, keep it from falling through the cracks - keep the council interested in our progress Action Items: - a stream under the council - charter with goals - maybe teams entry for the wg (if we're going to last a while?) - seems heavy weight, how do we spin this down? can we make this easier? ### update on discussion from last council meeting - time sensitive items, sept 21 deadline - discussed where is this gonna go - within a github repo (rust-lang/leadership-council?) - Delegation - subsets of the council - helps with faster iteration, empower smaller groups to make decisions - meta discussion about how we're going to create the selection process - resulted in this wg - council wanted experts outside the council involved in meta process - under the impression that deadline was july - easy to extend terms if we need - preference to avoid further extensions - looking to replace 2-3 project directors - depends on who wants to step down Action items: - communicate that we don't need an extension - still aim for mid july proposal ### Explore current proposal - have representatives gather nominations from subteams - teams can pick their own process, but lean away from vote as a good option since we're gathering objections - Proposed process does a good job of incorporating input from whole project but also avoids the need to clearly define what the "whole project" is - Process is inspired by Sociocracy, but new to us. Maybe we should bring in external training? - Launching Pad used a similar process for choosing a leadership council rep. It did successfully choose a rep, but the process was suboptimal or frustrating in a lot of ways, mainly bootstrapping related. People largely didn't even know they were part fo the Launching Pad team at all. Proactive communication about the process coming from the Council (e.g. on Inside Rust blog) could avoid these frustrations in a project-wide selection process. Action items: - Clarify how nominations are gathered - Clarify who decides - Draft blog post introducing selection process - gives reps ability to get input from subteams on the process proposal ---- # Agenda Template ## DATE Present: eholk, yaahc (facilitator), rylev Proposal Draft https://github.com/rust-lang/leadership-council/pull/12 - Check-in - Consent to agenda - (I/E/D) Agenda Item 1 - Call for clarifications - Check-out ### Agenda Item 1 #### Outcome & Action Items