I agree that a conversation can help understanding where we are at. I'm less sure about the need of a visit to the office, though, since the first candidates for this discussion that come to mind are all remote: Wes Moran and Maggie Dennis as heads of Product and Community Engagement (both in US East Coast), and myself (EU).

If this plan works for you, I can arrange a meeting. Thank you for your flexibility.

PS: I will still work on "Working on a positioning that has the consensus of WMF Product teams, and document it in the PDP." because that is a piece of the Product Development Process that needs to be clear and confirmed anyway.

(Note -- my earlier closure of this ticket was a mistake, and I didn't realize I had done it until Quim pointed it out to me today. Apologies for any confusion this caused.)

Please keep going. Your behaviour is just the argument I need in favor of working in private, because dealing with these situations is a bit of waste of too many people's time (and therefore of donors' money). I'll leave this to others now.

@Nemo_bis: When in doubt, please do not change the status of assigned tasks. Instead please add a comment suggesting the change and convincing reasons for it, as recommended by the Etiquette.
If tasks being worked on suddenly disappear from an assignee's task list due to being closed by others, organizing and managing work in public places becomes harder and less attractive for assignees.

If this ticket has gone too far in the direction of discussion (rather than mere task-tracking), then I am to blame for that. I agree with @Nemo_bis that Meta Wiki is the best place for public discussion. For anyone who believes this can be handled at the executive level rather than the board level, the page you linked does not make sense; this is one of the reasons I have suggested the Superprotect Letter's talk page. https://meta.wikimedia.org/wiki/Talk:Letter_to_Wikimedia_Foundation:_Superprotect_and_Media_Viewer#November_2015_poll:_Has_the_letter_achieved_its_goal.3F Speaking for myself, I am watching both pages.

As for this ticket -- I think it is clearly valuable. Let's not have substantive discussion here going forward, but let's not close the ticket prematurely.

To whom it may concern: I'll let you know I'm not advocating for working in private. I trust you can find evidences for this statement. Quim and Andre expressed better my concerns, I guess. The only conditions I'm "requesting" are about working in a "productive environment" (as I also stated on Meta), and I obviously don't feel like privacy is necessary for that to happen.
I do want to voice all of my colleagues, and there are too many of them, for whom unnecessary conflict with community members is a big deal; I'm tired to see them going because we can't have civil conversations everywhere, all the time.

As you can see, I edited this comment several times. I'm not sure how to convey the message above if people don't trust me when I say it, so I'm just going to leave all of my comments here, rather than deleting them, and I'm adding a smile at the end of the sentence, which probably doesn't harm. :)

might be relevant here: https://commons.wikimedia.org/wiki/Commons:Village_pump#2014_RfC_for_the_Media_Viewer

In T119595#2066032, @Qgil wrote:

I will try to get progress in this task following these steps:

1. Working on a positioning that has the consensus of WMF Product teams, and document it in the PDP.

Instead of working on a positioning specific to "permitting" local projects a specific configuration for MediaViewer (the original request of the letter), I have been drafting a more generic Opt-out process for Wikimedia wikis that addresses this question and more. It has been reviewed and fine tuned by the Technical Collaboration team. We want the Product team to have a look before publishing, just to assure that they don't see any showstoppers.

2. Checking with @Peteforsyth whether the positioning itself is acceptable from the point of view of the Letter he promoted.
3. If he still thinks that the 'clear assertion' should come through an official response from a WMF executive, I will do my best satisfying this point as well.

The official reply from a WMF executive continues to be the tricky part. With an interim ED and an executive team rebuilding itself, they have other priorities. None of the main actors of the Superprotect situation are around anymore...

At the end, I guess that the people who signed the letter want to see clear changes agreed, documented, and put in practice. If the problems described in the letter were addressed without the official response from a WMF executive, would that be enough?

@Qgil is there any chance you can immediately post the "generic Opt-out process"? That may be preferable to the chaotic events that are currently unfolding.

JDForrester gave explicit assurances that the Single Edit Tab deployment was not going to impose Visual Editor as the default for new users. The WMF just imposed VE as default for all new users. (i.e. either the deployment contains a serious BUG, or the WMF lied.) The community liaison just stated that the WMF has no intention of even discussing this problem for the next week. That week would be spent ramping up international RFCs on the subject.

"Week" was ambiguous but I'm happy to see T132806 has been opened to address the issue. Thanx.

@Alsee I want to publish the draft for an opt-out process as soon as possible, but it will not happen immediately. And it will be still a draft, not a tool ready to be used in an ongoing discussion. The "opt-out tool" makes sense in the context of T132622: Agreement on when and how Product teams communicate, not in isolation.

