Uninstall Flow from Commons
Closed, DeclinedPublic

Description

Consensus to uninstall the Flow extension has been established on Commons.

Note: This is not a request to reduce Flow pages to zero or "socially disable" Flow.
Exact text for which consensus was established: Uninstall Flow, as was done on English Wikipedia and Meta wiki.

For helpful previously used procedures see:

  • T63729 Remove Flow from Meta-Wiki
  • T148611 Plan to disable Flow on Enwiki
There are a very large number of changes, so older changes are hidden. Show Older Changes
MarcoAurelio added a comment.EditedFeb 5 2018, 12:05 PM

The only pages using flow seem to be https://commons.wikimedia.org/wiki/Commons_talk:Flow and https://commons.wikimedia.org/wiki/Commons_talk:Flow/tests

You should handle those pages before removing the feature from Commons.

There are instructions on Wikitech at https://wikitech.wikimedia.org/wiki/Flow on the how-to.

MariaDB [commonswiki_p]> SELECT CONCAT('Topic:', page_title) AS page_title FROM page WHERE page_namespace=2600;
+------------------------+
| page_title             |
+------------------------+
| Topic:Smtpj8utllnryc3k |
| Topic:Smtrcre7hhh81d4z |
| Topic:Smtrd0oxngijcsq9 |
| Topic:Smtsy0wtqqml28ke |
| Topic:Smtt99p7yp47d4wc |
| Topic:Smy2af0luk1wz5es |
| Topic:Sn6grtdjn70cisb7 |
| Topic:Sn6hmfa58460l238 |
| Topic:Sn8f3y8qir8oxzjb |
| Topic:Sn8f417nuorxes8d |
| Topic:So4juczs8f56jvp5 |
| Topic:Ssg1557c6pg1r8zg |
| Topic:Tg8hmw5fl6cc5c35 |
| Topic:Ty0zgb6jtxsi07hk |
| Topic:Ty2mpskkqgqx26k4 |
| Topic:Ty2ntvbvaj5ymdoj |
| Topic:Ty36xz9nqpmqx36d |
| Topic:Ty3afiw134mdwu6a |
+------------------------+
18 rows in set (0.00 sec)

@Mattflaschen-WMF at gerrit you added:

Code-Review-2
Under discussion by the team. Do not merge at this time.

It's been a week since progress was halted without explanation. Could you or anyone explain the holdup?

It's been a week since progress was halted without explanation. Could you or anyone explain the holdup?

