Page MenuHomePhabricator

Provide a reply to Letter to Wikimedia Foundation: Superprotect and Media Viewer
Closed, ResolvedPublic

Description

Letter to Wikimedia Foundation: Superprotect and Media Viewer was partially answered by the removal of Superprotect. However, there is one request of the letter that @Peteforsyth and others are still expecting us to address explicitly:

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.

This task is used to track progress only. The discussion is happening at https://www.mediawiki.org/wiki/Topic:Sstzmtuojrak02d5

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Qgil claimed this task.Nov 25 2015, 8:13 AM
Qgil raised the priority of this task from to Normal.
Qgil added subscribers: Qgil, Peteforsyth, Rdicerb.
Restricted Application added subscribers: Steinsplitter, Aklapper. · View Herald TranscriptNov 25 2015, 8:13 AM

Thank you for creating this item, Quim. If and when it's established that senior leadership at WMF wishes to put this issue behind them, I am willing to have some focused discussion on what a realistic answer to this provision might look like, over a year after the letter was written. I think any reasonable person would agree that no consensus established in 2014 should be regarded as unequivocally binding a year later, so this is an open question. I am happy to share my thoughts on this, and my speculations about what would be acceptable to those who signed the letter. I'd rather not get into that discussion in the absence of a clear expression of intent from senior leadership, however.

Qgil added a parent task: Unknown Object (Task).Dec 1 2015, 8:36 AM
Qgil mentioned this in Unknown Object (Task).Dec 1 2015, 8:48 AM
Qgil added a subtask: Unknown Object (Task).Dec 1 2015, 9:06 AM
Qgil mentioned this in Unknown Object (Task).
ResMar added a subscriber: ResMar.Jan 2 2016, 8:35 PM
Qgil set Security to None.
Qgil raised the priority of this task from Normal to High.Feb 26 2016, 10:45 AM
Qgil added a project: Liaisons-March-2016.

Sorry, there was no direct action in this front during February either. I was busy with other tasks that came with fixed deadlines, the Product Development Process (PDP) work itself needed (and still needs) consolidation and its own inertia, and the Wikimedia climate was not the ideal to try to push this discussion inside the WMF.

In all honesty, the climate is still very peculiar, and will continue to be in the next weeks. 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.
  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.

I hope you find this plan sensible. A lot has changed since the Letter was signed by all these Wikimedians and I honestly believe the root of the problem is solved, really solved. It's the public positioning part that objectively isn't simple these days.

Peteforsyth closed this task as Resolved.Mar 1 2016, 12:11 AM

@Qgil Thank you for the update. I appreciate your efforts, and I agree that trying to push this through in this particular month might not have been the best idea.

If it would help, I am willing to come into the office on my own time to consult about this. It could be that a face-to-face meeting would be more conducive to success. I'm happy to follow your lead on what the most useful kind of communication is, and I appreciate being kept in the loop here.

Qgil added a comment.EditedMar 1 2016, 8:21 AM

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.

Peteforsyth reopened this task as Open.Mar 9 2016, 4:54 PM

(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.)

Trizek-WMF mentioned this in Unknown Object (Task).Mar 11 2016, 10:09 AM
Nemo_bis closed this task as Invalid.Mar 14 2016, 9:38 AM
Nemo_bis added a subscriber: Nemo_bis.

Phabricator is not a proper venue for such governance matters.
Please keep updates on https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Board_noticeboard thanks.

Elitre reopened this task as Open.Mar 14 2016, 9:59 AM
Elitre added a subscriber: Elitre.

You must have missed https://www.mediawiki.org/wiki/Phabricator and/or temporarily forgotten this is a project management tool. Updates can of course be posted elsewhere, but there is no reason for interfering with Quim's legit use of this tool for his work.

Nemo_bis closed this task as Invalid.Mar 14 2016, 10:53 AM

There are reasons, see the page I linked for more context.

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.

Elitre removed a subscriber: Elitre.Mar 14 2016, 10:59 AM
Qgil reopened this task as Open.Mar 14 2016, 11:08 AM

This task is here to track my progress completing it, and it is part of my backlog. If you read the description or the discussion, no governance matter is being discussed here.

@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.

Elitre added a comment.EditedMar 14 2016, 7:17 PM

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. :)

Qgil removed a parent task: Unknown Object (Task).Mar 22 2016, 10:21 AM
Nemo_bis removed a subscriber: Nemo_bis.Mar 24 2016, 4:37 PM
Qgil added a comment.Apr 12 2016, 10:55 PM

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.

  1. Checking with @Peteforsyth whether the positioning itself is acceptable from the point of view of the Letter he promoted.
  2. 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?

Alsee added a subscriber: Alsee.EditedApr 15 2016, 1:33 AM

@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.

ResMar removed a subscriber: ResMar.Apr 15 2016, 1:38 PM
Qgil added a comment.Apr 15 2016, 3:16 PM

@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".

Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptApr 19 2016, 1:36 PM
Alsee added a comment.Apr 21 2016, 1:41 PM

@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.)

debt added a subscriber: debt.May 24 2016, 5:22 PM
Qgil changed the task status from Open to Stalled.Jun 15 2016, 1:43 PM
Qgil lowered the priority of this task from High to Normal.

My progress on this task depends on feedback from the WMF Product and Executive teams. I'm seeking to get this feedback, but when will I get it is not in my control.

Qgil changed the status of subtask Unknown Object (Task) from Open to Stalled.Jun 15 2016, 1:45 PM
Qgil closed subtask Unknown Object (Task) as Invalid.Jul 7 2016, 9:32 PM
Alsee added a comment.Jul 23 2016, 8:00 PM

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?

Qgil added a comment.Aug 2 2016, 12:43 PM

I have replied here.

Qgil closed this task as Resolved.Nov 11 2016, 12:33 PM
Qgil moved this task from October to November on the Community-Relations-Support (Oct-Dec-2016) board.

It is time to resolve this task. 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.

The Technical Collaboration Guideline includes a recommendation about local configurations that explains how a situation like the one described above should be handled. This recommendation is a draft being reviewed during this quarter, just like the rest of TCG texts (T144625). It has already been reviewed by WMF's product managers and community liaisons. Feedback about this recommendation should be posted in the related Talk page.

Alsee reopened this task as Open.Nov 12 2016, 1:33 AM

@Qgil this is either "Open" or "Declined". The purpose here was to get some sort of clarity. We definitely do not have that here. 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.

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.
Alsee added a subscriber: WhatamIdoing.EditedNov 12 2016, 1:42 PM

@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.

Qgil added a comment.Nov 14 2016, 11:19 AM

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.

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.

Qgil closed this task as Resolved.Nov 14 2016, 11:19 AM
Elitre removed a subscriber: Elitre.Nov 14 2016, 11:21 AM
Alsee added a comment.EditedNov 15 2016, 6:43 AM

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'?

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.

Qgil added a comment.Nov 15 2016, 7:25 AM

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.