Wikimedia Developer Summit/2016/Scope

As stated in the Wikimedia Developer Summit 2016 introduction, we welcome developers and other technical contributors of MediaWiki core, extensions, gadgets, templates, bots, Wikimedia apps and tools, and third party products relying on Wikimedia APIs. This page attempts to enumerate and organize the areas of focus to collaboratively build a productive and fulfilling event. As of this writing in September 2015, this probably doesn't represent an exhaustive enumeration of all focus areas, and editing/commenting is welcome.

There is a lot of work we need to do before the Developer Summit to make sure that it’s successful. We want to use this as an opportunity to agree on Wikimedia's software development goals, and clarify our collective direction (for everyone committing code hosted on Wikimedia's development infrastructure, not just Wikimedia Foundation).

Good engineering meetings

Below is a taxonomy 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. We hope WikiDev16 will 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.

RobLa has further defined this taxonomy in User:RobLa-WMF/Meetings

Learning from the IETF

We can 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 Areas

Link: WikiDev16 § Areas

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 ArchCom) 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 ArchCom process lacks explicit balance of specialization and interest, whereas the IETF has the concept of “areas”.

ArchCom is trying to address this now. As of this writing, there are a number of working areas for collaboration at WikiDev '16:

• Content format (T119022) - This is about the format of our data, with a primary emphasis on the future of Wikitext & markup (or possibly, the future of eliminating it). The central problem in this area: "how do we make manipulating our data easier and more useful" (both for humans and computers)
• Content access and APIs (T119029) - this is about getting our data in-and-out of the system (e.g. rest.wikimedia.org). The central problem in this area: "how do we make accessing and distributing our data easier and more useful?"
• Collaboration (T119030) - this is about how we work together. Central problem: "how do we scale editing our code up to populations similar to editing our projects, proportionally increasing our positive impact and productivity?"
• Software engineering (T119032) - this is about building and delivering high quality code. Central problem: "how do we build high-quality software that we can dramatically increase the number of people that can understand it while increasing the reliability and maintainability of Wikimedia sites?"
• User interface presentation (T119162) - improving our user interactions. Central problem: "how to we make our software look and feel joyful to use?"

These are, of course, overlapping concerns. We may end up having Phab projects for each of these working areas, assigning each WikiDev '16 proposal to one primary area. For some proposals, it may be good to put them in multiple projects, but let's try to resist that urge.