Page MenuHomePhabricator

Remove Flow from Meta-Wiki
Closed, ResolvedPublic

Description

Please uninstall the Flow extension from Meta-Wiki. Relevant discussion: https://meta.wikimedia.org/w/index.php?title=Meta:Babel&curid=69328&diff=16251209&oldid=16240965.

The extension was installed in https://gerrit.wikimedia.org/r/114088.

Explicit consensus for complete removal (and lack of consensus for any partial survival of the extension): https://meta.wikimedia.org/w/index.php?title=Meta:Babel&oldid=16337330#Proposal_to_remove_Flow_on_Meta-Wiki

Details

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

The RFC on Meta has closed with a clear consensus to remove Flow. Note that this was not an RFC to reduce active Flow pages to zero, this was an RFC for the extension be uninstalled as was done on Enwiki. (T148611)

Alsee raised the priority of this task from Lowest to Needs Triage.Jan 23 2017, 11:02 PM

I think it's reasonable to wait for T154816: Migrate ORES_paper flow board from Meta to Mediawiki.org to be resolved, if possible, but we should set a firm deadline. Is four weeks enough time?

Change 333860 had a related patch set uploaded (by MarcoAurelio):
Remove Flow from Meta-Wiki

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

I think it's reasonable to wait for T154816: Migrate ORES_paper flow board from Meta to Mediawiki.org to be resolved, if possible, but we should set a firm deadline. Is four weeks enough time?

4 weeks seems unnecessarily long, but should be tolerable.

It seems about time to schedule the configuration change and send notices. Can a week or two of windows be added to https://wikitech.wikimedia.org/wiki/Deployments ?

Flow board still needs to be ported to mw.org and a maintenance script run
afterwards to convert remaining Flow boards before being removed I think.

Flow board still needs to be ported to mw.org and a maintenance script run
afterwards to convert remaining Flow boards before being removed I think.

That would be nice, but not necessary: we're not dropping the database tables any time soon. Also, if there is really an urgency to keep the content the script for conversion to wikitext is available.

<rant>Sometimes I would really want a more firm standpoint from WMF against people moving backwards… </rant>

Standing against the communities which gave success to the WMF movement ain't going to work. Saying that Flow is moving forward is also a disputable statement, specially when so much people has objected to its use on that project, some of those because they ain't able to use that software at all. World is not fair, but excluding community members from discussion pages is not what I'd call moving forward.

I asked for a status update regarding T154816: Migrate ORES_paper flow board from Meta to Mediawiki.org at T154816#3038183. This task turns three years old in a couple of days. ;-) But more seriously, I'd like to see this task resolved in the next week or two. March 1 seems like a reasonable deadline.

One way or another, I'm going to call March 1, 2017 a hard deadline. We will not be saving posts to a Flow-backed version of https://meta.wikimedia.org/wiki/Research_talk:ORES_paper after this date.

T154816 is not a hard blocker, just a nice to have (why not make a couple persons happy if it costs us nothing). Doing T156113 before the disabling is instead definitely recommended, though not absolutely necessary per T156113#2964757.

Since there is no way in Phabricator to distinguish "real blockers" from "things you'd also do at the same time in an ideal world", I'm removing the soft subtask again.

<rant>Sometimes I would really want a more firm standpoint from WMF against people moving backwards… </rant>

<rant>Agreed. And the necessary prerequisite is to correctly identify "forward" in the first place. During the Flow prototype stage numerous community members told Flow's lead designer that the project was going in the wrong direction. He was told that it could never be successfully deployed as a replacement for Talk pages. The designer aggressively ignored critical project requirements. Uninstalling a non-viable project is a step forwards.</rant>

I ran the preparatory scripts.

Thanks to @Matiia for doing the 4 steps above.

Change 333860 abandoned by Dereckson:
Remove Flow from Meta-Wiki

Reason:
Per discussion on #wikimedia-operations, we'll disable it socially, but will leave the Flow extension installed.

That will avoid to get an inconsistent state in the logs, contributions.

The meta RFC is still satisfied as there isn't any active Flow page on meta. (and socially won't), as steps have been taken to move the last one to another wiki.

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

Change 333860 restored by MarcoAurelio:
Remove Flow from Meta-Wiki

Reason:
This is not appropriate, Dereckson. The discussion at -operations is that the contribs of Flow talk page manager can stay where they are w/o any problems so far. Restoring. Please implement the community consensus. If this was done for enwiki, this can happen for Meta-Wiki as well. Nothing broke there and nothing will break here either.

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

