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

Quim Gil, I addressed this on the Signpost page, but to repeat here: the Meta:Letter to Wikimedia Foundation: Superprotect and Media Viewer|Letter expressed two conditions as being necessary prior to engaging in substantive discussion about effective future processes for software development, and the appropriate roles for WMF staff and volunteers. I am glad to see you have been thinking through possibilities (I have as well, as, I'm sure, have many others). But I hope it is clear to you and your colleagues that a lack of commentary here does not necessarily indicate a lack of interest. Issues as important as this should not be deliberated when there is substantial reason for one party to mistrust another's intentions. Lila Tretikov identified trust as a major concern, and yet has thus far declined to do the things that must be done to begin restoring trust. I hope these conditions change soon, but for the moment I will not be commenting on the substance of your proposal, and I'd imagine many others feel similarly.

p.s. This is my first time using Flow, and I seem to have generated several errors. I will try to fix them in wikicode after posting; help or suggestions welcome.

I am having trouble with this. Any assistance welcome. I have learned to use the "Edit" button, which is tricky (have to click on the text, not just the shaded area) and learned that my signature doesn't render the way I'm used to. What I still need to learn (and would be glad if somebody could fix for me) is:

1. How do I ping a user? I tried both the "ping" and "user" templates, which brought up promising-looking wizards (which slowed me down considerably due to the need to use the mouse), but the results both came up as errors. I can't figure out how to make either one work. I was trying to ping Qgil-WMF and then LilaTretikof (WMF), it should be rather obvious in my text where.
2. The link to the letter is not intended to include the full title of the page, but just the word "letter" in the prose.
3. I don't know if I used the right "header level" -- if my comment belongs somewhere better, feel free to move it.
4. My name above should appear as entered in my preferences, "Pete F" instead of "Peteforsyth".

Any help appreciated.

@Peteforsyth, thank you for your efforts, for what is worth I also appreciate them. :) I hope we can continue talking frankly and productively here.

If I understand you correctly, the problem you are expressing has two components: content (the two questions of the letter should be clearly addressed) and protocol (the answers should come from "the leadership of the Wikimedia Foundation", to whom the letter was addressed). Is this correct? Let's agree on these details and then I will try to solve whatever is missing.

Content

The demands of the letter:

"The Wikimedia Foundation should remove the "superprotect" status recently enacted on the German Wikipedia's MediaWiki:Common.js" JavaScript page; and"

This is now done.

The Wikimedia Foundation should clearly assert that it will permit local projects (such as German Wikipedia, English Wikipedia, and Wikimedia Commons) to determine the default status of the Media Viewer, for both logged-in and non-logged-in users, uninhibited.

Permitting local projects to determine the default status of features in their wikis is the aim indeed, but this hasn't been "clearly asserted" by the WMF yet.

One detail that needs to be polished is that our communities have not only this right, they also have this responsibility. They are expected to exercise their determination as active participants in a product development process. The details of how will this work exactly are being discussed right now. For instance:

• Communities should have a chance to influence this plan, proposing release blockers and non-blockers specific to them (not all issues impact equally all types of projects and languages), or choosing a different wave (some communities will be socially more excited about a certain product, or more stressed about it).
• Communities have the final say on the deployment of a product in their wiki. This is a right and a responsibility. A community blocking the deployment of a product as planned is expected to provide proof of community consensus and actionable blockers, to be open to discuss the blockers in product terms, and to be involved in their resolution. The aim to provide a consistent user experience across Wikimedia projects should always prevail. Moving from a deployment wave to another should not be a big deal.

We will reach to a conclusion eventually. Feedback is welcomed. Please discuss these topics in their own threads.

Protocol

I see two consistent approaches. Please choose one or propose a third:

• The current aim expressed above is enough to consider the mission of the letter completed. We can discuss the protocol to "clearly assert" this.
• The aim is not enough. We need to wait until the implementation details are agreed so the Wikimedia Foundation can clearly assert them. The protocol will be discussed then.

