@Qgil: could you lead this area? More on this in a bit...

Yes, my pleasure. Thank you!

I think we can add this question for this group to grapple with: "what tools can/should we introduce (or remove) to make quality contribution easy, and make it easy/automatic to counteract negative contribution?" This is a question I derived from an early description of the "Functionality" area, which was an old catch-all from 2014 that we used in earlier drafts of the 2016 plan. I would love to enlist help from Community-Tech making the Collaboration sessions at WikiDev '16 really useful (and offer them the opportunity to use this event to achieve their goals).

Other proposals which might interest this working group:

• T112984: Real Time Collaborative Editing has a significant "working together" component, obviously. In particular, it would be nice to get early involvement from Community-Tech to envision how real-time contributions should work, and what existing features (say, WikiProjects) can be used to help organize real-time sessions.
• T113004: Make it easy to fork, branch, and merge pages (or more) seems to contemplate (in some incarnations) using code-review-style fork/merge processes for article editing. Perhaps best practices from code review could help inform the UX for article fork/merge.

Are we talking about collaboration between developers only (MediaWiki governance, code review, code of conduct...) or also about collaboration between editors in Wikimedia content projects (real-time editing, WikiProjects...)?

In T119030#1824614, @Qgil wrote:

Are we talking about collaboration between developers only (MediaWiki governance, code review, code of conduct...) or also about collaboration between editors in Wikimedia content projects (real-time editing, WikiProjects...)?

Good question. I think it's fair to limit the scope of this question to be one of "collaboration on source code", where "source code" can still be pretty broadly defined, but I would recommend stopping somewhere well short of "the prose of a typical Wikipedia article". So, in answer to your question, I'd recommend something closer to "developers only" than to an "all things collaboration" definition. The answer in drawing the line may be to clarify the bolded words in the question "how do we scale editing our code up to populations similar to editing our projects, proportionally increasing our positive impact and productivity?"

No matter how you slice it, there will be a "grey zone". Gadgets and templates seem to live near the border, to me.

In answer to @cscott, I think T112984 and T113004 both seem to be most clearly trying to answer the question "how do we make accessing and distributing our data easier and more useful?", and thus fit much more clearly with T119029: WikiDev 16 working area: Content access and APIs than they do with this area.

In T119032#1846945, @RobLa-WMF wrote:

My original statement of [the central question in T119032] was an attempt to state that concisely, but it could use some wordsmithing. I'd like to make sure that we define this concisely, as well as to make the problem distinct from T119030: WikiDev 16 working area: Collaboration. I see T119030 as more focused on the social side of the equation, whereas this area (T119032) is more about the technical side. To use a playground metaphor, I see T119030 as about making sure the kids on the playground are able to have fun without worrying about fights, predators, criminals, unfair playmates, unfair/negligent parents, etc, whereas T119032 is about whether the playground equipment is well maintained, works well, is the best equipment for the space, and is safe and fun.

I go into more detail about the difference between this area and the "Software Engineering" area in T119032#1846945.

It's not necessary for us to have an impermeable dividing wall between areas, and in fact there are proposals such as T114320 that seem pretty cozy in both. That said, it strikes me that T115762: Shadow namespaces at the 2016 Wikimedia Developer Summit is largely a software engineering problem that people in this area are interested in making sure that it "gets solved" but may be less interested in participating in the process of solving. It clearly helps in answering the question "how do we scale editing our code up to populations similar to editing our projects, proportionally increasing our positive impact and productivity?", but is that the best statement of the central question? I would like to have central questions for "Software Engineering" and "Collaboration" that help distinguish the two.

In reference to T115762: Shadow namespaces at the 2016 Wikimedia Developer Summit, from a Collaboration point of view the ultimate goal is "To concentrate the development and distribution of all templates/modules and gadgets at mediawiki.org, together with the rest of the developer community and resources." It is a social goal (an integrated developer community) with clear implications in software quality (a centralized infrastructure allows for better review and quality of the software developed here and deployed elsewhere).

Developer Relations, Community Liaisons, and Community Tech can help describing the current problems and defining an ideal scenario. However, at least myself I have no clue how I can help with the technical implementation that will get us there. If #legoktm says shadow namespaces is the way, I have little to say other than trust him and try to help on the sides. Even for the average template/module/gadget developers the MediaWiki backen discussion and work falls too apart from their skillset? Meanwhile, those focusing on MediaWiki core keep being dragged by the consequences of higher product priorities.

I really want to be useful breaking this loop, I really will! I have no doubt that centralizing the development and distribution of gadgets/templates/modules will have a huge beneficial impact among the editors having to deal with the current mess and also among our developer community, thirsty of the kind of fresh developer blood that gadgets, templates, bots, and tools still get.

Great, thanks @Qgil, that's really helpful. As you said in another comment elsewhere, we probably shouldn't get too worried about making sure we have mutually exclusive, collectively exhaustive areas, and instead focus on making sure we have the right sessions.

In my mind, the idea of "areas" is becoming more clear. An area is the motivating purpose that is likely to draw a respectful and constructive coalition together. Individuals may believe equally passionately about the motivating purpose of multiple areas (coalitions), and thus may consider themselves to be members of multiple coalitions.

