The areas defined here cover a lot of stuff, but they don't cover a lot of the work done by the Front-end-Standards-Group. Let's figure out how to reconcile that; we clearly want to talk about items important to that group at Wikimedia-Developer-Summit-2016

I like this idea a lot! Thank you very much for proposing it.

These four areas are simple to recognize and their relevance is almost self-evident.

We could have a fifth area "Specialists", used to organize the "other" sessions. If some owners of 'specialist' sessions see a possibility to organize a new area, we could create a new one.

If each area has an owner, it would be good that these owners are the people in charge of deciding what to do with proposals without enough definition or discussion. Currently it looks like it is the ArchCom, Robla, or myself who is deciding, but I would rather prefer to let each area organize themselves.

We still would need to think how to address the "other" / Specialists proposals if there is no direct owner there, but at least the four areas proposed would comprise most of the submitted proposals.

@Qgil: I like the idea of having a place where specialists feel at home. So much so that my initial reaction was "sure, I'll add it, and then I'll declare 'done!'". Now, if you don't mind, let me overthink it a little bit :-)

I started to create the central question for "specialists", which made me think through some of the same thoughts I had when suggesting things for our post describing the Composer effort. A lot of the Composer-related proposals are filed under T119032 (software engineering), but the messaging in that blog post seems pretty squarely in the mandate of T119030 (collaboration).

So, I'm now thinking that "specialists" should be part of "collaboration". Thoughts?

Here's some text I'm probably going to nuke from the WikiDev16/Areas section on mediawiki.org:

''The initial version of this section is based pretty closely on the [[Architecture Summit 2014/RFC clusters|"RfC cluster" structure of the 2014 meeting]], and borrows a lot of structure and wording from it.''

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.

I posted on wikitech-l, but I'll recap here: I'm a little concerned about putting "user interface presentation" off to the side; there's a design component involved in a lot of proposals that are "mostly" in some other area, for example (just listing some I'm directly involved with):

• T112984: Real Time Collaborative Editing
• T112991: Semantic image styles / beautiful layout
• T113004: Make it easy to fork, branch, and merge pages (or more)
• T114454: [RFC] Visual Templates: Authoring templates with Visual Editor

And reading the comments above, it seems that there are similar issues with other overlaps, like for the composer efforts.

I'd like to suggest that instead of restricting ourselves to "one working group per proposal", we might instead tag a "primary" working group *and in addition* as many secondary working groups as necessary (although realistically one would hope there would be 0-2 secondary working groups).

This will also help later on during scheduling, so we don't inadvertently occupy all the designers in some important "user interface" track at the same time we're discussing (say) T112984: Real Time Collaborative Editing, which really needs a lot of design input.

The primary working group would be in charge of proposal selection, guidance, development, and scheduling; the secondary working groups would be present to "deconflict" and ensure group participation when necessary.

I have created columns for the four undisputed areas at Wikimedia-Developer-Summit-2016 and I have pulled there the tasks about Collaboration (the track I accepted to coordinate). We can pull undisputed tasks to undisputed columns, and then decide the next steps based on which tasks still need to be classified.

In T119018#1820795, @cscott wrote:

I'd like to suggest that instead of restricting ourselves to "one working group per proposal", we might instead tag a "primary" working group *and in addition* as many secondary working groups as necessary (although realistically one would hope there would be 0-2 secondary working groups).
[..]
The primary working group would be in charge of proposal selection, guidance, development, and scheduling; the secondary working groups would be present to "deconflict" and ensure group participation when necessary.

This sounds like a good compromise, and I think your gut feel is about right. For each proposal, we should have champions from one working area emphasizing the importance of the conversation, and we should consider the collaboration of the secondary working areas. "Consider" being the key word here; the more we try to put in parallel, the less flexibility we'll have in allowing for broad participation in a topic.

@cscott proposed the working group idea back in September:

In T96903#1659718, @cscott wrote:

In the interests of advancing concrete discussion, let me propose four concrete "user-focused" architectural challenges:
[four suggestions follow, not too different from what ended up in this task]
I would love to see architectural working groups formed around top-down challenges such as these, incorporating not only developers but also UX designers and community members, charged with writing and coordinating specific low-level tasks/RFCs necessary to address the challenge. The top-level architectural committee work can decide on top-level tasks (such as "social wiki"), set up the working groups for each, and then audit the results and ensure coordination on points of overlap. For example, if multiple working groups would benefit from (say) storage backend refactoring, then the top-level architecture committee can identify and prioritize that subtask and coordinate the work so that the result will satisfy all potential users.

This makes me wonder if we should have working area sessions that aren't necessarily tied to a particular proposal. I don't think the working areas should be "in charge" of their areas so much as coordinating the discussion/consensus around particular areas. Let's use the subtasks of this one to discuss these areas in more detail.