I strongly agree with MarcoAurelio. Installing Flow on Meta-Wiki never had consensus and there's now a strong consensus to remove the extension completely. The discussion even specifically addressed whether this meant removing Flow from all pages or completely uninstalling the extension.

If there are technical reasons that Flow cannot be uninstalled from Meta-Wiki currently, I would like to know what those reasons are specifically in Phabricator Maniphest tasks so that these issues can be addressed.

As @MZMcBride said, I don't think there are technical reasons for not doing this. The English Wikipedia had way more Flow boards enabled and got removed there per request of its community. Now there's this request, with large community consensus and no active Flow boards. It should be even easier to perform, even if afterwards we need some manual work to do. The community has asked clearly that they want the feature removed (@Alsee even opened a section in that discussion for if it was any doubt), not socially disabled, which is an euphemism for not doing what it was explicitly requested. I don't think they are serious problems for this not to be done, but some personal choices of not wanting Flow gone from Meta; and that is not appropriate when executing valid community consensus. The community at large had their opportunity to voice their personal opinion, and the result was that we want the feature removed. We ain't requesting anything impossible to do, or prohibited or absurd (ie: remove CheckUser or CentralAuth). Thank you.

@Dereckson: I missed the discussion in #wikimedia-operations. I'm trying to better understand the status of this task. Are you unwilling to deploy https://gerrit.wikimedia.org/r/333860?

@Dereckson: I missed the discussion in #wikimedia-operations. I'm trying to better understand the status of this task. Are you unwilling to deploy https://gerrit.wikimedia.org/r/333860?

I'm more than willing.

@demon @MZMcBride The collaboration team have some reserves about the logs integrity: it will be difficult to see the previous contributions.

As much, as an alternative discussion, it's offered to keep the extension, so it's still possible to explore the full contributions, but don't have any Flow page active.

To remove the extension is possible, but will be at the detriment of the capability to explore past contributions.

@demon @MZMcBride The collaboration team have some reserves about the logs integrity: it will be difficult to see the previous contributions.

Integrity? What?

To remove the extension is possible, but will be at the detriment of the capability to explore past contributions.

Why did we not have this discussion with enwiki?

There were two flow boards: the ORES talk page has been moved to mw.org and the contributions can be seen there (also in Special:Contributions). As for the development test page, I daresay I won't miss that. The comments on there were: 1 thread of complaint and 1 thread of test. Given the clear, explicit consensus to remove the extension in the RfC, this isn't an excuse not to honour it.

@demon @MZMcBride The collaboration team have some reserves about the logs integrity: it will be difficult to see the previous contributions.

Integrity? What?

The concern here was that the rendering of e.g. https://meta.wikimedia.org/wiki/Special:Contributions/Flow_talk_page_manager would break, because the Topic namespace would go away. Flow also doesn't let you delete pages in the Topic namespace, and without Flow the namespace doesn't exist. So the way I worked around this on enwiki was:

  • Uninstall Flow
  • Temporarily add $wgExtraNamespaces[2600] = 'Topic'; to the config
  • Use deleteBatch.php to delete all pages in the Topic namespace
  • Remove the $wgExtraNamespaces config

That's a bit ugly, but we should just do the same thing on metawiki, since there's only a test board there and the only real board was transwikied. If we ever wanted to reinstall Flow there, we could undelete the relevant pages: they wouldn't be gone forever, they just wouldn't be viewable or undeletable without reinstalling Flow (because of content model issues).

I've scheduled this (the uninstall + namespace + deleteBatch dance) for the deployment window we already had (for T159047) at 22:00 UTC (i.e. 7 minutes from now).

I'm not sure we need deleteBatch.php in this case since it's already down to just one page, but otherwise that plan sounds good. Let's get this on Wikitech.

I'm not sure we need deleteBatch.php in this case since it's already down to just one page

We do need it, there is more than one topic page: https://meta.wikimedia.org/wiki/Special:AllPages/Topic:

, but otherwise that plan sounds good. Let's get this on Wikitech.

It's already there, for the deployment window that's right now. Matt is doing the cawiki change, I'll coordinate with him.

I'm not sure we need deleteBatch.php in this case since it's already down to just one page

We do need it, there is more than one topic page: https://meta.wikimedia.org/wiki/Special:AllPages/Topic:

Ah ok, I understand what you mean.

, but otherwise that plan sounds good. Let's get this on Wikitech.

It's already there, for the deployment window that's right now. Matt is doing the cawiki change, I'll coordinate with him.