PS: I have posted your other questions under Talk:Flow, and I will reply to them there if nobody beats me at it.

@Qgil-WMF, thank you for the considered response.

• A small detail, but one that is important to me: The letter contained requests, not demands.
• I am glad to hear that autonomy around software features is the aim. I agree that it has not been clearly asserted.
• I am not sure about the emphasis on "responsibility." Local communities are not legal entities, or anything like it; any kind of accountability around such a standard seems unattainable. As I have said before, I have no personal desire to get involved in software development in a volunteer capacity, and I suspect that is true of many other Wikimedians (but of course not all). A desirable outcome for me is that I no longer have to worry very much about software development, trusting that the entity approaching it is doing so in a responsible way. When it comes to "responsibility," it seems to me it is WMF that has a responsibility to approach software development in a way that effectively balances the needs of its various stakeholders. In this way, the challenge is not so very different from that of numerous software development companies, many of which have met this kind of responsibility successfully over the years.

Under "Protocol," I'm not sure I fully understand you -- especially on the second point. I think the first point matches my views better, though. I truly don't understand why this assertion was not made more than a year ago, and I am baffled by every day that passes without it. But, I'm not really sure what there is to discuss? I believe I have expressed my own views pretty clearly, and frankly my own views can only go so far to represent those of 1,000 people I mostly don't know. The WMF has a capable communications staff, and the mechanics of an announcement like this are not complex.

p.s. Thank you for putting the Flow comments in the appropriate place, I have already gotten some useful answers there.

Tracked in Phabricator
Task T119595

@Peteforsyth, sorry for the late reply. The emphasis on responsibility refers to this idea:

• Communities have the final say on the deployment of a product in their wiki. This is a right and a responsibility. A community blocking the deployment of a product as planned is expected to provide proof of community consensus and actionable blockers, to be open to discuss the blockers in product terms, and to be involved in their resolution. The aim to provide a consistent user experience across Wikimedia projects should always prevail. Moving from a deployment wave to another should not be a big deal.

Please give me a bit more time to work on this "clear assertion" from the WMF.

You are concerned with "A community blocking the deployment of a product", and that "consistent user experience across Wikimedia projects should always prevail" I previously agreed with you that single-configuration could be a valid basis to force over stragglers at the end.

I have to object again to the term "actionable blockers" (previously mentioned here). "Actionable" blockers implies that moving the project forwards is non-negotiable. Especially when you followed it up asserting resolution of the blockers.

If multiple wikis representing a majority of our global editing community reach consensus that something is harmful, do you agree the WMF should be willing to engage in unrestricted discussion of the issue? This is where I'm coming from when I object to "actionable blockers". The WMF previously took the actionable-blockers approach, against a majority of the global community, to declare the issue "out of scope" for discussion. The actionable-blockers approach made the situation worse. WMF staff literally started blanking people's comments because it didn't want to hear anything except actionable blockers.

Maybe it is a matter of choice of words?

In my view, "actionable blockers" are blockers that allow the development team to respond in a consequent way. If the imaginary sole admin of foo.wiki simply says "We just don't like it", "There is no need to discuss it", "What the WMF should do instead is (something unrelated)", then the development team cannot even continue the discussion.

Instead, if the radical opposition is based in blockers such as "This feature doesn't solve the problem and creates these new ones...", "Thank you, we are happy with the current status", etc, at least the team can assess the arguments and, if they have better or alternative ideas, continue the discussion. Or give up if the community arguments are indeed more appropriate.

If a community decides that a feature is harmful, that harm should be defined in some way. The discussion can be unrestricted, but it should be still framed within a common strategy and a common will to find better solutions. That requires the identification of actionable problems.

Just curious, what are you referring to with "The WMF previously took the actionable-blockers approach..." and "blanking people's comments..."?

