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. For WikiDev16, we hope it 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 &quot;gatherings of the tribes&quot; 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”
"The initial version of this section is based pretty closely on the 'RfC cluster' structure of the 2014 meeting, and borrows a lot of structure and wording from it."

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”.

Backend internals
Stakeholders: TechOps, Readers, Editors (anyone helping improve our performance, privacy, security, and stability of Wikimedia software)

Areas of focus: Configuration, debugging, storage services, linking, media backend, parsing architecture and iterative improvements, backend efficiency, database use

APIs/Interfaces/Protocols
Stakeholders: Developers wanting to build applications with access to Wikimedia-hosted data, Tool labs, Wikidata

Areas of focus: Action API, RESTBase, CentralNotice, HTML templating, metadata, data presentation (e.g. mobile frontend), parsed output access, SOA, thumbnail access and storage, Wikidata/Wikimedia-site integrations

User interface presentation
Stakeholders: Readers (usability), Editors (usability)

Areas of focus: styling, interface responsiveness, media presentation, skins

Software management
Stakeholders: Developers wanting to build dev/test instances, non-Wikimedia MW maintainers

Areas of focus: software management, assembling backend code modules (e.g. Composer), installing MediaWiki and supporting components, release strategy (e.g. performing updates and impact on dev work), how outside open source gets used on Wikimedia infrastructure, and if/how it gets distributed from Wikimedia (e.g. as part of MediaWiki tarballs).

Functionality
Stakeholders: Curators/Moderators, Editors, Readers

Areas of focus: improving user experience through increasing productivity and/or increasing joy in using our software. Improving our site by making quality contribution easy, and making it easy/automatic to counteract negative contribution. Making it easier to learn how to use our sites.