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:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | Catrope | T186463 Uninstall Flow from Commons | |||
| Open | None | T188806 create a Flow uninstall script | |||
| Open | None | T96301 Solution for disabling Flow on a page | |||
| Resolved | matthiasmullie | T90075 Update and retest the convertToText script | |||
| Invalid | None | T107097 convertToText.php not working | |||
| Open | None | T230683 New syntax for multiline list items / talk page comments | |||
| Open | None | T114432 [RFC] Heredoc arguments for templates (aka "hygienic" or "long" arguments) | |||
| Open | None | T246960 Publish Technical RfC: new syntax for multi-line list items/talk page comments | |||
| Resolved | • ppelberg | T256694 Add RfC link to "switching disabled" exception message | |||
| Invalid | • Whatamidoing-WMF | T258850 Make volunteer stakeholders aware of RfC for implementing new syntax for multi-line comments | |||
| Open | None | T256324 References may disappear in DiscussionTools when switching from visual to wikitext (or saving) | |||
| Open | None | T317352 Remove switching restrictions |
@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.
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.
@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?
I think any gerrit administrator should just remove the -2 here. There is nothing that halts this task from going forward.
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.
@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.
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).
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.
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.
@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.
Hey, here's an idea: everyone stop commenting on Alsee's behavior and limit your posts to discussing the task.
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.
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.
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.
+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
Change 420131 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable $wgFlowReadOnly on commonswiki
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)
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.
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.
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.
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?