Alsee's description of the previous conversation is unfortunately inaccurate. @Elitre said "I'd be quite surprised if James could weigh in here this week" (=the work week that ends today). Nobody has said that "the [entire] WMF has no intention of even discussing this problem for the next week".

Some context for the opt-out discussion: https://www.mediawiki.org/wiki/Technical_Collaboration_Guideline/Vision

@Whatamidoing-WMF you might want to consider striking your comment calling my comment "inaccurate"..... unless someone at the WMF addresses the problem in the next 7 hours. It's been a week since Elitre made that comment, and James has been ignoring the issue on Phab and on his talk page for 9 days. So far no one at the WMF has been willing to discuss the faulty deployment. ("Faulty deployment" is the only good-faith option here.)

It's been over 700 days since the letter, and just under 4 weeks to the two-year mark. Maybe someone can make it a goal not to cross the two year mark?

I have replied here.

Related: https://www.mediawiki.org/wiki/Technical_Collaboration_Guideline/Community_decisions

I think that the guideline is fairly clear:

• The community needs to identify actionable blockers, such as "this software doesn't work in the local language" or "we here at the Ruritanian Wiki have a local policy about complying with the laws of Ruritania, which requires that copyrighted images be displayed with a copyright symbol" or "this tool totally breaks a critical maintenance bot" or whatever (but not "I personally don't like it" or "I think it's ugly", which aren't "actionable").
• If they don't identify blockers, then they're required to accept the software.

@WhatamIdoing it's not clear at all.

As Qgil noted above:

The problem described above was that the removal of Superprotect and associated communications didn't address this point:
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.

It seems the answer to that is "no", except no one wants to actually say it.

And as I noted above:

I for one (still) have absolutely no clue what would happen if one or more communities were to again alter the the default status of the Media Viewer.

Whatamidoing, your reply didn't answer that. If you are stating Superprotect will be redeployed, then please say so. If you are saying something else, then please actually say it.

The letter referred to "permit local projects (...) to determine the default status of the Media Viewer", which is a scenario addressed in the recommendation about local configurations:

Given these circumstances, communities should have a chance to discuss these local configurations, in these terms:

• Communities have priority defining the first configuration to be tested for features primarily affecting existing editors.
• WMF teams have priority defining the first configuration to be tested for features primarily affecting readers.
• ...
• Ultimately, the responsibility for defining product configurations belongs to the Wikimedia Foundation.

As explained in the same recommendation, the process expected to handle this negotiation is based on communities reporting blockers. Replying to the point of the letter, if any community has a problem today with MediaViewer's configuration in their project, they should file a blocker explaining their reasons.

I believe this answers the point of the letter, and this is why I think it is correct to resolve this task.

In T119595#2789681, @Alsee wrote:

I for one have absolutely no clue what would happen if one or more communities were to again alter the the default status of the Media Viewer.

If by "alter the default status" you mean bypassing the established configuration through MediaWiki's web interface for administrators, then such move would be out of process and out of the TCG recommendations.

If your question is what happens when one or more administrators of a community use the configuration tools they have at hand to bypass the decisions of a development team, please create a task about this problem. The letter this task is addressing did not mention such scenario.

And again, bringing back Superprotect or any kind of technical alternative is not an option.

In T119595#2792103, @Qgil wrote:

The letter referred to "permit local projects (...) to determine the default status of the Media Viewer"

I believe this answers the point of the letter, and this is why I think it is correct to resolve this task.

Your belief is mistaken, the point of the letter has not been answered. The mistake was in selectively misquoting the letter. The actual quote is:

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.

Will the permit local projects to determine the default status of the Media Viewer uninhibited? It it still your belief that that question has been answered? And if so, could you help me to understand, with a simple 'yes' or 'no'?

In T119595#2792103, @Qgil wrote:

If by "alter the default status" you mean bypassing the established configuration through MediaWiki's web interface for administrators, then such move would be out of process and out of the TCG recommendations.

If your question is what happens when one or more administrators of a community use the configuration tools they have at hand to bypass the decisions of a development team, please create a task about this problem. The letter this task is addressing did not mention such scenario.

The letter was addressing exactly that historical event, and was directly addressing that in asking if the WMF will permit local projects to determine the default status of the Media Viewer uninhibited. And I think that needs an answer.

However I'd also like to point out that the community only needs the "MediaWiki's web interface for administrators" if they want to change the default behavior. The community can completely disable media viewer without using administrator rights - however that would also disable media viewer for users who have preferences set to media viewer on.

If in this context the term "uninhibited" means that communities could push a decision without needing to agree with the development team, then no, the TCG recommendation explicitly says

• Ultimately, the responsibility for defining product configurations belongs to the Wikimedia Foundation.

Any use of the MediaWiki web interface practically boycotting a decision of the development team would be an act of protest, not the regular way to collaborate in software development. This is why the TCG cannot endorse such tactics, we are here documenting best practices for everybody. The historical event that motivated this letter was an act of protest. Wikimedia projects have processes to deal with protests and conflict. If something similar would happen again, we all would need to rely on those processes.

For posterity, three points seem worth noting:

• In this 2015 essay, I considered what the results of the letter were: https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2015-11-11/Op-ed#Was_the_letter_finally_successful? In particular, I cited five reasons (as expressed by those signing the letter) why the Wikimedia Foundation's response was considered inadequate. It seems strange to me that these five reasons were never discussed here, when WMF staff determined that this task had been "resolved"...I'm including the link so that others may draw their own conclusions from the original text.
• This item is titled "Provide a reply to Letter to Wikimedia Foundation: Superprotect and Media Viewer." However, on the page linked, there is no mention of any letter. Quite odd, for something to be characterized as a "reply" to something whose existence it doesn't mention.
• As of December 2019, the page linked is still marked as a "draft." Also odd for a draft document to be considered a "reply."

@Aklapper, after I posted the comment above, I see you have marked the page @Qgil had identified as constituting a "reply" as "historical/obsolete". https://www.mediawiki.org/w/index.php?title=Technical_Collaboration_Guidance/Community_decisions&diff=3555787&oldid=2534515 Could you explain?

I think it is confusing to anyone following this issue to see a ticket, whose goal was to "provide a reply...," marked as resolved...when no reply (or even formal acknowledgment) ever occurred. It would be interesting, at least, to understand why a document previously considered significant is now considered an obsolete draft.

Hi @Peteforsyth, could you elaborate? My edits say See [[Wikimedia Product Guidance]] for an evolution / follow-up of the [[Technical Collaboration Guidance]] as the TCG is not worked on anymore and has been superseded. Not sure that answers your question though...

OK, I (sort of) understand. I also don't see how something described as an "evolution" constitutes a "reply..." but I suppose if there were a clearer answer available, it would have been mentioned by now.

To the extent that [[Wikimedia Product Guidance]] constitutes a "reply", it is a profanity-laced one.

If the Foundation tries to actually apply that "guidance" it is going to railroad us into the exact same crisis or worse. I'm afraid the Foundation will escalate the next conflict into community-banners at the top of every article telling readers to stop donating. But don't worry, the Foundation considers the issue "Closed, Resolved". Up until the moment it isn't.

@Alsee: If you do not wish to contribute in a constructive way to this discussion, then I suggest you spend your time on other topics. Thanks for your understanding.

@Aklapper if I noticed that the Foundation had left its servers set with the default password, or even worse put gasoline in the fire extinguishers, it is constructive contribution to alert the Foundation of that failure and the very real and very grave consequences of failing to constructively address the issue. Even if my reports are not warmly received and even if they are not immediately successful.

To the extent that the Product Guidance is intended to be a response to this Phab task, it's like putting gasoline in your fire extinguishers. At this time, the number of community members who know what the Product Guidance says is close to zero. Sooner or later the Foundation is going to appeal to that Guidance trying to address some disagreement with the community. The community will almost certainly interpret it as a two-word-profanity directed at the community. An initially minor issue will almost certainly be grossly inflamed, and the result will likely be equal to or worse than the Superprotect incident. It is constructive to ensure that the Foundation is acutely aware of the likely severe consequences of failing to more constructively address the issue.

My "Don't worry" was a bit sarcastic, so I apologize for that bit.

I'd compare this to the Flow situation. I extensively reported that the Flow design was flawed, that the community was not going to accept it, and that we should stop wasting time and money continuing new development on a doomed project. My reports were not warmly received and they were not successful in the short run. However in the long run the Foundation ran the global Talk consultation. In that consultation the Foundation determined that the Flow design was flawed, that the community was not going to accept it, and that new development on the project should be terminated. It is constructive and important to tell the Foundation truths that it is resistant to hearing.

I would welcome any advice you can offer on how we could have reached that result, putting a stop to Flow, more quickly and more painlessly. Perhaps I can apply such advice to be more constructive and more effective here.