(Commented at T110744)

I agree with @MGChecker:
The problem:
For example the VisualEditor or MediaViewer, each user can decide, if he want to opt-in or out. The problem with flow is, if I would enable flow at my talk page, every user, who wants to speak to me, have to use flow, or don't communicate, and that's a problem with this feature.

just fyi: There is drama on the german signpost (Kurier) because of this bug: https://de.wikipedia.org/wiki/Wikipedia_Diskussion:Kurier#Flow

In T117990#1797689, @Jdforrester-WMF wrote:

Could you please provide a link to the security bugs please?

@Jdforrester-WMF: https://phabricator.wikimedia.org/maniphest/query/QyJjgb9fUwgg/ (note that the result list will be empty without sufficient user account permissions)

In T117990#1798441, @Luke081515 wrote:

(Commented at T110744)

I agree with @MGChecker:
The problem:
For example the VisualEditor or MediaViewer, each user can decide, if he want to opt-in or out. The problem with flow is, if I would enable flow at my talk page, every user, who wants to speak to me, have to use flow, or don't communicate, and that's a problem with this feature.

That's also true about features in MediaWiki you now take for granted, like categories or templates. When we introduced those things they were also disruptive. Just because something is disruptive doesn't mean it can never be released.

However, because the discussion on the Kurier is leading a lot of people here and making them worry unnecessarily, I'm happy to re-state that we are not going to enable even this opt-in for Flow on a wiki where its community is against it.

So this is more a kind of a Tracking-Neverending task? Just for a few wikis?

It is important to note at this point that community consensus regarding Flow usage at de-wiki was not yet polled. There are supportive and opposed voices, with the latter ones currently being a little louder on Kurier. @Luke081515 is actually just guessing that the community would reject flow pages, but there is no evidence yet that this is correct.

A real problem is the somewhat unclear situation about Flow. There was an AFAIK non-WMF story in Signpost titled “Flow placed on ice” in early September [1], which many of the de-Kurier readers understood as the end of Flow. Within that context, it was a bit surprising that Flow shall now be introduced in all Wikis. However, this merely seems to be a communication problem, since most of the de-wiki users probably did not read the official (?) WMF statements at en-wiki [2] and on the mailing list [3]. To my opinion, an official statement about WMF’s stategy regarding talk pages and the collaborative processes connected with it would be very useful, particularly if it covers information about what actually is about to change for the communities.

Something else:

In T117990#1798441, @Luke081515 wrote:

For example the VisualEditor or MediaViewer, each user can decide, if he want to opt-in or out. The problem with flow is, if I would enable flow at my talk page, every user, who wants to speak to me, have to use flow, or don't communicate, and that's a problem with this feature.

This is also valid the other way round. If I were to prefer Flow talk pages, I had to life with users who would not like to switch to Flow. Our users are almost entirely free in managing their pages in the user namespace including the user talk page. I would strongly encourage giving them the opportunity to use modern tools for this process, like for instance the Flow extension. A self-developed bot code like in Luke081515’s case must not be a blocker for the introduction of such an important feature.

References:
[1] https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2015-09-02/News_and_notes
[2] https://en.wikipedia.org/w/index.php?title=Wikipedia_talk%3AFlow&curid=39332539&diff=679000704&oldid=678995621#Priorities_for_the_Collaboration_.28Flow.29_team
[3] https://lists.wikimedia.org/pipermail/wikitech-l/2015-September/082993.html

But there is another possibility to use Flow on all the wikis:

• let the reader decide (opt-in), how to read and write by Flow on talk pages
• don't let the page owner decide, how to read and write his talk page
• the talk page source code will be the same, but the formatting will be different

You have to change the programming code for that, but so Flow can be accepted better ...

Regards ...

I'm removing Community-consensus-needed as it's not true that we need all wikis to agree before we enable it on any wiki, and User-notice because this isn't a step we would announce. The sub-tasks for each wiki would of course have these tags, but they're not appropriate here.

No, you need community consensus of that wiki Flow should be enabled, also as Beta opt in.

You cannot override the community opinions about the enabling on their wiki. That is not the right way.

I did it back to Community-consensus-needed

Isn't it possible to enable Flow in a new namespace? So the user keeps his user talk:$user and gets a user flow:$user ?

user talk: for important messages, bot messages and admin messages to user's address and his work.

user flow: for any further discussions and forum postings, to hold up the community life

I think, we should discuss this seriously ...

Thank you ...

In T117990#1841837, @doctaxon wrote:

No, you need community consensus of that wiki Flow should be enabled, also as Beta opt in.

You cannot override the community opinions about the enabling on their wiki. That is not the right way.

You have mis-understood my comment. I said:

"it's not true that we need all wikis to agree before we enable it on any wiki"

For example, if the French Wikipedia wanted the feature, they do not need to get the permission of all the other wikis.