I meant more a [[Uninstalling Flow]]

, but otherwise that plan sounds good. Let's get this on Wikitech.

It's already there, for the deployment window that's right now. Matt is doing the cawiki change, I'll coordinate with him.

I meant more a [[Uninstalling Flow]]

Oh, the procedure for it, gotcha. Will do that right after I do it on meta so it's fresh in my mind.

Change 333860 merged by Catrope:
[operations/mediawiki-config] Remove Flow from Meta-Wiki

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

Mentioned in SAL (#wikimedia-operations) [2017-03-02T22:46:23Z] <catrope@tin> Synchronized dblists/: T63729: disable Flow on metawiki (duration: 00m 58s)

Catrope claimed this task.

This is now done

, but otherwise that plan sounds good. Let's get this on Wikitech.

It's already there, for the deployment window that's right now. Matt is doing the cawiki change, I'll coordinate with him.

I meant more a [[Uninstalling Flow]]

Oh, the procedure for it, gotcha. Will do that right after I do it on meta so it's fresh in my mind.

Done now: https://wikitech.wikimedia.org/wiki/Flow

Keegan subscribed.

I would like to thank all participants in this and related tasks here on Phabricator for their communication and handling of what was and is a delicate and sometimes tense matter on the wikis. I truly appreciate it from everyone.

@demon @MZMcBride The collaboration team have some reserves about the logs integrity: it will be difficult to see the previous contributions.

Integrity? What?

The concern here was that the rendering of e.g. https://meta.wikimedia.org/wiki/Special:Contributions/Flow_talk_page_manager would break, because the Topic namespace would go away.

It's also the actual logs:

  1. Valid log entries don't render, so you just get "flow-delete-post (Test)", instead of something like "deleted a post on "Test" on Structured Discussions/Sandbox (delete test post)" (these are different examples, but the same action type; correct version also has proper links): https://en.wikipedia.org/w/index.php?title=Special%3ALog&type=delete&user=Fram&page=&year=2016&month=9&tagfilter=&subtype=
  2. The namespace stops existing, which still causes breakage even with https://wikitech.wikimedia.org/wiki/Flow . See https://en.wikipedia.org/w/index.php?title=Special%3ALog&type=&user=Roan+Kattouw+%28WMF%29&page=&year=2016&month=-1&tagfilter=&hide_thanks_log=1&hide_patrol_log=1&hide_tag_log=1&hide_review_log=1 (namespace is missing even for the workaround deletes).

1 can be fixed with a rWMME entry as for 2 I'd not care much, as the Topics are either converted to Wikitext using the script, or deleted, or both. As for Meta-Wiki, nothing broke after uninstallation.

Considering that the extension is uninstalled, I'd say those log issues are pretty insignificant.

However I think it suggests that new extension development should have a checklist item to consider and test uninstallation. We wouldn't want some other extension causing hard-to-reverse problems in the future.

Actually please follow the discussion at T186463. This task has been long closed. Thanks.

1 can be fixed with a rWMME entry

Before we identify an alternative technical solution (e.g. code duplication to put log formatting in WikimediaMessages), we should first identify a technical problem with the simplest solution (deleting SD boards, preventing new ones from being created, and leaving the extension installed).

Considering that the extension is uninstalled, I'd say those log issues are pretty insignificant.

However I think it suggests that new extension development should have a checklist item to consider and test uninstallation. We wouldn't want some other extension causing hard-to-reverse problems in the future.

This applies to any extension with log types, not just StructuredDiscussions. It's expected behavior. There is no solution other than code duplication (which is okay if that's the best solution, but no one has explained why it is in this case).

This applies to any extension with log types, not just StructuredDiscussions. It's expected behavior. There is no solution other than code duplication (which is okay if that's the best solution, but no one has explained why it is in this case).

The Flow logs are OK as-is, but I have a possible generic solution that can handle (probably) any future extension. Wouldn't it be possible to run the logs through the extension and store the results as plaintext? Then you don't need the code anymore. Any links would generally point to non-existent objects anyway.

This applies to any extension with log types, not just StructuredDiscussions. It's expected behavior. There is no solution other than code duplication (which is okay if that's the best solution, but no one has explained why it is in this case).

The Flow logs are OK as-is, but I have a possible generic solution that can handle (probably) any future extension. Wouldn't it be possible to run the logs through the extension and store the results as plaintext? Then you don't need the code anymore. Any links would generally point to non-existent objects anyway.

But then users wouldnt be able to select language. It also makes searching through logs much more difficult (see issues with checkuser logs).