Thanx, "actionable blockers" was causing confusion here. You are using it in a far more inclusive way than I would interpret it. To my ears "actionable" sounds limited to things the devs can act on, to unblock and advance the project. (bugfixes and enhancement requests.)

I've been trying to avoid dredging up history, but what I was referring to was the Media Viewer incident:

When Superprotect was turned off Lila promised a Community Consultation "with no predetermined outcome". We were then given a process with a predetermined outcome. Various staff repeatedly declared the only acceptable discussion was upgrade the software. It was nothing but a suggestion box for actionable bug reports and enhancement requests. The page history is littered with staff edit warring to blank numerous sections.

It was a disaster. The only thing it did was make people more angry. When the "Community Consultation" was finished people rejected the outcome by more than 2-to-1 in another RFC. It is still an open wound for a lot of people. When I heard "actionable blockers" it sounded like that Consultation, limited to actionable bugfixes&enhancements.

Regarding sole admin of foo.wiki, I've been agreeing with you on that. You don't want fringe elements being disruptive, and I don't want weighty consensus to be disregarded. I think those are compatible. During the Media Viewer incident EnWiki, DeWiki, and Commons all established consensus that Media Viewer should be opt-in. I think those three wikis represent a global majority, and presumably a number of silent wikis would have concurred.

Quim, thank you for creating the Phabricator ticket, I offered some assistance there, in case it's deemed helpful. Regarding "please give me a bit more time": I appreciate your focus on moving forward. I don't think my personal patience is much of a factor; it seems to me that it's in the interests of Wikipedia and of WMF to not let too many "milestone moments" pass without resolving this. To my thinking, the end of calendar 2015, the 15th anniversary of Wikipedia, and the 2-year anniversary of Lila Tretikov's hire are all dates that it would be ideal to mark with a resolution to this issue, rather than having the issue hanging over everybody's head. But I'd expect the WMF to make its own judgments about that. The decision, I believe, is fairly simple -- more complex due to the foot-dragging, but still fairly simple.

It's now over 700 days. There's just under three weeks left to resolve this on-or-before the two year anniversary. (August 19)

On

The Wikimedia Foundation should clearly assert that it will permit local projects (such as German Wikipedia, English Wikipedia, and Wikimedia Commons) to determine the default status of the Media Viewer, for both logged-in and non-logged-in users, uninhibited.

My intention is to publish a recommendation for the Technical Collaboration Guideline about the role of communities and developer teams agreeing on local deployments and configurations.

There is also an interest in answering "What happens when they don't agree?". I think the best way to answer this question is having a recommendation for a sensible escalation path.

At this point I am not expecting nor pursuing a formal reply from the WMF executives. I think the WMF has addressed the root of the problems that brought us to a crisis two years ago. Looking at our current projects, deployments, and discussions one can see that differences and opposition are being addressed in ways that reasonably honor and satisfy community concerns. The Technical Collaboration Guideline is an official goal of the WMF for FY2016-17, and clear recommendations in this document is what will guide WMF Product teams.

The discussion of your personal essay at Talk:Technical Collaboration Guideline/Vision suggests that the WMF has not addressed these issues. Perhaps you would like to list some of the "current projects, deployments and discussions" that you feel demonstrate this satisactory state of affairs that you discern.

Since the MediaViewer crisis calmed down, the WMF hasn't pushed a feature or specific configuration as it did in that situation. There hasn't been any other clash of that style related to software deployments. To name some examples:

• Superprotect was removed, and the WMF committed not to pursue this type of control in the future.
• Flow hasn't been pushed to any wiki through a WMF decision, and its deployments in new projects have consistently followed requests from those communities only.
• Gather was pulled from en.wiki after a discussion with this community.
• Recent discussions about specific configurations of Single Edit Tab or Content Translation in en.wiki reached satisfactory results following the line of community consensus.

