Topic on Talk:Technical Collaboration Guidance/Vision

This Vision sees communities "controlling the products and major features" in two ways: Timing of the deployment; Opt out based on blockers accepted by the development team. This seems quite inadequate.

Firstly, it suggests that communities are not involved in the innovation, specification or design of software. If so, that is ineffective and unacceptable.

Secondly, it enshrines the notion that communities can opt out only if the WMF says so. Again this is unacceptable and wrong: in fact, it's Superprotect all over again -- was nothing learnt from that fiasco?

That section refers to community decisions at deployment time. The previous sections explain how communities can get involved since the publication of a new project idea.

The Superprotect scenario happened when a new feature was deployed to some wikis that didn't want to be early adopters. This essay proposes that communities can always decide to be early adopters or the opposite, the last ones to get a new feature. Therefore this is not Superprotect all over again.

Exactly -- the communities get involved after the publication of a new idea. No suggestion, then, that the communities, the volunteers and the end users, might be involved in the setting of requirements and development of those new ideas.

Oh, and Superprotect was about a community deciding it didn't want a feature at all, and WMF deciding to impose it anyway. Your essay seems not to cater for this possibility.

It was assumed that anyone can start a new idea, and it was also assumed that new ideas are open for discussion as soon as they are published. I made this explicit. Please check the diff.

Individual and community opinions may change over time for different reasons. The essay says "The hypothesis is that most of these blockers will either be solved through deployment waves, or will stand and stop a feature for all Wikimedia projects." The scenario of a feature happily deployed to +800 wikis but still not welcomed at all in 2-3 is quite unlikely, looking at 15 years of Wikipedia history. When the plan is to deploy a feature everywhere, the result so far has been to have it either deployed everywhere indeed, or deprecated and removed because it didn't work as expected.

Thank you for making those changes, they do help to make clear the point I was concerned about.

The fact that opinion changes over time is not relevant and indeed not really reflected in the essay at all. Whether all, most, many or few groups regard a blocker as important is subordinated in this essay to the view of the WMF. That seems important to discuss, as it is a recipe for significant conflict and we have already seen that. Perhaps you would care to explain how you expect to resolve such issues in the future. The scenario of a major project determined not to accept a change which the WMF are determined to implement is far from hypothetical. I further note that you envisage the possibility that a change may be removed because it didn't work but apparently do not envisage removing a change because it was roundly rejected by a project as contrary to their policy.

Hi @Rogol Domedonfors, the text says that "The more disruptive and expensive the plan, the more it is required to be checked against the mission, principles, strategy, annual plans, supported technologies..." If a project is contrary to a Wikimedia policy, that should be detected ideally at the planning phase already. If the policy infringement is due to a specific implementation approach, then maybe that problem can be solved within the same project with a different approach.

Note that this aspect is already documented in the actual TCG draft: Technical Collaboration Guideline/Milestone communication#When and how. If this concept needs more clarification, it is better to focus on fine tuning the TCG itself.

The analogy does not allow for the checking of ideas against local community policies, which is one of the ways in which it is deficient. The phrase "Wikimedia policy" does not adequately capture the notion of a community policy, such as caused the difficulty with Gather, in which the desire to turn the English-language Wikipedia into a social media forum ran directly counter to a policy of the community of workers on that project, rather than a global or Foundation policy. Simlar remarks apply to the TCG.

I thought you were talking about policies as in m:Policies. The essay refers to "principles", which seems to be more in line with your comment. In any case, I think what matters is the ability by communities to present blockers with a good argumentation, regardless of whether such arguments refer to more abstracts concepts like principles or more concrete details like software bugs.

The ability of a community to block a development which is at odds with one of its more important policies certainly matters. Better still would be to discuss such issues before development starts, and this does not seem to be captured by this analogy.

"section.Yes, communities should be able to discuss issues related policies / principles, and the sooner the better. The essay says: "The more disruptive and expensive the plan, the more it is required to be checked against the mission, principles, strategy, annual plans, supported technologies..." The first checkpoint proposed is when there is a project proposal in place, and that should happen well before serious development starts.

Communities should be able to delay and opt-out when a feature goes against their principles / policies, also later in the game. This is also mentioned, in the "Community decisions"section.

Qgil-WMF, I'd also like an answer to Rogol's question about how you expect resolve the issue when there is a disagreement about deployment. Actually, I'd like to add a bit more detail to the question. I hope Rogol won't mind.

