Enable StructuredDiscussions on wikis that require it
Closed, DeclinedPublic

Tokens
"Pterodactyl" token, awarded by Liuxinyu970226."Dislike" token, awarded by BethNaught."Dislike" token, awarded by Alsee."Like" token, awarded by TerraCodes."Like" token, awarded by Shizhao."Like" token, awarded by AdHuikeshoven."Dislike" token, awarded by Sturmjaeger."Like" token, awarded by MichaelSchoenitzer."Dislike" token, awarded by Man77."Dislike" token, awarded by Sargoth."The World Burns" token, awarded by MGChecker."Like" token, awarded by MisterSynergy."Dislike" token, awarded by Steinsplitter."Dislike" token, awarded by Syrcro."Dislike" token, awarded by Luke081515.
Assigned To
None
Authored By
Jdforrester-WMF, Nov 6 2015

Description

Any community can require to have Structured discussions on their wiki by following the requirements described on https://www.mediawiki.org/wiki/Structured_Discussions/Request_Structured_Discussions_on_a_page.

Related Objects

StatusAssignedTask
DeclinedNone
ResolvedJdforrester-WMF
ResolvedJdforrester-WMF
ResolvedJdforrester-WMF
DeclinedCatrope
ResolvedCatrope
ResolvedCatrope
DeclinedNone
ResolvedTrizek-WMF
ResolvedCatrope
Invalid Mattflaschen-WMF
ResolvedCatrope
ResolvedCatrope
ResolvedCatrope
ResolvedCatrope
Resolvedjeblad
DuplicateNone
Resolvedjmatazzoni
ResolvedTrizek-WMF
ResolvedTrizek-WMF
ResolvedTrizek-WMF
ResolvedTrizek-WMF
ResolvedCatrope
ResolvedCatrope
ResolvedCatrope
ResolvedCatrope
ResolvedKartikMistry
StalledNone
ResolvedCatrope
There are a very large number of changes, so older changes are hidden. Show Older Changes

Talk pages are depending on bots (archives etc.) so much, changing the concept of talk pages could break important bot taks in general, which work on a way that is important, but not possible anymore is Flow is used.

It is completely possible. I co-mentored @happy5214 on a project specifically to address this issue. Pywikibot now has support for the most common bot scenarios (posting a new topic or replying to an existing topic with a warning, etc.), as well as a rarer scenario (resolve/reopen for clerking bots).

This work is merged, and the Pywikibot community is maintaining it (and I expect more work will be done for Pywikibot Flow support in the future).

I expect other bot frameworks will start to support Flow if they haven't already.

Flow does not require archives, though, so those particular bots will not be used. It just shows you the most recent topics (either in order of topic creation, or order of activity), and you can go as far back into the past as you want.

The problem at this point is, that there are also bot owners, who use custom code, like me, and want to do (in my view) more important things, than fix API Edit action, if there is a flow board. Why we don't require community consensus for each wiki? In this case, bot owners can prepare them, if the community accepts flow. Otherwise, everthing is unchanged. There are strong communitys, they don't want flow, without asking them, like at dewiki. Remeber the MediaViewer story, where the WMF uses superprotect, to overrule this community decision. I guess noone (WMF and community) wants something like that again. The other problem is, that flow has at my view to important security bugs, they are not fixed yet. I know a few of them, because I found them, the security bug I reported, has not a low impact, and this a big problem, if someone knows, how to replicate that. And there are still other issues, that were not fixed, for example, that you can't leave a redirect, when moving a flow board.

Why we don't require community consensus for each wiki?

As this task is about "personal talk opt-in", would that in consequence mean that a community's majority decision would disallow its community members to individually opt-in for trying such a beta feature?

MGChecker added a comment.EditedNov 10 2015, 10:01 PM

Why we don't require community consensus for each wiki?

As this task is about "personal talk opt-in", would that in consequence mean that a community's majority decision would disallow its community members to individually opt-in for trying such a beta feature?

Exactly, because other people of the community have to use Flow too if they want to communicate wirh users using the beta feature.

Jdforrester-WMF added a comment.EditedNov 10 2015, 10:09 PM

The other problem is, that flow has at my view to important security bugs, they are not fixed yet. I know a few of them, because I found them, the security bug I reported, has not a low impact, and this a big problem, if someone knows, how to replicate that.

This is an incredibly serious comment to make in the middle of a discussion. Could you please provide a link to the security bugs please? Please do not give details here.

[Edit: I guess that you mean T110744, which is definitely a bug to fix but I disagree is a security issue. Are there any others, given that you said there were multiple important bugs?]

Qgil mentioned this in Unknown Object (Task).Nov 11 2015, 12:08 AM
Luke081515 added a comment.EditedNov 11 2015, 6:41 AM

(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

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)

(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 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:

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

doctaxon added a comment.EditedNov 11 2015, 4:32 PM

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.

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 ...

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.

MGChecker renamed this task from Enable the Flow personal talk opt-in Beta Feature on all wikis to Enable the Flow personal talk opt-in Beta Feature on some wikis.Dec 8 2015, 1:14 PM
Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptDec 19 2015, 1:36 AM
jayvdb added a subscriber: jayvdb.Apr 20 2016, 1:39 AM
Restricted Application added subscribers: TerraCodes, JEumerus. · View Herald TranscriptApr 20 2016, 1:39 AM
Danny_B moved this task from Tag to Should be Goal instead on the Tracking board.Jul 11 2016, 3:18 PM
Trizek-WMF changed the status of subtask T110846: Enable Flow in Odia (Oriya) Wikipedia from Open to Stalled.Aug 4 2016, 1:20 PM
Glaisher removed a subscriber: Glaisher.Aug 31 2016, 5:11 PM
Alsee awarded a token.Nov 3 2016, 5:42 PM
Trizek-WMF lowered the priority of this task from Low to Lowest.Jun 7 2017, 2:52 PM
Trizek-WMF changed the status of subtask T110846: Enable Flow in Odia (Oriya) Wikipedia from Stalled to Open.Sep 12 2017, 12:13 PM
Trizek-WMF renamed this task from Enable the Flow personal talk opt-in Beta Feature on some wikis to Enable StructuredDiscussions on wikis that require it.Dec 18 2017, 8:20 AM
Trizek-WMF updated the task description. (Show Details)
Trizek-WMF moved this task from Inbox to Upcoming Work on the Growth-Team board.Sep 17 2018, 2:48 PM
Trizek-WMF removed Trizek-WMF as the assignee of this task.

Moved to Growth team scope, not just mine.

Trizek-WMF closed this task as Declined.Sep 17 2018, 5:43 PM

After discussion Growth team has decided to close that task, because there is no need to track or goal those deployments.

It is still possible to have Structured discussions enabled for wikis that wish them. Any community can require to have Structured discussions on their wiki by following the requirements described on https://www.mediawiki.org/wiki/Structured_Discussions/Request_Structured_Discussions_on_a_page.

Restricted Application removed a subscriber: Liuxinyu970226. · View Herald TranscriptSep 17 2018, 5:43 PM