User:RobLa-WMF/WikiDev16
 | This page is currently a draft.
|
We’re in the midst of planning out the Wikimedia Developer Summit 2016 in January. This is being tracked in Phabricator task T104346: Goal: Define Wikimedia Developer Summit 2016. Rachel Farrand is leading the planning effort, and I’m planning out what the architecture-related bits should be (which, if I get my way, is everything!….bwahahahaha) :-) I’ve been thinking a lot about how we use these opportunities to set our software development goals, and clarify our direction.
I think there is a lot of work we need to do before the Developer Summit to make sure that it’s successful. Modernizing our software is going to take a lot of work, so let’s not squander this opportunity. Let’s figure out the most productive way to use this meeting to get 2016 off to a really positive start.
Good engineering meetings
[edit]Below is the taxonomy I've been thinking of for good consensus-oriented engineering meetings.
- Problem-solving - Discuss a problem that we don’t know how to solve (and decide if it's even a problem)
- Strawman - Talk in depth about an engineering idea that doesn’t have consensus
- Field narrowing - Narrow down choices for solving a problem
- Consensus - Arrive at tentative consensus about the best solution to a problem
- Education - teaching people about an idea that already has consensus and/or is already in widespread production use
This taxonomy works well for consensus-oriented meetings between engineering peers (possibly from different employers) rather than WMF-controlled meetings. In this model, let's shoot for WikiDev16 to be dominated by "problem-solving", "field narrowing" and "consensus" meetings, with the other types of meeting happening asynchronously (e.g. mailing lists, video tutorials) and/or remotely via video call.
Learning from the IETF
[edit]We should probably learn from the Internet Engineering Task Force (IETF), where many contentious issues of software design are discussed in a very open way. Here’s how The Tao of the IETF describes their format:
The computer industry is rife with conferences, seminars, expositions, and all manner of other kinds of meetings. IETF face-to-face meetings are nothing like these. The meetings, held three times a year, are week-long "gatherings of the tribes" whose primary goal is to reinvigorate the [working groups] to get their tasks done, and whose secondary goal is to promote a fair amount of mixing between the [working groups] and the [working group areas].
IETF meetings are a cacophony of activity, covering pretty much every area of Internet interoperability. Their scope is enormous, and their work is still relevant. IETF meetings keep the “conversations for education” on the periphery of the scheduled time. I’ve put in a request (T111306) to purposefully scout the next IETF meeting to give us more knowledge of their process.
Working Groups and “Areas”
[edit]If we adopt elements of the IETF model, we have bits and pieces we can map onto their process. We have (with the Architecture Committee, aka ArchComm) something somewhat akin to the IETF’s Internet Engineering Steering Group (IESG). Our process for picking the membership of the Architecture Committee isn’t nearly as formal as the IETF, which is probably a good thing. That said, our current ArchComm process lacks explicit balance of specialization and interest, whereas the IETF has the concept of “areas”.
RfC taxonomy
[edit]Stas recommended splitting the RfCs into these categories:
- immediately actionable (task T486)
- big tasks (task T88666)
- architecture guidelines (task T384)
My sessions
[edit]I'll put something here if/when I submit a session of my own. Probably "when" rather than "if", but I'm not going to make something up right this instant. Just linking to this from the WikiDev 16 registration form, when I registered for Wikimedia Developer Summit 2016, aka WikiDev 16.
My main focus at WikiDev16 will likely be in helping others succeed with their sessions, rather than running anything of my own.