Let's say WMF is enthusiastically working on a project. Let's call it Unstoppable Train.

The Train visits the Checkpoints. There are objections. According to your essay: Sometimes Project crews and some watchers agree to disagree. The crew takes note, hands are shaken, and the journey continues.

So the crew politely shakes hands with all the little people and it appears that Unstoppable Train runs through checkpoints.

Let's say a number of wikis have RFC's on Unstoppable Train. Let's say that every single wiki that runs an RFC on the subject reaches the same conclusion - that it would best serve editors and best serve readers for Unstoppable Train to be Disabled by default. Let's say those wikis represent a majority of the global community. So we have a Global Community Consensus on the issue. When there is a consensus on an issue, there is a good faith presumption that those who did not speak up generally agree with the established consensus. Silent wikis may not request the product if isn't deployed.... and they may not say anything if it is deployed.... but the good faith presumption is that they would probably agree with the Global Consensus if they were asked.

And let's say blocking is declined by the project team, just like like your essay says. It appears that Unstoppable Train barrels through.

There are no outstanding issues, so it appears your essay says the WMF proceeds with deployment. Unstoppable Train runs over the community, against a Global Community Consensus.

The Community implements consensus and uses javascript or other means to effectively disable it.

Rogol's question, my question, is what happens next? You essay doesn't say. A lot of people will interpret your essay, as currently written, as implying that the WMF intents to repeat the Superprotect incident in one form or another.

If I'm misinterpreting something in your essay, that's probably a point that could use clarification.

Hi @Alsee, the text says at the end that "The hypothesis is that most of these blockers will either be solved through deployment waves, or will stand and stop a feature for all Wikimedia projects." In the scenario you describe where the community opposition to a project keeps growing, the likely scenario is that such project will be stopped.

There seems to be a really big gulf in communication and understanding between the WMF & Community. Sometimes I wonder if part of the problem is that I avoid getting into unavoidably ugly discussion of history and why this is such a big deal.

Were you aware that you didn't answer my question?

Would it surprise you if many in the community view this process and essay as offensive and/or a hostile declaration?

> Were you aware that you didn't answer my question?

No, I wasn't. May I ask you to define your question?

> Would it surprise you if many in the community view this process and essay as offensive and/or a hostile declaration?

It would totally surprise me. What do you find offensive or hostile?

What do you find offensive or hostile?

I've been struggling to figure out how to explain the issue, but I abort the posts because they turn into a walls of text filled with negative rehashing of past events or inflammatory explanations of why it's such a big problem. I'll try.

I don't think most people at the WMF realize just how bad things got. To quote the Letter to Wikimedia Foundation, signed by a thousand editors, Longtime and respected Wikimedians... repeatedly discussed whether it is time to create a fork of Wikimedia projects. I want to note that a fork attempt is not the worst case scenario. Things could have gone in a much easier and uglier direction. (For the record, I shut down fork-talk when it showed up in an RFC I was running.)

The conflict started over a rather petty issue. It was a disagreement over a default setting, on a feature that was substantially cosmetic. Whichever way it went, anyone could pretty much be unaffected the issue by personally opting-in or opting-out. I know staff believed survey numbers showed that readers liked it, but eventually the WMF acknowledged the positive numbers were wrong and that the survey actually showed a majority of our readership didn't want it. I bet most staff are unaware of that.

That petty matter then became a war against our essential foundation of consensus, waging a war against the community itself, violating one of our most serious taboos (abuse of trusted technical access as a battleground tactic to "win" a reasonable disagreement by force), and threatening at-will revocation of admins as a weapon in that war. Then the WMF flat out declared it was unwilling to participate in any discussion to resolve the issue. The WMF declared the issue "out of scope" for discussion.

The community has this odd notion that Wikipedia is governed by consensus, and that the core community are more than mere Facebook users. We could go over the history of why the community has this odd notion, we could be debate whether it is true or whether should be true, but a lot of people do believe it. The community will passionately defend the project against threats to the foundation of the project, even if that perceived threat is the WMF itself.

Use of force to defeat consensus is viewed as such a threat. The WMF often says it's a member of the community, but it's impossible to be a member of a consensus-based-community and stand over it as a King at the same time. The WMF can't declare that it knows better what's good for us and impose it by force, without coming across as condescending, patronizing, disrespectful, abusive, and a threat to the project. The WMF can't do that without treating the Community like a bunch of Facebook users.

