Page MenuHomePhabricator

WikiDev 16 working area: Collaboration
Closed, DeclinedPublic

Description

This is a potential area for work at Wikimedia-Developer-Summit-2016. "Collaboration" 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?

Main session in Robertson 1: Make code review not suck

Currently scheduled for Tuesday, January 5 at 2pm PST. Check the official schedule to confirm.

T114419: Event on "Make code review not suck": a very important discussion 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

Goals for the session (copied from T114419)

  • We have a number of ideas on how to fix the problem
  • While we may not have decided which idea to implement, people come away from the meeting feeling that at least one of the ideas would fix things, and that there is hope for a brighter tomorrow.
  • A summary of the ideas is presented to wikitech-l for further evaluation, in the hopes that the wikitech-l discussion will narrow down the choices to the best ones.

Plenary wrapup session: Tuesday, 3:40pm

Recommended for breakout scheduling

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

Recommended for unconference

In a limbo

Other working areas (and the meta conversations about the idea of working areas) can/should be found here: T119018: Working groups/areas for macro-organization of RfCs for the summit

Related Objects

Event Timeline

RobLa-WMF claimed this task.
RobLa-WMF raised the priority of this task from to Needs Triage.
RobLa-WMF updated the task description. (Show Details)

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

RobLa-WMF set Security to None.
Qgil added a comment.Nov 19 2015, 9:51 AM

Yes, my pleasure. Thank you!

Qgil triaged this task as Normal priority.Nov 19 2015, 9:52 AM
Qgil added a project: DevRel-December-2015.

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

cscott added a subscriber: cscott.Nov 20 2015, 4:55 PM

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.
Qgil added a comment.Nov 23 2015, 10:00 AM

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

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.

Qgil updated the task description. (Show Details)Nov 27 2015, 8:38 AM
Krenair added a subscriber: Krenair.Dec 1 2015, 5:38 PM
Qgil moved this task from Backlog to Doing on the DevRel-December-2015 board.Dec 3 2015, 12:32 PM

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?

bd808 added a comment.Dec 4 2015, 5:18 PM

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

Recommended for unconference

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

Qgil raised the priority of this task from Normal to High.Dec 9 2015, 2:18 PM

@RobLa-WMF, currently I'm focusing in clarifying which of the existing session proposals will be pre-scheduled. We will have the flexibility of the unconference setup to address other proposals, already submitted or not.

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?

Qgil updated the task description. (Show Details)Dec 16 2015, 2:16 PM
Qgil added a comment.Dec 16 2015, 2:35 PM

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.

Qgil lowered the priority of this task from High to Normal.Dec 21 2015, 10:19 AM

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.

Replied at T121672#1894370.

I also have suggested a slot for T114320: Code-review migration to Differential status/discussion. With this, the urgent activities related with the area of Collaboration are covered.

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?

Qgil closed this task as Resolved.Jan 7 2016, 4:25 AM

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.

RobLa-WMF reopened this task as Open.Jan 23 2016, 12:25 AM

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

Elitre added a subscriber: Elitre.Feb 2 2016, 3:45 PM
Qgil added a comment.Feb 10 2016, 1:56 PM

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.

greg added a comment.Feb 10 2016, 3:26 PM

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.

Qgil lowered the priority of this task from Normal to Low.Feb 11 2016, 10:28 AM

Thanks @greg. I will let this idea sink in the next weeks. If there is a sensible push to evolve this Summit Collaboration area into an TechCom related group, fine. If not, then I will consider this task Resolved by the end of this month.

Qgil removed Qgil as the assignee of this task.Feb 25 2016, 9:37 PM

I have been thinking more about this idea. I think that, in terms of priorities, it is better to put my/our time on T124021: Define the Technical Collaboration team strategy. Once we have a first complete iteration on the strategy of my team, them we will be able to decide better what is the role of my team and myself in this Collaboration group. And in the meantime, perhaps T123606: RFC: Implement ArchCom-affiliated working groups (process inspired by Rust's "subteams") and the TechCom's governance conversations in general are more settled.

I'm going to de-assign myself from this task while I focus on the Technical Collaboration team strategy. If someone else wants to take the driving seat of this Collaboration team, please be my guest. In any case it is not clear that I / my role is the best shepherd / facilitator for this group.

RobLa-WMF moved this task from Inbox to unused on the TechCom board.Mar 17 2016, 9:41 PM