Wikimedia Bugzilla is closed!

I did not see this mentioned anywhere on https://wikitech.wikimedia.org/wiki/Deployments (link welcome if I missed it). 
The patch is missing any link to a bug report or on-wiki discussion, as MZMcBride correctly pointed out. And I have no idea what the "one page of meta" is, as the commit message is so vague.

I really hope I missed something, otherwise this would look like pretty bad communication.

(In reply to Andre Klapper from comment #1)
> I did not see this mentioned anywhere on
> https://wikitech.wikimedia.org/wiki/Deployments (link welcome if I missed
> it). 
> The patch is missing any link to a bug report or on-wiki discussion, as
> MZMcBride correctly pointed out. And I have no idea what the "one page of
> meta" is, as the commit message is so vague.
> 

It's https://meta.wikimedia.org/wiki/Talk:Flow/Developer_test_page . You can find flow pages by doing searches like https://meta.wikimedia.org/w/index.php?title=Special:Search&search=%22This%20talk%20page%20has%20been%20taken%20over%20by%20a%22&fulltext=Search&profile=all&redirs=1 (Surely flow should add a page property or something to flow pages so that they can be found sanely?)

(In reply to Bawolff (Brian Wolff) from comment #2)
>(Surely flow should add a page property
> or something to flow pages so that they can be found sanely?)

Filed as bug 61747

Andre: From https://wikitech.wikimedia.org/wiki/Deployments: Tuesday February 18th, "enable Flow on meta test page and a few more mediawiki.org talk pages" :)

I got a request from the WMF Programs Evaluations team to enable Flow on the talk page of https://meta.wikimedia.org/wiki/Programs:Evaluation_portal/Learning_modules. The extension's been tested in production for 2 months now (on mw.org, as well as English Wikipedia for about 2 weeks now), but we wanted to be sure to enable it on a test page on Meta before releasing it on a real discussion page. 

This is all following along our course of enabling Flow on an opt-in, user requested basis on a limited set of pages for testing purposes over the next 3-6 months.

No. Meta is not your playground. Go test Flow on the Beta cluster if you need to.

Enabling Flow on a wiki test page before enabling it on a requested Talk page on that wiki is clearly the right thing to do. We found a problem with Parsoid configuration on meta by doing so.  We do indeed have playgrounds already so I didn't see much point in publicizing yet another test page, but since people find them anyway we should do so in the future.

I think people's bigger objection is Flow coming to a wiki because some small group requests it on "their" Talk page. That's implicit in the roll-out strategy Maryana mentioned, which is on the main Flow page:
   Wider release to more WikiProject and community discussion spaces on English Wikipedia and other projects, on an opt-in trial basis

I don't think this bug is the best place to discuss the rollout strategy, I've created https://www.mediawiki.org/wiki/Flow/Rollout and it has a talk page, the latter is not yet Flow-enabled :)

(In reply to spage from comment #6)
> Enabling Flow on a wiki test page before enabling it on a requested Talk
> page on that wiki is clearly the right thing to do. We found a problem with
> Parsoid configuration on meta by doing so.  We do indeed have playgrounds
> already so I didn't see much point in publicizing yet another test page, but
> since people find them anyway we should do so in the future.
> 
> I think people's bigger objection is Flow coming to a wiki because some
> small group requests it on "their" Talk page. That's implicit in the
> roll-out strategy Maryana mentioned, which is on the main Flow page:
>    Wider release to more WikiProject and community discussion spaces on
> English Wikipedia and other projects, on an opt-in trial basis
> 
> I don't think this bug is the best place to discuss the rollout strategy,
> I've created https://www.mediawiki.org/wiki/Flow/Rollout and it has a talk
> page, the latter is not yet Flow-enabled :)

I think you're totally missing the point about the objections raised in this bug.

(In reply to Maryana Pinchuk from comment #4)
> This is all following along our course of enabling Flow on an opt-in, user
> requested basis on a limited set of pages for testing purposes over the next
> 3-6 months.

I don't believe the Meta-Wiki community wants the Flow extension enabled right now. Have you tried asking the community about its thoughts on the matter?

Unlike most of the Flow team, most active users at Meta-Wiki have been around for a long time. Meta-Wiki eschewed LiquidThreads (I believe I even once proposed enabling it there and it was quickly shot down). Perhaps with Flow, the Meta-Wiki community will be more receptive, but I think it would make sense to ask. Have you asked?

We are not going to disable Flow from Meta unless there is an actual issue with the software. Please do not reopen this bug again unless you can point to an actual issue with the software; doing otherwise is disruptive and pointless.

Just as is enabling an extension on a production wiki without asking its community for opinion first.

Change 115412 had a related patch set uploaded by Odder:
Remove Flow from Meta

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

(In reply to Maryana Pinchuk from comment #9)

> We are not going to disable Flow from Meta unless there is an actual issue
> with the software. Please do not reopen this bug again unless you can point
> to an actual issue with the software; doing otherwise is disruptive and
> pointless.

You have conveniently avoided answering any of the questions asked by MZMcBride. The truth is, you did not ask the Meta community for their opinion on whether Flow should be enabled or not, and you refuse to acknowledge it.

This is VisualEditor all over again: you have learnt nothing from that experience, and that's just sad.

We can't get consensus on a per-wiki basis before enabling any software change. That has never been our practice and never will be. Clear communication is another matter and it looks like we could have done better in this respect.

What are the actual material issues with this deploy?

(In reply to Erik Moeller from comment #13)
> We can't get consensus on a per-wiki basis before enabling any software
> change. That has never been our practice and never will be.

Nobody is asking you to.

> What are the actual material issues with this deploy?

I think both you and Maryana are perhaps missing the point.

* [[m:Wikimedia Forum/Archives/2010-04#LiquidThreads]]
* [[m:Meta:Babel/Archives/2010-12#LiquidThreads]]
* [[m:Meta:Babel/Archives/2012-01#Enabling Liquid Thread on meta]]

The Flow team has put forward the idea that it can operate in a vacuum on a wiki. I don't believe this is acceptable or reasonable. The Flow team has also put forward the idea that hyper-local consensus (or in the case of Meta-Wiki, no visible consensus...) can override project or global consensus. This is pretty unchartered territory, no? For example, when's the last time a group of five or six users determined whether to enable an extension on the English Wikipedia?

The Flow team says Flow will be opt-in software, but then unilaterally declares that it's going to deploy Flow to Meta-Wiki, with an accompanying self-merge in Gerrit, and without any on-wiki discussion or any attempt to discuss the idea with the Meta-Wiki community. Consensus is a _pillar_ of Wikimedia wikis.

I can't help but think that Tomasz is correct that you're repeating the mistakes of VisualEditor by trying to steamroll communities into accepting this software. Particularly on a smaller wiki such as Meta-Wiki, Flow can't simply exist in a vacuum. Special:RecentChanges, Special:Watchlist, IRC feeds, etc. are all common and will be infected by Flow.

Echoing what I said in comment 8, Meta-Wiki has repeatedly rejected LiquidThreads, but perhaps the response to Flow will be different. Has anyone asked the Meta-Wiki community about its thoughts on using alpha discussion software? If the Flow team came into this seeking collaboration, it might find users willing to test out its software.

I can't directly stop you from deploying the Flow extension to Meta-Wiki or any other Wikimedia wiki against the local community's wishes, but I wouldn't recommend it: history has repeatedly shown that the insurgents quite often beat out an occupying force. If you try to force Flow onto the wikis, I think you can only expect backlash and an increasingly inhospitable discussion environment.

I think everyone agrees that the communication about the single-page test wasn't sufficient. But I don't think the LQT comparison is valid. LQT comes with a rather scary per-page flag allowing any page to be LQT-enabled, and the discussions you're pointing to refer to enabling LQT across Meta.

Flow has no such flag right now - pages are manually and carefully selected for testing purposes, and effects truly are pretty limited. This deploy enabled a page called "Developer test page". So this analogy seems _very_ stretched, and the arguments seem theoretical at this point. What practical concerns are there with the current test page deploy?

(In reply to Erik Moeller from comment #15)
> What practical concerns are there with the current test page deploy?

I think you and I may fundamentally disagree about whether pissing off a local editing community and engendering further ill will toward these type of projects (ArticleFeedbackv5, LiquidThreads, Flow, UniversalLanguageSelector, VisualEditor, etc.) is a practical concern. The erosion of trust and collaboration between the Wikimedia Foundation and the active editing communities is a very serious and practical concern, in my opinion.

As far as I know, deploying Flow will not cause anything to explode. This is _not_ the same as saying deploying Flow will not cause any harm. I think attempting to force this alpha discussion software on Meta-Wiki (and wherever else next) will actively harm already battered relations.

I'll try to put it another way: if the software has virtue and merit as a product, it should be no issue for the Flow team to establish local community consensus to test it out. However there are over 800 Wikimedia wikis; if, after discussion and consultation, the Meta-Wiki community decides it doesn't want to install Flow right now, test it elsewhere. What's the issue?

Yeah, sure - I agree there's no point pissing off people unnecessarily while we're looking at different test scenarios. There's also no point creating more drama than required about a single page test deploy. :) Preemptively deleting comments on a page flagged as "developer test page" and then raising alarm bells about the coming incursion seems a wee bit premature. Let's all have a sensible chat about what makes sense on Meta, but let's also give each other the benefit of the doubt as we go please.

Where does the single page test end, and using it as a backdoor to enabling it wider or sitewide without community consensus

(In reply to Erik Moeller from comment #17)
> Yeah, sure - I agree there's no point pissing off people unnecessarily while
> we're looking at different test scenarios. There's also no point creating
> more drama than required about a single page test deploy. :) Preemptively
> deleting comments on a page flagged as "developer test page" and then
> raising alarm bells about the coming incursion seems a wee bit premature.
> Let's all have a sensible chat about what makes sense on Meta, but let's
> also give each other the benefit of the doubt as we go please.

AGF is stretched a bit, since there were clear examples cited, communications channels were not used, etc. That is, AGF is not required from only one party.

I interpret comments 13 to 17 as WONTFIX for this request.

Are there any further arguments that have not been brought up yet plus need answers?

Change 115412 abandoned by Odder:
Remove Flow from Meta-Wiki

Reason:
This is very unlikely to ever be merged.

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