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.