Working groups/areas for macro-organization of RfCs for the summit
Closed, ResolvedPublic

Description

Here's a possible division of our list of proposals into "working groups" or "working areas" that we are using to organize our tradeoff decisions about the WikiDev '16 summit

  • 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 make software development more logical and obvious for all Wikimedia contributors, while simultaneously making Wikimedia software more useful and reliable for the Wikimedia sites?"
  • User interface presentation (T119162) - improving our user interactions. Central problem: "How to we make our software beautiful and joyful to use?"

These are, of course, overlapping concerns. We have tasks for each of these working areas, which we assigned each WikiDev '16 proposal to a working area. As we've figured out the distinctions between the various areas, we have asked area owners to consider proposals we previously added outside of their original assignments.

These working areas may persist beyond WikiDev '16. Working groups may form in each of these areas.

Related Objects

Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptNov 19 2015, 12:20 AM
RobLa-WMF set Security to None.

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

Qgil added a subscriber: Qgil.Nov 19 2015, 9:48 AM

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.

Qgil added a comment.Nov 19 2015, 10:43 AM

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.

This comment was removed by Aklapper.
cscott added a subscriber: cscott.Nov 20 2015, 4:39 PM

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):

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.

bd808 added a subscriber: bd808.Nov 20 2015, 5:20 PM
Qgil added a comment.EditedNov 23 2015, 9:39 AM

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.

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

Qgil triaged this task as "High" priority.Dec 11 2015, 8:13 AM
Qgil closed this task as "Resolved".