User:KSmith (WMF)/ArchCom thoughts

For a potential vision of what ArchCom (or a successor) could be, see: User:KSmith (WMF)/ArchCom thoughts/Vision.

Existing material
Architecture committee

Architecture committee/Team practices

Architecture meetings

Consensus

Requests for comment/Process

Essence
My goal for this quarter is to identify and document the essential outcomes of the ArchCom. Currently, RobLa is somewhat of a single point of failure as the ArchCom chair, and that's never healthy. Someone else who stepped in as the chair might choose different rituals and artifacts, but those should be in service of the essential activities:
 * Coordinate the handling of RfCs, from creation through approval
 * Approve RfCs
 * Encourage and participate in discussions about strategic and/or high-priority technical projects

Coordinate handling of RfCs
This currently includes: Proposal: Continue to refine the existing RfC process and associated documentation.
 * Document and maintain the documentation of the RfC process
 * Maintain, groom, and update the RfC-related phabricator workboards
 * Committee members volunteer to be "shepherds" for specific RfC tasks
 * Organize IRC discussions about RfCs, and posting the results
 * Provide feedback to RfC owners
 * Meet weekly as a committee to review and plan IRC meetings, monitor and update the status of active RfCs, and have specific high-level or framing discussions about specific RfCs

Approve RfCs
According to existing ArchCom documentation, the committee might "approve" or "deny" an RfC, based on "consensus". I can't find anywhere that explains what those terms mean in this context. In particular: With that in mind, I will propose the following straw dog:
 * What is the criteria to approve an RfC?
 * What are the tangible benefits to an RfC of being approved?
 * What is the criteria to deny an RfC?
 * Is there a difference between denying and never approving?
 * Consensus of who (the committee, the technical community, the whole world)?
 * What level of consensus (no vetoes, majority in favor, unanimity)?

The architecture committee's responsibility is to assess and summarize how the relevant technical community feels about an RfC. To that end, they will provide guidance and help to the RfC proposer, so that the ideas within the RfC are communicated clearly to the appropriate people, and a rich discussion follows. While committee members are expected to participate in those discussions, their opinions are as individuals, not from a place of power as committee members. The RfC proposer is expected to answer clarifying questions, correct errors, and generally make the RfC complete and accurate.

As objections or concerns are raised, the RfC proposer is expected to address them. That doesn't necessarily mean agreeing with the concerns, but rather accepting that the concerns may be legitimate. They might alter the proposal, or they could explain why, in their opinion, changes are not necessary.

After a reasonable amount of time and discussion, the committee might choose to "approve" or "deny" an RfC. A denial would indicate that there is a strong sense that the technical community believes that this RfC would be problematic or harmful, and that the proposer is unwilling or unable to make changes that would solve the concerns. This is a strong action, and should not be taken lightly by the committee.

Approving an RfC indicates that any concerns raised by the technical community have been acknowledged and addressed in some way. Members of the committee might personally disagree with the proposal, or harbor concerns. But their role is to reflect the consensus of the broader technical community. Approval of an RfC is indicated by adding the "ArchCom-approved" tag to the phabricator task.

'''TBD: What is the consequence after an RfC has been approved? What is the proposer now able to do that they were not able to do without that approval?'''

Discussions about strategic/high-priority projects
This has mostly been ad-hoc. To bring it into the normal process, the RfC process documentation should be changed to make it clear that no idea is too large or audacious to be an RfC. Instead of discussing massive possible changes in unstructured ways, those ideas could be turned into an RfC, and then discussed through the normal RfC process. It's possible that a massive RfC might end up spinning off multiple smaller RfCs, as tangible steps to work toward the overarching goal.

Proposal: Update the RfC documentation to explicitly allow/encourage RfCs that cover large, strategic proposals.

RfC process
Any major change to a process or technical direction should go through an RfC process, to ensure that the relevant stakeholders have had a chance to give input. After comments have been received and addressed, ArchCom would determine whether it has sufficient consensus to proceed to implementation. Note that different levels of consensus might be required for different proposals, based on size, risk, etc.

History
Prior to the RfC process, proposals would be emailed to wikitech-l, and discussion would happen there. A lack of discussion might be interpreted by some as an indication of consensus. This was formalized as the Requests for comment/Process, which directs the discussion to wiki pages and/or Phabricator tasks. See also Requests for comment.

Details
Anyone can draft an RfC. It must have an associated phab task, and will often have an associated wiki page. The phab task enters the ArchCom process by being added to the #ArchCom-RfC phab project. Tasks start in the Inbox column, where they can be triaged by RobLa or someone else in ArchCom.

An RfC generally goes through the following states: NOTE: It would be great to have a diagram showing the possible state changes
 * Needs triage
 * Not ready for ArchCom to consider
 * Needs an ArchCom shepherd
 * Only for “important” RfC’s; others could go straight to backlog
 * Backlog
 * Don’t even have a plan for a plan yet.
 * Might not have a shepherd if it’s not needed
 * In progress/on track
 * No consensus yet
 * ArchCom has said “the idea sounds good”
 * Developer is working (e.g. on a prototype) to help frame discussion or build consensus
 * Doesn’t need discussion; “maybe check back in 3 months”
 * Under discussion (via phab comments or other channels?) (“Needs Discussion”)
 * No consensus yet
 * RFC meeting might accelerate it
 * Ready for interactive RFC meeting (weekly on IRC)
 * Final comment
 * Approved

ArchCom shepherds
Each RfC is assigned a member of ArchCom to act as its “shepherd” The shepherd:
 * From https://phabricator.wikimedia.org/T125865 :
 * Makes sure that stakeholders are informed.
 * Guides the discussion.
 * Once the discussion plateaus or stalls & in coordination with the RFC author(s), announces and widely publicizes a "Final Comment Period", which is one week.
 * Acts as the single point of contact within ArchCom for communication about this RfC
 * (other shepherd responsibilities?)

Columns in #ArchCom-RfC

 * Backlog (blocked or draft)
 * Inbox
 * Needs shepherd
 * Under discussion
 * Ready for RFC meeting
 * Final comment
 * ArchCom Approved

Other related projects/workboards
#Architecture - No longer actively monitored. Candidate to be deleted?

#ArchCom - Unclear purpose. Probably need to update the phab project description.