When people read this essay, they are going to read it exactly in the context of Superprotect events. They are going to read it to see if that outcome would have changed. The checkpoints won't be viewed as changing the scenario at all - the WMF was already polite and "shook hands" while disregarding any feedback that didn't advance the project. The "blockers" will be seen as a patronizing fiction: the WMF already "declined" a Global Consensus that it didn't like, and this essay says the WMF plans to do it again. The essay ends with the exact same conclusion as before. Nothing has changed.

I asked what happens if the WMF follows your process, if the WMF declines a Global Consensus, and the community disables the product? What happens next? If you don't answer that question, people will simply fill in the same answer that we got before. The endpoint of your essay will be taken as a face-value declaration of the intended outcome, it will be taken as declaring that the WMF intents to use Superprotect or admin-revocation or whatever other means of force to carry out the essay's outcome.

If you don't answer that question, that is the answer people will hear.

> I don't think most people at the WMF realize just how bad things got.

I disagree, but the question here is why this essay could be offensive or hostile.

According to your reply, the problem is that regardless of what the essay says today, "people" will not believe that WMF Product teams will actually listen, will actually follow Global Consensus, and will not rely on brute force to push their own agenda. In other words, you are describing a problem of trust. If this is correct, then I could probably add to the essay the reply to "What happens next", but would that change anything, as long as the problem of trust remains?

The answer to "What happens next" belongs to the actual Technical Collaboration Guideline. I agree that it is an important question with deep implications. The WMF, my team or myself are not in a position to provide the precise reply you are expecting. We keep working on it.

Meanwhile, if you identify an actual situation where there is a Global Consensus being broken by the WMF, or a situation that is evolving in that direction, please point to it.

According to your reply, the problem is that regardless of what the essay says today

I was saying the exact opposite. I was saying there's a problem with the current text.

This process/essay is explicitly a response to the Superprotect incident, and people are going to read it in that context. People are going to imagine what would have happened if this process had been in place in 2014. If this essay had been in place at that time, the 2014 staff would have hung up a "Checkpoint" sign and they would have gathered substantially the same feedback as before. They would have been polite, just like before. They would have proceeded, just like before. Three communities representing a Global Community Majority all submitted a block on making Viewer the default. The 2014 staff considered that block and they issued a "decline". Your essay explicitly authorizes them to do that. Then they asserted your decline result as a final outcome. Considering that your process comes to a halt at the Decline point, it sounds like they did exactly what your essay told them to do. They asserted this process's final outcome as the definitive final outcome.

If you want to say that things will go differently, then write a process that says things go differently. Write a process that clearly directs the 2014-staff to do something different.

Perhaps I wasn't direct enough, but I have been suggesting that the WMF could do a 51% roll out and plausibly assert a force over of the remaining 49% on the technical grounds of consistency and single configuration support. I have been suggesting that a 51% Global Community Consensus blocker constitutes a per-se well founded blocker. And of course discussions can be pursued trying to resolve it.

You have been worried about how to deal with some unreasonable wiki making unreasonable or unconstructive objections. I just handed you a solution on a silver platter. In exchange I'm just asking the WMF to have an explicit external acknowledgement and internal acknowledgement that the WMF isn't going to use force against consensus in a situation where the damage would outweigh any possible benefit anyway. A blocker with 51% Global Community Consensus goes to discussion rather than decline. In 2014 we would have gone to discussion rather than Superprotect.

If this process would have been in place two years ago, de.wiki and Commons would have filed their blockers to the new MediaViewer and/or their specific configuration for logged/anonymous users, and their deployment would have been postponed to a later deployment wave instead of being pushed as early adopters. This would have made a big difference and would have probably resolved most if not all the big issues (since anyway most of the big issues reported were resolved by the development team a few weeks after the Superprotect crisis exploded).

So yes, I think a process like the one described in this essay would be very useful and would introduce a big change to prevent situations like the MediaViewer / Superprotect crisis.

since anyway most of the big issues reported were resolved by the development team a few weeks after the Superprotect crisis exploded

Do people inside the WMF believe that the fake-consultation and those fixes solved the situation?? That isn't what happened. Are you aware that the Community rejected that outcome and rejected that fix list and still said more than 2-to-1 to default-off the viewer?

Your answer to "What happens next" is currently "We keep working on it". Is there any prospect of getting that filled in before this conversation wraps up?