All in all, I don't think we have any outstanding urgent problem, neither I think the WMF can be accused of unfairness towards the communities in our software deployments. Room for improvement sure, and this is what we are doing with the Technical Collaboration Guideline, but nothing remotely recalling the situation that brought the deployment of Superprotect two years ago.

If you have examples of ongoing software projects, deployments, configurations, or behavior demonstrating that the WMF hasn't addressed the issues that led to Letter to Wikimedia Foundation: Superprotect and Media Viewer, please share them.

The fact that you cite those as positive examples just illustrates how huge the gap is between the WMF's understanding of events and the Community's understanding of events. In fact I was the community member at the center of two of those stories, and I was intimately involved in almost all of them. They are trainwreck after trainwreck after trainwreck.

The fact that they didn't turn into MediaviewerSuperprotect level crises is hardly a good threshold for good WMF-Community relations.

I started a write-up on each example, but I realized my text is up to 9Kb already and I'm not done. Do you want to read a community-side narrative on them? Should I post the wall-of-text here? Perhaps it would help if I just did one at a time.

I appreciate your efforts to make me understand the past, but I think I have a reasonable good understanding about that past. I was there as well. What about sharing your understanding on current problems and how would you solve them? See my comment below.

I have a reasonable good understanding about that past. I was there as well.

Really? You were there, on Phab, five months before Single Edit Tab (SET) was deployed... when I asked Forrester whether the WMF was going to try to sneak in a VE-default as part of the SET deployment? You were there when he promised me no, the WMF would never do that without asking the community first? And I apologized for being paranoid?

You were there four months before deployment, when the liaison announced SET at village pump, with a link to see how it worked on TestWiki... and I told the liaison there was a problem... and the liaison assured me that what was deployed at TestWiki was NOT what was going to be deployed at EnWiki?

You were there three months before deployment, when I spoke to Forrester on his talk page and he went into more detail assuring me the WMF was not going to do it?

You were there a month before deployment when the liaison re-announced it, with links so we could see how it works on TestWiki, HuWiki, and PoWiki... and I again told the liaison there was a problem.... and the liaison again promised me that what was at TestWiki, HuWiki, and PoWiki was NOT going to be deployed an EnWiki?

You were there when SET was deployed, and we spent OVER A WEEK posting to Forrester on Phab and on his talk page that there was a problem.... and he didn't respond? He was regularly editing on those days, but no response.

You were there when I had to escalate to the Executive Director's talk page to say that there was a problem and Forrester was non-responsive? SHE had to summon him to give a reply.... and SHE linked to Forrester's response on his talk page telling us that it was a bug, and assuring us he'd fix it.

You were there when.... eventually.... Forrester told us that the WMF had always intended to do it from the beginning, and that he had no intention of following through on his promise fix it?

You were there when a community member had to write a goddamn site-wide javascript hack to override the WMF's setting? And the community was deciding whether to just deploy it immediately or whether expand the discussion before we deployed it?

You are telling me that we've solved the root of the problems that brought us to a crisis two years ago?

I don't know whether the Executive Director gave Forrester a kick in the butt, or whether he decided it wasn't worth continuing the fight, but he did make the change. And he didn't do it in any sort of collaboration... he agreed to fix it and left us with a parting insult.

Maybe next time I'll go over Gather. It's a grand story of complete dysfunction in WMF-engagement, utter deafness, and the WMF's complete refusal to discuss problems until the flames are half way to the roof.

> Really?

Yes, really. And back to my point, I'd rather focus on processes, tools, and documentation to prevent the repetition of known problems.

I am surprised that you give these as satisfactory examples of "differences and opposition are being addressed in ways that reasonably honor and satisfy community concerns". The first (Media Viewer/Superprotect) was a disaster for WMF-Community relations; the second (Flow) has been more-or-less abandoned by WMF as a failure; the third (Gather) was designed in apparent ignorance of the English Wikipedia community policy and apparently on the basis that a community of encyclopaedia writers would be happy to do unlimited amounts of extra work curating a social media forum without consultation. I rather hoped that you would be able to give examples of development projects where the communities were engaged as an integral part of the initial planning and where their input had been key to the successful design. Should I assume that this has never happened, and never will happen?

