Page MenuHomePhabricator

Documenting thoughts on uptake of community software experiments
Closed, DeclinedPublic


@Quiddity and @Qgil casually responded in an email thread about "What does a pipeline for community software experiments look like?", and the answers were interesting. They could constitute the beginning of a draft in about this topic. No specific plan at the moment, but let's just not lose those thoughts in those emails.

The quite raw replies:

I wonder whether our discussions about community/distributed innovation would benefit from some technical background to understand how "distributed innovation" actually works in Wikimedia, and how we could improve it. I'm saying this because nowadays a lot of that innovation doesn't "get into trunk", and getting into trunk happens quite often without any WMF Product involvement at all. Meanwhile, when a developer does want to get something into trunk following the processes defined by the WMF, chances are that they will get stuck in under-resourced queues.

Usually everything starts with a gadget, a template, a bot, or a tool scratching someone's itch. These are pieces of software that a single developer can write and deploy without needing any review or permissions.

Usually the next step is promotion in the channels of the project(s) where the piece of software is being deployed. For many developers this step takes more effort and is more likely to fail than actually writing the piece of software.

In some cases, adoption will eventually arrive (might take months, or years). In some cases, when the curve of adoption really hits, the original author is long gone, posing a problem of maintenance...

The community-originated software projects that reach a point of popularity and want to enter a consolidation phase, face then a hard problem:

Our team is in a good position to help discovering interesting community innovations, and helping them on basic improvements of quality, promotion, and definition of a long term plan. However, there is so much we can do if WMF Product and Technology doesn't provide a better infrastructure for community innovation (a centralized catalog to discover and host gadgets, templates, bots, tools is basically the required start), and a percentage of their resources to help productizing those innovations that need to "get into trunk" in order to flourish.


See also/especially T71445: Implement a sane code-review process for MediaWiki JS/CSS pages on Wikimedia sites wherein the developers are discussing a code-review system for gadgets
Plus T31272: Implement Gadgets 2.0

The other problem here, is that moving onwiki-tools into extensions/core, makes it a lot harder for most of the gadget/script/bot authors to actively help with it (because git/gerrit is more complicated than just editing a wikipage), and also for everyone (dev and non-dev) to keep track of changes (because then it is no longer built into their usual watchlist workflow).

Additionally, when a gadget is converted into an extension with an expectation of greater scaling/performance, it might need to be rewritten entirely, and possibly in a different language (eg. javascript into php). This further complicates the original authors participating. E.g. hotcat would basically need to be rewritten entirely, in order to be turned into an extension, according to one dev.

Event Timeline

Qgil raised the priority of this task from to Needs Triage.
Qgil updated the task description. (Show Details)
Qgil added subscribers: Qgil, Quiddity.

What are "community software experiments"?

Whenever someone starts writing a gadget / template / bot / tool that may end up being interesting as a fully fledged featured deployed in all Wikimedia projects one day. The path from A to B is complex by nature, but there are many additional difficulties that maybe we could alleviate, and for that the first step would be to document them.

I'm so tempted to throw my whiteboarded workflow in here, but I think we've moved beyond that by now (email backlog!) - though do let me know if I should.

I'm so tempted to throw my whiteboarded workflow in here, but I think we've moved beyond that by now (email backlog!) - though do let me know if I should.

@Rdicerb: Can't hurt if it allowed me to better understand the scope of this task? :)

Qgil triaged this task as Low priority.
Qgil set Security to None.

"Idea" is a suggestion, "support" is less the action of support and more the idea *has* support. As mentioned, extremely rough.

Qgil raised the priority of this task from Low to Medium.Nov 11 2015, 2:34 PM

Well, at least the essence of these emails is now in the description of this task, hence I'm not blocking it.

Meanwhile we have been discussing about the WMF product development process, also as a way to structure topics like this one and set their priority. We are currently working on T124022: Goal: Clarify community engagement in WMF product development process and the Concept stage.

This task is about community engagement, and it has an interesting mixture of Concept and Maintenance stages.

I have been kicking this can down the road for some months, and I still don't know what exactly to do with it. i have linked it to T131689: Second iteration of the Technical Collaboration strategy not to forget completely about it, but I don't see which useful action can I take right now.

The problems defined in the description are known by the people or groups that have the skills or responsibility to do something about them. Most of these topics are low priority nowadays. Including Technical Collaboration, a team that currently is focusing our developer relations efforts in relation to the Community Wishlist as a way to try to help some developers getting through these problems.

According to the WMF Annual Plan draft, we should see some progress in areas like Wikimedia Labs and our collaboration infrastructure, see

I think this is it for this task. I'm closing it as... Declined.