Is the WMF dead-set on a process which amounts to "The community is permitted to request early deployment"? Because that's what you've currently got with with a blanket-decline and no answer to the last question.

Are you still of the opinion that it would be surprising if many in the community find the current essay/process offensive? If so, we can easily find out.

The hypothesis is that by not pushing those wikis as early adopters and by agreeing on specific blockers for the deployment/configuration, we all would have moved the discussion into a more constructive path. Do you agree with this hypothesis?

I cannot promise a deadline for a TCG recommendation answering the question "What happens next?".

The idea of communities deciding to become early or late adopters is part of this essay but it is not part of our deployment process yet. We can see how new features are following this pattern already, but this is based on the decisions of the own teams and the requests they receive from communities and it is not a systematic process.

If someone finds this essay, I am interested in knowing specifically why, and I am happy to discuss potential improvements to the text and the concepts behind it, yes.

You and I are having two completely disconnected conversations. You are trying to address the average or hopeful case. I am trying to address the problem case. I agree you're making the average case go more smoothly, but that's not relevant to discussing the problem case.

The hypothesis is that by not pushing those wikis as early adopters and by agreeing on specific blockers for the deployment/configuration, we all would have moved the discussion into a more constructive path. Do you agree with this hypothesis?

In the problem case, the answer is basically "no" by definition. In fact the new process literally makes the problem worse. Let's define the Problem Case:

1. In some cases, consistency should prevail. Let us define it as a given that we are discussing such a case.
2. In some cases, the WMF believes something is beneficial. We can take also this as a given. The WMF would not be working on a project unless it believed the project was beneficial.
3. In some cases, the Community believes something is harmful. I assume you agree this can happen. You once said that "actionable blocker" did include "Thank you, we are happy with the current status". Let us define it as a given that we are discussing a case where the community views something as harmful.

How does the Problem Case play out under this process?

1. Per Given #3, one or more major wikis assert Consensus block. Perhaps the Community does a poor job explaining why they view it as harmful. Perhaps the Community's real-world experience using and running a wiki creates a different perspective and understanding of the problem which is difficult to explain. The WMF still views the project as beneficial. Per this process the WMF "shakes hands" and assigns the wiki(s) to Last Wave deployment.
2. Per this process the WMF proceeds with general deployment. However the vast majority of wikis are tiny, and they almost never adopt or reject anything. It is difficult to surmount the language barrier, or they believe they are too small to influence anything, or they do not have the population to devote to it, or for whatever other reasons they just don't. They leave it to major wikis to deal with platform problems. So the WMF does a massive bottom-up deployment to wikis that don't adopt or reject.
3. You have now face a catastrophe. The WMF has just deployed the product to ~200 wikis and is expecting to complete job. However the last 1% or 2% of wikis represent around two-thirds of the Global Community. Those few large wikis are the only ones to ever speak, and for this discussion we have a documented Global Community Consensus to block. The only reasonable expectation is that many or all silent wikis would agree with that Global Consensus if asked. They just don't manage to surmount the participation barrier. The WMF is now painted into the worst possible corner, in the worst possible scenario. There are two options:
   1. The WMF is going to do a massive rollback of the product from ~200 wikis, per Given #1 Consistency. Most in the Community see little likelihood of the WMF being willing to do so. If this is the planned scenario then it would HUGELY help improve the atmosphere of trust if this process were to properly document this.
   2. Or: The WMF still believes the project is beneficial, per Given #2. The WMF has the notion that Final Wave is supposed to be a mere formality. The WMF views a ~200 wiki rollback as intolerably disruptive. The WMF tries to finish up final wave, per Given #1 Consistency. The Community shuts it off, per a consensus that it's harmful. The WMF perceives the Community as unreasonable, obstructing the last few deployments after ~200 wikis of supposedly successful adoption. The WMF decides it is "necessary" to resolve this minor last-wave matter. The WMF starts using nuclear weapons again because it is "necessary". At this point the Community stops caring what the software issue was. Using force to fight Consensus makes the WMF a non-participant in dispute resolution. It makes the WMF a fundamental threat to the project. This time the community decides the WMF's nuclear war requires a nuclear response. This time someone posts a seven letter RFC: SOPA WMF. God-forbid we get to the point where THAT ever gets consensus. That is Game Over. The WMF has no choice but to surrender that war. Everyone loses because the damage would be enormous. That is the worst case scenario. We came perilously close to that point during Superprotect.