By owning this task/area, Quim is leading it. His responsibility is building the priority list for this area. Quim, do you have everything you need to build an ordered list for this area (to use a political metaphor, to build this party's slate)? Is the formation of this list clear enough to everyone aligned with the core question?

The request for T89907: Discuss and approve a MediaWiki developer community governance model kicked off a year ago and I really haven't heard much about it since. This topic to me seems to be key for collaboration as it should in some sense describe the system in which we as a developer community collaborate to make decisions about the software platform.

T113490: 10 tips for communicating with communities when developing software would be great to have for the Wikimedia Foundation staff in attendance. This would seem to be especially useful for the Product Managers and team leads/managers who tend to drive timelines and planning for new features.

I think it will be hard to make a lot of progress on T114419: Event on "Make code review not suck" in a meeting format but would be glad to be proven wrong. Personally I think most of the problems here are related to resourcing and lack of confident reviewers. T114320: Code-review migration to Differential status/discussion promises some tools that may help in some areas but will likely come with some challenges that hurt in others. This topic should almost certainly be discussed so we can find out who is most worried about the challenges and start finding concrete methods for ameliorating those concerns.

This is what I plan to propose at T119593: Define the list of "must have" sessions for WikiDev '16 (unless someone posts better ideas here quickly):

Recommended for pre-schedule

1. T114419: Event on "Make code review not suck": a very important discussion that should be combined with @Aklapper's T101686: Goal: Define potential actions to reduce code review queues and waiting times & T78768: Agree on and implement actions to prioritize code review of patches submitted by volunteers
2. T114320: Code-review migration to Differential status/discussion: this is ongoing work, there is an RfC developing, and will have a big impact in our community.

In a limbo

• T89907: Discuss and approve a MediaWiki developer community governance model: very important topic, but the discussion hasn't moved much. If @RobLa-WMF wants to push for it, I will support him
• T115762: Shadow namespaces at the 2016 Wikimedia Developer Summit: for the reasons exposed, if @Legoktm wants to push for this, I will support him.

Recommended for unconference

• {T90908: Goal: Binding code of conduct for all Wikimedia technical spaces with consequences for breaches}: even if it is a general topic, the unconference context might be more appropriate for a focused dicussion at this stage.
• T113490: 10 tips for communicating with communities when developing software: there hasn't been much discussion before the Summit, and people expressing their interest seem to want to "listen" more that be part of the effort for defining these tips. People motivated by this session could participate in the Unconference context, and then a Tech Talk could be produced with the final presentation.
• T114400: WikiBadge: very narrowed focus; people intersted can meet any time in the unconference setup.

How can we use WikiDev '16 to specifically help make more progress T115659: Collaborate on community-involved Prioritization process? Also, what level of involvement should we invite/suggest/coerce/beg from the IdeaLab folks (per current wikitech-l conversation about IdeaLab)?

Quim and I discussed the overall scheduling (see T116024#1880035) earlier today. Quim suggested that the focus for the Collaboration focused time scheduled for Tuesday, 2pm should be T114419: Event on "Make code review not suck". Quim, is that still your choice? Does everyone else agree with that choice as a "big room" topic in this area?

I went ahead pre-scheduling T114419: Event on "Make code review not suck" in the main slot for the Collaboration area, on Tuesday at 2pm: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016#Tuesday.2C_January_5

The idea is to pre-schedule T114320: Code-review migration to Differential status/discussion as well, but it is better to wait how the schedule evolves (although it will be difficult to find a spot without overlap, considering that the code review process affects basically everybody).

T121672: Present results of Community Wishlist Survey at Dev Summit is very important, and we should probably have it in the "Recommended for pre-schedule" stuff. It's admittedly a very late addition, but I think it still clears the bar for consideration of new stuff.

Quim and I discussed this area, and we think these questions would be good for the wrapup session of the summit:

• How do we recruit? How do we make building Wikimedia software deeply interesting work that people want to be part of? How do we make this summit something that more people outside of our world want to be part of?
• What's the best use of our face-to-face events? Is this annual gathering the best use of WMF time/money/resources?
• How should we better collaborate with non-tech users of our sites (readers, editors, etc)?

As of this writing, this is how we intend to kick off the wrapup/retrospective conversation on Tuesday afternoon (with Quim asking these questions). I would love for people to be thinking about these questions now, and would love to see your thoughts now. So, thoughts?

Per T124504: Transition WikiDev '16 working areas into working groups, lets figure out if this area should be a working group before closing down this area.

@Qgil: I've created an RFC calling for the creation of a "Collaboration working group". I would be very happy if you (or really, anyone else interested in this topic) took this RFC over and led in this area.

I'd like to suggest that we do the following in this area:

• Write https://www.mediawiki.org/wiki/Collaboration_guidelines similar to our Architecture guidelines as well as the performance guidelines, user experience guidelines, and security guidelines listed on that page.
• Link it into the Code of Conduct conversations
• Shepherd some of the other collaboration-oriented RFCs (e.g. T123606)
• Possibly have some sort of regular IRC office hour for this area to invite more synchronous collaboration. Not a big announced event, but just more of a low-key opportunity at an easy time for Europe (or wherever the host is) where people know they'll have the opportunity to pounce if they want a real-time answer.

That said, all of the above may be overly prescriptive. I'd just like to make sure we can scale things up for ArchCom, and these areas seemed like a useful tool to keep building with.

I have been loosely thing about the idea of having a Collaboration area and I am becoming more skeptical about its usefulness. I'd rather focus on more specialized committees created to solve a specific problem and formed by people that are clearly the experts in that scope. These committtees could be temporary or permanent, depending on their goal.

For instance, a committee to solve the code review problem (temporary) or a committee to maintain and enforce the Code of Conduct.

In T119030#2014769, @Qgil wrote:

I'd rather focus on more specialized committees created to solve a specific problem and formed by people that are clearly the experts in that scope. These committtees could be temporary or permanent, depending on their goal.

+1, I was thinking the same for the Software Engineering area/group.