Topic on Talk:WMF product development process/2015-11-05

I have added a new Q&A based on questions about how will the WMF proceed when there is no agreement with a community over a feature: What happens when there is no agreement between the WMF and a community about the deployment of a feature?

Just to be clear (and to address related comments): I'm posting this announcement and I'm updating this Q&A in the name of the Wikimedia Foundation, working closely with the Product and Community Liaison teams, and with the support of my manager Luis Villa (Senior Director of Community Engagement) and the rest of the Executive team, Lila included. As Engineering Community Manager, effective collaboration between engineering teams and our communities falls squarely within my domain.

Take MV and it's deployment as an example. The actions done by the WMF against the communities in that situation must never happen again, they were never justified:

It was developed by some programmers in the WMF and deployed to deWP as opt-out without being in beta beforehand for quite some time. So no qualified feedback was possible until it was suddenly deployed. Yes, it was somehow unbeknownst disabled in beta by an admin in deWP, but very little feedback from one of the biggest projects has to be a sign of non-paricipation of that project, and the programmers have to make sure all are proper involved.

You write on the other side Volunteers are responsible for providing feedback and shaping features early in the process, that as far correct, as those volunteers have knowledge of these projects, and it's the sole responsibility of those paid programmers in WMF to make sure every community is properly informed. It's not the responsibility of unpaid voluteers to search in meta or here for new projects, the programmers have to announce them. And without any feedback from the, let's say at least big 20 projects, it's not made public enough.

The MV was massively buggy as deployed, it was unable to deal with all licenses in a appropriate way, and the programmers obviously didn't care about proper licenses, that menial task was delegated to the volunteers, they should do the work to make this pet project of some head honchos workable. Only after the shitstorm they deigned to care about licenses an such, not just shiny surfaces.

There was never ever any need to hastily make the MV opt-out instead of opt-in, besides the vanity of some people in the WMF. The bugs and shortcomings were shown in the process of the MB, but at the start and short after completion said the completely unacceptable "We will keep it, no matter what, bugger off with your complaints".

Superprotect was implemented, to explicitely prevent community consensus to ever be implemented, it was not just some vandalism cure, it was a pure political tool. It would have been very simple, and the only valid way, to make it opt-in in deWP and enWP in a proper, non-hack way, so DaB would not have been pushed to a not that proper way. It was the duty of the well paid programmers in the WMF to implement the community consensus, not to push through with the MV.

If the tree biggest projects reject a software, it's by definition a failed project and must never be implemented as opt-out. Is that a clear premise or not?

With the initial release of VE the basic message from the community was that the product was not ready. Looking at VE now it a much faster, more stable product. It would have less of a problem were in to be made the default now. I can see that there were conflicting pressures on JF: internal pressure from within the foundation/development community to get a release out and external pressure from the editing community for a working product. There need be good top level management to ensure product developers do not develop a silo mentality.

Not enough time is spent by the people at the top on the production wikis. This is a task which cannot be delegated to community engagement people. Jimbo does engage on his talk page but I see little sign of an other people from the foundation having any contact.

Will there be any answers by the WMF in this thread? Or do go on further with your ignorance of the communities? This koind of threads are the very place to engage with "the community". Phabricator is for Nerds (and diskussions explicitely verboten). Mailing loist are for a very select group of insiders, no real community input ther. The only proper venues for diskussions are on-wiki, in the real world. Preferable not with Flow but with a prober talk page, but better so then not at all.

If the tree biggest projects reject a software, it's by definition a failed project and must never be implemented as opt-out. Is that a clear premise or not?

I don't think that is a clear premise at all. First of all, "rejects a software" would mean that they have identified specific blockers. Some of these blockers might be conceptual, radical, while other might be about implementation, performance, or other factors that can be amended. Then, some features might be received with resistance by big projects precisely for the fact of being big (hence more conservative, and with different needs/priorities) while exactly the same features will be requested as a priority by smaller projects.