In this scenario, none of the big or tech-curious medium size projects wants the new feature, but none of them (and neither none of their individual members) is capable of explaining why in the form of a specific blocker during the entire development process. This scenario seem unlikely. Could someone mention any precedent remotely similar in our history?

The more likely evolution of that situation is that things would change as soon as betas and deployment dates would be proposed to these bigger / more active wikis. Specific blockers would be raised, discussed, and sharpened in those communities if they really don't want that feature in their wikis.

I almost forgot that you asked for any precedent remotely similar in our history? I could give endless examples, but I'll go with one that is hopefully uncontroversial. The initial deployment of opt-out for VisualEditor. The community said it shouldn't be given to inexperience editors yet, said that opt-out needed to be rolled back, said that it was causing way too much damage and disruption, and said that new editors were frightened and confused that they were destroying articles. The WMF gave little weight to those concerns. The WMF wanted it to be opt-out so they could collect data faster for improving it. The WMF told the community that it was forbidden to set VisualEditor back to opt-in. The community used the sitewide javascript to do it anyway, to stop the damage and disruption. Eventually VisualEditor was upgraded and opt-out was agreeably re-deployed.

The community gave a clearly articulated reason. The community gave a darn good reason. The WMF was focused on their own internal work and gave little weight to the damage being caused. The WMF issued a "decline". I have the impression that the WMF now generally accepts that the initial VE opt-out was premature. This is hopefully an agreeable example of the WMF issuing a bad "decline" because it under-weighed the community's clearly articulated concerns.

In this scenario, none of the big or tech-curious medium size projects wants the new feature, but none of them (and neither none of their individual members) is capable of explaining why in the form of a specific blocker during the entire development process.

That is not what I said.

What I said was that the WMF may fail to understand the objections, or may fail to give proper weight to the real-world problems it causes. I was trying to be generous and place 100% of the "blame" on the community for failing to explain it well enough.

The fact is that sometimes reasonable people disagree. I am merely suggesting a situation where the WMF has not yet persuaded the Community that something is beneficial, and the Community has not yet persuaded the WMF that it's harmful.

I am merely suggesting, when you're facing a Global Community Consensus, and neither side has yet persuaded the other, then it must go to "Discuss" rather than "Decline and try to use nukes to force it out".

The position you are defending here is that the WMF decides it doesn't feel like talking anymore, that it inherently knows better than the people running things on the front lines, and that the WMF will benevolently go to war.

If there are solvable issues, then talk about solving them.

You suggest "Discuss" rather than "Decline and try to use nukes to force it out". I agree with this and this is an idea that this vision supports. This vision is not promoting the idea of development teams ignoring lack of consensus and going to war. Again, the hypothesis is that most of these blockers will either be solved through deployment waves, or will stand and stop a feature for all Wikimedia projects.

You suggest "Discuss" rather than "Decline and try to use nukes to force it out". I agree with this and this is an idea that this vision supports. This vision is not promoting the idea of development teams ignoring lack of consensus and going to war.

It "supports" both outcomes. It doesn't "promote" either outcome.

If you want to rebuild trust, if you want the community to work with you better, if you want the community to hand you the solution for dealing with a rogue obstructionist wiki, if the WMF is not going to repeat an even worse superprotect incident, then you have everything to gain and nothing to lose by saying that the WMF isn't going to use force against a Global Community Consensus just because we have a reasonable disagreement.

Trust is indeed the issue. Trust grows from transparency. How can we know whether there are projects evolving in a direction that will lead to conflict with community consensus when we have no clear view of what is being planned? Where is the single, simple source of ground truth on issues about how the WMF would like to see the projects move and what they are developing to further that movement? And why do you expect trust in an environment where in situations of conflict you expect to impose your will? Why not trust the communities in turn by giving assurances that in the event of disagreement projects will not proceed? You want the community to trust you, demonstrate willingness to trust them in return.

Yes, I think the WMF trusts the communities.

You are touching problems that the Technical Collaboration Guideline aims to address. A simple way for communities to know about new ideas and upcoming plans. A simple way for communities to know which projects are being developed and in which stage is each one. A fair way for communities to participate in plans and decisions.

In the event of disagreement projects should indeed not proceed. But there needs to be a common definition of disagreement, otherwise in a movement of hundreds of projects and thousands of contributors it wouldn't be difficult to find mechanisms to stop almost anything new.