It is explained in Gerrit and you even quoted it yourself: "Under discussion by the team." (Generally speaking, there sometimes seem to be expectations that software development/maintenance allows to "drop any other stuff you work on or discuss, and only concentrate on this very task". That's usually not the case.)

Nemo_bis triaged this task as Normal priority.Feb 13 2018, 1:35 PM
Nemo_bis added a subscriber: Nemo_bis.
Alsee added a comment.Feb 13 2018, 1:37 PM

@Aklapper I did not ask for all other work do be dropped. I was amazed when this task was picked up within four minutes. I was even more impressed when a patch was written and uploaded to gerrit within fifteen minutes.

I am asking: why did someone order a halt on the work? Your response was unhelpful. "Under discussion by the team" explains nothing. What is the issue that requires discussion? It's been a week. Posting a comment hardly requires a major diversion from ongoing work.

I am asking: why did someone order a halt on the work?

The question does not make any sense as nobody ever stated that. Your response is unhelpful.
Indeed, it's only been a week.

@Aklapper In fact a -2 is a veto. The steps to remove Flow from a project are properly documented here. Any deployer can take care of doing the needful to submit this change IMHO. Maybe the collaboration team could keep us updated? Otherwise this would seem like a pocket veto that should be overriden.

@Aklapper please don't go in pointless circles. Progress on this task was halted with a -2 code review and an order "Do not merge".

If you know why, it would be appreciated if you posted that information. If you don't know the answer, it would appreciated if you could help find someone to reply here with that answer.

I have a very understanding and generous view on a reasonable timeframe for progress. I had no complaints when there was a delay in the task to remove Flow from Meta. I am more than happy to help calm any impatient voices. I am happy and helpful so long as it is sufficiently clear that the task is constructively proceeding to completion.

It is currently unclear whether this task is indeed proceeding towards completion. In fact one staff member has explicitly expressed (on Commons) an intention to disregard and deny consensus. I am very much hoping that is not the case. I would very much appreciate clarity that this task isn't being silently and permanently diverted to dev/null.

Alsee added a comment.EditedFeb 16 2018, 8:35 AM

@Zoranzoki21 thanks for so quickly addressing this task. A four minute response time and a 15 minute gerrit submission was impressive. Could you provide an update on why your efforts were halted? As well as if or when the task expected to be completed?

Zoranzoki21 added a subscriber: demon.EditedFeb 16 2018, 9:46 AM

@Alsee I am sorry, but I am blocked until 20th February on gerrit by @demon and I can not provide informations because I have not access to gerrit

I think any gerrit administrator should just remove the -2 here. There is nothing that halts this task from going forward.

Alsee added a comment.Feb 16 2018, 1:23 PM

@Zoranzoki21, thanks. Is the block potentially related to this task???!?

@Zoranzoki21, thanks. Is the block potentially related to this task???!?

No. I no know status related for this. On patch is -2 with reason Under discussion by the team. Do not merge at this time.

Alsee added a comment.EditedFeb 23 2018, 11:12 AM

@Mattflaschen-WMF @Aklapper or anyone else:
The RFC was closed on January 26. I'm planning to post a 'one month update' to the Village Pump RFC at Commons, on or around Feb 26.

It has now been 18 days since this task was effectively halted with a -2 code review. It has been 11 days since I asked why. Could someone either (A) explain the holdup - something significantly more informative than "under discussion", or (B) remove the -2 and indicate that this task is proceeding towards completion? Thanx.

I am hoping to provide some update status other than "The WMF halted the task three weeks ago with no clear explanation, and the WMF has been non-responsive for two weeks when asked why".

@Alsee: I already provide a response above in T186463#3966733. No need to ping me again as our understandings of "reply" or "responsive" might differ. Thanks.

Sau226 added a subscriber: Sau226.Feb 25 2018, 2:33 PM

What exactly needs to be discussed before this can go ahead? "Under discussion" can mean a lot of stuff and isn't specific enough (maybe something like "there are technical issues related to this" or something similar would be better).

Stryn added a subscriber: Stryn.Feb 25 2018, 2:57 PM
Arbnos added a subscriber: Arbnos.Feb 25 2018, 7:13 PM
demon removed a subscriber: demon.Feb 25 2018, 8:01 PM
DannyH added a subscriber: DannyH.Feb 26 2018, 5:26 PM

Hi everyone: Sorry this has taken a little while for us to respond; it's been a busy time at the Foundation over the last month.

We want to be thoughtful about our response to the RfC, and we're still talking internally about a couple of options. I expect we'll have a response to post by the end of this week. If it takes longer than that, I'll post here and explain what's going on.

@DannyH thanks for replying. I can hang on for a response "by the end of this week". However I do have to pointedly note that you were also non-responsive on why the task was halted and what is being discussed.

The clearly deliberate decision not to communicate comes across very badly on multiple levels.

@Alsee: I don't see how the unrealistic expectation that questions asked by individuals will have to receive a [quick] response by other individuals is constructive criticism. Please refrain from such postings. Thanks.

@Aklapper Add me back as subscriber, when here happen update of task. I can not to receive spam. Noone no like spamming. Thanks!

If you don't care for what you want to subscribe to no one will do it for you. We ain't your footmen. There's a new mute feature that allows you to keep subscribed to a task while at the same time not receive any notifications from it.

If you don't care for what you want to subscribe to no one will do it for you. We ain't your footmen. There's a new mute feature that allows you to keep subscribed to a task while at the same time not receive any notifications from it.

Please refrain from personal attack on me. Thank you!

Please refrain from personal attack on me. Thank you!

Saying that we're not your servants and that you should care for what you want to subscribe to is, simply, the truth. If you want to take that as a personal attack it's your choice. Conversation over.

Zoranzoki21 removed Zoranzoki21 as the assignee of this task.EditedFeb 28 2018, 7:52 PM
Zoranzoki21 removed a project: User-Zoranzoki21.
Zoranzoki21 removed a subscriber: Zoranzoki21.

Please refrain from personal attack on me. Thank you!

Saying that we're not your servants and that you should care for what you want to subscribe to is, simply, the truth. If you want to take that as a personal attack it's your choice. Conversation over.

No, I no told for it to is personal attack. I told for We ain't your footmen.

In order not to start to talk about gerrit, I end this with the following: This is normal and correct to you and others say without to any think to message is personal attack:

On Wed, 2018-02-28 at 18:36 +0000, Zoranzoki21 wrote:
> Zoranzoki21 added a comment.
>
>   @Aklapper Add me back as subscriber, when here happen update of
> task. I can not to receive spam. Noone no like spamming. Thanks!

It is up to you what stuff you follow, not to me...
I do not plan to start a list who asked me where to subscribe them to
what after what - I don't have time for that, sorry. :)

Thanks for your understanding.

No: We ain't your footmen.

All the best,
Zoran.

P. S. Sorry for bad English.

Alsee added a comment.Mar 1 2018, 1:05 AM

@Aklapper I took note of your request that I not ping you. I explicitly avoided doing so. However you just pinged me. And pinged me with unreasonable criticism to boot.

I don't see how the unrealistic expectation that questions asked by individuals will have to receive a [quick] response

It has been weeks. That is above and beyond a reasonable time frame for a simple answer. Furthermore you and other staff have already been taking the time to post here. The time-expense here is entirely due to replies-without-answers. An actual answer would have avoided this entire conversation.

As for questions asked by individuals, I believe that is a bad faith objection. I'm sure I'm more acutely aware of my status as a random individual than you are. I am firmly of the position that anyone at the WMF can blow off any individual at any time. Just utter the magic words: "come back when you have a demonstrated consensus". I assure you I will immediately vanish. I am an irrelevant random yahoo on the internet. You will not hear from me again on this subject. Not unless and until I return speaking with the official consensus voice of the community.

The reason I call it a bad faith objection is because I think you well know I am here making a good faith inquiry on behalf of the community. I think you well know there is a latent community consensus for this question. I hope you know that insisting that an explicit consensus be established would only serve to degrade WMF-community relations.

I don't understand why it's so hard for the WMF and community to work as good faith partners. We're all supposed to be on the same team. Whatever the Flow discussion is, the WMF shouldn't be fighting to lock the community out of the room.

Danny said he would provide a response by the end of the week. If you wish to reply with a constructive answer before then, that would be great.

This comment was removed by Gryllida.
This comment was removed by Gryllida.
Dcljr added a subscriber: Dcljr.Mar 1 2018, 4:46 AM

Hey, here's an idea: everyone stop commenting on Alsee's behavior and limit your posts to discussing the task.

DannyH added a comment.Mar 3 2018, 2:40 AM

Hi everyone, I posted a response to the RfC on Commons village pump:

https://commons.wikimedia.org/wiki/Commons:Village_pump#WMF_response_to_proposal_to_uninstall_Flow

We're currently working on T188577: Add a config setting making all Flow boards read-only which will be what we use to disable Flow on Commons.

It's unclear why you're treating Wikimedia Commons differently than the English Wikipedia, where Flow was fully disabled. Is there a reason you appear to be intentionally overstating the difficulty of disabling the Flow extension? We've already done this for other wikis.

Alsee added a comment.Mar 3 2018, 6:32 AM
This comment was removed by Reedy.
gh87 added a subscriber: gh87.Mar 3 2018, 6:46 AM
gh87 removed a subscriber: gh87.

The comment posted on the village pump doesn't reflect Wikimedia best practices, in particular where it suggests that once an extension is installed we commit to keep it forever because otherwise the logs would not look pretty. The real policy is that we install things when they pass some strict requirements and we uninstall them when they do more harm than good, otherwise our technical debt and interface clutter would always go up.

So, this request must be satisfied as is; but we can also address the concerns raised by Danny in separate tasks such as T188812 and T188806.

Krenair added a subscriber: Krenair.Mar 3 2018, 2:49 PM

The comment posted on the village pump doesn't reflect Wikimedia best practices, in particular where it suggests that once an extension is installed we commit to keep it forever because otherwise the logs would not look pretty. The real policy is that we install things when they pass some strict requirements and we uninstall them when they do more harm than good, otherwise our technical debt and interface clutter would always go up.

The extension will still be in production on other wikis, so technical debt shouldn't be really be a problem. I don't think Interface clutter will be left around if the Flow developers do as they've suggested.
If we were talking about a global undeployment I might suggest that instead the history/logs/etc. be converted where possible to be in a core-native format (wikitext) and the extension code removed from the production servers, but we're not.

Jeff_G awarded a token.Mar 3 2018, 7:10 PM
Jeff_G added a subscriber: Jeff_G.
Teles added a subscriber: Teles.Mar 4 2018, 10:47 AM
Alsee added a comment.Mar 4 2018, 11:13 PM

+1 to @Krenair's history/logs/etc. be converted where possible to be in a core-native format (wikitext).

This is clearly the correct technical approach. Any extension has a presumption that it may be uninstalled at some point. That's one of the most important design reasons why code is structured into extensions.

This also resolves any concerns about logs where Flow has already been uninstalled (EnWiki and Meta). The Commons request to uninstall is now the third, and that pattern is highly likely to continue. This fix resolves uninstall concerns, and avoids the serious social costs of not uninstalling. Most significantly, it would be irresponsible or even malicious if anybody ever argued in favor of technical flaws because they believe there shouldn't be a global uninstall in the future. Given the overwhelming rejection of Flow by editors, there is an undeniable prospect that Flow may unavoidably face the same future as LiquidThreads.

@Jdforrester-WMF weighed in on Commons in September 2017, apparently:

I have decided not to de-install this software from this or any other wiki without a solid technical reason for doing so. Custom configurations for each wiki slightly slow down the sites for every reader and editor, and complicates Ops' work, which, unlike the assertions above, actually is a security risk.

The comment about "custom configurations" seems to hold no weight when you consider that Flow is disabled by default and only enabled on wikis listed at https://noc.wikimedia.org/conf/dblists/flow.dblist. Simply removing "commonswiki" from that list, as we did with "enwiki", would largely resolve this task.

The "slightly slow down the sites" comment might be worthy of a response, were it backed by any substantiation or evidence. As it is, it appears to be a classic appeal to fear argument that should be discarded.

Change 420131 had a related patch set uploaded (by Catrope; owner: Catrope):
[operations/mediawiki-config@master] Enable $wgFlowReadOnly on commonswiki

https://gerrit.wikimedia.org/r/420131

Change 420131 had a related patch set uploaded (by Catrope; owner: Catrope):
[operations/mediawiki-config@master] Enable $wgFlowReadOnly on commonswiki

https://gerrit.wikimedia.org/r/420131

Scheduled for deployment on Monday March 19 at 18:00-19:00 UTC.

Alsee added a comment.Mar 17 2018, 1:59 PM
This comment was removed by Reedy.

Change 420131 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable $wgFlowReadOnly on commonswiki

https://gerrit.wikimedia.org/r/420131

Mentioned in SAL (#wikimedia-operations) [2018-03-19T18:33:58Z] <catrope@tin> Synchronized wmf-config/InitialiseSettings.php: Enable $wgFlowReadOnly on commonswiki (T186463) (duration: 00m 57s)

Catrope closed this task as Resolved.Mar 19 2018, 6:34 PM
Catrope claimed this task.
Reedy added a subscriber: Reedy.Mar 20 2018, 10:05 PM
MZMcBride reopened this task as Open.Mar 21 2018, 1:45 AM

Re-opening this. I'm not sure how much clearer this request could be. It's very explicitly about uninstalling Flow from Commons. That's the title of the task ("Uninstall Flow from Commons") and the task description goes on to further clarify. According to https://commons.wikimedia.org/wiki/Special:Version, Flow is still installed.

It's unacceptably misleading to mark a task in Phabricator Maniphest, our issue tracker of record, as "closed, resolved" when this is not the case. If you want to file a task about setting Flow to "read-only mode" on Commons and mark that task as resolved, that would be appropriate. If you're choosing to decline this task, then you should mark that way.

Aklapper closed this task as Declined.Mar 21 2018, 6:51 AM

Indeed, changing to declined. (I'm afraid https://meta.wikimedia.org/wiki/Limits_to_configuration_changes applies.)
https://gerrit.wikimedia.org/r/420131 which is not the requested technical solution was applied instead, with the same visible outcome to an end user.

Change 408073 abandoned by Zoranzoki21:
Disable Flow extension on Commons

Reason:
Ok than. I will abandon this change.

https://gerrit.wikimedia.org/r/408073

Change 408073 abandoned by Zoranzoki21:
Disable Flow extension on Commons

Reason:
Ok than. I will abandon this change.

https://gerrit.wikimedia.org/r/408073

I am much confused, but I abandoned my patch about uninstalling flow from commons because this is closed first as resolved, than reopened and than as invalid.

Please read my previous comment.

@Aklapper

Indeed, changing to declined. (I'm afraid https://meta.wikimedia.org/wiki/Limits_to_configuration_changes applies.)
https://gerrit.wikimedia.org/r/420131 which is not the requested technical solution was applied instead, with the same visible outcome to an end user.

added this entry, any things to be clarified more better?

Restricted Application removed a subscriber: Liuxinyu970226. · View Herald TranscriptMar 24 2018, 8:19 AM
Restricted Application added a project: Growth-Team. · View Herald TranscriptSep 2 2018, 10:35 AM