Wikipedia talk:Flow/Archive 15

Archive 10

←

Archive 13

Archive 14

Archive 15

Enabling Flow in some pages request

Hi! Can someone enable Flow here?

• ru:User talk:Ochilov
• eo:User talk:Ochilov
• meta:User talk:Ochilov

--Ochilov (talk) 14:57, 25 November 2015 (UTC)

No one here can do that, they can't even re-enable Flow on the Flow test page here (which is a good thing). However, if you really want Flow on those pages, you can request it at mw:Flow/Request Flow on a page. Just be aware that you will lose a lot of functionalities normal user talk pages have, for very little added benefit. Fram (talk) 15:08, 25 November 2015 (UTC)

Such as?Jo-Jo Eumerus (talk, contributions) 15:22, 25 November 2015 (UTC)

Subsections, for one. A working history (with all history visible), with a useful diff option. Links in headers. Archive search. Probably a lot more I don't think of right now. Fram (talk) 15:48, 25 November 2015 (UTC)

Requested! :) --Ochilov (talk) 16:50, 25 November 2015 (UTC)

Why no link in Pages that link to

I posted a new messsage in wt:Breakfast that included a link to Portal:Liquor, but checking the portal now I don't see it in Pages that link to "Portal:Liquor". Ottawahitech (talk) 15:28, 29 November 2015 (UTC)please ping me

It is there, but the link comes from the Topic namespace. BethNaught (talk) 15:41, 29 November 2015 (UTC)

Why no time stamp?

I believe I voiced the same concern already, but it has not been addressed{

Old messages show up as posted (for example) a year ago with nothing more specific to try and pin it down to a real date&time. WHY??? Ottawahitech (talk) 19:34, 28 November 2015 (UTC)please ping me

Ping Ottawahitech. Why? Because that's how Facebook and Youtube do it. (No, I'm not kidding.) Flow aims to be "more familiar" forum software for casual or drive-by commenters.

You can still access the true timestamp by hovering the mouse pointer over the fake how-long-ago date. However it can be a hassle trying to select it to copy it. Alsee (talk) 20:43, 28 November 2015 (UTC)

Thanks for saying that's how Facebook and Youtube do it, Alsee. That was my suspicion. I hope that this project will not be derailed by working towards a goal of becoming flavor of the month/year/ or even decade. I hope Wikipedia will still be arround after we are all gone.

As far as the hover is concerned my comment above applies to it as well. Ottawahitech (talk) 15:35, 29 November 2015 (UTC)please ping me

A lot of other forum software uses it too. The ones I am familiar with though use a precise date.Jo-Jo Eumerus (talk, contributions) 15:53, 29 November 2015 (UTC)

Fwiw, Facebook does not use relative timestamps forever (only for 2 days); only Youtube and Reddit do that, that I could find. I did a bunch of external research on this, at phab:T94648#1178640. Quiddity (WMF) (talk) 00:40, 1 December 2015 (UTC)

They're planning on changing the timestamps. The current proposal is to use exact timestamps for everything older than 24 hours, and to use exact and relative (or elapsed) timestamps for anything within 24 hours. Details in phab:T94648 and phab:T111596. I.e. something along the lines of:

• 09:25 (UTC) (1 min. ago) - for posts within one hour.
• 08:26 (UTC) (1 hour ago) - for posts within a day.
• 08:26, 1 Oct. (UTC) - for posts older than a day. (whether to include the year here, is undecided. I'm advocating including it.)
• 08:26, 3 Oct. 2014 (UTC) - for posts older than a year.

HTH. Quiddity (WMF) (talk) 00:40, 1 December 2015 (UTC)

Some Flow problems

Tracked in Phabricator
Task T112230

[1] gives me 50 edits from mw:Talk:Flow. No older edits can be reached in this way (with some effort one can see at most 500 edits, the remainder is not accessible through history).

At the top are 6 "deleted a comment" edits, spanning 8 minutes. On a normal talk page (or any other page), one goes to the history and can undo or rollback multiple edits, spanning multiple sections, at once, or one can easily revert to an older version of a page by editing that version. No such things is (as far as I know) possible with Flow. E.g. "Undo" is available on edits that edit a comment, not edits that add a comment (the majority). These can be hidden, but only one by one.

In general, maintenance of Flow pages is very poorly conceived. Fram (talk) 13:31, 26 November 2015 (UTC)

That's because Flow is not built around pages at all. It's a "conversation". It doesn't look particularly well suited to the needs of archivists like the people engaging with the Wikipedia project. Diego (talk) 14:02, 26 November 2015 (UTC)

True. Sad but true... Fram (talk) 15:19, 26 November 2015 (UTC)

Aye, Flow is basically a forum software. Wiki talk pages are a sort of forum, but they can also be used as drafts and some other uses.Jo-Jo Eumerus (talk, contributions) 15:47, 26 November 2015 (UTC)

This is phab:T112230. There's code/work in progress towards fixing it. Quiddity (WMF) (talk) 00:45, 1 December 2015 (UTC)

It was "fixed" in February, when the earlier bug about the exact same problem was closed by the same one that created this phabricator bug. I'll believe that it is fixed once I see it, not when the WMF declares it to be. This problem was noted here from the very first starts of Flow. Apparently not being able to access the history (or decent diffs, undoing of multiple edits, and the list of such problems and deficiencies is seemingly endless) wasn't and isn't a blocker though, as this is happily being promoted and rolled out to other wikis. Repeating the fiasco of LiquidThreads all over again seems like a good idea to someone? At least Jdforrester (WMF) has rapidly stopped sprouting his nonsense here after a failed attempt recently. Can't you just shut down all testing on Wikipedia and be done with it? Fram (talk) 21:00, 1 December 2015 (UTC)

NOTICE: RFC to end Flow trial at Project Breakfast?

I posted an RFC Wikipedia_talk:WikiProject_Breakfast. A few months into the Flow trial all project work declined to zero, with no project activity in over a year. Should the trial be ended? Alsee (talk) 01:52, 30 November 2015 (UTC)

• Support removing Flow from WikiProject Breakfast. I speak as someone who supported Flow testing initially and participated in a San Francisco workshop to help provide input from experienced editors. In my opinion, Flow is inferior in every way to our current project page and talk page collaboration techniques. Cullen³²⁸ Let's discuss it 02:51, 30 November 2015 (UTC)

Cullen³²⁸ I struck your "Support" here to avoid any possibility of confusion. The RFC and !votes are on the Wikipedia_talk:WikiProject_Breakfast page. Alsee (talk) 07:23, 2 December 2015 (UTC)

Feel free to Strike any comment of mine you want, anywhere you want, Alsee, as long as my message remains clear. I have the right to comment on any proposal in any discussion venue, as long as my comment is not off topic. Which it isn't. Thank you. Cullen³²⁸ Let's discuss it 07:32, 2 December 2015 (UTC)

Cullen³²⁸, I firmly agree with your message. I was one of the people on the WMF Director's talk page, getting the brakes applied on the Flow-train. The way you formatted your comment, it looked like a !vote on the RFC. I was just worried someone else could mistakenly !vote here without seeing the actual RFC. I'm sorry if there was any confusion. Alsee (talk) 08:12, 2 December 2015 (UTC)

Like I said, Alsee, it doesn't bother me, so there is no need to say you are sorry. I will use various forms of polite emphasis as I see fit when I feel strongly about an issue, and anyone can strike through my simulated !votes if they choose, as long as my message itself gets through. Thank you. Cullen³²⁸ Let's discuss it 08:19, 2 December 2015 (UTC)

Why I can't enable Flow function in beta?

I opened the beta page, but I can't find it. And I am looking forward this function can enable by users and I hope this function will unable in English Wikipedia in January 2016. Also, Chinese Wikipedia can enable Flow function by users already. Please publish the date of enable, thank you.--Shwangtianyuan (talk) 07:14, 5 December 2015 (UTC)

Shwangtianyuan, New Flow development has been suspended, although the WMF is working on a way for users to opt-in to Flow for their talk pages. I'm not sure if it's done. However I believe it would require a Village Pump RFC to enable this on English Wiki. Flow has been controversial. The current WMF policy is that Flow deployment requires a demonstration of community consensus for it. This is not a simple matter of "it's just my talk page, no one else is forced to use it". Everyone would be forced to use both systems in order to be able to post business on on other user's talk pages. That would need a thorough community discussion to weigh the pros and cons. Alsee (talk) 11:13, 5 December 2015 (UTC)

Yeah, the difference between Flow and say VisualEditor is that using VE doesn't really affect other people, but setting up Flow on your talkpage does affect other users (Homo sapiens sapiens and silicon-based ones).Jo-Jo Eumerus (talk, contributions) 11:37, 5 December 2015 (UTC)

Templates?

Tracked in Phabricator
Task T121956

What is the purpose of these templates. Are they actually in production? They say to never modify - in which case they may need protection - but really shouldn't system type messages be in the mediawiki space? — xaosflux ^Talk 15:05, 18 December 2015 (UTC)

Filed as phab:T121956. I asked before, but don't recall the answer. Thanks. Quiddity (WMF) (talk) 00:57, 19 December 2015 (UTC)

Thanks, I've applied sysop-only protection to them as pseduo-interface messages. — xaosflux ^Talk 03:52, 19 December 2015 (UTC)

Analyzing User:Flow_talk_page_manager

What is User:Flow talk page manager [2] actually doing? It seems to edit every topic that gets created, as if every individual topic needs to be "Flow-enabled". This seems like a lot of overkill. Strangely, while one can see in the contributions of Flow talk page manager that these edits are made, they can not be seen in the history of the topic. I didn't know that some edits could be shown in one edit history (by user) but not in another (on the page the edit was made). I also don't think this is a good idea, it certainly seems like a dangerous precedent.

The edit summary for the edits, "This page has been converted into a Flow discussion board" is also quite wrong, as no page is being converted, only a new topic is being started.

The topic edits are not deleted when the actual page gets deleted, although edits made to pages are deleted apparently. It makes it hard to follow what the "manager" actually has done (of course, the nonsensical topic titles also don't help one bit).

The same "user" also created templates like Template:LQT post imported with supressed user (with typo in the name) and Template:LQT Moved thread stub converted to Flow. I don't think enwiki has even a single LQT page, so why the manager was used to create useless templates is not clear.

Is it correct that blocking this "manager" would basically disable Flow on a complete wiki (no more new topics or Flow pages, only posts in existing topics remain possible)? That's ... interesting and potentially useful, if the WMF would reverse its position and try to impose Flow against the wishes of a community ;-). Perhaps not using the Flow manager for other stuff like importing unwanted templates will reduce the likelihood of it getting blocked here. Keep automated edits to Flow pages and topics and other stuff separated please, for your own good. Fram (talk) 08:14, 17 December 2015 (UTC)

It looks like you should ask Mr. Stradivarius.  — Scott • talk 14:46, 18 December 2015 (UTC)

@Scott: Why do you say that? I haven't been involved with Flow development at all before. At a glance, it looks like this related to the conversion of wikitext talk pages and LiquidThreads pages to Flow, rather than being part of the core Flow software, but I don't really know any more than that. — Mr. Stradivarius ^{♪ talk ♪} 23:52, 18 December 2015 (UTC)

(Mr. Stradivarius, you had created the initial description at the userpage)

I've updated the description, and I will ask for technical details as to why Flow is using a useraccount for these topic-initializations - IIRC it has something to do with converting the location's ContentModel, which might be a thing that editors can do soon (for unrelated extensions) hence public logs are needed.

Removing the unused LQT templates is phab:T115518, and the spelling error is phab:T121953.

I've filed phab:T121951 for changing the edit summary and improving the docs. Quiddity (WMF) (talk) 00:51, 19 December 2015 (UTC)

Aha, I had forgotten about that. I probably just saw a discussion about the account on WP:VPT or somewhere similar and decided that it needed a description. — Mr. Stradivarius ^{♪ talk ♪} 02:24, 19 December 2015 (UTC)

A thought - now that we have global user pages, that page can probably just be deleted. m:User:Flow talk page manager does job of explaining what the account does perfectly well, and deleting the local user page would mean one less page to keep up to date. — Mr. Stradivarius ^{♪ talk ♪} 02:27, 19 December 2015 (UTC)

Seeing as no-one objected, I've gone ahead and deleted it. — Mr. Stradivarius ^{♪ talk ♪} 10:26, 21 December 2015 (UTC)

MfD nomination of Wikipedia:Co-op/Mentorship match

Wikipedia:Co-op/Mentorship match, a page which you created or substantially contributed to, has been nominated for deletion. Your opinions on the matter are welcome; you may participate in the discussion by adding your comments at Wikipedia:Miscellany for deletion/Wikipedia:Co-op/Mentorship match and please be sure to sign your comments with four tildes (~~~~). You are free to edit the content of Wikipedia:Co-op/Mentorship match during the discussion but should not remove the miscellany for deletion template from the top of the page; such a removal will not end the deletion discussion. Thank you. Alsee (talk) 16:17, 22 December 2015 (UTC)

Note: I used Twinkle to nominate the page for MFD. Twinkle tried to post a notice to the page-creator's talk page. Somehow this page is listed as the creator's talk page. That explains the text "a page which you created or substantially contributed to". Alsee (talk) 17:11, 22 December 2015 (UTC)

Flow in action

At the bottom of Help talk:Citation Style 1#Automatic ISO conversion (timestamp 10:41, 31 December 2015) is a post that was originally posted at mw:Talk:Citoid. However, that uses Flow and the post comprehensively broke. And https://www.mediawiki.org/w/index.php?title=Topic:Suuu319c6knnexd9&topic_showPostId=sv4lwbfo5mxk8176#flow-post-sv4lwbfo5mxk8176 is a link to who-knows-what. Johnuniq (talk) 11:15, 31 December 2015 (UTC)

Mass delete doesn't work for Topics

Tracked in Phabricator
Task T115695

There have been a lot of complaints about the abilities to deal with lots of problematic edits by one editor in one go, on Flow. A simple example is User:ZOKIDIN3, obvious sock of User:ZOKIDIN, who created the new topic "Sockpuppet IP + Account ZOKIDIN" on Wikipedia talk:Flow/Developer test page. This is indicated in his contributions with a nice fat "N" indicating a new page, but when I use "mass delete" on his contributions (as as a test, mass delete isn't intended to delete one page of course), I get "No new pages by ZOKIDIN3 in recent changes.". Since there also is no rollback, no mass undo, whatever, the only way to remove multiple posts by one user is one by one. This is highly inefficient, and a serious step back from what we have on other talk pages. Please make sure, if you ever want to roll out Flow, that good tools for maintenance are available. Fram (talk) 14:25, 11 January 2016 (UTC)

• @Fram: Assuming that "mass delete" is the same thing as "Nuke" that's up for work in Phabricator: phab:T115695.Jo-Jo Eumerus (talk, contributions) 14:35, 11 January 2016 (UTC)
  • Thanks, I think it is the same, yes. This problem was mentioned here (in theory, not tested at the time) from the very start, but only got a Phabricator issue (and a bit later priority high) when someone started spamming Flow pages on Mediawiki, I believe. Makes you wonder why there is testing and feedback needed on enwiki of course, if our concerns are of no interest apparently. Fram (talk) 14:55, 11 January 2016 (UTC)

User:Flow talk page manager, the unstoppable

I have blocked User:Flow talk page manager as a test. Turns out that this doesn't make any difference, it can still create new topics. Is it acceptable that there are unblockable "editors" on Wikipedia (without any discussion, as far as I know), which if they would malfunction can not be stopped? Or can every blocked editor still create topics? I presume the user right "Flow bot", which I hadn't noticed before, is somehow involved with this, but I doubt this is a good idea (standard bots can be stopped by every admin, why does Flow need a separate account with other "powers"?). And if it can't be blocked, then please don't let me block it but just give an error, with an indication of who can stop it if necessary (stewards? bureaucrats?).

Anyway, I'll leave this "user" blocked for now, if anyone notices a difference in behaviour please drop a note here. Fram (talk) 14:44, 8 January 2016 (UTC)

My guess is that the "(flow-create-board)" permission doesn't respect block status. Actions don't respect block status by default as far as I know; each one needs a hook to check the block status. Something for Phabricator, I guess.Jo-Jo Eumerus (talk, contributions) 14:57, 8 January 2016 (UTC)

Ah, that seems logical. I hadn't checked the listgrouprights page, thanks. Fram (talk) 15:19, 8 January 2016 (UTC)

Fram this is far for a "normal" account, as you can see on Special:CentralAuth/Flow talk page manager, this account was merged using special steward/developer actions. It does not so much as edit, as have edits attributed to it. I think it is sloppy, but I think most of Flow is. As blocking as no affect, and this account is under WMF control I've reverted the enwiki block - we certainly don't want any unknown side affects of a local block making things worse. — xaosflux ^Talk 02:11, 12 January 2016 (UTC)

Undo sucks badly on Flow

Another sock of the same user, Zokidin4, has now edited the Wikipedia talk:Flow/Developer test page header three times in a row. I can't undo these all at once, but have to undo them one by one. There is no separate history for the header (or I haven't found the link, same difference), so I can't go back to the previous version and restore that one, as I have no idea how old the last version was. I can't simply undo the first of the sock's header edits, because then I get the error about conflicting intermediate edits (good), so it seems as if the only option is undo, undo, undo. Which is feasible if the number of edits is limited, and if the edits are very recent: but to restore an old version or to remove older vandalism seems hardly possible. I can find a Permalink to an older version, like [3] this, but I can't use this in any way (no restore, edit, view source code, ...). The older version says "from 19 days so", soon it would probably say "from 1 month ago" so finding it again would be a needle in a haystack for somewhat active talk pages.

So my end reaction was "screw it", the WMF or one of their cronies can clean up this mess themselves if they can't give us decent tools to do so. Fram (talk) 17:07, 11 January 2016 (UTC)

@Fram: Does rollback work there? I only have the Twinkle rollback which isn't designed for Flow - nor for tagging that sockpuppet topic for G5. I've manually undone all edits.Jo-Jo Eumerus (talk, contributions) 17:19, 11 January 2016 (UTC)

No, no rollback (as far as I could see, perhaps there is a possibility I'm not aware of of course). Fram (talk) 07:23, 12 January 2016 (UTC)

2nd ask about enable Flow function in beta

I want to ask about enable Flow function in beta again. In the last talk said Flow development has been suspended. I also would like to call to resume Flow development and enable Flow function in English Wikipedia as early as possible. Thank You.--Shwangtianyuan STRONGLY CONDEMNS 2016 North Korean nuclear test 07:48, 11 January 2016 (UTC)

Current WMF policy is only to enable Flow when there is a community consensus requesting it. You can certainly open a Village Pump RFC proposal, however every Flow page has seen activity drop to zero, a series of discussions have been reaching consensus to remove Flow pages one by one, and the last informal Village Pump discussion was unanimously opposed to Flow. The more likely outcome of the RFC would be to ban new Flow deployments and to shut down the final 2 Flow pages on EnWiki. Alsee (talk) 15:06, 11 January 2016 (UTC)

@Shwangtianyuan: I am editor who did a lot of work getting a wikiproject I am involved in to agree to a FLOW trial. Unfortunately, some editors who were not involved in this trial have declared consensus to shut the trial down through an RFC, when only one or two of this trials participants have endorsed this RFC (while three have opposed it). For more deeails see: User_talk:Ottawahitech#Flow_.2F_projectbreakfast_RFC Ottawahitech (talk)please ping me

I also agree to enable Flow beta. @Shizhao and AddisWang: What do you think? (Note: Shizhao and AddisWang are the administrators of the Chinese Wikipedia, Shizhao also is the Bureaucrat of the Chinese Wikipedia, they both enable Flow beta in their talk pages in the Chinese Wikipedia.)--Shwangtianyuan STRONGLY CONDEMNS 2016 North Korean nuclear test 05:53, 12 January 2016 (UTC)

@Ottawahitech: What project are you talking about? If it's the one from which Flow was removed, the page/conversations hadn't been used for anything actually related to the WikiProject for some time. (That might be incorrect. What is correct is that no one could find such usage. It might have been there. Somewhere.) — Arthur Rubin (talk) 07:44, 12 January 2016 (UTC)

Arthur Rubin, it is WT:WikiProject_Breakfast. There had been zero project activity in fourteen months, so I opened an RFC to end the defunct Flow trial. I encourage anyone and everyone to look at that page before the WMF gets around to converting it back to a Talk page. Running an RFC inside Flow was a disaster. The RFC is a nearly unreadable mess. Alsee (talk) 12:52, 12 January 2016 (UTC)

You're not supposed to read "resolved" discussions, apparently.

What a total shitload of nonsense Flow is.

On Wikipedia talk:WikiProject Breakfast, I opened the top list (the TOC). Took a few seconds to appear. I scroll to the bottom, "Welcome to Flow" (light grey), click on it. Nothing whatsoever happens. Perhaps because it is light grey, whatever that means? So I click the second-to-last, "Article collaboration", which is a nice solid black. Again, nothing whatsoever happens. A huge improvement over the TOC of standard talk pages, of course.

Up, up, up, still nothing happens if I click in the browse topics drop down on "Update on Flow trial". Only when I click on "Price of breakfast foods going up?" can I actually use the TOC. Yep, you get "infinite scrolling", "no need to archive" (no possibility to archive as well of course), but you are not supposed to go to anything older than the ten most recent topics. A page like WP:ANI has more active discussions than that, but that "problem" will be solved with Flow! No wonder they only wanted to test it on moribund project pages with sympathetic WMF people involved.

So, now that I can't use the TOC, I tried to go down by scrolling. Patience, patience, ... eventually you get there (but I wouldn't want to do this on a truly active talk page with a few hundred topics, which isn't that unusual). It's very annoying that when the "waiting signal" (some spinning wheel) appears, you may get catapulted back up again a number of topics, but that's par for the course probably.

Having arrived at "Welcome to Flow", I notice that it is tagged as "resolved". Very well, but that means that I can't read it at all. Oh wait, on the right side, I can "reopen the topic". Perhaps that's a way to read it? Yes it is, but now it is no longer resolved, and I have to re-resolve it afterwards, which means that instead of a topic from two years ago, it suddenly is an "active" topic from a few minutes ago with my name attached, and the history of the topic shows two edits by me. Not really an anonymous way of reading topics, or a good way to handle pages where topics are ordered by most recent activity.

So, now the topic is at the top of the page, instead of at the bottom, only because I wanted to read it, and everyone can see that I did read it. Perhaps I can change the header to indicate this? Edit header, in wikitext. Hey, there is (almost invisible at the bottom) a line that says "Wikitext uses markup and you can preview the result anytime." So that's where the preview went! Finally, something positive to say about Flow.

Oh, wait, that's not a preview, that's a switch to VE mode, and it doesn't show me what the header will look like (it won't have that big "link" box, or the italic, bold, underlined A in the bottom left corner, or... By the way, there doesn't seem to be a way to get rid of that box apart from the "slashed red circle" symbol which unlinks the link. I just want to type something after that link, is that too much too ask? Oh wait, I'm talking Flow plus VE here, obviously anything is too much to ask with that combination.

Please remove this utter piece of shit from enwiki and annoy the people at mediawiki with it instead. Come back in a few years time when you have wasted some more donations on badly tested developments (this thing is more than two years old, surely things as basic as this should have been found and solved by now), but in the meantime leave us well alone. Any continued deployment on enwiki is a disgrace and an indication of the total lack of respect you (WMF) have for us. Not that that is any news of course. Fram (talk) 09:36, 13 January 2016 (UTC)

• Huh? For me the TOC still works well.Jo-Jo Eumerus (talk, contributions) 09:47, 13 January 2016 (UTC)
  • That's quite possible, see the below I composed meanwhile to get a feeling for the unpredictability of it all. Fram (talk) 10:04, 13 January 2016 (UTC)
  • Or it might be because by getting the "resolved" topic at the top instead of as the bottom one, the cause of this one problem was solved. Fram (talk) 10:05, 13 January 2016 (UTC)
• To read the comments of a "resolved" discussion you have to click on "93 comments" and wait for the javascript to work. So it's not necessary to open the topic. Whether this is nice is a matter of opinion, but it is worth noting that this is very much in the style of Facebook, and in the context of MediaWiki is an unexplained and, evidently, confusing change. BethNaught (talk) 10:21, 13 January 2016 (UTC)
  • Thanks. I think I tried that and it didn't work, but I can't reproduce that (I mean that now it indeed works like you describe it). For the TOC not working for older topics, I tried it again on mediawiki, and my first two tries gave no result, but a thrid try worked, so it seems to be unpredictable and irregular somehow. Fram (talk) 11:09, 13 January 2016 (UTC)

Further testing

Ah, a subheader, good thing we are not in Flow here. Anyway, when I go to Wikipedia talk:Flow/Developer test page, for some reason I can click on every topic in the TOC and it takes me to the correct post. For the sake of predictability, we get a number of other problems instead though.

• Not every topic is visible in the TOC. When I open it (and wait for a moment), the bottom two topics are "Articles for deletion - Hell (test only)" and "Test post". Clicking on "Test post" brings me to a topic with that title, and below it I immediately see the topic "Testing real article talk page comments". Scrolling up from where I am now gives me

• "[995815d5] Database query error" Ouch... Scrolling up any further gives me "Disruption test #2", which is (again) the tenth topic in the TOC, so again the 10 topics limit is causing problems. Looking again at the TOC shows me that

• The page I first had as the bottom one, "Test post", no longer is the oldest topic, there are now 9 older topics (there's that batch of 10 again!), ending in "Categories don't work" (yes, many topic titles were quite positive about Flow as well!). Clicking on that one opens that topic, then starts opening (again) topics below the "final" one, and then

• Jumps to another topic, in this case "replication of an actual talk page discussion" high, high up the page. On the plus side, the TOC has again been expanded with 10 entries.

Basically, sometimes it works, sometimes it doesn't, sometimes it works in quite unexpected ways (but rarely are they a nice surprise). It is not intuitive, predictable, or useful beyond the very basics. It is unmaintainable, not user-friendly, and riddled with bugs. The above problems all come from simple testing, mostly not even trying to edit, never mind doing more complicated stuff or actievly trying to break things. I don't dare do any destructive testing with this thing, as chances are I would break things outside of Flow as well again. Good going! Fram (talk) 10:04, 13 January 2016 (UTC)

Current? Flow in "my contributions" sucks big time

In "my contributions", I can see for every edit whether it is the current one or not, through the nice bolded "(current)" at the end of the line. Every edit, that is, except for Flow edits.

I also sometimes don't get a "diff" for Flow edits, and sometimes I do. E.g. this one comes from my contributions. Yes, that's supposed to be a diff, even though it is not one as we know it. But for e.g. this post I made in the middle of a topic, there is no "diff" available. In that link, you get the line "This is a permanent link to the first version of this post. You can view later versions on the post history page." But while what I posted was a "post", the link to the "post history page" leads me to the "topic history page", which is of course a different thing.

Notice also that with such a permalink to a post, you don't get any information. Who posted it, and when? In which topic? A complete mystery! I guess some bugzilla or phabricator task could be tagged as "finished" when the permalink was implemented, and no one cared whether it was actually useful or not. Fram (talk) 12:33, 13 January 2016 (UTC)

Tracked in Phabricator
Task T123336

The amount of effort made to integrate Flow with existing special pages has clearly been minimal, and the result is absolutely atrocious. Here's another bug with its integration with Special:Contributions that I noticed yesterday.  — Scott • talk 16:32, 13 January 2016 (UTC)

Filing Flow bug reports? Yes? No?

General question, do we want to open Phabricator requests to fix Flow bugs? At one point I was reporting bugs, I was literally running into new issues faster than I could write them down. After a while I decided reporting bugs was probably counterproductive. I realized I didn't actually want them fixed. In my opinion fixing the bugs wouldn't turn Flow into a viable product. It crossed my mind that reporting a bug only served to divert valuable developer time away from other important work.

What do other people think? Alsee (talk) 23:23, 13 January 2016 (UTC)

I'd been having similar thoughts myself. I can't work out whether I want to file the bugs just to add to the total picture of how terrible Flow is, or because the WMF coders still haven't completely abandoned it. Other people are still having to suffer through using it.  — Scott • talk 23:27, 13 January 2016 (UTC)

Any developer time spent on this weak forum impersonation is futile, it should be spend on something useful. That's not against those devs, who are told by their bosses, who prefer shiny brand-new bling gadgets over concrete improvements of existing software, to work here, but it's a waste of time. But if only the fanboys go to the last Flow pages and thus pretend everything's OK, the Bling-pushers will probably only be assured in their delusion about this piece of software. As long as there is no real commitment in the WMF to listen to the communities in such decisions (look at superprotect), I don't think there is a right answer to this question. Grüße vom Sänger ♫ ^(talk) 05:32, 14 January 2016 (UTC)

@Sänger: I appreciate that you're not happy about the current situation, but I don't think that calling WMF staff "bling-pushers" will help things much. Let's keep things civil, please. — Mr. Stradivarius ^{♪ talk ♪} 08:22, 14 January 2016 (UTC)

<squeeze> I made a very important destinction between WMF-staffers, who just do their work as told, and even waste it on stuff like this because their higher-up say so, and those, who push bling, like Eric and Florice with MV, explicitly against the communities, or whoever jumped the gun extremely with VE before that (OK, VE might one day really be a good thing, but it was pushed by know-nothings into the open far too early out of either vain or pointless deadlines), and now some higher-ups again obviously want this forum impersonation, that doesn't fit the broad use of talk pages in any way, regardless of feedback from the major communities. It's a shiny new thing, not bothersome maintenance of working stuff. As Dirk Beestra says on further down: The focus is in shiny bling instead of down-to-earth maintenance. Grüße vom Sänger ♫ ^(talk) 08:48, 14 January 2016 (UTC)

Though I agree that we do not have to return in kind - after SuperProtect I am afraid that the position of the WMF is clear. The list of very old bugs and very old feature requests (both by regulars who find problems) is massive, and I believe that those were filed for a reason. Nonetheless focus is on Visual Editor, Flow, SuperProtect, MediaViewer. I do think that terms like 'Bling-pushers' do, unfortunately, fit - an extraordinary amount of work goes into 'trying to make new editors happy and make them stay' (for which they can not show any positive statistics), pissing off current editors by overruling their decisions and ignoring their requests (which undoubtedly makes them walk away). --Dirk Beetstra ^{T C} 08:32, 14 January 2016 (UTC)

I don't know if the number of unfixed bugs and feature requests says much about allocation of resources. In almost all places, there are more requests than people to work on them. Also, throwing manpower and money does not necessarily speed up certain things. Finally, Superprotection was scrapped a while ago.Jo-Jo Eumerus (talk, contributions) 08:57, 14 January 2016 (UTC)

I agree, Jo-Jo Eumerus, there will always be more than requested. But I do know that a certain group of bugfixes has gotten zero interest, while I here on-wiki am regularly on the receiving side of user-complaints regarding the bad/blund implementation of the current system (plus partially bringing down Labs due to overload of what is in the end a 'patch'. there is now work being done to make that specific part of the problem less extreme, though it forces me to spend time to rewrite part of my bots). Another old bug that I once filed was open for a long time, until someone figured out that it was 'accidentally' fixed by an update that was implemented some time ago. That combined with zero communication regarding implementations of (necessary but not requested) code-changes that bring down independent systems that rely on it .. and opposed by Flow, MediaViewer and Visual Editor (with SuperProtect in support of it) .. is not very suggestive of a reasonable equilibrium between the different parts.

I know that SuperProtect was scrapped, but that cost also developer time to implement, and we know why it was implemented. I named it mainly as a response to the 'Let's keep things civil, please.' --Dirk Beetstra ^{T C} 09:20, 14 January 2016 (UTC)

Let's assume for a moment that all the bugs in Flow (reported or not) were fixed. If this were the case, what would stop it from being a viable product? — Mr. Stradivarius ^{♪ talk ♪} 08:06, 14 January 2016 (UTC)

Depends on what you get, of course. I can imagine that fixing all the bugs will turn it into something very close to the current system, which would perhaps make it a viable system and a huge waste of time and money at the same time. One of the main problems, like I said in the archives of this page two years ago or so, is that they have at the start made a list of what is deficient in the current system, and set out to make a tool without these deficiencies: but they have forgotten to list what works in the current system, which aspects should be kept, and without those, Flow will never be a viable system for most talk pages. These are not bugs per se, but design choice errors from the very start. Fram (talk) 10:04, 14 January 2016 (UTC)

The main problem of Flow is that it's a product in search of an audience. As Fram said, it was originally designed without input from the people who would eventually use it, and thus doesn't serve the needs of any of its potential users; by the time real users were involved in the project, major design decisions had already been taken in a direction that made it impossible to fit its stated purpose. Flow might work as a forum software for naive users, but there are better tools for that purpose out there; and this goal doesn't fit the functions for which a discussion system is needed in Wikipedia. Diego (talk) 22:18, 14 January 2016 (UTC)

From time to time, I test Flow a bit and write down some remarks, like above. I don't file any bugs, if the devs or the product manager (of such a person still exists) want to do so they can convert my reports to bugs. I refuse to post anything to phabricator or to mediawiki, the first for security reasons and the latter for the toxic admin and WMF groupthink culture in that place. But not posting the occasional complaint list here may wrongly give the impression that everything is shiny and happy in Flow-lalaland. No one even seems to know anymore if Flow is abandoned or not, and on what they are actually working ("workflow", I think the latest bubble was). Fram (talk) 07:42, 14 January 2016 (UTC)

I see 998 open phabricator files regarding flow - One would not even know whether the 'new' bug is covered or not. And history has shown that .. bug reports and feature requests get ignored anyway. --Dirk Beetstra ^{T C} 08:32, 14 January 2016 (UTC)

Perhaps we should just file another 2 to get to the 1,000 milestone! And then write a Signpost article about how Flow, 2 years after the first rollout (development started years earlier, I believe), is not really ready yet :-) Fram (talk) 10:04, 14 January 2016 (UTC)

I've been spending a LOT of time over at WMF Wikis. They haven't given up on Flow, and they plan to restart Workflow at some unknown date. Workflow could be a great and valuable project - if the WMF doesn't make it a subsystem of Flow. However the former project manager told me that communities that don't switch over to Flow "will not be served" by Workflow. I try to be polite and constructive in my discussions with the WMF, but to be frank, that sounds like "you're going to take Flow or screw you". I've been struggling for months to get the WMF to discuss this issue. When I tried to ask if the WMF would pay attention to a community RFC on Workflow, I was told that an RFC was "not needed". The reason an RFC is not needed because they already know the result - the consensus of editors are obstructionist change-averse luddies. (It was said more politely of course, but that's the message I got from it.) Then it was pointed out that an EnWIki RFC doesn't speak for the global community. (I expected that comment was coming.) So I asked if the WMF would listen to multi-community RFCs representing a global majority. The response? He told me to go ahead and run those RFCs if that's what I felt I needed to do, goodbye, he's switching to another project. Months later there's finally a new project manager. I could be mistaken, but I think they are a new hire with zero familiarity with the unique situation with the Wiki community. It's too soon to come to any conclusion, but so far they still equate Workflow with being a Flow project, so far they have given the WMF's standard suggestion-box-style comment about being open to input, and so far I have gotten the WMF's standard no-response-at-all when I ask if the WMF is willing to constructively discuss this issue with the community. Alsee (talk) 22:03, 14 January 2016 (UTC)

Is there a place where work on the Workflow tool can be followed? I've lost all track of the project since they said Flow development was in maintenance mode and stopped updating this Flow page. Diego (talk) 22:23, 14 January 2016 (UTC)

Another sneakily enabled Flow page, against all promises

I was pretty sure that already in 2014, the WMF promised to not enable any further Flow pages on enwiki without prior community approval. This isn't the first one we discover where this promise was broken. Please remove it ASAP. And please stop using enwik as your personal playground and testing ground. Fram (talk) 15:33, 20 January 2016 (UTC)

MfD nomination of Wikipedia:Gather/User Feedback

Wikipedia:Gather/User Feedback, a page which you created or substantially contributed to, has been nominated for deletion. Your opinions on the matter are welcome; you may participate in the discussion by adding your comments at Wikipedia:Miscellany for deletion/Wikipedia:Gather/User Feedback and please be sure to sign your comments with four tildes (~~~~). You are free to edit the content of Wikipedia:Gather/User Feedback during the discussion but should not remove the miscellany for deletion template from the top of the page; such a removal will not end the deletion discussion. Thank you. Fram (talk) 15:36, 20 January 2016 (UTC)

Should we draft an RFC now?

Most Flow pages have been deleted. Project Breakfast has consensus to end the Flow trial and convert back to a talk page. The Gather page is currently at deletion discussion with unanimous delete votes. Assuming I haven't missed anything, that only leaves the Flow Test board and Wikiproject Hampshire. Wikiproject Hampshire has a grand total of one project-related post in the last five months, plus a few incidental updates posted about Wikiproject X.

Do we want to start a Village Pump RFC about Flow? And if so, does anyone want to collaborate on drafting it? I was thinking of making a subpage here for drafting discussions. I was considering a series of questions: Do we want to enable the WMF's new system that lets people opt-in to Flow for their user talk? Should any new Flow deployments be required to go through Village Pump discussion? Should we end the Hampshire Flow trial (convert back to talk)? Should we remove Flow from both Hampshire&Test_page, and remove the Flow Extension completely? Alsee (talk) 02:19, 21 January 2016 (UTC)

My opinion is that current Flow instances should be converted back to wikitext, Flow should be removed, and new Flow pages should require a full RfC. In November I drafted an RfC to this effect here. If you think it would be useful as a first draft and you wish to collaborate on it, let me know. BethNaught (talk) 08:01, 21 January 2016 (UTC)

• I say keep the test page and nothing else. The test page has a valid purpose here, but should have a note that Flow shouldn't be used anywhere else. User:BethNaught, your draft RFC is good, but change Support/Oppose to Disable Flow/Keep Flow or similar. Oiyarbepsy (talk) 23:07, 21 January 2016 (UTC)

The test page could be a redirect to the WMF Flow testing page. I don't think we should have the infrastructure of an entire major extension installed just to support one page - especially a test page with a rather circular purpose. Alsee (talk) 03:09, 22 January 2016 (UTC)

@Alsee: How much of an impact is there from having Flow enabled but not used? That could be included in the rationale. If it's important, I think the option of redirecting the test page should be mentioned in the proposal, so that it's clear there will still be a place for testing it. Also, is disabling it technically easy to reverse if the community changes its mind in the future? Sunrise (talk) 23:22, 23 January 2016 (UTC)

Sunrise, if we weigh the pros and cons, it doesn't take much on the con-side to outweigh no real benefit to having an unused Flow extension installed. If the only purpose is to host a testing page, a redirect to the WMF's test page covers that rather well. On the con side, I can say as a programmer that having a large chunk of unneeded code is a bad idea in general. Things should be as complex as necessary, and never more complex than necessary. Having a large chunk of beta-quality code is even worse. There are a thousand open Flow bugs and tasks listed at Phabricator. It would take days just to skim them for known issues, not to mention some huge number of unlisted issues. Then there's the fact that people at the WMF have fallen into the temptation of creating Flow pages simply because someone on some project thought it was a dandy idea, even after the WMF declared that Flow pages would not be created without consensus requesting it. But my primary concern relates to new project development. If Flow isn't even installed, then it is crystal clear up front that they need to talk to the community before expecting to create and deploy new projects that are dependent upon Flow. For example the WMF plans a Workflow project. I have been following it closely and discussing it with various staff. It could be a valuable and popular new toolset for us, IF the WMF builds it to support existing pages. Their current plan for Workflow is that it would only work on Flow pages. We would, quote, "not be served" by the project if we don't switch everything to Flow. As long as Flow is installed they have this background-presumption that we merely haven't completed the switch yet, and that new projects can/should simply be built as Flow-only. Alsee (talk) 06:21, 24 January 2016 (UTC)

Thanks Alsee. I should have been more specific - as a non-programmer, I'm not really able to evaluate the first part of your reply. Are there potential consequences to regular editors, e.g. degrading performance in other parts of WP? If Flow is buggy but isn't used anywhere, could that still cause problems? Would leaving the code in make it harder for programmers to maintain other things? I asked since the responses here so far sound like the community might conclude that the test page causes no harm (which was my own first intuition as well). Sunrise (talk) 08:07, 24 January 2016 (UTC)

Sunrise any performance impact should be negligible, but I can't say for certain from this end. Removing Flow definitely simplifies maintenance. That frees up dev time to handle other bugs or community requests. I don't know what's in the list of one thousand Flow bugs and tasks, but removing Flow would instantly fix any known negative impact. All complex code contains hidden bugs, possibly serious bugs that pop up unexpectedly, so it avoids that risk of disruption. Removing any extension also reduces what is known as "attack surface" - that means it reduces the chance that someone can find a security hole. That's less chance that someone could hijack admin powers, get root system access, steal passwords, or deliberately crash the site. Removing Flow also allows us to drop the entire Topic: namespace, and whatever else was added to support Flow. I'm not making a firm argument that any of those things are major or high risk, those are routine facts that come along with any useful new addition. However those are all dead-weight costs if we're not actually going to be using Flow. And as I mentioned, my main motivation is that removing the extension removes an unwanted-creep-forwards with Flow. If the WMF has awesome ideas about advancing with Flow then it's clear they need to talk to us, to see if we agree those ideas actually are awesome. If Flow is uninstalled then I expect the WMF will realize that the Workflow project really does need to include support for our existing pages. If we don't consider Flow to be a viable option then building a Flow-only Workflow is a steaming pile of useless. An expensive steaming pile of useless. Alsee (talk) 18:01, 24 January 2016 (UTC)

Seconded: keep the test page as an archive, for testing, for the curious. But remove it from any other page, i.e. WP Hampshire, and do not add it to any other. In particular if users could add it to their own user pages it would just confuse people, and in its half-finished state then a lot of things would stop working and as it is currently inactive they are unlikely to be fixed.--JohnBlackburne^words_deeds 03:14, 22 January 2016 (UTC)

Test page can probably be kept. As for that RfC, if memory serves that Signpost announcement was not completely accurate with regards to the status of Flow; there was a follow up statement from the WMF here on this page I think. Also, may be worth mentioning meta:Community Tech/Global cross-wiki talk page here - even if it isn't implemented though Flow, enwiki may lose the control over its user talk pages from this change.Jo-Jo Eumerus (talk, contributions) 09:54, 22 January 2016 (UTC)

I made some modifications to BethNaught's Draft Flow RfC. Inviting Naught and anyone else to review and contribute. Alsee (talk) 04:34, 23 January 2016 (UTC)

Strongly agree. If Flow beta function still unable in English Wikipedia, I would like to call WMF to change the policy. My suggestion is, the Flow beta can skipped community consensus and allow for users to enable in some days (in major language versions). If the feedback's result is OK, the Flow beta function can still exist.--Shwangtianyuan (talk) 01:04, 3 February 2016 (UTC)

Comment. You do know that if you want to "skip community consensus" then you need to oppose an RFC don't you? RFC's are filed to gain a consensus one way or the other. MarnetteD|Talk 05:27, 6 February 2016 (UTC)

Conversion back from Flow, or another set of false WMF promises

Wikipedia talk:WikiProject Breakfast is shutting down their Flow experiment (against the wishes of some members, for ideological reasons) after an RfC. Problem is that no one at WMF knows how a Flow page should be shut down.

The simple solution would be to move it to an archive (in Flow mode) and fully protect it. Disadvantage is that this works for one or two pages, but wouldn't work if Flow should be totally disabled and the Topic namespace removed. Other disadvantage is that no one seems to know whether a Flow page can be moved anyway. It certainly can't be done here, you get "The "Create Flow boards in any location" permission is required to move a Flow board." even if you want to move it to another Flow-enabled place (I know, I tested). Strangely, when you try to move a Flow board, you also don't get the "Leave a redirect behind" box, it is grayed out. While leaving a redirect wouldn't be wanted in this case, in general it is something that should be standard when moving many talk pages.

The apparently harder solution is to convert the page back to a standard wikiproject talk page, with history and all preferably. This is easy, according to all WMF statements, until it is actually needed, and then it is very hard, like here, and needs to be developed. In Wikipedia talk:Flow/Archive 11#Can Wikipedia talk:WikiProject Breakfast be easily switched back? (from September 2014), the question was asked, and Erik Moeller and Quiddity indicated that it was "certainly doable" and that "The script to convert content back was updated at the end of June, and was locally tested by the dev". An actual test the next week was catastrophic (section "Deletion of Wikipedia:Teahouse/Questions/Flow test" a bit lower), but the Flow manager at the time (and other WMF people) didn't respond to any questions about it, even when pinged.

As can be seen from e.g. this phabricator page, apparently the claims from the WMF from September 2014 were, as could be expected, false (let's call them "severely exaggerated"), which was noted a few days later by the non-WMF people but only realised at the WMF now apparently.

So, at the moment, two years after the first Flow deployments and more than a year after we were assured that moving back to wikitext wasn't a problem, it can't be done in a somewhat correct way at all. What a surprise...

On 23 November 2013, Okeyes(WMF) changed the Wikipedia:Flow/FAQ[4] to include the following (in the "Can I opt-out?" section):

If you convert to using Flow during the trial period (in a WikiProject discussion space), we'll be able to convert the content back into a normal talkpage if needed.

This was before the trials here in Wikiproject discussion space started. The above text can still be found on the FAQ (which I tagged as "historical" this week because it is totally outdated in many aspects). So before the WMF asked us to start a temporary trial on some Wikiprojects, they explicitly and clearly promised that conversion was possible. By September 2014, they still said it was doable and they had a tested script which only needed a little tweak to update it. But now that we actually want it, it's panic in the streets of San Francisco apparently.

And people wonder why we don't trust the WMF... Fram (talk) 10:56, 14 January 2016 (UTC)

I'm ok with giving them some time to update the conversion software and sort out the first use of it. On Phabricator T90075 matthiasmullie claimed this task and moved this task to In Development on the Collaboration-Team-Current workboard. It looks like work is active on this. Assuming this is resolved in a reasonable time frame I'd give the WMF credit rather than complaints here. Alsee (talk) 22:53, 14 January 2016 (UTC)

The individuals now working on it, fine. The WMF? No way. They made the promises, they lied. They claimed it worked, they claimed it was tested, and the first time it was needed here (September 2014), it failed badly. No communication followed about this, no improvements were made, the claim that this was no problem remained in the FAQ, and now that it is needed, they'll start to work on it to see if it is even possible? Screw them. If these things, which were said to be possible, written and tested more than two years ago, turn out to be completely incorrect, then it is another argument to shut down Flow completely (together with the 997 other arguments already on Phabricator). But of course, we can't. Fram (talk) 07:51, 15 January 2016 (UTC)

Apparently the current situation is that they can convert the final "text" of the page to a wikitext page, but are unable to recreate the history (not surprising, considering how poor the history is on Flow pages). Their "solution" is to create a text archive without history, and keep the Flow page (and all the topics) as well for the history. So at the moment it is not possible to remove Flow from your wiki if you don't want it anymore after the trial. Well thought out, obviously, this implementation. Fram (talk) 08:08, 15 January 2016 (UTC)

Quick work! They already completed a test-conversion of Project Breakfast. (Copy it from here and paste into a wiki page for preview.) As expected, the rely structure is often hard to follow, but aside from that it turned out significantly better than I expected. There are mixed discussions across different Phab pages on whether they will replicate the history or just snapshot the final page. I asked on Phab for clarification on that point. For Project Breakfast losing the history would be.... sub-par but tolerable. If for some reason this were to get broader use then history would be a necessity. Alsee (talk) 13:50, 15 January 2016 (UTC)

The page has now been converted back. Sorry again, for the long delay. Hopefully we can discuss any issues here, and let that WikiProject get back to focusing on content collaborations. Quiddity (WMF) (talk) 01:36, 18 February 2016 (UTC)

MFD: WikiProject_Breakfast/Flow_archive

Any interested parties are invited to comment at MFD: WP:Miscellany_for_deletion/Wikipedia:WikiProject_Breakfast/Flow_archive

The WMF converted the Flow discussion page for WikiProject_Breakfast back into a Talk page after RFC - Remove Flow from WikiProject Breakfast? reached an affirmative consensus. There now exist a Talk page and a Flow page with identical content. The WMF explicitly left it to us to decide whether to keep or delete the duplicate Flow version. Alsee (talk) 21:22, 20 February 2016 (UTC)

I removed info about Flow the "planned release" from another page.

Based on the failed proposal box on the WP:Flow page and my skimming of the top of this current talk page, I deleted the following from Wikipedia:Wikimedia Foundation § Recent rollouts and planned new features:

*Wikipedia:Flow is a planned release, and you can test it out at Wikipedia talk:Flow/Developer test page.

I trust there are no objections? BTW, the notice box in WP:Flow still promotes it as testable, but it is right below the failed proposal box, so it's debatable IMO whether it needs changing at all. Thanks for all your hard work being bold'n'stuff. —Geekdiva (talk) 04:50, 23 February 2016 (UTC)

Is this alive or not?

I've been asking around to get info about editors needs and Wikipedia's toolset and intentions to end with the mess that Talk pages and discussions in general are. In my opinion, the current state is unacceptable. I've been reading this talk page and still is not clear to me what's the real situation of this project. I see that some significant design choices have been made (I don't know by whom) and that now it's just a bent tree. I'm a dev that wants (or wanted, I don't know after reading too many nonsensical decisions) to create an standalone open source webapp for editors to have a tool that's useful to discuss, argue, edit and basically not scare off new users or make your eyes bleed when you're trying to make sense of some consensus or arguments. Are there any devs interested in that? Because this -> http://i.imgur.com/BdNxXvS.png is unacceptable. Nmaxcom (talk) 04:33, 11 February 2016 (UTC)

The reason stuff is hard to follow is that it's complex and messy with lots of opinions and few facts. The problem is the complexity of the topic, not the complexity of the method used to discuss the topic. Forums (at other websites) generally are talking because they like talking—they are not working on solving an actual problem. A mailing list discussion is generally working out who is going to do what, or is polling opinions on someone's suggestion. Such discussions seldom involve a large group of people arguing about each word.

There have been some suggestions for how the current system could be improved rather than erased. For example, software could make a best-effort guess at how to indent and sign a reply, with a user-preference that disables such assistance. One issue is that if a contributor cannot learn how to handle a few colons and tildes, they are unlikely to be able to do more than fix an occasional typo in an article—why should there be one procedure for editing an article and a different procedure for editing a talk page? By the way, the convention is to click "new section" at the top of the page when wanting to create a new topic. That puts it at the bottom and handles edit conflicts. Johnuniq (talk) 04:58, 11 February 2016 (UTC)

• Hi @Nmaxcom: I feel your pain and share it, but I don't think Flow is the solution. See the Teahouse. Notice the "Join this discussion" at the top of each thread? The tools to solve the most egregious part of the problem do exist, it's all about using them or not.

I wonder if it's time to propose at the Village Pump that we add that widget by default in all talk pages as a vaccine against Flow at en.wiki, to deactivate the primary reason why it is being pushed around. Maybe it should be part of that that Flow RFC that some guys here are talking about. Diego (talk) 10:36, 11 February 2016 (UTC)

I think working on the syntax highlighter or a related feature would also be helpful. @Nmaxcom: you might find it useful, since your image link shows you haven't enabled it (Preferences -> Editing -> Syntax highlighter on enWP). It has a bigger impact for articles, but it makes talk pages at least a bit easier to read as well. I'm also sure it could be improved - there are several useful features like that which I think deserve more support. Sunrise (talk) 04:01, 16 February 2016 (UTC)

Hi @Diego Moya:, @Johnuniq: and @Sunrise:. Thanks for joining in the conversation.

I'm sorry, but I think we're missing the important point. It's not about patching this or that or enabling a preference or two... The current editing system gets in the way of good human interaction, reasoning and fruitful debates. Please try to look beyond the efforts you've already made to get used to this clumsy and complex set of tools. It's pure madness.

We're missing out on good people, smart contributors that would enrich the content and make this place even better. I understand the logic behind the "well, if they can't know, learn, understand and strictly follow dozens of rules, use different tools and have a horrible experience fighting the heinous UX... they aren't that good", but it's wrong. It's not true. I agree some filtering is good, but this improvised filter of torture is not a solution.

Do you know the kind of people I think Wikipedia is losing for no good reason? At least two types come to mind that will drop out or never get in:

* People with great knowledge in a particular field or theme but not very motivated with computers or coding-like writing

* Busy people! With time enough to enrich a particular discussion but not enough to get a damn PhD so then he/she can suffer through intricate syntax and rules and not enjoy the process at all.

Not only the English Wikipedia will be way poorer than it could be, but other languages that don't have as much traffic have even worse articles and are prone to less surveillance and biases. Not to mention, all the other Wikimedia projects. It's all governed by this horrible, outdated system.

I mean no disrespect to the work that has been put here. I mean that. If someone finds my criticism too harsh, please forgive me. But it's time to check the calendar, it's 2016. Why does this have to look and work like it's 1992? When is this going to be addressed? Nmaxcom (talk) 07:23, 20 February 2016 (UTC)

@Nmaxcom: We understand the problem, we're not missing it. I have written many times about it and I agree that it's a problem, and that's why I've become a regular to this project talk page for more than a year.

Believe me when I say, Flow is not the solution to that problem. For a start, it does not look like any other forum system, and it doesn't look like any of the other pages on this site (you'll agree that is a problem for lack of consistency, right?). Moreover, in practice it has proven itself lacking in its ability to support basic workflows which are typical in Wikipedia, such as keeping track of a series of proposals to edit the article (which is the core function of Wikipedia discussion pages), reading new posts in a thread where you have already participated, or voting in a straw poll to decide which alternative course of action should be taken. All these scenarios are badly accomplished with the Flow interface, and it alienates the experienced users that understand the fine details of editing the encyclopedia.

An interface that makes it easy for beginners to participate should still keep all the powerful features of the wiki system on which Wikipedia is built on. Wikis are by its nature one of the simplest ways to collaborate on building content, so the mediawiki platform is really close to allowing an easy interface on top of it; see for example the Wikipedia:Teahouse/Questions page, where newcomers can participate without learning mediawiki syntax. I've made this draft for a request for comments to activate that gadget in all talk pages, as a way to improve the interface for beginners and smooth the learning curve. I'm convinced that other improvements could be made without migrating to an entirely different software platform (that would miss almost all of the current functionality), in special now that the Visual Editor is mature. Diego (talk) 20:05, 21 February 2016 (UTC)

I've made it, I've drafted a RfC proposal to activate the Teahouse gadget at talk pages, complementary to User:BethNaught/Draft_Flow_RfC proposal to deactivate Flow; I'll post it if Beth's RfC is published. Suggestions are welcome. Diego (talk) 13:32, 24 February 2016 (UTC)

@Diego Moya: We definately agree on the problem but not on the solutions proposed. I see your good intended efforts as yet another half measure. Yet another patch over the patch over that other patch. Even your patch were to be implemented, it'll be just another drop in the ocean. Damn, even the Flow monster was just a bad patch, as I think you agree.

The lack of vision and action by the appropriate agents is honestly disappointing. Not to mention the amount of f***s that are given by discussions like this one. RIP Wikipedia Innovation. Nmaxcom (talk) 02:39, 2 March 2016 (UTC)

Yes, I definitely see nothing wrong with patching systems that work to make them work better, so I guess we disagree there; the advantage of software that evolves organically is that it is perfectly suited to the needs of those who use it, even for obscure cases that the designers could have never thought of.

Yes, such system will be much more difficult to maintain, and it will expose some rough edges and quirks. Yet throwing everything away and creating a new tool from scratch is prone to suffering the second system effect. It can be done, but it's better approached with care, as a sidetrack project which may or may not get traction; and which should replace the original only when most people agree is a genuine improvement over the original.

I wouldn't oppose such effort, and I have indeed participated in this very talk page with considerations of what Flow would require to be such a system; although the designers never explained the technical aspects enough to assess if my ideas were viable.

The benefit of the stopgap solution I propose in the RfC is that we could have it in no time, as the hard work has already been done, and it has shown in practice that it works. Fixing paper cut bugs does improve the overall usability of a system, and an imperfect solution tomorrow is better than a perfect solution 10 years down the line. Diego (talk) 11:28, 2 March 2016 (UTC)

Vanilla idea

I know that this is extremely vanilla, but should we activate it on the Signpost or WikiProject newsletters for commenting? It would be similar to existing systems of social participation/engagement. Discuss-Dubious (t/c) 16:44, 17 May 2016 (UTC)

No. Wikipedia is an encyclopedia where the purpose is to edit articles. BTW, those watching this page may like to know that the rumors of Flow's death have apparently been exaggerated as a page at nowiki that I watched has recently been converted to Flow, and I get excited notifications here, whenever a change happens there. Johnuniq (talk) 23:44, 17 May 2016 (UTC)

I don't really understand your objection. I don't understand how a comment system affecting a few pages like this would go against the purpose of the encyclopedia anymore than they already are by simply existing. Are you saying it would eat up more time than they already do? Can you draw the line connecting these points for me? Discuss-Dubious (t/c) 01:08, 18 May 2016 (UTC)

Why would anyone able to edit articles want to use a different system to edit a comment? How do you use a link/template/whatever? How do you see an old revision or revert spam? The current system makes it exactly the same as every other edit! If people can't chat using wikitext they are welcome to use Facebook or whatever interests them. Some improvements to how MediaWiki operates on talk pages might be good, but throwing it all out and creating a new system is pointless. Johnuniq (talk) 03:54, 18 May 2016 (UTC)

I had no idea what your leanings were. I agree with the reasons myself. I'm not saying that we should use it on talk pages. I'm saying that if they want to use it, then VG newsletters and the Signpost are a reasonable place, but not if it is a slippery slope to all articles. Frankly, I prefer the current method of editing talk pages and agree with your concerns. Discuss-Dubious (t/c) 16:26, 18 May 2016 (UTC)

I don't really have skin in the game (to be brutally honest I don't particularly like flow though I've certainly used it many places and find it usable) there are definetly some good reasons people could want a different system. The reality is that MediaWiki itself is designed to write Wikipedia articles and long form pages in general. It's not designed for conversation or chat. We've hacked together systems such as indention that many of us are used to but it's still not designed for that. Flow (for both it's good and bad qualities) IS designed for that and I can completely understand someone wanting to use 1 system (wikitext) for what it's designed for (articles) and 1 system (flow) for what it's designed for (conversation). James of UR (talk) 06:35, 18 May 2016 (UTC)

I honestly understand and agree with his reasoning, but I figured, if they really want this, they can put it where it can do least harm and feel most natural. Discuss-Dubious (t/c) 17:43, 18 May 2016 (UTC)

Putting Flow on a few pages where "it can do the least harm" is a rather poor case for actually doing it, chuckle. There's an inherent downside to having one system for 99.999% of all pages, and a second system for 0.0001% of pages. It's a very poor "compromise" just for the sake of offering some token compromise. The WMF has zero interest in deploying Flow on 0.0001% of pages.

The big problem is that Flow is intended to eliminate all our talk pages, Flow is designed to be a chat board, and it's utterly utterly unsuitable to wiki work. Flow is a preview of their plans for article pages as well. Flow doesn't actually use wikitext. It lets you put in wikitext, it literally throws your wikitext away and translates it into something else, and whenever you ask to see "the wikitext" it invents new, fictional, mangled, wikitext to show you. The entire underlying system is a god-awful kludge and it's broken as hell. If you save and re-edit, it translates back to invents new (often mangled) fictional wikitext. Merely clicking back and forth with the preview button can mangle what you typed in, and clicking preview and back a second time can re-mangle it even further. It can delete tags from your wikitext and mangle the rendered page. That's how broken the system is. The translator is called Parasoid, and WMF literally plans to do the same thing for article pages. The vision is move everything off wikitext, to make Visual Editor the editor, to make Flow-chat-boards the talk pages, and only to maintain fictional wikitext support via the Parasoid translator. If you edit an article in wikitext it will throw the wikitext away, and when you try to look at it again it invents new, mangled, fictional wikitext for the page. I've run into so many Flow bugs that I just plain stopped reporting them. There's literally negative value in diverting valuable programmer-hours continue working on it. Alsee (talk) 04:00, 19 May 2016 (UTC)

I see. I'll take your words for it. You make a good case for throwing the idea out entirely. Discuss-Dubious (t/c) 02:04, 22 May 2016 (UTC)

Archiving flow page

https://www.mediawiki.org/w/index.php?title=Talk%3AUniversal_Language_Selector%2FDesign%2FInterlanguage_links%2FArchive_1&type=revision&diff=2146526&oldid=2140172 These archiving actions triggered the mediaiwiki notification as if there're something new happened on the page and made it feel like users have edited an archived page if you look at contribution history of users who have leave their comments in the page before. Can that be improved?C933103 (talk) 11:10, 24 May 2016 (UTC)

Flow satisfaction survey

I'm just letting interested parties know that the WMF is planning to run a satisfaction survey on Flow soon. I'll probably post the link here when it's released, but here is a preview. Alsee (talk) 15:57, 22 July 2016 (UTC)

User:Alsee Can you ping me when it is released? Thanks Doc James (talk · contribs · email) 14:07, 22 August 2016 (UTC)

I'll be interested in knowing whether there will be a difference between the large wikis such as ours and the small ones. Also, Doc James, I think you got your sig wrong? Jo-Jo Eumerus (talk, contributions) 08:09, 22 August 2016 (UTC)

Thanks one tidel to many. Doc James (talk · contribs · email) 14:07, 22 August 2016 (UTC)

Doc James, and everyone, I'll definitely let you know when the survey goes live. I'm keeping an eye on MWF's task for it. It was supposed to go out months ago but progress has been extremely slow. I'll probably post it at Village Pump and even add it to Central Notice. I'm severely concerned that their current plans for selective survey invitations seem inadvertently designed to bias the results as hard as possible. They plan to post invitations on Flow board only, and to send survey invitations to people's talk pages... but only to people who have replaced their talk-page with Flow.

Hi! I noticed you installed a wine cellar in your house! Would you mind answering our survey? Do you prefer beer or wine?

Alsee (talk) 04:31, 24 August 2016 (UTC)

You totally called it.  — Scott • talk 20:34, 7 September 2016 (UTC)

More like

Hi! I noticed you've used steam automobiles in the past, and are now trying out electric automobiles. Would you mind answering our survey on how you'd like electric automobiles to evolve in the coming years? 

Quiddity (WMF) (talk) 02:06, 10 September 2016 (UTC)

That perfectly represents how the WMF and probably a dozen others see it. For most people, it is

Hi! Bicycles have too many wheels, so we invented the unicycle. Aren't we brilliant? 

And then send that survey only to circuses... Fram (talk) 05:16, 11 September 2016 (UTC)

It looks like the survey should be released in the next few days. It was bumped up to High priority, they have compiled a list of pages to send the invitation to, and there was a comment targeting yesterday as the release date. Alsee (talk) 09:19, 7 September 2016 (UTC)

Note: survey announcement moved into a new section. This will make it easier to link to it as a fresh discussion, without the text in this section being a distracting lead-in. And after I did it, it suddenly struck me as ironic how easily and thoughtlessly I did it in Wikitext. All I did was insert a new section heading above it. Flow's "Structured Discussions" are an iron cage. It gives you zero power or freedom to make unusual edits like that. Alsee (talk) 14:14, 8 September 2016 (UTC)

Flow survey released

Survey now closed. Thanks for all the feedback. Will update once the results are available. Quiddity (WMF) (talk) 22:16, 21 September 2016 (UTC)

The survey has been released. @Doc James, Jo-Jo Eumerus, and Alsee:. The full announcement is:

Hello!

Like some other community members, you are using Flow.

An increasing number of communities now use Flow or are considering it. Although Flow itself is not scheduled for major development during 2016 fiscal year, the Collaboration Team remains interested in the project and in providing an improved system for structured discussions.

You can help us make decisions about the way forward in this area by sharing your thoughts about Flow — what works, doesn't work or should be improved?

Please fill out this survey, which is administered by a third-party service. It will not require an email or your username. See our privacy statement.

Thanks for your ideas and opinions about Flow!

HTH, Quiddity (WMF) (talk) 17:59, 7 September 2016 (UTC)

• For the record, I've stated that the pointlessly different parser/markup and the difficulty of performing structured discussions are the key problems. Incidentally, the latter is one of the two reasons why I am wondering about small wiki/large wiki differences - the smaller projects are less likely to have issues with these as they tend not to have as much structure. The other reason being that they generally are younger and thus don't have as much entrenchment. Jo-Jo Eumerus (talk, contributions) 21:50, 7 September 2016 (UTC)
• Done the survey, despite some useless or leading questions (I don't want Flow, so I skipped the "order by importance" question: does that mean that the default order will be counted as my preference? Probably, but in reality I have no preference, which I couldn't indicate). Fram (talk) 06:40, 8 September 2016 (UTC)

  @Fram, answers are recorded only if you click on the "next" button. If you haven't finished the survey, your results will be incomplete, but your previous answers will count for the final results. Trizek (WMF) (talk) 15:48, 9 September 2016 (UTC)

  Thanks for the explanation, but that's not a solution of course. I can't skip a question which has no importance for me, and I don't think I had any indication of how many questions were still coming (nor of the fact that my answers until then would be counted), so I could hardly stop the survey then and there. Basically, you will have no way of knowing how many people really answered a question, and how many just skipped it, making the survey results rather meaningless (never mind the heavily biased way the survey has been posted to the remaining Flow users). Fram (talk) 15:55, 9 September 2016 (UTC)

• It's beyond belief that the WMF built Flow without genuine wikitext support. The simulated wikitext is a bottomless bug-hole, and it's aggravating how often it mangles wikitext that I type in. Flow's "Structured Discussions" turn into unreadable spaghetti when more than about three people are involved. It doesn't have the power or flexibility of talk pages. If the WMF puts up chatboards the WP:NOTFORUM/WP:NOTHERE disruption would be catastrophic. I was working on a bio where a partisan-political website with significant traffic linked directly to a BLP's talk page. The site sent probably hundreds of angry POV-Warriors on an explicit mission to attack the bio and attack Wikipedia. They would have spread everywhere if we had chatboards. And that was just ONE inbound link. I don't see any prospect that Flow could be upgraded into a viable replacement for talk pages. Alsee (talk) 20:08, 8 September 2016 (UTC)

  Huh - why do you think that Flow would trigger WP:NOTFORUM/WP:NOTHERE disruption, other than the one that already happens on regular talk pages anyway? Jo-Jo Eumerus (talk, contributions) 20:14, 8 September 2016 (UTC)

  For starters, that's exactly what happened at Wikinews when LiquidThreads was installed along side Talk pages. They refer to it as "trollspace". Neo-nazis and other random internet commenters rant about the stories. If it looks like a typical internet chatboard then that's how people will use it. Anyone who edits an article has no problem editing Talk pages, but a generic internet-commenter with no interest in editing is likely to see Talk, shrug, and move on to conventional chatboards. Alsee (talk) 20:58, 8 September 2016 (UTC)

  I'll need to check that out. Not sure about "no problem", though. JoJo Eumerus mobile (talk) 21:44, 8 September 2016 (UTC)

  , Alsee's referring to Wikinews, which has used LiquidThreads for reader comments (not for discussing article improvements) for years. I'm sure that nobody means to imply that Wikipedia editors would behave like random commenters on news websites. Whatamidoing (WMF) (talk) 12:41, 10 September 2016 (UTC)

  JoJo, following up on my comment above, I just looked at the stats[5] from Article Feedback Tool. Out of 646,200 reader comments on Enwiki, 577,672 went unreviewed. That's 89.4%. Either we didn't have the editor time to look at them, or every editors who did look at the comment skipped it (i.e. it was de facto unproductive). Of reader comments that were assigned an evaluation, 10% were rated as potentially useful. Of those, half were marked "resolved". That is a Noise to Signal Ratio of approximately 189-to-1. If those non-editor comments had been left on a chatboard, many of the unhelpful or inappropriate non-editor commenters would have stuck around to internet-argue their cause with us, or to internet-argue with each other. At that point it turns into massive disruption of our workspace. I worked on a biography where an outside website linked directly to the article_talk page. It was an extremely partisan activist political website with substantial traffic. It was deliberately attacking Wikipedia and deliberately attacking the living-person subject of the article. It ultimately resulted in ~two thousand edits to the article_talk page, and it resulted in some good editors snapping under the stress and getting blocked. If the Talk page had been a chatboard we would have been utterly crushed with probably hundreds of non-editor political-hyperpartisian-comment-activists ranting and trying to "vote" in the RFC, demanding the biography be turned into an attack piece. The incident spread to several other community and article pages. If we had chatboards the disruption would have spread to countless political articles, religious articles, scientific articles, and community pages. Trying to put page-protection on the biography article-talk just would have pissed them off more, they would just rant on unlocked chatboards. Just ONE inbound link would have forced us to mass-protect discussion pages, blocking ALL new users from discussion pages until they managed to auto-promote themselves with article-space edits. Imagine a hundred activist forums and activist websites linking to our talk pages, arguing and trying to "internet-vote" every RFC on any remotely controversial topic. Politics, GMO food, vaccines, evolution, abortion, global warming, religion, astrology, homeopathy, UFOs, every nationalistic-issue under the sun, and everything I forgot to list. WP:NOTHERE non-editors with no interest in policy or encyclopedic-content or anything else, only here to internet-argue and internet-vote their pet cause. Do you think we could function under those conditions with anything less than permanent semi-protection on EVERY discussion page? Alsee (talk) 19:10, 12 September 2016 (UTC)

Alsee Just for future reference, my username has a hyphen between the two "Jo"s. One wonders why that doesn't happen with current talkpages - maybe because the WMF is actually right and the current talk page system is a piece of junk that discourages posting in it? It would fit the pattern I've seen on Commons, with changes that facilitate the use of upload tools (e.g mobile upload or the VE upload interface) caused a flood of bad uploads. That said, the difference in average upload quality before and after the changes didn't seem all that large, certainly not as much as between current talk pages and the scenario you are describing. I am also not convinced that Flow is the same thing as a chatboard except for having a similar thread structure. Jo-Jo Eumerus (talk, contributions) 19:29, 12 September 2016 (UTC)

• FWIW, if I were involved in closing a discussion about Flow on the English Wikipedia, I wouldn't be relying on results from a third-party survey. That's not how we do things. - Dank (push to talk) 20:35, 8 September 2016 (UTC)

  The WMF doesn't have much interest in RFC's for the community to make decisions on stuff. They want to start up work on Flow again, and this is a survey to help them decide what parts of Flow to prioritize. It does contain one question on whether people prefer Flow or wikitext, and there is a free-text area we can comment in. In theory a sufficiently negative response might persuade them to reconsider the Flow plan. However the results are almost certainly going to be inflated. They explicitly WP:CANVASSED survey invitations onto the talk pages of people who opted-in to Flow on their User_Talk. The intent was not an unbiased survey on Flow itself, the intent was to find out what Flow-users want upgraded. Alsee (talk) 20:58, 8 September 2016 (UTC)

  Also, I am fairly sure a survey is not meant to make binding decisions. JoJo Eumerus mobile (talk) 21:44, 8 September 2016 (UTC)

• I just filled out the survey, and I found it pretty easy to communicate the things I feel negatively about (which is most of it). I agree that the survey comes across as biased in its design, but that did not prevent me from marking the negative things as negative, and using a comment field to point out the trollspace issues. I encourage other editors to respond to the survey, and to do it on one's own terms, without accepting any implied assumptions. --Tryptofish (talk) 21:47, 8 September 2016 (UTC)
• Done, Told them I couldn't find any useful aspect of Flow... which is true, You'd think the WMF would give up on this lost cause and simply create something that we'd all like, Sure you can't please anyone and everyone but I wouldn't be surprised if Flow only pleases about 5-10% of editors on this entire project. –Davey2010^Talk 23:18, 8 September 2016 (UTC)
• Done. But one comment: I believe that Flow is an attempt to solve a problem that doesn't exist. If newcomers are confused with wikitext-based talk pages, then build something over it, not nuke the whole thing out of existence. Flow provides no useful tool: it just separates Wikipedia into a content edition and a bulletin board system. In fact, the WMF has already done what I've suggested: we have VisualEditor for the newbies. The WMF software department, or even a volunteer programmer, can just add some features into VisualEditor that simplify talk page editing. And at the reciprocal of umpteen the cost! 12 years have been wasted on trying to replace talk pages: see LiquidThreads, another doomed project. What happened to learning from history? — Esquivalience (talk) 00:06, 9 September 2016 (UTC)

<squeeze> I've asked aboiut this on the talkpage Flow forum impersonation of the VE at Mediawiki, and got as an answer, that it's impossible to use VE on talk pages, and I should shut the fuck up about this issue. The thread was closed several times by WMFers, who didn't want to listen. Feel free, to start your own thread there, or post something in my thread as well. I wonder, how such a squeeze would work in this Flow thingy ;) Grüße vom Sänger ♫ ^(talk) 11:58, 9 September 2016 (UTC)

If you want to experiment, I've copied this talk page to my sandbox, where Visual Editor is enabled. ;-) Diego (talk) 12:33, 9 September 2016 (UTC)

It is easy to port VE to talk pages: add an indent feature, remove the features that are only for "content". If VE was programmed with even the smallest whit of focus on abstraction and modularity, it would take at most a month to port it to talk pages. — Esquivalience (talk) 20:36, 9 September 2016 (UTC)

If you could please enlighten those, who vehemently deny this possibility in this thread, and tried to close it with flimsy denials about the usage of VE anywhere on talk pages, I'd be grateful. It looks more and more that it's not implemented, because it would work against the pet project Flow. Grüße vom Sänger ♫ ^(talk) 10:06, 11 September 2016 (UTC)

I think your position would held more weight if we actually built something over wikitext-based talk pages. I've drafted a proposal to activate the "Join this discussion" widget used by at Wikipedia:Teahouse/Questions to make using talk pages easier. I think I will start that RfC when the Flow survey results are published, depending on how they go. Diego (talk) 08:46, 9 September 2016 (UTC)

Off-topic for here, but I would probably support that RfC with the option that it needs to be disabled or disable-able (is that a word?) in preferences for logged-in editors (it should be default on for all newbies and IPs of course). The WMF sometimes seems to forget that there are other (and probably better) ways of making our talk environment more accessible than just building something new from scratch, which they have now tried twice (at least). Fram (talk) 08:55, 9 September 2016 (UTC)

As WP:VPR#Regularise spacing between paragraphs on talk pages (and below) notes, a historical quirk means that we're abusing the HTML "description list" feature by using ::::'s to indent. This is opaque to screenreaders and hard to understand for many sighted people. The "rules" of how it works have to be intuited via observation (or waiting for someone to correct any mistakes). Yes I'm completely used to it, as are most editors, but it's not ideal, and I don't think it will be enshrined as such by baking it into VE. Look at this discussion for example, and the random mix of * and : that have been used above, and my own comment below which is ambiguous as to whether I'm indenting (I am) or other people are interleaving replies (they might, but I request they don't).

There are a number of things that it is utterly unfeasible to do with wikitext talkpages at a large scale, such as

• watchlisting individual topics

  (a few Wikipedias maintain individual subpages for every single discussion topic (e.g. da:Wikipedia:Landsbybrønden), or even every day and every topic (e.g. it:Wikipedia:Bar) on their village pumps, for this kind of functionality. But AFAIK no wiki has done so throughout all namespaces, because it makes it hard to keep track of new discussions.)

• or connecting discussion topics to maintenance tags so that in-article problems can be discussed in-situ with direct context, at will

  ibid

• or moving individual topics or comments from one location to another, whilst keeping attribution intact

  (no, it hasn't been implemented in Flow yet, but in wikitext it can only be accomplished by cut&paste moves).

Some sort of a "structured discussion & workflow system" where each topic and comment and piece of metadata is independent, but logically connected, is necessary for any kind of powerful enhancement (that is done with any kind of reliability/automation). (It could be argued that we "just" need to create a few (hundred) bots that keep track of all subpages, and section-title changes, and page-moves, and etc. But bots are hard to develop/maintain across 280+ languages that have individual wikitext-talkpage informal rulesets.) It doesn't have to look or work like Flow currently does (which is part of the point of the survey), but it would have to be "structured".

Just like we don't use plain wikitext pages for the contents of Wikidata, and can't reliably use them for MassMessage or other uses of JSON, it similarly isn't ideal to use them for the complexity of discussions and !voting and tagging and bot-manipulation and more that occur on our discussion pages. We're used to it, but it's not ideal. Quiddity (WMF) (talk) 02:02, 10 September 2016 (UTC)

If MediaWiki has to use bodged indents, that is a problem with MediaWiki itself, and shows that the code for indenting needs a rewrite. The visually impaired population have waited 12 years for a solution. Perhaps the MediaWiki wikitext-to-HTML parser and translator also needs one. But again, build something over wikitext:

• watchlisting individual topics: the section is the basic unit of discussion. It is easy: make the watchlist seek individual sections that users have watched. It will not cripple the WMF's servers, as long a table is maintained storing the sections watched by users, sorted by the title name and the section name combined in order. If the software detects a section change is changed, search through the wiki's database and change the name using the same algorithm. SQL maintains a B-tree, so searches should be fast, worst-case $O(log_{\frac {m}{2}}n\log m)$, where $m$ is the order of the tree. (TAOCP §6.2.4).
• Section linking. Easier to update every wiki's maintenance tags to support section linking than to spend 12 years trying to fix the problem.
• A note in the edit summary is sufficient for attribution, I believe.

Flow actually makes it harder to keep track of large discussions. Go on any bulletin board system and see how large informal conferences on one thread are handled using even a mature forum system. Wikitext is very space efficient and long individual reply chains can be sustained with occasional {{Od}} to glue things together, although not optimally (building something over wikitext would be helpful, again). Not to mention that unless Flow is optimized correctly, loading busy talk pages would lag readers with older computers. Not to mention a nightmare to read. — Esquivalience (talk) 03:21, 10 September 2016 (UTC)

If memory serves, #1 would require an unacceptable amount of work to implement and has thus been declined in Phabricator a couple of times. And Wikitext talk pages lead to TL;DR much faster than a bulletin board thread, at least for me. Jo-Jo Eumerus (talk, contributions) 09:29, 10 September 2016 (UTC)

It is amusing for the WMF to suggest that watchlisting sections would take "too much work". For 1% of the cost of Flow, they could have implemented section watchlisting and a pile of other enhancements. If I have a page watchlisted, how about highlighting new text? That way I don't have to read it from the DIFF portion of of watchlist's changes-since-last-visit link? They have a perverse interest in not working on that sort of stuff because it undermines the primary goal of replacing Talk pages with Flow. (I'm not saying they are malicious about it, but they just don't perceive value in upgrading something they expect to be gone "soon".) Regarding TL;DR, Flow's spaghetti message threading rapidly becomes unreadable, and the WMF have been dead-stubborn against endless complaints about Flow's whitespace problem. I did a test copying a reasonably typical Talk discussion into Flow. Flow has ~40% of the density of a Talk page. That means a discussion that is ten screens tall in WikitextTalk will be around twenty-five screens tall in Flow. Alsee (talk) 13:25, 10 September 2016 (UTC)

The higher density of wikitext is the reason why TL;DR happens more quickly there, more whitespace is not always a bad thing. The Phab task for section watchlisting is phab:T2738, as an aside. Jo-Jo Eumerus (talk, contributions) 14:41, 10 September 2016 (UTC)

If section watchlisting works only 98-99% of the time, then it is a net positive. Of course edge cases will have to be handled:

• If the section is moved (except to an archive), then the editor moving the section has the responsibility to ping all participants.
• If the section becomes "dead" and archived, then the space efficiency of section watchlisting may decrease. The solution is easy: if there are no edits to a section in n days, then strike it off the watchlist.
• If the section is renamed trivially, then rename the instances in the database.
• If the section is split for some reason, then the editor doing the split should have a very good reason, making this rare. In these rare cases, the editor doing the split should also ping all participants.

And with little impact to WMF servers. Let's assume that editors are watching 10 million sections across all wikis. We will assume that an average entry in the database costs 200 characters. Let's assume even further that the Unicode characters take the full four bytes to store in the database. Then 4 times 200 times 10 million equals eight gigabytes. You can literally buy a flash drive for about the price of a few cups of coffee that can store all our sections. And not to mention that we can compress the string, to 30-50 percent, such that it only takes four to six gigabytes. The Internet Archive can store historical copies of almost every major website, not to mention historical books, with about $5 million in assets, so the WMF can store four gigabytes with $82.7 million in assets. — Esquivalience (talk) 01:17, 11 September 2016 (UTC)

There is only one valid response to comments like this, and that is, that this is opensource software that you can contribute to. We definitely need more hands to do this kind of stuff and you clearly qualify and should be able to dive straight in. —TheDJ (talk • contribs) 12:03, 11 September 2016 (UTC)

• I most strongly concur with all Alsee's comments. I don't think I've ever seen (except work by my 1st year students on communication science or communication psychology courses) a less professionally compiled survey. It's just full of leading questions designed to solicit responses that are positive towards Flow, and there are no options to skip totally irrelevant questions. In fact the list of glaring errors in the concept and design of this survey is too long to mention here. There is also the absolute proven fact (a 2011 discussion is on meta) that the results of surveys of this kind are presented to the community in a manner that they reflect what the WMF wanted to hear. It is possible that the largely new Foundation staff may have a higher level of moral and financial responsibility towards the stakeholders but this remains to be seen. There are far more serious issues to be resolved than even thinking of creating some other form of talk page communications. I mean big issues that affect the very reputation and quality of Wikipedia - and whether or not Quiddity (WMF) is personally responsible for prioritising the various development projects, he certainly is in no doubt whatsoever as to what I am alluding too here. Perhaps in fact, these are issues for which the community should now probably put direct pressure on the new CEO and the Board of Trustees to look into. Instead of Flow, the WMF staff should be looking into means to allow the volunteers to be more actively engaged in the overall concept and development of te encyclopedia. Kudpung กุดผึ้ง (talk) 03:38, 10 September 2016 (UTC)

• I had a long and futile discussion about this with Trizek here as I started to translate it. I first tried to correct all this faults an errors in the German translation, and tried to convince him to get them more truthful and less biased. But he insisted on his bulls*** and I simply sett all my translations back, as I was not ready to deceive the German readers with such utter nonsense translated. Grüße vom Sänger ♫ ^(talk) 18:46, 10 September 2016 (UTC)

• WTF WMF? Why are we even considering bringing back something that (a) wasn't that bright of an idea to begin with (b) didn't even work properly and (c) was resoundingly rejected by the community? In what stygian depth of utter madness does this even come close to resembling a good idea? Andrew Lenahan - Starblind 01:58, 11 September 2016 (UTC)

• You've obviously never worked at a big software company. Standard operating procedure is the suits decide what to do, and then order their underlings to find justifications for said decisions. Everyone needs to "ship" "deliverables" regularly so they can add bullet points to their performance reviews and resumes. What the victims users feel about said "deliverables" aren't listed on such things, so no one cares. The WMF has been pretty transparent about wanting to be a Silicon Valley tech company, so none of this should be surprising. Coming soon: "We've removed the headphone jack Talk pages. They're outdated and you didn't want them anyway." The WMF (or at least the people at the WMF calling the shots), in true management form, views all editors as interchangeable widgets, so even if people leave en masse due to Flow or some other WMF fiasco, they figure they can just spend money on recruitment drives, hence the lack of concern over the dismal relationship between the WMF and community and the constant focus on growing the number of active editors. --47.138.165.200 (talk) 10:02, 11 September 2016 (UTC)

• I'm very interested in the comments above, about watchlisting sections while still using wikitext. I would think that such a system would only be needed for WP: and WT: pages. And I also would suggest that it be implemented only at the level of "Level 2" headers (the section headers with two = signs on each side of the title), and not for subsections. There is little need to watchlist only subsections of a discussion. Would that simplify some of the issues involved in writing the software? --Tryptofish (talk) 01:00, 12 September 2016 (UTC)

  That would be consistent with Flow, as in Flow is as well only the whole topic is watchable. In Flow it doesn't matter to differentiate further, as there are no substructures possible. Grüße vom Sänger ♫ ^(talk) 04:27, 12 September 2016 (UTC)

  No, that would not simplify and of the issues involved in writing such software. —TheDJ (talk • contribs) 07:51, 12 September 2016 (UTC)

  Thanks, both of you, for the replies. I realize that it would be consistent with Flow, but my point is that most of us don't want the very thing that Flow offers in that regard: that absence of sections, replaced by what looks like a chatroom. I see, above, that editors disagree about whether it is practical to watchlist sections in the existing wikitext, and I think that the community would welcome that one feature. It probably would make more sense to put a lot of effort into making it work, instead of putting the effort into Flow. --Tryptofish (talk) 20:51, 12 September 2016 (UTC)

  I've been a bit sarcastic, imho it's one of the severe failings of this forum impersonation gimmick Flow that it's not better structurable. But this way none of the WMF-fanboys could argue, that it should be any deeper then their stuff goes at all. You can’t even watch the whole talk page at once, you'll only get a message for new started threads, and if you want to watch longer, you have to watch any single thread by itself. OK, You won't be bothered by stuff, you don't want to, but there's currently no option to watch the complete talk page with one click under Flow. Grüße vom Sänger ♫ ^(talk) 14:24, 13 September 2016 (UTC)

  That's interesting, thanks. So really, what editors would find most useful is the ability to choose either to watch the entire page, or to watch individual sections. And Flow is no better at offering that choice than the existing wikitext is. In fact, that's all the more reason to seriously consider working this feature into wikitext. --Tryptofish (talk) 21:45, 13 September 2016 (UTC)

  @Tryptofish: The related feature-request for Flow is tracked at phab:T121138 and further discussion in the 3 linked tasks and more in the links therein. (Flow is still very simple, with many as-yet-uncoded features - that's one of the many difficulties with agile/live development). The only way to do it 100% reliably with wikitext, would be to have every single section as a separate wikipage, as done by the limited examples mentioned above. Quiddity (WMF) (talk) 20:31, 14 September 2016 (UTC)

  Thank you very much for that information, Quiddity. Based on the discussion above within this section, I get the impression that, even if it cannot be done 100% reliably within wikitext, it may (perhaps?) be possible for it to be >90% reliable. I think we all agree that making every section a separate page is not what we are looking for. But I can also tell you that, even with a lot more development, Flow is also not likely to be what I and many other editors are looking for. I'm not asking here about features for Flow. @Esquivalience: do you see this issue the same way that Quiddity just described? --Tryptofish (talk) 20:56, 14 September 2016 (UTC)

  @Tryptofish: The ancient feature request for this as part of wikitext is phab:T2738 (applying to both content pages and discussion pages and everything inbetween), which contains some discussion. I'll try to track down related onwiki discussions and link them there. Quiddity (WMF) (talk) 21:19, 14 September 2016 (UTC)

  Again, thanks. Speaking as an editor who has a very poor understanding of software writing, I wonder whether software could recognize Level 2 headers (or Level 2 headers could be made recognizable). --Tryptofish (talk) 21:34, 14 September 2016 (UTC)

  The software can easily recognize headers (see how TOCs work). I'd imagine the difficult thing would be to tell the watchlist that, in a way that works gracefully if a header changes, doesn't require one to write the whole software anew and doesn't have unacceptable performance issues. Jo-Jo Eumerus (talk, contributions) 21:44, 14 September 2016 (UTC)

  Yes, that makes good sense. Wouldn't a change of header, at the section level, be similar to page move, at the page level, in terms of what a watchlist could detect? At a minimum, I would think that an edit made to the section header would be recognized by the watchlist as an edit to the original section. --Tryptofish (talk) 21:48, 14 September 2016 (UTC)

  Pretty sure that from the software's point of view it's a completely different thing. But I am not a developer and only comment here because some of the Flow and WMF debates remind me of past disputes on TV Tropes, a website I have been active on for a long time. Jo-Jo Eumerus (talk, contributions) 22:00, 14 September 2016 (UTC)

• Dear WMF, please do not spend donation money on Flow. In fact, please spend less money on software. Please divert some of donation money to spend directly on content, such as funding access to paywalled sources for trusted editors, creating a fund which offers incentives to photographers who take decent pictures of hard-to-photograph subjects to release their work on Commons-compatible licences, or to people who create useful sound files in the same way. Please divert other donation money to increased legal resources to deal with claims and allegations against content editors. Please set the software staff to developing scripts and other automated solutions that will help with the colossal backlogs which are everywhere you look. Please do not hand them yet another trainwreck-in-the-making. All the best—S Marshall T/C 20:01, 12 September 2016 (UTC)

Until the WMF is accountable somehow to the donors hoping that Wikipedia will improve based on their efforts, it probably won't happen. — Esquivalience (talk) 20:17, 12 September 2016 (UTC)

May want to reconsider that. Jo-Jo Eumerus (talk, contributions) 20:21, 12 September 2016 (UTC)

• Somebody break out the wooden stake an kill this vampire. Liquid Threads was a mess, this is a mess. Utterly unwanted software that only project engineers seem to love. Carrite (talk) 16:17, 14 September 2016 (UTC)
• NOTE: The WMF is currently discussing whether they have enough responses to end the survey. As of Sept 14 they had 358 recorded responses, 193 responses in progress. They don't want too many responses because it means more non-English translation work. If you haven't responded yet, or if you have only partially completed it, I advise doing so as soon as possible. Alsee (talk) 05:54, 16 September 2016 (UTC)

Done for the survey but I'm neutral with Flow talk page format proposal. KGirlTrucker81 ^{huh? what I'm been doing} 12:23, 17 September 2016 (UTC)

• Note: With 583 responses, the survey has been closed. Trizek will take some time to work on and publish the results (phab:T144730). Thanks for all the input. Note that there was/is no intent to use the survey results in antagonistic ways, as some expressed concerns about above - it was initiated by the liaisons as a way to get a better understanding of how the editors who use the current version of the software feel about it; that's all. HTH. Quiddity (WMF) (talk) 22:16, 21 September 2016 (UTC)

My 2 cents

Put some type of forum thing on the admin and 'crat noticeboards and their (non-archive) subpages, Arbitration/Requests/Case subpages, and "X for (deletion OR discussion)" pages, but NOT on talk pages. KATMAKROFAN (talk) 00:27, 22 September 2016 (UTC)

Flow removed from Enwiki for now

Hi all. There is agreement from the main participants and original volunteer to end the Flow testing at WikiProject Hampshire for now, due to the pause of current development work. The only other Flow page on Enwiki currently is the sandbox. Following discussion at User talk:BethNaught/Draft Flow RfC and elsewhere, we all want to avoid a long and frustrating discussion about continuing the overall testing on this wiki at the moment, despite some editors willingness to continue, and so we're removing Flow from Enwiki for now, after converting the 2 existing pages back to wikitext, today.

In the future, if Flow improves to such an extent that Enwiki collectively decides we want to test it again in 1 or more locations, then it will be simple enough to follow that consensus and re-enable the extension here. We're (collectively) trying to resolve this amicably, and after much discussion, in various locations, this is the agreed upon process. Thanks. Quiddity (WMF) (talk) 23:27, 3 November 2016 (UTC)

Nomination for deletion of Template:Wikitext talk page converted to Flow

Template:Wikitext talk page converted to Flow and other similar templates have been nominated for deletion. You are invited to comment on the discussion at the templates' entry on the Templates for discussion page. Pppery 01:57, 19 February 2017 (UTC)

Flow Survey Results Released

m:Collaboration/Flow_satisfaction_survey/Report

This is the most extreme case of POV-pushing that I have ever seen come out of the WMF. The WMF selectively canvassed thousands of Talk page invitations to people who had actively converted their User_Talk pages to Flow, WP:Votestacking the survey as hard as possible in favor of Flow. When the report was being written, I requested that this concern be explicitly noted on the Flow-vs-Wikitext figures. I was told to wait and see how the report turned out. I was unsurprised that this concern was not addressed. I was however shocked-beyond-belief to discover that the authors had done the exact opposite. The report alleged that EnWiki community members posted messages attempting to bias the survey against Flow, alleging that the survey was ballot-stuffed against Flow, and asserting that survey responses critical of Flow were less than fully legitimate. As far as I'm aware, the only advertisement of the Survey on EnWiki were neutrally worded announcements on this page, on Central Notice, and (I think) on Village Pump. I have requested that citation be provided for the asserted inappropriate messages.[6]

The most noteworthy data point is that 52% of participants preferred wikitext talk pages, 38% preffered Flow, and 10% were neutral. Those results are particularly striking, given the massive canvassing of Flow's most enthusiastic fan base. Even more significantly, "Strongly Prefer Wikitext" still outnumbered "Strongly Prefer Flow" and "Somewhat Prefer Flow" combined.

Despite the uniformly dismal survey results on Flow, the entire report pushes a pro-Flow interpretation and phrasing as hard as possible. The report uses these canvassed results and biased interpretation to determine that Flow development should continue, and that the WMF should seek to expand deployment. Alsee (talk) 18:35, 7 February 2017 (UTC)

Note: The most troublesome paragraph, and allegations, have been removed. Alsee (talk) 17:02, 8 February 2017 (UTC)

Gah missed filling out the survey. Just used FLOW again as was on mediawiki. I really really do not like it. I cannot figure out how to search talk page discussions to verify I am not started a new discussion on something were a discussion is already occurring. Doc James (talk · contribs · email) 16:39, 20 February 2017 (UTC)

Nomination for deletion of Template:Archive for converted wikitext talk page

Template:Archive for converted wikitext talk page has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Jo-Jo Eumerus (talk, contributions) 16:30, 25 March 2017 (UTC)

Give us your feedback about some new features for the Flow:Extension

Dear Wikipedia Community,

You might use Flow discussion boards on some wikis of the foundation.

Since you discussed about the Flow:Extension, I imagine you are using the Flow extension on your wiki.

To us, Flow discussion boards are very powerful. However, they can only be used on the discussion page of a specific page. This doesn't encourage collaboration because users usually visit the pages they watch and some discussions remains unanswered for days...

We believe a special page that gather all the discussions of the wiki will improve collaboration between users.

In the meantime, discussions boards are displayed in a separate tab. This can be confusing to newcomers. If the discussion boards were transcluded under the wiki page itself, it'd look like what users are used to see on other sites (like comments on a blog).

As Mediawiki developers, our team have apply for this Grant to develop such features.

If you think this project should be selected for a Project Grant, please add your name and rationale for endorsing at the bottom of this page : https://meta.wikimedia.org/wiki/Grants:Project/ClemFlip/Wikifab/Various_types_of_transclusions_of_Flow_discussion_boards

Of course, other constructive feedback is welcome.

Thanks a lot for your help.

ClemFlip 09:51, 17 September 2017 (UTC)

@ClemFlip: Regarding Since you discussed about the Flow:Extension, I imagine you are using the Flow extension on your wiki. - Flow was uninstalled from the English Wikipedia in November last year after an overwhelmingly negative response from the local editing community. It's unlikely to ever be reinstalled.  — Scott • talk 21:12, 12 September 2017 (UTC)

Not to mention that a special page that gather all the discussions of the wiki for en-wikipedia would be roughly the size of the whole of Twitter combined and would instantly crash the browser of anyone who tried to load it. ‑ Iridescent 21:26, 12 September 2017 (UTC)