I think ideas like defining checkpoints, blockers, and deployment waves help identifying agreement and disagreement at the time and in the places where matters most.

"A simple way for communities to know about new ideas and upcoming plans" is all very well, but what will be needed is a simple way for the community to be fully engaged in developing new ideas from the very beginning. To be honest, everything you write seems to be based on the notion that the WMF is the active proponent of everything new and the communities are the passive recipients, willing or unwilling. How about joint initiative, joint planning, joint development -- would that not be better?

We agree on this. Ideas may come from anyone, regardless of affiliation. Projects may be started by anyone too. We are supporting many spaces allowing individuals and communities to propose ideas and/or get involved in the planning stage.

Through Phabricator, Gerrit, hackathons, etc, we can see that the composition of the projects is not only made of 100% teams. There are projects with 100% volunteer participation, and there are projects with mixed affiliations too.

It is important to note that "the WMF" or "the community" are not proponents, contributors, developers... Specific people in the WMF, the communities, etc, are the actual participants. Joint planning and development means actual people working together. Some of them actively, regularly, side by side, and many of them more as watchers, occasionally, whenever projects reach to them requesting feedback or other ways to help.

"We are supporting many spaces allowing individuals and communities to propose ideas and/or get involved in the planning stage." Please name five.

Individuals and communities can propose ideas and/or get involved in planning in

• Phabricator, where feature requests can be discussed and be assigned, and where we also have #Possible-Tech-Projects, which is connected to Google Summer of Code and Outreachy.
• WMF Product teams share plans and ask for feedback and involvement in MediaWiki.org and Meta, distributing announcements through Tech News, wikitech-ambassadors, and other means (not consistently, and this is something we want to fix with the TCG). Current examples include Wikidata descriptions in articles and interwiki searches.
• The Architecture committee organizes a RFC process allowing anyone to propose deeper changes in our software.
• The WMF Resources team organizes the IdeaLab space and Inspire campaigns, both connected with different types of grants, allowing anyone to propose ideas and obtain the resources to implement them.

See also the ongoing task Explore a process for UX/UI discussion.

Thanks. As I'm sure you realised, this was a somwhat loaded question. The more answers you give (four as it turned out), the more obviously incoherent is the process or lack thereof. Which of these would be the venues in which Knowledge Engine was formulated for the community to enagage in, for example?

Specifically, Phabricator is a bug report tool. It is not intended to be, or appropriate for, a forum where community members and developers thrash out ideas for radically new projects. Mailing lists are fine for announcements but again not for complex discussions. The ArchComm RFC process is for technical interactions, not strategic and community issues.

You mention IdeaLab. Perhaps I might mention Meta:Grants:IdeaLab/Strategy Alpha‎, Meta:Grants:IdeaLab/Innovate Beta, Meta:Grants:IdeaLab/Translate omicron‎ and Meta:Grants:IdeaLab/Knowledge Sigma which are modest proposals that may help to fill the gap.

Read again the sentences highlighted above "Sometimes Project crews and some watchers agree to disagree. The crew takes note, hands are shaken, and the journey continues." You'll notice it doesn't say "The crew says 'Oh dear we got it wrong, sorry about that' and goes back to plan again from the beginning". Your whole analogy is predicated on the assumption that the norm is that whatever is decided by the developers will happen, and when the community disagrees, then it will happen anyway. Can you see why the community might find that just a little unfriendly?

This may or may not be the likely outcome. The question was, and is, how is the decision to be taken? How will such issues be resolved? Who owns that decision?

These are good questions, and I am trying to define the answers in the context of phab:T119595. This essay doesn't aim to get into implementation aspects.

About "Who owns that decision?", I believe the WMF does, as entity responsible for providing the essential infrastructure and an organizational framework for the support and development of multilingual wiki projects.

If you really think that the question of who gets to decide whether an unwanted implementation is deployed or not or not is some kind of implementation detail, then I suggest that you really do not understand why there has been very significant friction between the WMF and the community in the past, and that until these issues are made explicit and addressed in a satisfactory way that friction will recur. The whole tenor of this essay and of your answers here suggests that you believe that the WMF can and should continue to develop products in the absence of serious engagement with the community and deploy them in the face of serious and sustained community opposition. This is not the way forward.

For what is worth, participation of communities in decision-making was a main theme in my presentation at Wikimania Analyzing conflict and possible solutions around WMF software development.