Topic on Talk:Technical Collaboration Guidance/Flow

I'll copy here what is relevant of a comment I made about how the TCG "handles" community concerns here.

Year after year the WMF has forced out disruptive and controversial software projects. In 2013, it took a community revolt on English Wikipedia for the rollout of VE, which (as I understand it) was ultimately revealed to have been rushed out in part due to financial grant terms, despite it causing significant damage. In 2014 controversy over Flow erupted. It took over a year of kicking and screaming for the WMF to concede that it wouldn't necessarily roll it out globally in the future, and yet more months before it was removed from enwiki, and even then only under threat of a serious flaming at RfC. In 2015 Gather was introduced to enwiki. In this case indeed, actionable blockers were proposed: collections could not be deleted, collections automatically used non-free content in violation of the EDP, the moderation system was very hard to use, and enwiki admins were being expected to patrol it with no benefit to serious contributors of content. Only one of these things was addressed. Complaints continued to be raised about the rest of the problems, but Moushira Elamrawy, the liasion for Gather, instead of understanding and passing on the gravity of these complaints, tried to pacify the community without taking any action about the problems. Eventually an RfC demanded Gather be removed. Then Toby Negrin needed a lot of convincing that yes, we actually meant it, and we wouldn't allow him to kick it into the long grass. Yes, the proposal looked reasonable on the face of it, but all trust had broken down.

For years the WMF has needed to be coerced into listening to community concerns on major software projects. Time after time, staffers have tried to avoid dealing with the issues. Now the TCG says that, to slow down a deployment, the community must declare actionable blockers. It doesn't [explicitly] allow for philosophical differences of opinion. It doesn't mention a community outright rejecting a feature. It's a codification of the existing uphill battle communties face when trying to get their fundamental, deep concerns heard about a project in progress.

Hi BethNaught,

I understand where you are coming from, and perhaps I can explain the difference here in implementation with the TCG and the previous experiences. Please keep in mind I might speak in some broad generalities in a few cases, and know that I understand specifics are much more complicated.

When the previous instances have occurred, a good deal of the pain and division was created by miscommunications, a lack of clarity in expectations, and a lack of clarity in roles and responsibilities in developing and deploying software. These failures create the philosophical differences that end up often times dividing and inflaming releases. Identification and engagement with communities and community members should be taking place from the inception of an idea, with discussions along the way as needed to review and mold the product to make sure that it fits community needs, both in philosophy and hands-on work.

What we often had in the past occurrences was a lack of engagement from the start of the idea; the result was that the WMF had the idea, built out the prototype or whatnot, released it, then asked for feedback. At that point we're in the bad feedback loop cycle, from the very start. At this point is when, as you say, the "philosophical differences of opinion" come to head and there's really no fruitful outcome to be had for anyone, because we weren't all on the same page from the start.

The idea behind the TCG is that communities and community members should be on the same page from the start. Ideas can be discussed through to make sure these philosophical differences are worked out before it is too late, identifying what a product can and can't do to fulfil the needs of the communities. In light of this approach, I do not consider it a codification of the uphill battle. If the idea was to continue on in the "old way," so-to-speak, just dropping things on communities and not taking "I don't like it" for an answer, I'd be much more inclined to agree with you.

Now, with that said, "I don't like it" still isn't a valid answer for blocking software, just as it's not a reason for changing content or policies on the wikis. What should occur is collaboration and consensus building, and we at the WMF can work on doing that from the start, just as volunteers do to build the projects.

Thank you for your considered and thoughtful answer which clarifies a few points. I would say that "I like it" isn't a reason for mandating a software deployment either. When there is agreement about a fundamental idea, the TCG seems to me to be a collation of good practice which ought to be observed. It might have helped the PageTriage extension and the abortive page creation workflow on enwiki, for example. Also, if as you say, collaboration on ideas from the start means that certain disliked ideas will be more readily killed off, that is good.

One specific provision I question in light of your comment is "It may happen that one or just a few communities will keep pushing back a new product/feature while all the rest are happy with it. The likely scenarios are that either the new product/feature keeps spreading until reaching full coverage, or the community concerns grow and ultimately force a change of product plans" (from /Community decisions). This needs to be better defined. Last time I heard, the Related Pages extension is not being deployed on dewiki because of their Themenring policy, although some other wikis actively welcome it. This is a counterexample. While I realise having many wikis with different combinations of extensions can be a pain, the TCG needs to lay out under what circumstances individual wiki opt-outs are possible/likely. "Change of product plans" is unhelpfully vague IMO.

I agree about your points that need better defined - and I'd extend that to most points raised in the TCG as a whole. This is something I think about constantly, and is something that will be pursued in the future. The idea right now is to establish some baselines and best practices in communication, which in turn will lead to general good habits around discussing ideas, transparency both in planning and decision making, and all those other dreams of working better, together. There's a whole lot of steps in between to accomplish this, and it will take a lot of time, but that's the general vision here.

tl;dr, in response to your further points, is they are good ones. We have to discuss and detail opt-in/opt-out criteria. That is a large topic on its own right, and will have to be worked out as a separate project from the TCG. It will happen, though I have not discussed any timeframes for those conversations at this point. Getting down these baselines of communications is a first step.