User:KSmith (WMF)/ArchCom thoughts

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

For some stray notes about the existing process, see: User:KSmith (WMF)/ArchCom thoughts/Stray notes

Existing material
Architecture committee

Architecture committee/Team practices

Architecture meetings

Consensus

Requests for comment/Process

Essential duties
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: Robla should 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 (or deny) RfCs
The primary goal of the RfC process is to ensure that any major change has been documented and thought through, and has benefited from feedback and review by relevant and interested parties. In a sense, the process serves as a form of "whim dampener", increasing the odds that major changes are likely to remain good ideas for some years after they are implemented.

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 as powerful members of some committee. 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 treat concerns as legitimate, and address them. They might alter the proposal, or they could explain why, in their opinion, changes are not necessary. If an RfC is changed in significant ways, it should be subjected to another round of community review, in its new form. Legitimate responses to feedback could include "we disagree that  will be a problem", or "yes,  is a possibility, but we are willing to accept the risk".

After a reasonable amount of time and discussion, the committee might "approve" or "deny" an RfC.

Approval of 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. Developers who try proceed with a major change that has not been approved through the RfC process are likely to face questions and resistance.

Denial is a strong action, which the committee should not take lightly. It indicates that: Approval or denial is based on "consensus" of the committee members. The exact threshold for this consensus is not defined, and may vary depending on the scope and risk of the RfC in question. Again, this is not based on how the members themselves feel about the proposal, but rather on their interpretation of how the broader technical community feels.
 * 1) The technical community has serious concerns that this RfC would be problematic or harmful, AND
 * 2) The proposer appears to be unwilling or unable to make changes that would solve the concerns.

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: Robla should update the RfC documentation to explicitly allow/encourage RfCs that cover large, strategic proposals.

Document and maintain the documentation of the RfC process
The documentation is probably "good enough" to survive with minimal ad-hoc updates.

Groom the RfC-related phabricator workboards
This could be done by the chair, or could be done by multiple committee members in a meeting. Theoretically it could be done asynchronously by committee members, but that runs the significant risk of it being neglected.

Keep the RfC-related phabricator tasks/workboards updated
In theory, each shepherd should keep their own tasks updated. The chair could watch for issues and make asynchronous changes, suggestions, or requests. Having a regular meeting would reduce the workload on the chair, and reduce the risk of neglect.

Organize IRC discussions about RfCs, and posting the results
The IRC discussion itself is fine as a standing meeting. However, related duties need an owner:
 * Select a topic for each upcoming meeting (and ensure any RfC owner and/or shepherd can attend)
 * This would best be done based on committee discussion, either in a meeting or asynchronously
 * Topics should be selected at least a week in advance
 * Email public notice of each upcoming meeting, including the topic
 * Meetings should be announced at least X days in advance
 * Choose a moderator for each meeting
 * The moderator should be responsible for posting the results right after the meeting ends

Approve (or deny) RfCs
The shepherd for an RfC is responsible for determining when the committee should consider approving (or denying) an RfC. Can the actual approval/denial happen asynchronously, or is a meeting required?

Discussions about ArchCom itself
The committee should probably meet regularly, even if just to discuss its own internal business and to work on continual improvement. Regular retrospectives (quarterly or every 6 months) would probably be helpful. Due to timezone issues, it might be worth experimenting with asynchronous retrospectives.

Technical discussions about RfCs
Presumably most technical conversations could happen on the associated phab task, or in IRC meetings, or on a public mailing list. Some small conversations between just a couple members could happen in private email or IRC. What kinds of conversations would need to happen at the committee level (including the whole committee, but excluding anyone outside, including RfC owners)?