In answer to your return question I point to two examples. Firstly, Workflow. There appears to be no evidence that any serious attempt has been made to research how the various workflows currently function or discuss how they might be re-engineered. Secondly, Knowledge Engine (or whatever it's currently being called) in its more ambitious form. Far from the community being engaged in the design of this grandiose project, it was apparently concealed from most of the WMF staff. And yet it would have required the community to deliver unquantified and unlimited amounts of extra effort to curate it. Of course, as a mere member of the community, I'm not in a position to say what projects are being cogitated by the WMF without the involvement of the community. Are you able to assure me that there are none?

Added later: here's a good example for you to demonstrate how the community was involved in the initial planning and design of an important development project. Apparently there's a new wikitext editor, being discussed at Talk:Wikimedia Product. Perhaps you could just point to the discussions that engaged the community with the planning, decision to proceed and initial design of this project.

Rogol, the WMF hasn't abandoned Flow. They did issue a very badly written statement that made it sound like that was the case, but they issued a clarification. Flow was put on hold. Major work on it was paused. The WMF is still moving forwards with deployments, but (usually) only where they have some invitation to do so.

It appears that the WMF is currently planning to ramp up Flow again. They are about to run a survey of Flow users, to determine what features they should work on first.

(EDIT to add) The survey does include a question on whether people prefer Flow or Wikitext, but the pages and my discussion with the staff involved indicate (as usual) the focus is entirely on what to upgrade. They are explicitly targeting the survey at people who actively use Flow. This of course means the supposed "Flow-approval" numbers are going to be grossly biased. People who have tried Flow and find it awful/unusable are unlikely to hear that the survey even exists.

Thanks for that. It is hard for mere volunteers to keep up with WMF strategic planning and the changes in WMF strategic priorities in the absence of a coherent communication channel. I asked Katherine at her Meta talk page for a statement about the current status of various projects, but sadly she seems to be too busy to reply, even though the answer is presumably known to her. If there were a clearer more unified place in which issues like this could be publicised and community engagement could be initiated, then discussions like this one would be less frequent and more profitable.

As far as Flow goes, it will perhaps be clear that I think Flow is a failure in itself and that it should have been abandoned, but of course it's a personal view. However, as an example of WMF-community engagement it was certainly not a success. As an example of really poor practice, the English-language Wikipedia was assured that if an experimental use of Flow turned not to be acceptable to the community then a reversion tool was available. When it turned out the the community did not accept the use of Flow, it was informed that the tool did not exist (at least, did not work) and that the reversion could not and would not happen. Fortunately that issue was resolved, but the project should never have got into that state. It was clear that WMF had not expected reversion as a practical possibility, did not want to do it, and so had not planned adequately for it. The statement "Flow hasn't been pushed to any wiki through a WMF decision" is an over-simplification when you consider incidents like this. If WMF think Flow is an example of satisfactory WMF-community engagement then they have a very different view of the matter to that of the community.

The whole Flow/Visual Editor/wikitext/Parsoid nexus represents an underlying grand strategy which appears to be in progress in the absence of any clear statement to the community or enggement with them. Why is this the case? Can this situation really be what the WMF regard as satisfactory?

Let's recap. This is the discussion topic related to T119595. Alsee said that the WMF had not addressed the underlying issues of the Superprotect crisis. I begged to disagree. Rogol asked for examples. I provided examples that I believe are relevant to illustrate my point.

Is the current technical collaboration between the WMF and the communities ideal? No, and this is why the Technical Collaboration Guideline is a WMF priority. Is it at the levels it was two years ago? No, I don't think so. I believe the situation nowadays doesn't compare to that of two years ago, and it is improving continuously even if there is clearly more work to do.

At the moment the three of us have several topics open in different pages about more or less the same underlying discussion. They are also following more or less the same pattern: you ask me a question, I try to provide my best answer, you tell me how wrong my answer is. We seem to be stuck, regardless of the experience of all participants and the amount of time we are investing in these discussions.

Here is a proposal to move forward. It would be very useful to know what would you change in order to improve the collaboration between the WMF and the communities in software development. Please go to Technical Collaboration Guideline and share your own ideas. You can also go to the related Phabricator project and file tasks pointing to problems and possible solutions. Do you think this is a sensible proposal?

Do I really need to open a Phab task to say:

The Collaboration Guideline fails to identify any escalation or de-escalation path, if the community takes a carefully-considered good-faith-action believed to be in the best interest of the project, in accordance with a Major or Global community consensus, after the WMF has declined that issue.

Possible solutions:

1. Be honest and say the WMF will redeploy Superprotect, summarily revoke admins, and take whatever other measures are necessary to enforce the Decline action.
2. Say that the WMF will pursue discussions to resolve the disagreement, and that Superprotect etc. are not considered an appropriate solution to reasonable disagreements between partners.
3. Pretty much anything that doesn't leave everyone wondering whether or not the WMF is going to start tossing nukes.

P.S. The alternative is the status quo, where the WMF is deliberately or inadvertently broadcasting #1, where it's infusing almost every engagement, where almost everyone is just waiting for Superprotect to pop out at any minute, and everything has a fog of dishonesty hanging over it.

@Alsee, it is true that the TCG currently doesn't provide any recommendation for escalation / de-escalation paths. I was already considering creating a task to track the resolution of this problem. If you want to create it, feel free.

The WMF committed not to bring Superprotect or any similar alternative back: WMF_product_development_process/2015-11-05#Is_there_an_alternative_to_Superprotect.3F. This means that Superprotect is out of the list of possible solutions.

There are some interesting points here. Firstly, the view that a conversation between staff and volunteers is about volunteers asking questions and staff answering them. No. This is, or ought to be, a discussion about a topic between equals, not one party humbly asking for enlightenment from the other. You say how it appears to you (things are getting better) and I say how it appears to me (not everyhing is getting better). This is not me telling you that you are wrong, any more than you are telling me that I am wrong. This is about describing different views in a hopefully fruitful dialogue. If this keeps iterating without forward movement, could it possibly be because staff are less than completely willing to hear things that disagree with their own perceptions?

Secondly, what would I change? Well, over the past couple of years I am numerous other volunteers have made suggestions, answered surveys, engaged in brainstorming. I have to say that for all the progres that had emerged, this has not been the best use of my time. What those of us with limited time and effort to devote the to project can to is to articulate clearly what the requirements are (roughly, community engagement with WMF throughout the planning cycle) and let those who are paid to devote their time and energy to the project turn the requirements into solutions. Asking the community for detailed solutions is inefficient, confusing and leads to dissonance and is a prime excuse for ignoring the community entirely. I am certainly not going to delve into Phabricator and start micro-managing your teams, and you wouldn't let me if I tried. I am well aware that this leaves me open to the retort that I am not interested in helping you to solve these problems. That of course would be entirely wrong. I can help you best by contributing to the discussion at the strategic level. Are you willing to engage at that level, or do you regard the long-term and strategic planning as entirely a matter to be done by staff behind closed doors?

"A discussion about a topic between equals... in a hopefully fruitful dialogue" is a good approach that I am trying to implement as well. I will focus on the points of this dialogue that can improve our strategy and/or its implementation.

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.

After the first wave of feedback, there were three questions either asked explicitly or implied in comments, that are now included in the Q&A for clarity:

• Why is Superprotect being removed?
• Why is the WMF doing this now?
• Is there an alternative to Superprotect?

The last question refers to comments about how technically easy would it be for the WMF to restore Superprotect, and also to doubts about the WMF perhaps looking for alternative ways to achieve the same goal. What matters is that the WMF will resort to the product development process and to regular community processes to seek consensus and resolve disputes, not to technical means like Superprotect.

Suprotect was invented, created and implemented in a cloak-and-dagger operation to impose the will of the WMF onto a community that dared to disagree with some decision regarding not-ready-for-primetime software.

Instead of just enabling the community consensus by better tweaking the commons-js in the right way (or whatever was necessary to implement the only right option of opt-in), they simply used might, no arguments needed. There was never any real justification for superprotect, besides consolidating the superior power of those in SF over those unwashed masses in the community.

"Disabling" superprotect, without a sincere apology for those bad-to-the-bone deeds by those rough hackers in SF against the wikiverse, means nearly nothing. especially since it's clear, it could be reinserted in no time any time in the future. OK, the main aggressor, Erik, is no longer employed by the WMF, and those who stayed mum in the board an let this extreme hostility towards and disdain of the communities linger didn't get reelected mainly because of this, so there's hope it will not happen again, but...

This whole issue is made more conflicting with Flow in the pipeline or not (depending on how you read the different posts by different actors in development) of the WMF, despite the pushback from the communities. With the bad example of the useless hostility by the WMF against the communities, lot's of editors expect the same arrogance and pure might with the next pet project of some programmers in SF after MV and VE. I sincerely hope that they finally have learned something, alas the AGF-bucket is next to empty after all those rough actions.

@Sänger, we are here to collaborate. Collaboration requires trust, and trust requires respect. No topic justifies the hostility you are showing in your comment. Please edit it and share your opinions in a respectful way. See also Code of Conduct/Draft.

Sorry, but the hostility was initiated by the WMF with it's putsch against the community on deWP. The implementation of superputsch and the actions graved in stone this ways was nothing less then a declaration of war against deWP.

MV should never ever have been forced with pure might, without legitimate reasons, against the community, just because you could. Even the lifting of superputsch from the page was done with the explicit thread not to dare to implement community consensus. That's not something that generates trust.

Trust was severely destroyed by the WMF with its actions. The WMF has to do something to regain trust, this here ist mere saying, not real doing. On the horizont the next desaster after VE (completely and with full knowledge beforehand botched by WMF in its first implementation) and MV (I just descibed how it was seen by those outside the blinkered WMF ivory tower: installed with disdain for the community, explicitely with ruthless threads against two very big ones) is Flow, some half-baked forum impersonation, that mainly breaks the connection between talk pages and the wikiverse. But somehow some people in WMF-dev-circles seem to see the next messiah in it, and so the fear of the next desaster is a quite real one.

If you say clearly, that such huge projects like Flow, MV, VE will only be implemented after explicit consent by the communities in the usual community vetting process (MB, RfC, whatever it's called in the wikis), without caveats, and do so on some official policy page here, it would probably regain some lost trust towards the WMF.

WMF has done nearly everything to loose all trust in the past, it's quite easy to ask for, but quite impossible to get, if you're proven untrustful. You have to prove that you really changed your way of acting, that you really know by heart that the WMF is only a service agency for the real wikiverse, the communities.

Seriously, we are STILL warring over this? What's happened has happened, please please please stop making a point of pushing a view on how it has happened. The WMF want to move on, most of the communities want to move on, can we just do so and try and work it out in the future, not constantly looking back to the past? If you expect them to move on, my best advice is to do the same yourself.

The WMF wants to move on without any real apology for what it has done. And your biased writing on the other side here, to whitewash what really happened, is another sign of no real grasp of what really had happened. That's what happens, once you remove yourself from the people and rule just with might, like Erik did.

There never was any need for superputsch, all those high-paid programmers in SF should simply have implemented the community consensus od opt-in, everything else was plain ruthless brutality by those with putsch devices.