Requests for comment/Governance/2016-01-06 meeting
- copied from https://etherpad.wikimedia.org/p/WorkingGroups on 2016-07-18
Version 1434 Saved January 6, 2016
Authors: robla, Tim, Gabriel, Krinkle, Dude
Who makes decisions?
What is the relationship with ArchCom?
Who is responsible for creating these groups?
Who disbands them?
What does membership in a group mean?
What are the responsibilities of these groups?
Should we have working groups at all?
Action item: RobLa: read the Rust model
Models to observe/study
- Rust - https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md
- Core team:
- ~8 members
- spins up subteams as needed, spins them down when decisions are done
- (after RFC is approved) makes final decision on whether a feature or change implementation enters stable release (or 'master' branch) of software.
- Each subteam is led by a member of the core team.
- Team lead decides initial team memberships. Further membership is decided by subteam members consensus.
- Sub teams are enpowered to decide.
- Discussions are mostly asynchronous, online.
- RFC shepherded by a member from a relevant subteam. The shepherd is responsible for guiding the RFC through the process. Shepherd is responsible to detect when all relevant arguments have been surfaced.
- Last call (1-2 weeks).
- Decision is made by that subteam, not by core team.
- Core team members can bring up arguments and concerns as part of the larger audience participating in the RFC process toward the champion of the RFC.
- Delegation of authority per RFC
- Last call called by the champion
- Questions about this process:
- What happens if ArchCom wants to override the WG?
- Meetings run by a consulting company
- IESG: 12 person steering group
- Some IESG members are area directors (ADs)
- IAB elected by ISOC (?), but not supposed to be important
- ADs approve creation/disbanding of WGs
- WGs are "temporary" (but sometimes measured in decades)
- ADs do not decide on RFCs with their AD hat on.
- WG chair decides on RFC status (draft or ready for approval by IESG)
- IESG delegates development process to WG but not final decision-making power
Roan: do we have a scaling problem? Do we really need WGs?
Robla: yes, people don't have enough time to read and review all RFCs. If we delegate RFC responsibility then archcom won't have such an impossible task
Daniel: sometimes I go into an archcom meeting not having read an RFC, seeing it for the first time. With WG split that is not so likely.
Questions for later:
- How does archcom membership work?
- What is the current membership of ArchCom
- Confirmed: Gabriel, Roan, Daniel, Timo, Tim
- Are Mark and Trevor still members? – https://www.mediawiki.org/wiki/Architecture_committee
- Mark: asked to drop out. RobLa failed to announce
- Trevor: Never accepted nomination – Tim
- Ori: declined, then agreed to attend "when it makes sense"
- What are archcom's responsibilities
- Do we want permanent "areas" like IETF
- Do we also/instead want temporary WGs?