Wikimedia Technical Committee/Processes
This page is currently a draft.
More information and discussion about changes to this draft may be on the discussion page.
This page (once finished) should document of the on-going responsibilities of Technical Committee members (e.g. routines and habits). This page was originally created as the result of an audit of existing practices, tracked as T125218.
Members of TechCom should budget roughly 20% of their time fulfilling architectural leadership goals. Furthermore, the team often relies on facilitation help from non-members.
Document and maintain the documentation of the RfC process
The chair is responsible for ensuring that the workboards are groomed. This includes triaging incoming RfCs, watching for tasks that end up in the wrong column or get stalled for too long, etc. The chair doesn't need to do all the work, and in fact every committee member should feel some responsibility. The chair should decide how much of the grooming to do alone, and what methods or channels to use to get help and support (e.g. regular meetings, emails, etc.).
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)?
Each shepherd is responsible for keeping their own tasks updated, which includes ensuring they are in the correct column on each workboard. The chair should watch for problems, and make asynchronous changes, suggestions, or requests. The chair should decide whether to require a status checkin during a regular meeting, or to use other processes.
Shepherds should liberally use the "needs work" status, to ensure that they are only responsible for taking action on a small number of RfCs at any point in time. Shepherds are also free to delegate task-related activities to others outside the committee, but the shepherd remains ultimately responsible for the RfC's movement through the process.
Shepherd duties (Work in progress!)
- Contact authors of RFCs to triage and ask them if they want a meeting
- Propose working groups?
- Contact people on older RFCs to see if they can move forward?
Organize IRC discussions about RfCs, and posting the results
Time: Every Wednesday from 2pm -3pm Pacific
Note: The meeting is time boxed. Interaction and discussion are more valuable than task processing.
Select a topic for each upcoming meeting (and ensure any RfC owner and/or shepherd can attend)
- The chair is responsible for ensuring that the committee chooses a topic at least a week in advance
- This should be based on committee discussion and consensus
- The chair can decide whether to use a meeting or asynchronous communications
As of this writing in 2016, TechCom typically prefers to have office hours center around a chosen topic, announced during the days prior to the meeting. The Good meetings page describes the meeting types (under "Taxonomy"), which TechCom tries to use to classify which meeting type the upcoming meeting is anticipated to be (typically "problem definition", "field narrowing" or "consensus").
When TechCom can't agree on a topic, then a triage meeting for the TechCom-RFC board is a common fallback. The goal is to quickly discuss each RFC, prioritizing tasks and placing them in the appropriate column (typically: "Needs Shepherd", "Under discussion" or "Ready for RFC Meeting"). The agenda:
- All attendees join the "#wikimedia-office" chat in IRC. Meeting chair starts the meeting.
- The meeting chair pulls tasks from the upcoming event in Phabricator for discussion and posts tasks in the chat.
- Attendees discuss details.
- The task should be handled so that it is either: Set to "Stalled", assigned, moved to the correct column (or any combination of these)
Related tasks and responsibilities
- Choose a moderator for each meeting
- The chair is responsible for finding a volunteer, assigning someone, or being the moderator
- Post upcoming agenda to upcoming Phab event
- Closer to the date, announce the RFC meeting agenda on wikitech-l
- The moderator is responsible for announcing the meeting (on [wikitech-l])
- Meetings should be announced at least X days in advance
- Post IRC minutes to Phab event
- The moderator is responsible for posting the results right after the meeting ends (or delegating that task)
- Extra credit: post full minutes in Phab Paste
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?
This seems to be important for cohesion and momentum. While many of the essential duties could be performed asynchronously, having regular time together has intrinsic value. In addition, several of the processes are more efficient and/or more likely to be done during a recurring meeting.
TechCom holds a private weekly meeting to plan community activity. The goal is to help provide clear, collaborative and timely counsel on architectural decisions. To do this, TechCom attempts to process the latest RFCs and review anything that has been overlooked, reviewing relevant Phab tickets (mainly on the TechCom-RFC board as of this writing in 2016). Attendance is private, but everyone is invited to add items to the agenda for the next meeting (additions from outside of TechCom are suggestions which TechCom members may decline).
Meeting chair copies committee meeting minutes from Google Docs to mediawiki.org.
Committee members need to know how to broadcast updates to each other, how (where) to ask each other questions, and where to post or read status reports not specific to individual RfCs. (Updates about RfCs should go on that RfC's wiki page or phab task.) Email, a conpherence in phabricator, and IRC are all valid channels, but the group should have norms about responsiveness.
Discussions about TechCom itself
This includes discussions about internal business (e.g. membership, meeting schedules), 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.