View text source at Wikipedia

Wikipedia talk:Flow/Archive 11

Archive 5←Archive 9Archive 10Archive 11Archive 12Archive 13→Archive 15

Strike

If this goes life, I will not use it. As not using your talk page is not compatible with being an admin, I'll have to give up the tools, which I will do, of course. I might even stop editing altogether. --Randykitty (talk) 10:15, 5 September 2014 (UTC)

Note that I left a fairly similar message yesterday up this page.--Ymblanter (talk) 11:46, 5 September 2014 (UTC)
Agree on not using Flow, but a better solution than a strike is surely just blocking the persons responsible for it. You want to force this bad idea on us? You don't listen to community input? Then you are editing disruptively, and disruptive editors get blocked. I don't think they will try the "superprotect" stunt a second time, although the WMF has an unbelievable tendency to not learn from their mistakes. If they roll out Flow to any more pages without any ability for us to undo this: block! If they continue to roll it out without consensus and with this many bugs, even if the "undo Fow" fature is enabled: block. All we have to do is find out who, apart from @DannyH (WMF):, is responsible for the rollout (perhaps he is the only one). Enough is enough. I don't understand how anyone, least of all a product manager, could think after reading this page and what was listed on it in the last week alone, that enabling Flow on more pages (or "updating" the software with this dreadful message system in Echo) could be seen as anything else than deliberate disruption and provocation. Fram (talk) 11:57, 5 September 2014 (UTC)
Don't worry, I won't roll over immediately and I'll join you in blocking disruptive editors, but if everything fails, then we can only vote with our feet. --Randykitty (talk) 12:36, 5 September 2014 (UTC)
I've left a warning at User talk:DannyH (WMF)#Only warning. Fram (talk) 12:01, 5 September 2014 (UTC)
That was probably a bit strong.--Ymblanter (talk) 12:21, 5 September 2014 (UTC)
We tried weak, that didn't work. Why should we work with him, if he has clearly no interest in working with us? Fram (talk) 12:28, 5 September 2014 (UTC)
And I've left a note at User talk:Philippe (WMF)#Major Flow problems (Philippe is the "Director, Community Advocacy, Wikimedia Foundation"). I haven't left a note for the WMF "community liaison (product development)" since I don't have any trust in her impartiality, and becaus she should be on this page already with that role anyway. If she is, she is free to do he job here of course. Fram (talk) 12:06, 5 September 2014 (UTC)
ANI? Dougweller (talk) 13:23, 5 September 2014 (UTC)
ANI is good if we believe that everything should develop like it is being developed, but DannyH (WMF) has overstepped his authority. (To be clear, I have not looked into this particular issue and I do not have an opinion whether he did). If we want to decide whether FLOW should be on en.wp at all, and if is should, on which pages and in which degree of readiness, we need RFC.--Ymblanter (talk) 13:29, 5 September 2014 (UTC)
I agree. A carefully-worded, widely-publicized RfC would be the way to go. There has to be a mandate from the community one way or the other. If the WMF would choose to disregard such a mandate, then forking and a kickstarter campaign would be an option worthy of consideration.- MrX 13:42, 5 September 2014 (UTC)
Yes. I wasn't clear about ANI, and that would have been wrong anyway - I was thinking of its effects on Admins and should have mentioned AN instead. Start it at one of the Village Pumps? Dougweller (talk) 16:29, 5 September 2014 (UTC)
One of the village pumps (technical?) seems like a good place to have the RfC. It should be publicized with a site notice, and with notices on some of the more visible noticeboards.- MrX 17:20, 5 September 2014 (UTC)
I am a bit hesitant because I an mot sure how to start. The developers are (intentionally) murky on wat FLOW actually is. Is this the product beling deployed now or the one which was deployed on two Wikiprojects recently? No, certainly not, we are improving it. Is it Liquid Threads 2.0? No, for sure not, Gott sei Dank, it is certainly smth else. Is it a Facebook (or Twitter) - style infinite structureless sequence of comments? No, definitely not, we are working on it. In this situation, I am not sure what to discuss. I am certainly opposed to the Facebook style sequence, ans I guess most of the Facebook users would. But if we hold an RfC and decide we do not want it, and next the third team comes and says that they are doing smth else - what do we do? May be we still should start it though and keep it more open-ended than usual, with a lot of room for discussions.--Ymblanter (talk) 17:27, 5 September 2014 (UTC)
@MrX and Ymblanter: There are no plans to roll out Flow any further, at the moment. Additionally the roadmap is likely to get bumped back by at least a quarter (it will be edited over the course of next week) due to upcoming staff changes, and the last few days of discussion here and elsewhere. The team really does want more feedback regarding specific features and options, and ways that you'd like talkpages to improve though. Good software needs to grow via eventualism just as much as Featured content does. Quiddity (WMF) (talk) 03:46, 6 September 2014 (UTC)
All of this is going to require change, change that might not be acceptable to some of you. I hope that all of you will be a part of this next step in our evolution. But I understand that if you decide to take a wiki-break, that might be the way things have to be. Even so, you have to let the Foundation do its work and allow us all to take that next step when needed. I can only hope that your break is temporary, and that you will return when the time is right.

So, he at least is happy for you to leave: in fact, quite prepared to dissolve the people and elect another. Deltahedron (talk) 16:44, 5 September 2014 (UTC)

If he would follow his own words ("We also need to remove things we are attached to that don’t have wide adoption.") and get rid of VE under that rule, I might take his comments slightly serious. As it stands, it's just sanctimonious bullshit. Many words to just say "we know better, we'll do what we like, and if you don't agree with us, you are no longer a Wikipedian". He doesn't seem to have noticed what that attitude have caused in the last few years. I pity the few good people at the WMF (well, the public-facing side of it, I don't know the people that e.g. keep the servers running, so no comment on that side of things). Fram (talk) 17:07, 5 September 2014 (UTC)
I neither support nor oppose his stance. I merely report that if we all choose to leave, that may not be seen as a Bad Thing by The Powers That Be. Deltahedron (talk) 17:15, 5 September 2014 (UTC)
  • ... As I said months ago when it was launched/tested - If VE and or Flow became the default here - I will simply go and won't be returning, I know things have to change here at somepoint but I love the wiki-coding and the fact it's nothing like facebook (yet!), Anyway that's my (perhaps unrelated!) view. –Davey2010 • (talk) 22:50, 5 September 2014 (UTC)
    @Davey2010: I love wikimarkup, too. (And refuse to interact with facebook, although not for UI reasons ;-) (I also still handcode my own HTML in a plain texteditor, and am angry at Firefox developers for moving "View source" from the "View" menu into the "Tools->Web Developer" submenu.). Wikitext isn't going anywhere, and the overall/details of the visual-design of Flow are still completely up for discussion. They need input from all types of editors, so that it can change into something we do all want. That might result in vast changes, or additional preferences. But they need your input! Please, let us know what you'd like to see changed or added, to improve upon both the current talkpage and flow experiences? Quiddity (WMF) (talk) 03:48, 6 September 2014 (UTC)
    Well, at least you can teach flow the asterisks, the hashes and the colons, and leave it up to the guys who fancy enabling it from the preferences. Maybe you can have some MOS for talkpages to make it easier for flow to read the code, but please leave our talkpages alone. --Fauzan✆ talk✉ mail 20:23, 6 September 2014 (UTC)
I'm genuinely conufused by what "Wikitext isn't going anywhere" means. Does it mean "Wikitext is a dead-end and incapable of supporting further developmement" or "Wikitext is a permanent feature of our lives and we will support it until the end of time"? Deltahedron (talk) 20:27, 6 September 2014 (UTC)

View history

The View History page for Wikipedia:Co-op/Mentorship_match doesn't have all the usual "stuff" (e.g. Revision history search, et. al.) -- is that a test artifact? NE Ent 23:33, 5 September 2014 (UTC)

I also noticed this today as well. I'm using monobook, and the tabs for revision history and such are there and were usable for time, but for some reason, they're not clickable today. I, JethroBT drop me a line 23:39, 5 September 2014 (UTC)
Yeah, the Flow board history doesn't have revision history -- each topic is stored as a separate page, so the board history includes changes made across several pages. So comparing selected revisions doesn't work the same way. Jethro, I'm surprised you saw that on the page before? You might be thinking of something else -- or maybe I'm thinking of something else. Or both.
NE Ent -- are you asking just because you expected to see it, or was there something you were trying to do through the history page and couldn't? DannyH (WMF) (talk) 00:07, 6 September 2014 (UTC)
@DannyH (WMF): It's possible I might be misremembering, but there's an issue; mw:Talk:Sandbox has this revision history. A similar revision history page does exist for the Co-op, but I cannot click on the history tab on Wikipedia:Co-op/Mentorship match. Perhaps this has something to do with the monobook interface I'm using, or the fact that the page is fully protected at the moment? I, JethroBT drop me a line 00:45, 6 September 2014 (UTC)
Oh! Okay, we actually were crossing wires there. :) I didn't realize that you can't actually click on that link. Yes, that's because you're using Monobook, and that's a bug I didn't know about. I filed a card in Trello 1, we'll take care of it. Thanks for asking; that's not good. DannyH (WMF) (talk) 01:34, 6 September 2014 (UTC)
@DannyH (WMF): Great, thanks! I, JethroBT drop me a line 02:20, 6 September 2014 (UTC)
@DannyH (WMF):, could you perhaps also respond to the many somewhat harder questions asked of you on this page? I think there are more pressing issues that need your input as well, but you seem to remain surprisingly quiet on those. Fram (talk) 08:42, 6 September 2014 (UTC)
DannyH, I've addressed the more general question at The sky is orange NE Ent 21:39, 6 September 2014 (UTC)
I think your analysis at that page misses out a possible option (d) they know but regard the downside as acceptable (to them). Deltahedron (talk) 21:50, 6 September 2014 (UTC)

Phantom Notifications

I posted on the teahouse board as a test, and yesterday SmokeyJoe replied to it. Today, I received the signpost in my talk, so it created two notifications and the little red button said 2. However, on clicking, the popup window was overidden by the Flow notifications, so I was unable to see my second notification that did not have to do anything with Flow. Only by going to the full page Special:Notifications was I able to see my message. KonveyorBelt 15:18, 6 September 2014 (UTC)

Yes, I have already noted above that it is completely ridiculous that messages (Flow notifications) are given more prominence than actual alerts, and that even when you have no new Flow messages, they are shown instead of the alerts. There has been no reply to that remark, just like to most pertinent remarks made here. Messages here about flaws, bugs, errors, ... are routinely ignored by the Flow developers and managers. Basically, all input gets ignored apart from the few things they like to hear (witness the start of a Teahouse Flow page, claimed to be done after discussion with that project, where the linked project makes it clear that there was a consensus against such a page at the moment). They have made Echo worse for no good reason, which was noted before it was deployed here, and afterwards, but there hasn't been a single indication that they take the many complaints seriously or that they are planning to undo this change. Fram (talk) 15:56, 6 September 2014 (UTC)
Hey Konveyor and Fram, sorry for these Echo-related issues.
To quickly get rid of Flow-related alerts, uncheck the Flow notifications in Special:Preferences#mwprefsection-echo.
My understanding of what's going on:
1) If you participate in Flow test discussions or are pinged from one, Echo gets a new panel to manage related notifications.
2) The bug is bugzilla:70461 and a report was added by Quiddity on Friday, with a patch already in progress. I'll ask DannyH to see if we can get a fix deployed early in the week.
Hope this helps.--Erik Moeller (WMF) (talk) 16:15, 6 September 2014 (UTC)
I won't disable the notifications, as I want to check the progress (or lack thereof) of the implementation. But thanks for the pointer. Plus, watching a Flow page doesn't give good results in the watchlist, as has been said countless times. So at the moment it is Echo or nothing.
The bug is only partially correct; Flow messages should always be the second tab, alerts should be the default, not the other way around as it is now. If I have both Flow messages and alerts, I want to see my alerts first, as these are usually more urgent.
Fixing the bug is good: reverting the change is better: not implementing something that has been reported before the rollout to be wrong is of course the only acceptable solution (I don't even dare to ask about testing, VE has shown that that is a word sorely lacking in the WMF vocabulary).
I still haven't seen an explanation of why many people have gotten multiple pings for the same thing, or for why I have a big red "No formatting defined for notification." in the middle of my Flow Messages. Fram (talk) 16:28, 6 September 2014 (UTC)
The second one is bugzilla:67945. I suspect from the actual report on your talk page by User:Sitush that what you describe as "multiple" pings is actually the fact that there's a "Mark as read" panel on the messages panel which you need to click for the notification to go away. Perhaps Danny can comment on the rationale on why there's a separate dismiss logic here.--Erik Moeller (WMF) (talk) 16:47, 6 September 2014 (UTC)
Thanks for updating that bugzilla report. As for the multiple pings, you can also see the section "Echo valley" a bit higher on my talk page, where people get multiple pings, even in pairs. Fram (talk) 16:50, 6 September 2014 (UTC)
I'm now finding it very difficult to spot errant Flow-related alerts from genuine Echo alerts and have just realised that there were four of the latter awaiting my attention but which were masked in some way by two of the former. The only way they showed up was by clicking on the "display all alerts" link. This is becoming a real nuisance - can we not disable whatever change has been made until it is fixed? - Sitush (talk) 16:55, 6 September 2014 (UTC)
Hi Sitush, if you go to Special:Preferences#mw-prefsection-echo and untick the box next to "Flow" notifications, that should help in the interim. Can you confirm?
Before you do, if you still have the issue visible, can you clarify what you mean by "were masked in some way"? There are two things about the current UI that are confusing, in my opinion: 1) It's not immediately obvious with the addition of the "Alerts" | "Messages" panel which one is active. The highlight is blue, which is a link color, so it's IMO too easy to get confused between the two. 2) You have to "mark as read" on the messages panel to make those notifications go away completely.--Erik Moeller (WMF) (talk) 17:04, 6 September 2014 (UTC)
Thanks, Erik. I've unticked the preference as you suggested and will see what happens over the next few hours. I think the two-section panel is inherently confusing and I cannot even really see the point of it. However, it didn't seem to matter which of the two I was on, I could only see two Flow-related notifications (from 7 days ago, allegedly, but in fact they appeared a few hours ago). They were still there despite having visited the page in question but they disappeared from the red-boxed count when I clicked on "All notifications" and found the four genuine Echo items referred to in my earlier message. The red-boxed count was only showing the number two and not the four others. I only saw notification of your reply above when I clicked "All notifications". Sorry if my attempt at explaining this is confusing to you. - Sitush (talk) 17:14, 6 September 2014 (UTC)
Update: the redbox now shows a zero count but on clicking it, the panel still shows two entries, both being Flow messages supposedly generated by Fram seven days ago. I can send you a screenshot if that would help. - Sitush (talk) 17:25, 6 September 2014 (UTC)
@Sitush: If you have time, a screenshot would be helpful indeed. Feel free to send it to erik(at)wikimedia(dot)org if that's easiest. Browser/OS information would be appreciated as well. Thanks very much!--Erik Moeller (WMF) (talk) 19:58, 6 September 2014 (UTC)

The notifications system continues to alert me on my notifications about a post that was posted six months ago with my user name linked. This appears to be Flow-related, so posting here. See: Topic on Wikipedia talk:WikiProject Breakfast. NorthAmerica1000 04:50, 7 September 2014 (UTC)

Notification error

Tracked in Phabricator
Task T69945

Am I the only one to get a strange "No formatting defined for notification." red line in the middle of my "messages"? Fram (talk) 09:22, 6 September 2014 (UTC)

That's bugzilla:67945, and they were looking at it on Friday. No news on a resolution yet. Quiddity (WMF) (talk) 00:10, 8 September 2014 (UTC)

Can't delete or hide messages

It wont let me hide or delete vandalism posted on flow enabled talk pages. When I click hid, it pops up the hide window, but wont accept input, or let me click the hide button. Same for delete. Running MonoBook on Firefox. Monty845 17:49, 6 September 2014 (UTC)

There's a trello card to track that at https://trello.com/c/n6h0KaaX/ (I will be so happy when bugzilla and trello all merge to phabricator). Thanks for the bugreport. :) (I'll ask if it's possible to run the automated tests with monobook) Quiddity (WMF) (talk) 02:44, 8 September 2014 (UTC)
I'm in monobook and get these same errors, just freezes my tab on anything that asks for edit in a popup. (also on monobook). — xaosflux Talk 03:40, 8 September 2014 (UTC)

Get lost, WMF

Wikipedia:Teahouse/Questions/Flow test. Really?

You claim on WP:FLOW, about deployments to anywhere else, that "All deployment ideas are preliminary; actual rollout depends on conversations with staff and community stakeholders. These can be unlocked when we meet our goals for the quarter." And then you don't contact any "community stakeholders" (who would that be? You simply mean the editing community, I presume, but prefer management terms apparently), but just start with another Flow page, despite people clearly expressing serious doubts about Flow at the Teahouse (here, and at the discussion I started at the Teahouse since you apparently forgot that).

It seems that you will fit in nicely with the majority of the WMF people we encounter here (with my apologies to the few that do deserve our repect for trying to really engage the editors here in an open and constructive way). And that Flow will fit in nicely with the majority of WMF deployments as well.

We can't delete the page you started, we can't disable Flow from it, we can't move it away from the Teahouse to your user space (three times very convenient for you), so I have fully protected it. If you want to roll out Flow any further, first discuss it, get some semblance of consensus, and then act upon it. And, of course, if you want that consensus, that agreement, then first seriously improve Flow. You have three pages here were you can test it, you have the whole of Mediawiki, you can enable Flow on the WMF homesite as much as you like. But don't use enwiki as your private testing ground, I thought the WMF had at least learned that much by now, but clearly I was wrong. Fram (talk) 07:49, 5 September 2014 (UTC)

I have given Wikipedia:Co-op/Mentorship match the same treatment, even though that page has one enwiki editor supporting it. Flow should not be rolled out any further without some serious discussion, not this "let's hope no one will notice it" approach. Fram (talk) 10:14, 5 September 2014 (UTC)

If you mean full protection, notice that doesn't show in the page history either. BethNaught (talk) 10:16, 5 September 2014 (UTC)
Indeed. They are reinventing the wheel, but it is a bumpy ride :-D Fram (talk) 10:26, 5 September 2014 (UTC)
Flow is worse than diarrhoea! I don't disagree that talk pages need to be made easier but Flow doesn't, even forum software (e.g. phpbb) can do a better job. Bidgee (talk) 11:55, 5 September 2014 (UTC)
Fram - Just to make this clear, Wikipedia:Co-op/Mentorship match is a testing space for the small team of editors on our team. The page is not linked anywhere (except here), so it would be practically impossible for new editors to use right now. I agree it's not ready right now, and I have no plans to make it accessible to new editors until it is, period. But like you, we want to dedicate time to testing it, and it'd be helpful to centralize our testing there. Could you please consider removing full protection from the page? I, JethroBT drop me a line 19:14, 5 September 2014 (UTC)
Out of interest, why was it necessary to host it on en.wp rather than mw? Deltahedron (talk) 19:34, 5 September 2014 (UTC)
@Deltahedron: Our mentorship space is going to be piloted on en.wiki in December this year. It made most sense to implement a testing space on en.wiki, not just so our team could tinker and test it out now, but to also to be able to evaluate whether Flow is compatible with the processes we will use to match editors together. I, JethroBT drop me a line 20:12, 5 September 2014 (UTC)
That was the page you pointed to above when you said "The teahouse editors discussed it in June". So what was the "it" they discussed? "It" seems to have been activating Flow on the main TeaHouse page, a proposal which was rejected. Could you now please point to the page where those pages "were specifically asked for" and a consensus was established to create them? Alternatively, if it was as a result of off-wiki meeting, or your own innovation, please just say so. Deltahedron (talk) 19:10, 5 September 2014 (UTC)
Flow is pre-alpha, shouldn't be used on any production site, it is also featureless, one can't even control their talk page. Bidgee (talk) 01:04, 6 September 2014 (UTC)

Please correct your mistake

@Quiddity (WMF): (and other WMF people involved in this debacle): You claimed above, quite emphatically, in a response to all this: "Note: Those 2 test pages were specifically asked for, by editors who want to brainstorm and test potential gadgets and scripts to work with Flow." Could you please, just as emphatically, state that this was a mistake on your part, that no such thing was asked for at the Teahouse, and that most editors there were quite clearly against enabling Flow at the moment? And could you then perhaps as well delete that page, as an unwanted implementation of new, buggy software against the wishes of most involved editors? Fram (talk) 08:39, 6 September 2014 (UTC)

@Fram: You are correct, and these were mistakes on my part, for not pushing back harder against further Enwiki page rollouts, and for not communicating the test page's deployment earlier (to give the wider community time to weigh in). Additionally, my apologies for not re-reading that old discussion before pointing it out, and for not pointing out all of the above details to Danny, as is my job. My rushed responses here on Friday were an over-reaction to the confusion that Flow had actually been set live on the main Teahouse /Questions page itself. I've discussed this with Dannyh, and we'll disable the teahouse's test page this week. I have no excuses beyond general exhaustion. Again, my apologies. Quiddity (WMF) (talk) 23:58, 7 September 2014 (UTC)
Thanks. Mistakes happen, and this thing didn't seem to match how you normally act on Wikipedia. Fram (talk) 06:56, 8 September 2014 (UTC)
Thank you.--Ymblanter (talk) 07:12, 8 September 2014 (UTC)

TesHouse roll-out — own goal?

At mw:Wikimedia Engineering/2014-15 Goals we read that for WMFQ1, what the rest of us call July-September 2014, number 3 on the list of "Top departmental priorities" we can expect 3) Deploy Flow to significant Wikipedia use case (in consideration: Teahouse or similar workflow) with the caveat Teahouse is a major use case, there are a fair number of must-have features still outstanding to support it well, and we may not be able to get all the way there in Q1. I realise that these Goals are subject to change like everything in the sublunary world, but it looks as if this was particularly visionary. It also looks as if the required community consensus is likely to be absent for a long time to come. Presumably a major rewrite of those goals is to be expected? I hope that in the light of the controversy above, a very serious attempt will be made to rebuld the consensus before writing another goal of this nature, namely one that imposes Flow on a significant working part of the Englis Wikipedia? Deltahedron (talk) 20:36, 6 September 2014 (UTC)

Yes, the plan is to spend more time updating documentation this week, beyond the changes from early August. That includes scaling back (or pushing till later) the quarterly goals, partially because of some upcoming developer team changes. Also, we'll be spending some time updating the subpages at mediawiki. Quiddity (WMF) (talk) 23:58, 7 September 2014 (UTC)

Communication and action

So, User:DannyH (WMF), when are you going to

You're the product manager, you are responsible for the implementation of these changes, you are responsible for the eventual acceptance of Flow by the community (if ever), and you are responsible for the mess of the last week. Just keeping quiet (or only responding to the easy questions and ignoring the more embarassing or hard ones) may seem preferable to you now, but (at least for me) the result is that I'll never trust you on anything Flow-related in the future. My impression from most comments is that there is already an extreme reluctance by many editors and admins (or "community stakeholders" in the WMF newspeak) to ever consider Flow as a possible replacement. You won't be able to give grants to every page in return for using Flow, so you'll have to find another solution. Communication and honesty may help. Having good, thoroughly tested software is also beneficial of course. Fram (talk) 07:16, 8 September 2014 (UTC)

Notifications icon not disappearing

I have a red 1 next to my user name atop the page. When I click on it, I see I've been mentioned on a Flow page, but the red 1 remains. If I click on the message, I'm taken to the page "[f830b7d3] 2014-09-08 13:14:23: Fatal exception of type MWException" (side point: why are the exceptions so non-specifically named?) and the red 1 remains. There seems to be no way of removing the red 1, no matter what I try doing. -- Ypnypn (talk) 13:15, 8 September 2014 (UTC)

You can either go to your preferences and remove notifications from Flow, or you can (if you are lucky) use "mark all as read" at the top right of the notifications drop down (the red "1" you have). And/or you can join me in requesting that this Flow - Echo change gets reversed since it contains too many problems and no obvious benefits yet. Fram (talk) 13:24, 8 September 2014 (UTC)
Why on Earth does flow need a special message tab? Why can't it use echo like everything else does? There is nothing special about flow messages that requires a special tab and different behavior. Looks like reinventing the wheel with a less round device. Chillum 14:11, 8 September 2014 (UTC)
My guess is that, since they couldn't get it to work the standard way (just like history, watchlist, contributions, related changes, ... don't work propoerly with Flow), they had to set up a separate system, which they could just integrate as a separate tab into Echo (and of course, being an untested and largely unwanted system, they gave it prominence over the existing part, why would you avoid a chance to piss of your user base when it so easy to grab it?). Alternatively, they don't really care about all these other problems and truly believe that they have made an improvement everyone was just waiting for. Either way, not good. Fram (talk) 14:31, 8 September 2014 (UTC)
As a professional software developer I sincerely hope that is not the case. The worst thing you can do with a well integrated software system is to duct tape something onto the side that uses its own way to do everything. If you find your task requires you to do this you should step back and ask yourself if the task makes sense in that system. Chillum 14:35, 8 September 2014 (UTC)
(ec) I though the idea is that you get a flow notification every time anyone posts in a thread you watch or you posted in. For those who heavily use talk pages these notifications are too numerous, and they cannot go to the wtchlist or echo without owerflowing them and making them unusable.--Ymblanter (talk) 14:31, 8 September 2014 (UTC)
A notification every time someone posts in a thread I used would be WAY to many notifications. We have a watchlist for that. If it creates too many notifications for a watchlist then it is not suitable for the notification tab either. I hope the end product looks and acts nothing like the current model. Chillum 14:35, 8 September 2014 (UTC)
It is not suitable for the watchlist. Last time, about a year ago (or was it hal a year), when a test version of FLOW was installed on two Wikiprojects, I added one of them on the watchlist. The watchlist immediately became unusable, and I had to unwatch it within hours. This was documented on this very page.--Ymblanter (talk) 15:10, 8 September 2014 (UTC)
It doesn't work with a watchlist?? Most of us have hundreds of pages on their watchlists (I have >4000) and I want to be able to see it if a message is posted on one of those talk pages. But if I understand things correctly, that is going to be a major pain just below the end of my spine? That is HUGE... Is there a plan to remedy this? If not, can someone please pull the plug on this waste of time and effort? --Randykitty (talk) 15:24, 8 September 2014 (UTC)
It didn't work with a watchlist because they added every single post to a Flow page to the watchlist separately. After complaints, they removed nearly everything from the Watchlist (way too much actually). Then, months later, they pulled the same trick with Flow on Echo. After entirely predictable complaints on mediawiki, they reduced it to the current Echo level, as if that solved the problem. I really don't know whether it is incompetence or indifference or willful sabotage (or any combination of these), but I don't understand why they are so unwilling to reverse the change and think that with a simple patch, this will be suddenly acceptable. But there seem to be company orders to stay quiet on this issue. That's probably the new Engagement Strategy they are promoting. Fram (talk) 15:45, 8 September 2014 (UTC)
Well, we are told that one of the main goal why FLOW inevitably has to be installed and why the current talk pages are a piece of junk (along with the necessity to avoid edit conflicts is that one needs to be able to watch separate threads. In this perspective, it is logical to use FLOW threads on the watchlist. It is just a watchlist of an active editor (I have above 4000 pages as well, including many in Wikipedia namespace) just can not afford it. And echo can not afford it either, it is not really a replacement as a watchlist. It is ok to get an echo notification once or twice per day, it is certainly not ok to get is 100 times per day.--Ymblanter (talk) 15:52, 8 September 2014 (UTC)
Yes, that seems to me like a basic rule: if something is too frequent for the watchlist, it certainly is too frequent for Echo. Furthermore, and probably more importantly until now, everything that happened in Echo could be seen in your watchlist (apart from "Thanks", but that's truly a special case). Now, with Flow, we get edits on pages you watch that appear in Echo but don't appear in your watchlist. This is really bad. Fram (talk) 16:16, 8 September 2014 (UTC)
No, if someone mentions you on a page which is not on your watchlist (and this happens with me a lot as people often mention me as an admin), you get it on echo but do not get it on the watchlist. Howewe, FLOW is not a replacement for such cases.--Ymblanter (talk) 16:20, 8 September 2014 (UTC)
You're right, hadn't thought about that one. Fram (talk) 16:35, 8 September 2014 (UTC)

I think keeping track of new posts on watched pages is genuinely a job for the watchlist, not for Echo. And the watchlist should easily be able to handle it, if Flow is properly integrated with it. After all, normal talk pages also generate watchlist entries for each added/edited post. Of course "properly integrated" includes respecting user preferences like grouping and showing all vs. the latest changes.

One could discuss having an Echo notification type for new watchlist entries, but then for all of them, not just those coming from Flow. And if introduced, this type of notification should definitely not be enabled by default for existing users (it might be useful for new users to make them aware of their watchlist though). The only argument I read (unfortunately not here, forgot where) for direct notifications about Flow activity was that new users don't know how to use their watchlist. That is indeed a problem, but I think direct Flow notifications are far from being a reasonable solution:

TLDR: Please integrate Flow with the watchlist (RC, history, contribs etc.) in the same way as normal pages/talkpages. Please don't use Echo as a Flow-watchlist. Please allow for a discussion of major changes in the respective roles of watchlists and notifications before implementing them. — HHHIPPO 19:18, 8 September 2014 (UTC)

Do not test Flow on pages for newbies

Maybe you need to be reminded again: Flow is not ready for deployment. It lacks basic functions and its look and feel is completely different from the rest of Wikipedia. Newbies need to learn about Wikipedia as it is, not as you hope it will be some times in the future. So please don't bother them with Flow or any other pre-alpha software. This request applies to the Teahouse as well as the co-op and any other page where newbies are expected in relevant numbers. --h-stt !? 16:42, 5 September 2014 (UTC)

Nothing of the kind is happening or has happened, and it's not being deployed anywhere where new editors can use it. I, JethroBT drop me a line 02:31, 8 September 2014 (UTC)
Any reason you couldn't test Flow on the existing Flow test pages? Fram (talk) 09:18, 8 September 2014 (UTC)
Yes, because there will be gadgets and bots at work in the mentorship space we will need to test locally on en.wiki within the mentorship space to see if they will work with Flow (or not). It's also helpful to have a dedicated space to test internal issues considering we are trying to focus on the specific needs of new editors and mentors in learning various editing skills. I, JethroBT drop me a line 19:51, 8 September 2014 (UTC)

Design goals, decisions and planning

I can see that it is time-consuming and somewhat inefficient for WMF staff to keep revisiting design decisions that have already been made a year ago, with users who were, for whatever reason, not involved in those discussions, raising questions and issues that will all have been considered and resolved during the planning process. As I think I suggested above, perhaps the relevant design documents, with the decisions and the reasoning behind them, which will have been generated during the design and planning process, could be posted, or pointed to? That way users can simply read off the answers to their questions without wating too much staff time. Deltahedron (talk) 18:06, 3 September 2014 (UTC)

I agree with you that I too would like to see these design documents/plans/etc. It is of interest that several of the people who have commented on this page (or on the comparable page on Meta) have been "following" the discussion on and off almost since its inception, and that several people newer to the discussion are making the same points in recent weeks that were made in the earliest days of the "discussion". Risker (talk) 18:23, 3 September 2014 (UTC)
The current status of design decisions should be summed up in the section Wikipedia:Flow#Components of the discussion system (I assume WMF still sticks to regularly updating it, there have been several lengthy discussions surrounding this (last year?)). The features marked as experimental seem to stick to a specific setting for a rather long time (doesn't experimental mean something like trying different settings to see what works best?) --HHill (talk) 19:02, 3 September 2014 (UTC)
Notice how it doesn't include a lot of what we would all assume are "basic" functions such as deletion, page moves, basic editing such as re-ordering sections or posts, etc. As someone who was involved in early discussions, I think there was an assumption that the "obvious, basic" functions were the starting point. We've since learned we were wrong, and that assumptions are never a good idea. Risker (talk) 19:15, 3 September 2014 (UTC)
(ec)Thanks for the suggestion -- is that endorsed by the team? The design documents would also be useful, as I stated. BTW, rather a lot of that says "Experimental", "The team is considering ways", "There will be a lot more discussions and experiments on this subject before we're done", "We still need to figure out", "We're still figuring out the right balance", "We have to look more closely at the use cases", "we're open to feedback". Is there a list, other than this document of course, of what issues are still under discussion? What process are the team using to acquire community input on those issues? Deltahedron (talk) 19:19, 3 September 2014 (UTC)
There are actually some good reasons to discuss revisiting old discussions, because the team has changed. I started as a Product Manager at Wikimedia in April, and I inherited a product with a long history. (Happily, I was able to get up to speed a lot faster than another PM would, because my last job was at Wikia, where I built Wikia's version of Flow, which we called the Message Wall.) I've been looking at a lot of the decisions and discussions, and there are some areas where we're definitely going to be making changes. Over the last few weeks, I've also been putting more energy into responding on talk pages and mailing lists, and making our priorities and process more transparent than it has been.
But there are obviously some pieces where we need to do more. We did a quick overhaul on the documentation before Wikimania last month, but there's a lot more to do.
I've been talking to Nick (Quiddity) about how to re-open some of the discussions, with some new questions and ideas. There are some big pieces that I want to bring back up for discussion (like editing other people's comments and indenting), but I need some time to put some wireframes together.
So there will be lots more opportunities to talk and think and share your ideas and questions, coming up over the next week or so. We can't simultaneously discuss every possible element in the feature all at once, but you'll see some of the big things coming up. DannyH (WMF) (talk) 23:20, 3 September 2014 (UTC)

Danny, one thing that would help is if WP:FLOW could be written more clearly, with a detailed summary in the lead, highlighting the issues that Wikipedians are going to care about. For example, it is true that the Foundation is effectively proposing to abolish talk pages? What is going to happen to current and future archives? Is it true that Flow will have infinite scrolling (as with Twitter)? I keep seeing these issues raised on this page, but can't work out whether people simply fear these things are the case, or whether they really are. Some very plain speaking would help a lot. SlimVirgin (talk) 23:48, 3 September 2014 (UTC)

I'm happy to do some plain answers here. The goal for Flow is to be a replacement for talk pages. That being said, there's a lot of work to do before the feature is ready to actually replace any existing talk namespace, let alone all of them, and it will involve a lot of work and feedback and testing with people in the community. There isn't a hard date on it. Lots of work still to do.
Current and future archives -- There will never be a point when old conversations will be deleted or thrown away, or even put very far out of reach. The existing wiki talk page conversations (both on talk pages and archives) are very important to the history of the collaborative work. When we get to the point where we're turning on Flow for a talk page that already has existing discussions, the existing talk page will be moved to an archive page, and there will be a clear, visible link on the Flow board to the archives. This means there will be an annoying moment when a current discussion may be interrupted, and have to restart on the Flow board. Except for that irritation, the archiving should be pretty much the same as archiving old talk page discussions now.
Flow boards have infinite scroll right now. Basically, this is a browsing/navigation question -- how do I browse back through the discussions on the page? The next two pieces of work in this area are the Table of Contents and an in-page Search interface for the Flow board. Once those are built and everyone's had a chance to try them out, then we'll definitely revisit the infinite scroll question and see if there's still a problem that needs to be addressed. DannyH (WMF) (talk) 00:05, 4 September 2014 (UTC)
Thank you, Danny, this is helpful. You say the Foundation is proposing to replace talk pages, but is the aim to replace one form of talk page with another? Or not to have talk pages? And what about user talk and user pages?
Regarding future archives, what will happen? Archives are essential to writing articles. Every time I rewrite, I read the archives to find old objections, sources, suggestions, article drafts. We do need to continue to create these in future. So my question is: does the Foundation's proposal for Flow include being able to create archives in future?
Infinite scrolling is something I've never understood the point of. How would it work in the context of a Wikipedia discussion, and what would be the benefit? SlimVirgin (talk) 00:42, 4 September 2014 (UTC)
I assume it's one of those things that works better on a mobile than a desktop? Deltahedron (talk) 06:37, 4 September 2014 (UTC)
Just in passing, then, when Brandon said [3] "In order for Flow to be successful (e.g., "meet its design goals"), it needs to work for the future,..." was he referring to a set of specific agreed goals in existence today that you can point to or publish, or should we read that as a statement about what the goals would be like when they are agreed at some point in the future? It seems like the latter? Deltahedron (talk) 06:37, 4 September 2014 (UTC)
Danny: Won't Twitter-style infinite scrolling make it rather harder to locate and link an old RfC on a talk page, for example? I find archive pages rather convenient. Andreas JN466 17:05, 5 September 2014 (UTC)
@Jayen466: Finding older content will be done via the search (which is being worked on now). Instead of a single result each from multiple pages (which current archive searches give us) Flow searches should be able to list the individually relevant topics. Pagination vs Infinite scroll is still being looked at, but pagination is needed for non-JS users, so I believe some form of it will definitely be available (I'll be in a long meeting with Danny on Monday, to discuss this and related issues). Quiddity (WMF) (talk) 20:07, 5 September 2014 (UTC)
@DannyH (WMF) and Quiddity (WMF): One major benefit of pagination, that infinite scrolling doesn't get, is that it provides a sense of position and volume within the stream of content. With plain I.S. it's impossible to tell how much content exists - the only way to know whether there's more content is to scroll all the way down and see if something else is loading. Pagination instead provides spatial navigation. This makes it easy to tell for example if you're near the beginning, at the middle or the end of the total amount of content in the board, or to answer questions like "at what time was the board most active", which are hard or impossible to tell with scrolling + search. I hope the table of contents for Flow is made paginated so that it can be used to address this shortage. Diego (talk) 04:43, 7 September 2014 (UTC)
@DannyH (WMF) and Quiddity (WMF): This recent article from the Nielsen-Norman group is also highly relevant to "pagination vs search": Search Is Not Enough: Synergy Between Navigation and Search. Diego (talk) 10:05, 8 September 2014 (UTC)
See also these ideas on a possible coexistence of pagination and infinite scrolling on Flow boards.— HHHIPPO 20:27, 8 September 2014 (UTC)
There is some reboot involved, yeah. But this is also a natural part of the development process. We experiment with things, we get feedback and questions and more ideas, and the feature evolves over time. I figured that was the creative process that everyone posting on this page wants to participate in. DannyH (WMF) (talk) 21:35, 4 September 2014 (UTC)

User stories

I was surprised to discover that mw:Flow/User_stories is currently a blank page. If there are no user stories, perhaps the discussions here are now moot? Or are they going to be rebooted too? Deltahedron (talk) 17:08, 6 September 2014 (UTC)

Hmm, Maryana archived that page in September 2013, and it was originally written in May of 2013 before the main development of Flow had begun. In a general sense, there's a "user story" associated with every single feature, and often for bug-tickets, so they've already developed (or fixed) many dozens of user stories. In a specific sense, I know Danny wants to update the userstories listed at mw:Flow/MVP#Personas and goals and at mw:Flow/Release planning#Personas (which aren't really personas), so I'll add a note in the todo list. Thanks. Quiddity (WMF) (talk) 23:42, 8 September 2014 (UTC)

Substituting templates

@Erik Moeller (WMF):: in a post here, you claim (about the difference between the transclusion we normally get vs. the substitution Flow automatically does) that

"Contrary to some descriptions, it's not quite the same as {{subst:}}ing the template. You can still get back to the wikitext used produce the output, and change it, and potentially re-parse it. It just doesn't do so automatically (which is also not an inherent limitation). "

If I substitute something, I get the wikitext it produced, I can change it, and reparse it. Or I can change the source (template, whatever) and re-substitute it. How exactly is what Flow does "not quite the same"? If it is exactly the same, then why did you claim otherwise? In any case, why not leave the choice to editors whether they want to transclude or substitute it? Fram (talk) 07:31, 8 September 2014 (UTC)

Flow is not {{subst}} ing the templates, but they're not live-transcluded either - the difference is that templates in Flow posts are not automatically updated when the template is altered. They can be automatically updated by editing the Flow post, which will trigger a refresh. This has the negative effects of: future template improvements won't be displayed in old posts. This has the positive effects of: a post will look exactly the way the author wrote it, in future years.
The explanation in the FAQ gives a few more details, but the last I heard the decision was to definitely support the behaviour described in the right-hand column there. I'll ask the devs for an update and/or details. Quiddity (WMF) (talk) 17:33, 8 September 2014 (UTC)
That makes it unsuitable for some talk page uses, particularly in the "template talk" namespace. I suppose workarounds are possible for most such uses, if there are no limitations as to what can be in the header, which seems not to be in the plan. However, if Flow messages can be in categories and then the categories are changed, it would make it a failed category, whether or not it's generated by a template. If "what links here" worked, then it might also fail because of that function, if pages generated by templates were moved. — Arthur Rubin (talk) 04:40, 9 September 2014 (UTC)
This also means that fixes in Flow rendering may not propagate. In other words, if I were to test how < math > tags work in Flow, I'd want the message to update each time I read it. As Flow is near beta (I'd put it at alpha, rather than pre-alpha, although it's possible that some flaws could prevent it ever reaching gamma), that at least needs to be an option. (It occurs to me, that we also need a "read source" function for posts. even for editors who are not permitted to edit those posts.) — Arthur Rubin (talk) 05:04, 9 September 2014 (UTC)
Thanks. This seems to me to be putting the exception as the rule. If people really want their post to remain unchanged, they can substitute templates. This is the current situation, which means that people can choose this once, and it reamins like that for ever. In the Flow setup, the default is that things remain unchanged for ever, but that automatic updates can not be chosen as the default state, and that you have to manually edit posts again to update them. So if there is an update (an improvement) to some fairly often used template in talk pages (e.g. reflist), that improvement won't help any older messages. Never mind headers, which simply need to be auto-updated.
The cost-benefit ratio of this thing seems to be rather negative. Fram (talk) 08:21, 9 September 2014 (UTC)

Note on who can edit messages

We (enWiki) have some bots which edit talk pages (and not just archiving bots and signature bots). For this functionality to continue, "what links here" must work, and those bots must be able to edit Flow messages. This also damages the stability of template expansion mentioned above. — Arthur Rubin (talk) 04:44, 9 September 2014 (UTC)

Danny's slated to re-examine "who can edit posts" this week. I believe it's basically confirmed that change is happening, I just need to give him the deluge of details from past discussions, in order for him to more-fully understand what we've discussed so far, and what the ramifications are for each option. (The top item, and the archive3 survey, in this list, are the most relevant/detailed overviews, but there are interesting points in all of them. (And I need to confirm just how nuanced the options are. I believe it's possible for this particular configuration to easily vary per-wiki, but I'm not sure if that's also true at the per-page level.)
Re: bots, I did a roundup of bots that edit Enwiki talkpages in April, at mw:Flow/Bots, but it needs more details and to be updated. The API is already stable (albeit in need of better documentation), and work on bugzilla:57512 progresses, so I'll re-start encouraging the staff to help the bot-writers investigate the possibilities, once that's a bit further along. HTH. Quiddity (WMF) (talk) 00:37, 10 September 2014 (UTC)

Can Wikipedia talk:WikiProject Breakfast be easily switched back?

Erik states above that "because you can't easily switch back and forth once you convert a page, we need to move very carefully." In the archives of talk:Wikiproject breakfast I see that we were told "What will happen to this pages contents when the trial ends? We can't turn wikitext into Flow posts, but we can turn Flow posts back to wikitext – so your discussions will be preserved and returned to you". These two statements don't seem consistent. Can someone please clarify this? Dougweller (talk) 14:37, 6 September 2014 (UTC)

I'm referring to repeated switching or a user preference. A one-time conversion back to wikitext is certainly doable.--Erik Moeller (WMF) (talk) 15:50, 6 September 2014 (UTC)
Can you show us where and when this has been tested? We now have live projects with a few months of Flow discussions, so it would be nice to have a bit of certainty (beyond your word for it) that this actually would work and wouldn't result in the loss of these months (not that much was said, but still). Fram (talk) 15:57, 6 September 2014 (UTC)
The script to convert content back was updated at the end of June, and was locally tested by the dev (I'll ask for a public demo page, next week). It regularly needs a few tweaks to update it for any API changes since the last update, and has been incrementally updated over the months for just that reason. HTH. Quiddity (WMF) (talk) 20:32, 6 September 2014 (UTC)
Thanks for the explanation. Dougweller (talk) 20:57, 6 September 2014 (UTC)
See below, WT:Flow#Deletion of Wikipedia:Teahouse/Questions/Flow test: the tool works as could be expected, i.e. badly. Fram (talk) 06:43, 10 September 2014 (UTC)

Why isn't it possible to delete the section

at Wikipedia talk:WikiProject Breakfast about black genitalia? The file seems to have been deleted but it the topic is still here. @Quiddity (WMF): you've supposedly hidden a topic there, but the topic heading is still there. I've suggested we go back to a normal talk page. Dougweller (talk) 13:30, 10 September 2014 (UTC)

It's only visible to admins (which is rather annoying for us, but not for most people). It's worse IMO that deleting pages doesn't really work, and that the conversion-to-standard-wikitext script has serious deficiencies as well. I support ending this useless test on those two projects (what benefit does it offer to enwiki or to the WMF devs to have these quasi-inactive projects on Flow anyway?), but perhaps it's better to move the pages to another title (FlowArchive), fully protect them (in as far as that works with Flow), and start with a new standard talk page (i.e. the exact opposite of what was done at the start of Flow). Fram (talk) 13:46, 10 September 2014 (UTC)

Removing flow from preferences didn't quite work

I still have two 10 day old messages and one 6 month old one alerting me to changes on the Talk:Flow/Developer test page. That's all I see unless I click on "All notifications". And why does the red box say 1? Dougweller (talk) 16:37, 9 September 2014 (UTC)

@Dougweller: The red box might still be saying "1" if you have either:
  • unseen notifications in the "Alerts" section of the flyout (which is not currently the default, but should be the default in about 6 hours),
  • or if you haven't marked the Flow notifications as read (they don't automatically get marked as read, just by opening the flyout. We have to either: visit the topic, or click "mark all as read" in the flyout, or click the "x" in the flyout.)
Let me know if that doesn't help. Quiddity (WMF) (talk) 17:15, 9 September 2014 (UTC)
@Quiddity (WMF): There is no X, there is no "mark as read". I visited the topic and the 1 has gone away, but the 3 old messages are still there. And what's worse is that I only see new ordinary messages by clicking on all messages, so an extra step until I get get rid of these 3 messages. Dougweller (talk) 18:44, 9 September 2014 (UTC)
We've made a change that will open the dropdown on the Alerts tab by default, unless you only have new Messages and no new Alerts. That change will remove the extra step. It's live on Mediawiki.org right now, and it's going to be ported to enwiki in about three hours. Sorry for the distractions. DannyH (WMF) (talk) 19:00, 9 September 2014 (UTC)
Any explanation on why you choose to tinker with it instead of simply reverting it? "Patching it week after week is easier and gives less problems" isn't really a convincing answer. While the patches make it less problematic, it still makes no sense to go for the second best option when you could just go with the best one, which would also respect the fact that this should never have been rolled out in the first place. Furthermore, I hope that the serious amount of trouble many people have here is an indication that the whole new design is clearly not intuitive and user-friendly (never mind that even with the patches, it is not scaleable at all to a live environment for frequent editors). Fram (talk) 19:12, 9 September 2014 (UTC)
DannyH, at mediawiki you stated "We released a version of the new notifications, because we wanted to get feedback once people were actually using it for real conversations, not just from team members on test pages. The feedback that we've had has been surprisingly varied -- some people see Echo notifications as requiring immediate notice, and getting more will be a big distraction, and other people don't pay attention to Echo at all, and only want to see things on their watchlist. And even then, there are differences between what and how much people want to see on their watchlist or Echo. " Surprisingly varied, but did anyone (not from the WMF) actually say "nice, this is what we need" (or even close to what we need)? Did anyone think it an improvement, a step in the right direction? Fram (talk) 19:16, 9 September 2014 (UTC)
Strangely enough, I tend to support the notion that Flow should not be rolled back. The team should be held to the notion that what they roll out is tested, working and useful: the discipline imposed by not allowing themselves to roll back could be valuable. As a corollary, of course, they should not roll out versions that are not fit for purpose. Agile software development means refining the product as you go along, not relying on users to find the bugs. Just to remind everyone of some of the lines in the Agile Manifesto (my emphasis): 1. Customer satisfaction by rapid delivery of useful software. 3. Working software is delivered frequently (weeks rather than months). 7. Working software is the principal measure of progress Deltahedron (talk) 06:34, 10 September 2014 (UTC)
In a normal environment, I might agree. In an environment where the trouble of the deployment doesn't touch the devs (who hardly edit here) but regular editors, I don't think your argument holds water. The only result of the refusal is to create more bad blood and to make all their promises about testing, discussion, community engagement, more empty than they already were. Fram (talk) 07:24, 10 September 2014 (UTC)
The point is that this is a normal environment. En.wp is a production wiki, where we are producing an ecyclopaedia. Code rolled out to this wiki must be of production standard. If the new code is buggy in itself, works badly with other features or otherwise interferes with production, then the Flow team have disrupted a working environment. They should imagine themselves in the same position as developers on Twitter or Facebook who roll out code to the working system that is buggy. In other words, they just should not do it. They simply do not have the excuse that it's just a test, we'll roll it back if it doesn't work. It is not a test, it's for real. Failure is not an option on a production system. Code rolled out to en.wp should already have been thoroughly debugged using some of the many available testing regimes on a test wiki. On en.wp we are not the bug testers, we are fellow workers. The Agile philosophy is that the new code contains working tested features to decide whether they are an appropriate part of the design. I want to put the Flow team on the spot here. Let me summarise the attitude we need to see from them. "If my code on test wikis has bugs, fine, that's part of the job, and what I do in testing. I should just get on and fix them. If my code on en.wp contains bugs, then I have failed. I am bad at my job. I am a horrible person. I grovellingly apologise, in public, for messing up. I hang my head in shame. I will work extra unpaid overtime to put it right. Oh, and I will fix it. Now." I challenge the Flow team to sign up to that. Deltahedron (talk) 16:41, 10 September 2014 (UTC)

Flow should be about Flow

I think the rollout of Flow might be more successful if it was just a rollout of Flow. Currently, the rollout includes many changes unrelated to Flow. For example: gray text, limited editing of others' comments, lots of whitespace, etc. These changes may be right or wrong, but they have nothing to do with Flow (why is gray text only needed for discussions, not articles?). Combining all of them into Flow is causing more conflict than necessary. I suggest that the rollout of Flow be focused on just Flow, and leave other changes to a separate project. -- Ypnypn (talk) 16:46, 10 September 2014 (UTC)

Deletion of Wikipedia:Teahouse/Questions/Flow test

So, Wikipedia:Teahouse/Questions/Flow test has been deleted, thanks. It seems that User:Xaosflux had the honours. A few questions

Please remind me who thought that this was even remotely ready to be deployed to a live environment? This is a troll- and vandal-magnet the way it is now.

Can you please finally agree to postpone all further implementations (outside mediawiki or testwiki or labs) until you get the basic functionalities to work? Fram (talk) 06:40, 10 September 2014 (UTC)

That link shows the following to me (non-admin):
Rename [[Wikipedia:Teahouse/Questions/Flow_test]] to [[Wikipedia:Teahouse/Questions/ExperimentalFlowRoom]]
Reply • 2 comments • 20:49, 9 September 2014
Ad Huikeshoven
The main objection to this page as I understand is the word "test" in the name. The intention is to experiment in the Teahouse with using Flow as the interaction tool. Another name might be a better fit for that use.
Fram
Ad Huikeshoven: Since you clearly don't understand the issues at hand, perhaps it is better if you just drop this?
Johnuniq (talk) 08:01, 10 September 2014 (UTC)
Thanks. Seems like you can see quite a lot of this deleted page :-) Fram (talk) 08:10, 10 September 2014 (UTC)
You can even comment on it, I just did a test! Excellent way to have secret discussions ;) BethNaught (talk) 08:19, 10 September 2014 (UTC)
Brilliant! Fram (talk) 08:27, 10 September 2014 (UTC)

@DannyH (WMF): you usually ignore my questions, but perhaps you can check at least this issue and indicate whether this works as expected? I'll not bother you about the issue that many edits made in Flow (to live pages and topics, nothing hidden or deleted) do not show up in ones contributions, I understand from other reactions that WMF people seem to think that this is a feature, not a bug anyway; but when we finally can test one page for deletion (indirectly, but it's a start), some seven months after this rather basic functionality was requested, it turns out that almost everything that could be wrong with it, is indeed wrong with it.

So I'ld like to know: why has a system that can not be properly tracked, removed, maintained, ... been rolled out to a live environment, with the clear intention (and attempts) to expand and speed up this rollout, and with promises that everything was reversible when obviously this has never been tested (or at least not successfully)? When you ask us to test things, shouldn't you be A) reasonably certain that it works for most cases and B) willing and able to reverse everything if it turns out to go wrong anyway? The past two weeks have been one deluge of major problems. Fram (talk) 17:29, 10 September 2014 (UTC)

Contributions to Topic namespace

Preliminary: when was the Topic namespace announced here (at enwiki I mean), and when was it implemented? Seems to have been done very hush-hush, but I may simply have missed it. Is a rather serious design decision, to replace all talk namespaces eventually with only one namespace, and something that just perhaps warrants some discussion?

Current problem: there are quite a few recent changes to the Topic namespace ([4]). But these can not be found in the user contributions when searching for the Topic namespace (e.g. [5] or [6] or [7] don't give any Topic namespace contributions (which they clearly have).

Could the devs perhaps not roll out a complete new namespace before it has been tested somewhat to see that the most basic functionalities actually work? Fram (talk) 08:46, 8 September 2014 (UTC)

And before people think "oh, contributions simply don't go to the topics namespace yet", some apparently do, as we have this. One of them is even not the current one. Mind you, I can't see easily if this is correct, as (just like I noted below) the history returns an error...

Strange (worrying for those of you that still worry about Flow) is that the dates indicated at that page don't match the dates indicated at the actual Flow topics. This seems to be not only totally unusable, but also totally unreliable and corrupt. Rather unlike the WMF, where I have no indications of any corruptness. Fram (talk) 17:06, 8 September 2014 (UTC)

In Special:Contributions, the edits all appear in the actual namespace that the editors were editing things in. I.e. [8] or [9] or [10] - I've filed bugzilla:70662 for the actions that are currently only visible in the namespace-specific section (and not also in the "All" section as they should be).
All topics have to be associated with an actual page (in a standard namespace), so the breadcrumb links from a Topic will always take us to the parent page.
The older entries from me, that you've linked above, [11], are a result of the bug that was fixed with https://gerrit.wikimedia.org/r/#/c/149337/ and they will disappear "as the recent changes table gets truncated" according to the developer (but I'll ask for an udpate). They are not actual changes, they're just page-initializations.
The topic namespace is not replacing other namespaces; it's just a separate namespace for the sake of functionality (such as watching individual topics, and being able to sort and filter the topics in a page). It was announced in m:Tech/News which gets sent to various global Noticeboards, users, and mailing lists. I've filed bugzilla:70595 to get more clarity into how the namespace is being used (now, and in the future), and how to align those mis-matched listings - it's probably not needed as a separate item in those dropdowns, just like the Gadget and VE namespaces aren't. Quiddity (WMF) (talk) 17:52, 10 September 2014 (UTC)

White-out conditions

Resolved

Had a Flow page entry in my contributions, clicked on "hist" and got a completely white page with the text

"[958a135f] 2014-09-08 16:37:25: Fatal exception of type MWException" [12]

If I go to Wikipedia talk:Flow/Developer test page and try the same (click on History), I get the same error. Perhaps an indication that they have started removing Flow from enwiki? (Hey, one can always hope :-D ) Fram (talk) 16:40, 8 September 2014 (UTC)

Filed as bugzilla:70583. Quiddity (WMF) (talk) 21:37, 8 September 2014 (UTC)
Fixed, it just needed a a cache purge. The dev's comment there is that he plans to make his script triggerable from the usual &action=purge so that we can do the same thing onwiki. Quiddity (WMF) (talk) 18:10, 10 September 2014 (UTC)

"Are you sure you want to leave this page?"

I have no idea where this came from, but when trying to exit pages with Flow on this project, I am now getting the standard microsoft "are you sure you want to leave this page?" pop-up, and I have to decide whether to leave or stay on the page before moving on. This has happened with both Firefox and IE9 in the last few days. Could we please not have that? It's one thing for a warning message when one is mid-edit and about to leave a page, but simply viewing a page shouldn't have this result. Risker (talk) 16:53, 8 September 2014 (UTC)

Hm, it should be following the userpreference for "Warn me when I leave an edit page with unsaved changes". I can't reproduce this at the moment, but I've filed bugzilla:70586 in case anyone else can help narrow it down (or in case it rings a bell for a developer). Quiddity (WMF) (talk) 21:56, 8 September 2014 (UTC)
Why should it be following that userpreference if I have not attempted to edit, but just viewed the page? Risker (talk) 00:23, 9 September 2014 (UTC)
@Risker: Sorry, I wasn't clear. I mean: It should only trigger that pop-up, if you A) have that preference enabled, and B) you've made an unsaved change somewhere on the page (typed text into a field somewhere).
I've tried to reproduce but cannot. Is this occurring for you at all of: Enwiki (test), and MediaWiki (test), and beta.wmflabs (test)? Thanks. Quiddity (WMF) (talk) 02:15, 9 September 2014 (UTC)
I'll try to play around a bit more in the next 24 hours, but I've noted it both on Enwiki and MediaWiki pages. It is not consistent, maybe 1 in 3 pageloads, and more noticeable on IE9 than FF. I do have that preference enabled, but it doesn't give the same warning. Risker (talk) 02:21, 9 September 2014 (UTC)
Quiddity (WMF), I've sent you a screenshot with a detailed list of actions that culminated in the pop-up, taken within the past hour. This should be in your email in-box...any second now... Risker (talk) 19:19, 10 September 2014 (UTC)

To the developer (minor but significant function)

As of now, I made the last edit to the page. It is in the table of expected functionality. I wrote that when Flow is perfect, the user will be able to bring the latest post to the top of the list, and then follow it back to its regular place in the discussion. It has been said in the text that the function of listing by date was sought. However, the nature of Wikipedia debate is that statements not only have a time, but also a given place on the page, so hopefully, even if it was just that you ordered them by date, then ticked a highlight button, and reordered them by placement, and followed the list down to where your highlighted statement was obvious to see, surrounded by a thin yellow border or something... Good luck o/ ~ R.T.G 09:33, 8 September 2014 (UTC)

@RTG: If I understand correctly, you're suggesting a way to toggle between flat-view and threaded-view. I.e. All the posts in a topic in either their chronological order, or their logical "A-replying-to-B" order.
E.g. The DPReview (Digital Photography) forum has a "Flat view/Threaded view" toggle-button that does this. (but you can only see the entire topic at once, in "flat view").
If that's accurate, I believe it has been requested before, and the answer was that it runs into a page-cache performance issue - by doubling the number of cached page-renders that need to be stored for each topic - particularly because we want to be able to see multiple Topics on every page, whereas most (all?) other platforms that enable this toggle-functionality only let a user see one topic at a time. However, it would potentially solve (or assist with) the disagreement of flat vs limited-threading vs deeply-threading, so I'll ask the devs again, so that we have more context.
Alternatively, you might be suggesting that we just need a better way to visualize "who is replying to who", in the limited-threading or flat/chronological view; and perhaps we could solve this by having a button that adds a dotted-yellow line connecting the replies to the posts they're responding to (either one-by-one, or all at once which would be an interesting visualization problem if there were hundreds of posts in a topic!).
Let me know! HTH. Quiddity (WMF) (talk) 02:18, 11 September 2014 (UTC)
Not just for the aesthetics. But the "who is replying to who" part, like that, except we only need highlight one at a time. Also on DPReviews page there is a button that says "Next unread". How about putting that button on this new floating talk-tools you are thinking about, if that is, you think that re-ordering is too difficult, but I was almost sure that I read more than once that we should expect to be able to re-order the posts by date to see the most recent and I thought yeah, and would be good to highlight the most recent while it is at the top of the list and then un-order them to find it still highlighted in the ocean of text. It would give us the ability to navigate the talkpage with the mouse on the scroll bar i.e at the fastest possible speed, and if you are going to remove user defined signatures, it will become much more difficult to navigate the longer discussion. It should (in my uninformed opinion) just be a matter of shuffling the page around locally on my own client-side PC. But of course adding that function on either end, I have no idea what that entails. There is various room for style in highlighting paragraphs and it seems you are going all out for a restyling also. However, on the side, don't make it too resource intensive please!@Quiddity: P.S. Sorry for editing your page, I only noticed afterward that it was marked as WMF edited only. ~ R.T.G 06:51, 11 September 2014 (UTC)

Mathematics problems

Tracked in Phabricator
Task T72187

Is mathematics supposed to be working? At mw:Talk:Sandbox, I found myself unable to reply (clicking reply did nothing) with a <math>...</math> formula: I could create a comment with maths in but the formula doesn't appear in the comment. This looks rather like the situation from last October [13] -- not identical, perhaps, but the executive summary is that mathematics markup under Flow is not fit for purpose. Sigh. Deltahedron (talk) 19:29, 29 August 2014 (UTC)

Yes it should be. It was working before (even a week ago, as you saw at mw:Topic on Talk:Sandbox), so this is a new bug. I've filed bugzilla:70187 after replicating it. Thanks as always. Quiddity (WMF) (talk) 20:37, 29 August 2014 (UTC)
Thanks. Just my bad luck to come back after a year and hit a time when it isn't working again, I suppose. Deltahedron (talk) 20:41, 29 August 2014 (UTC)
Oh, and thanks for the Bugzilla link which shows that currently no one is working on it. I'm quite a novice at this sort of thing -- should I have expected someone to be working in it? Will it ever get worked on? Manage my expectations here. (Oh, and if anyone suggests that I should fix it myself, I shall be ... unhappy). Deltahedron (talk) 09:36, 2 September 2014 (UTC)
That bug is currently at the top of our bug queue -- 1. It'll be picked up soon. I'm sorry this has been so frustrating for you. DannyH (WMF) (talk) 16:54, 2 September 2014 (UTC)
Thanks for that. Deltahedron (talk) 16:55, 2 September 2014 (UTC)
Oh, good. I think it's working on En.wp too. DannyH (WMF) (talk) 20:42, 10 September 2014 (UTC)
Perhaps you can reply here about the many things that don't work as well? Fram (talk) 07:04, 11 September 2014 (UTC)

Watching doesn't work

So I watched the Breakfast project talk page. That promised to subscribe me to all new topics. However, I did not get a watchlist item for any of the new topics that started overnight, only a ping (though one ping). To get watchlist items I had to individually star the topics. I'm sure that's not how it's supposed to work? Also, generally, people don't want pings because stuff changes – say I watch ANI (god help them when they get flow), I will permanently have a ping from it even if I don't care about discussions there. People want pings when stuff specifically relevant to them happens.

I'm still concerns the devs don't understand the differing purposes of Echo and watchlists. BethNaught (talk) 07:10, 11 September 2014 (UTC)

A quick look

Firstly, apologies, haven't looked at the comments, so I may be bringing up a perennial topic or something discussed to death. Sorry if I am.

I had a quick look at WT:BREAKFAST. I'm using monobook skin (force of habit). "Page" doesn't do anything. "Edit" and "View source" are not available - this must be why somebody had to go to ANI to ask somebody to revert vandalism a while back! There must be backwards compatability so that, either out of force of habit for existing editors or if (not when) bugs are found in the UI, the old mechanism is instantly available as a workaround. I'm reminded of this link - getting people to switch to a new system is great, but if they can't switch back, you'll be borrowing trouble. Ritchie333 (talk) (cont) 12:54, 11 September 2014 (UTC)

Remote editing

Don't know how to call this feature otherwise :-)

In normal talk pages, you can provide links to e.g. Edit a page or to Start a new section, on the same page but also from a different page. Can you do this with Flow? If not, is such functionality planned? Fram (talk) 13:48, 11 September 2014 (UTC)

Simple solution

The rap on classic talk page is that it's hard for newbies. The simple solution is Model–view–controller -- simply have a "Flow" view and a "classic" view. Whether the conversation is presented as nested colons or facebook style little boxes isn't that important. NE Ent 21:00, 6 September 2014 (UTC)

But the problem is that the current model has no concept of a single person's post--how do you tell where one person's post ends and another person's post begins, in order to display them in the right little boxes? What about separate comments that are at the same indentation level, especially combined with multi-line posting? To MW, it's all just a giant blob, and I don't know how any MVC model could suss out which comment is which through the view alone. You'd need extra data stored somewhere, and once you do that, it probably won't be compatible with the classic view, since it's a different model. Writ Keeper ⚇♔ 03:37, 8 September 2014 (UTC)
I've yet to see any actual evidence that using wikitext in discussion spaces is any more difficult for new users than using wikitext anywhere else. I've seen several studies that strongly suggest that newbies find the *discussions themselves* (or their non-discussion replacements, templates) unappealing and difficult. Technology is not going to fix this issue; if anything, the use of technology (in the form of templates) has actually been detrimental in encouraging collaborative discussion. Risker (talk) 05:38, 8 September 2014 (UTC)
Just anecdotes: I recently encountered a fairly new editor who had been contributing more or less successfully to articles for months. His first response to my talk page message (also his first post in that namespace ever) was I don' know how to get in touch with you, can you see this post? After this experience I looked again at early discussions with a writer of good wikipedia articles (also capable at drawing maps) who appears to be identical with a published author in his field, so clearly neither an idiot nor technically incompetent. It took him about a month to learn proper indenting. Learning how to reference correctly in the wikipedia style (at the moment technically rather complicated as well) appeared to be easier and and more important to him. --HHill (talk) 13:05, 8 September 2014 (UTC)
I said, somewhere above, that it would be much more helpful (and a logical first step) to help editors find the talk page, than to make the talk page easier (ignoring the discussion about whether Flow does that or not). As far as I can tell, nothing in Flow addresses this or is trying to address this, despite DannyH's emphatical claim above that "The Flow team has two main goals. One is to make discussion on wikis more accessible for new people. That part was easy; we passed that a while ago." (despite multiple requests, he has not given any indication of what that claim is based on). Fram (talk) 13:13, 8 September 2014 (UTC)
Yes this is something, that should receive some thought as well (maybe even as part of an interim solution, like the one Erik has written about). A visibly placed suggestionbox can clearly inundate us with mostly useless messages, as the AFT trials have shown. But this does not change the problem that at least some, if not many new users (even those somewhat familiar with wikitext) appear to have difficulties recognizing talkpages as some sort of discussion medium they could use even as they are reading them (and for me, first edit in 2006, it was a little surprising how difficult this apparently must be). So, remembering AFT, we probably should not explitly ask people to comment, but how can we make it more obvious that (empty) talkpages are a place where they could report problems, give some useful hints etc.? --HHill (talk) 01:02, 9 September 2014 (UTC)
I would assume that once implemented, clicking the talk link would create a new flow-style talk page, prompting for a heading and a comment. From the new users perspective, it's not a non-existent page, just an empty one, same as being the first to comment on a news article. If no comment is entered, the new talk page wouldn't be created. So, to the user, there would be no difference between a non-existent talk page and an empty one (aside from the color of the link), both would appear as a request for comments. Oiyarbepsy (talk) 18:03, 11 September 2014 (UTC)

A possible fundamental reason for many of the problems

Looking again at WP:FLOW, I reread the "Rationale" and especially the Expectations. It doesn't really matter for this discussion whether they are good or not, but what is clear that the developers haven taken them too literally, as if these are all the expectations.

What everyone involved seems to have forgotten or ignored is that these are the expected improvements, to be added to the existing good aspects of the functionality. What has been done instead is to remove all functionality and only build the expectations. That's a bit like redesigning the car: the expecttation is that it should be less noisy and less polluting, and instead of an electrical car, you design a bike. Now, a bike is a wonderful invention, and some people need nothing more, but that doesn't mean that we no longer need cars.

Can you please go back to the rationale and rewrite it with an initial list: "key features from the current system that need to be kept". Starting from that, we may perhaps get a Flow system that indeed is useful for what is needed at Wikipedia, instead of one that seems to have forgotten what use cases it was intended for and what system it should be integrated in. Fram (talk) 09:07, 10 September 2014 (UTC)

I concur. Everything about Flow is backwards. It has zero support for collaboration. It's the antithesis of everything Wiki. Alsee (talk) 21:03, 11 September 2014 (UTC)

User talk opt-in

I mentioned this at the test page, but then noticed that you aren't supposed to put feature requests there, so first of several:

Can I opt-in my user talk page to Flow? I think it would be great to make this an option for all users. Oiyarbepsy (talk) 14:45, 11 September 2014 (UTC)

Seriously? No TOC, no archive/history pagination, poor watchlist/Echo integration, bugs with contribution history, poor reversibility, and breaking DPL bot. What makes you think it's ready for serious use? BethNaught (talk) 14:49, 11 September 2014 (UTC)
What, so you should decide for me because you don't like it? Oiyarbepsy (talk) 14:54, 11 September 2014 (UTC)
No, I'm asking you the question I asked: "What makes you think it's ready for serious use?" Devs willing, you're perfectly free to play with (pre-)alpha software if you want to. BethNaught (talk) 14:58, 11 September 2014 (UTC)
No you're not. Not until you can be sure that deploying the pre-alpha software on a production wiki is not going to disrupt the work of other users, as seen for example here. Deltahedron (talk) 20:46, 11 September 2014 (UTC)
You could do that on any page on Wikipedia, Flow or not, by typing {{subst:WP:ANI}} Oiyarbepsy (talk) 21:38, 11 September 2014 (UTC)
Firstly, that would not been as disruptive, and secondly, adding security loopholes rather than fixing existing ones seems an odd way to proceed. Deltahedron (talk) 21:44, 11 September 2014 (UTC)

So, I noticed a bug, pretty low priority. Links to topics don't work properly with hovercards. For example, when I mouseover test, it previews the page test (Well, it does it on my watchlist, even if not here), instead of previewing that discussion topic. In other cases, mousing over topic links, such as on the permalink button, gives me the preview for topic. This is obviously a low priority fix, but put it on the list. Oiyarbepsy (talk) 00:57, 12 September 2014 (UTC)

Watchlist star location

I would suggest that the talk page watchlist star should be located next to the history tab for consistency with every other page on Wikipedia. Oiyarbepsy (talk) 14:46, 11 September 2014 (UTC)

That is being changed back at the moment. Hopefully it'll be ready for next week. Quiddity (WMF) (talk) 01:06, 12 September 2014 (UTC)

To Flow or not to Flow

Hi all,

There continue to be arguments about whether a project like Flow is needed at all, so I'd like to provide some background on the decade-long history of thought behind talk pages and how they can be improved.

Fundamentally, there's one key question to answer for talk pages in Wikimedia projects: Do we want discussions to occur in document mode, or in a structured comment mode? All else flows from there (pun intended).

Document mode

There are not many examples of document mode discussion systems beyond wikis. You sometimes see people use collaborative realtime editors as such, because people want to talk in the same space where they work, but Google Docs provided alternatives (a pretty powerful comments/margin system and built-in chat) early on, for example.

The current talk page system is a document mode system. Individual comments have unclear boundaries (a single transaction can result in multiple comments, signed or unsigned; indentation levels are unpredictable and often inconsistent). All the joys and pain points of working on the same document are present (a heavily trafficked talk page will see many edit conflicts). You can't easily show comments in multiple contexts (cross-wiki, via email, as a notification, etc.) because of the boundary problem.

You could try to make a document mode system work better. On the basis of wikitext, you can do some very basic things, like the "new section" link I added to MediaWiki back in July 2003 [14], when I wrote: "This feature could also be the first stage of a more sophisticated discussion system, where the next stage would be auto-appending signatures and providing a 'Reply to this' link after each comment."

But due to the aforementioned unpredictability, even making a "reply" link work consistently (and do the right thing) is non-trivial. You can get some of the way there, and the Wikipedia Teahouse actually has a gadget, written by Andrew Garrett (more on him below) that does precisely that.

Visit Wikipedia:Teahouse/Questions to play with it. Note the "Join this discussion" link. It does give you a pop-up, and posts the comment for you in the right place, with indentation (it does not auto-sign, but instead tries to teach users the signature habit which they'll need to use on other talk pages).

It may be worth doing more research and development on this, to see just how far we can get without changing the fundamentals, since a wholly new system may still be years out for wide use. However, there are inherent limitations due to the lack of a predictable and consistent structure.

You could go further down the road of a document mode or hybrid system, but IMO not without introducing fully predictable comment markers (think <comment id="234234">Bla ~~~</comment>) -- which would pollute the wikitext, be fragile (e.g. accidental or deliberate corruption of identifiers), and probably be considered unacceptable in a system that still supports unlimited wikitext editing for those reasons.

Structured

I personally gave up on patchwork on top of talk pages about 10 years ago. The advantages of having comments clearly identified as such are many:

I identified some of these reasons when I wrote the proposal for LiquidThreads in October 2004. At that point, the Wikimedia Foundation had 0 employees, and this was too large an effort to likely get traction from volunteers. So after some time, I managed to persuade third parties to fund development, including Wikicities and WikiEducator, and found a developer to do the initial work, David McCabe. David did a good initial job but the system had many known issues and was only deployed at a small scale.

At the same time, I think there were many things about even the original design that were good (and aren't found in most other forum systems):

As WMF started to grow, it took on development of LiquidThreads -- with one developer, Andrew Garrett, who did an amazing job cleaning up the codebase and rethinking many of the assumptions David had made. LQT got to a point where some Wikimedia wikis actually requested for it to be enabled and traction started to build in favor of it. To this date, it is still found in some nooks and crannies in the Wikimedia universe.

translatewiki.net still uses it for its support page [15], and MediaWiki.org for its support desk [16], which are probably the highest profile uses left, and both get a fair bit of comment traffic.

Andrew did a ton of work on the project, but he himself recognized many architectural issues he wanted to address, and there are also UI assumptions we wanted to revisit. The project didn't have a team behind it at that time -- just one very talented part-time developer who was still at university! This was when WMF was barely growing to do development work, picking up some stuff (like LQT and FlaggedRevs) that had been simmering at a smaller scale before then.

In 2011, Brandon Harris, the first person at WMF ever to be tasked exclusively with design responsibilities, took a crack at some initial redesign drafts [17] [18], which still contain many ideas worth looking at. But we pulled the plug at that time, because we recognized that we simply didn't have the personpower to put the resources behind the project to actually get it anywhere near completion -- and that a major architectural overhaul was required to do so.

A new effort was launched about a year ago, now resourcing a full team including design, development, product management, community support. (We're still pretty short staffed on UX research, QA, and data analyst support, but we make do.) As the team (including Andrew with his LQT experience under his belt) thought through the architectural needs of a modern discussion system, they decided that the LQT architecture was not salvageable. A migration script [19] is in development by Andrew himself.

The Flow architecture [20] differs in some important ways from LQT, including:

I don't think the architecture is perfect, but it should be a reasonable foundation to build on and iterate from.

The Flow UI, similarly, represents a first pass at this point. A lot of basic functionality is still missing. Things we know will make users happy (like cross-wiki features) are still ways out. It doesn't support VisualEditor yet, and yet its wikitext input suffers from any issues Parsoid does -- decisions made to future-proof the architecture have negative short term impact.

And like any brand-new UI, it could use lots of micro-optimization -- glitches here and there, which you may not even consciously notice, but which give you the feeling that you're using not-quite-ready software. Which you are.

At the same time, we know from user studies that talk pages are incredibly hard for new users to figure out. The semantics are just extremely different from anything else on the web. So we think a support forum like the Teahouse, and its equivalent in other languages may be a good place to start -- provided the hosts agree that there are no dealbreaker issues for them. This parallels the long adoption of LQT for support desk type forums.

In this context, we also want to do some systematic measurement: How does such a system affect the # of comments posted, and the quality of the discussion?

We expect that we'd need to focus in on this use case in production for quite some time to get it right and really get people to fall in love with the system as it improves. At the same time, there may be other use cases that are less contentious and could serve as additional trials -- like talk pages in Wikidata.

We're not pushing an aggressive schedule on Flow -- we understand it needs to happen at the pace of the communities, since you can't build an "opt-out" for this kind of system (unlike VisualEditor). So the schedule is going to have to give as needed.

And as above, I'm open to us putting some short term effort into talk page improvements that can be made without Flow -- knowing it's still some time out. But based on the above long term functional and architectural considerations, I think a system that treats comments/threads as structured information, rather than as documents, is ultimately necessary, so I'd argue against procrastinating. It's going to be hard enough as it is to get this done without putting it on the backburner once more.

Finally, any comment that is about specific Flow UI aspects should be treated with a massive block of salt. The UI will evolve dramatically as we learn what works for new and experienced users alike.

Sincerely,
Erik Moeller (WMF) (talk) 05:03, 6 September 2014 (UTC)

Discussion of Erik Moeller's statement

Flow isn't ready for a production environment, I find it laughable that it is considered as beta, when it is clearly pre-alpha. Flow can't do what the current talk pages can, archive, delete, remove (blank section or whole page), protect, rearrange comments, inconsistent flow (no pun intended) .... I could go on but to imply that the community is "procrastinating" is a bit insulting, the community shouldn't be forced to make a decision whether to use a incomplete and buggy extension, in fact if you think Flow is so great, why don't you use it on your own talk page? Flow needs far more work before it should even see the light of day on a site like English Wikipedia. Bidgee (talk) 06:46, 6 September 2014 (UTC)
Hi Bidgee, can you clarify what your concern is about using it on test pages clearly labeled as such? This makes it more readily accessible for people on English Wikipedia, rather than pointing them to a separate wiki to test. This is all that happened (a new test page was enabled, in addition to the previously existing ones). Thanks, --Erik Moeller (WMF) (talk) 06:48, 6 September 2014 (UTC)
English Wikipedia shouldn't be used as a testing ground, use Meta for such testing. Who do you think will administrate the comments posted on the test page? En Wiki Admins can barely do anything with their tools on that test page as it is (if you've bothered to read this whole page, you would've found that out by now). Though as I said, if you think it is so great, why don't you use it on your talk page? Bidgee (talk) 07:04, 6 September 2014 (UTC)


My first concern with the particular test page was that it was at the Teahouse: the very last place that we want to expose people to an odd-duck piece of software that they won't encounter anywhere else on Wikipedia. That will lead to nothing but confusion and more demoralization among newbies. Nominating the page for deletion was a singularly frustrating experience as well: it took seven edits to get it right. First because every time I edited the comment, every template in the comment duplicated itself and reexpanded when I saved; second because wikilinks inside the comment were always treated as local links to sections inside the page, not external; third because the page title information presented to templates is wrong; and fourth because there's no "preview" button to allow an editor to get a glimpse of how the edit looks before saving. You are getting ahead of yourself again. There's no reason to have test pages to see how well the page works for particular applications when it can't handle the basic bread-and-butter elements of actually making a comment. This can't handle basic alpha-level tests that developers should be running at unit-test time.—Kww(talk) 07:09, 6 September 2014 (UTC)
Hello again Kww, always nice to hear from you. ;-) Well, technically it's Wikipedia:Teahouse/Questions/Flow test, which isn't linked from the teahouse itself, so no newbie is likely to come in contact with it. Danny posted it purely so the hosts could give feedback in a place that feels a bit "closer to home".
Even leaving the VE experience aside, I'm OK with playing this one slowly, actually -- because you can't easily switch back and forth once you convert a page, we need to move very carefully. I think there's some benefit to a local test page, but if it's causing problems, we can slow down.
Leaving bugs aside (the glaring ones of which I can't reproduce, actually, but I'll let Danny and the team respond as appropriate), have there been issues with the existing small deployments on two WikiProject pages causing workload for admins etc.? I don't see anything relevant in their histories. And this is a much more modest test page relative to two live WikiProjects.--Erik Moeller (WMF) (talk) 07:28, 6 September 2014 (UTC)
@Erik Moeller (WMF): you say about Wikipedia:Teahouse/Questions/Flow test: "Danny posted it purely so the hosts could give feedback in a place that feels a bit "closer to home"." The "hosts" had explicitly rejected using Flow as it stands for the Teahouse, and that was the last that was said about it. Now, at a time when people were clearly asking not to roll out Flow to any other pages, as it has many major bugs, suddenly DannyH rolls it out to that test page without any discussion, community approval, anything. Why hasn't this been reverted yet? Fram (talk) 08:48, 6 September 2014 (UTC)
If you got any of what I tried to do to work, I'm surprised. Go open a topic, put {{mfd}} in the topic, and go from there. Report your experience with getting the page with the MFD template to be reported on our MFD page. Be sure that you actually try to click on the wikilinks and see where they go: I found that every wikilink of the form [[WP:X]] would get magically redirected to WP:Teahouse/Questions/WP:X. The problem with having the "test page" wouldn't be as severe if there was an actual demand for the software, and there would probably be a higher demand for the software if the people developing it weren't intentionally making it incompatible with our discussion processes.—Kww(talk) 16:20, 6 September 2014 (UTC)
Erik, thanks for your explanations. I am not opposed as a matter of principle to a restructuring of the talk pages. However, you probably remember that I was pretty active on the strategy wiki at the time the strategy plan was discussed, and I had to discuss using Liquid Threads. With all my respect to Andrew Garrett, this was the worse nightmare I experienced on any Wikimedia projects as far as the software is concerned. When my taskforce was completed, I left that wiki, with the main reason that I did not want to use LT ever again. I know this was not just my experience, and I do not see a future of anything similar to LT in Wikimedia projects possibly except for some very special situations. The bottomline is not that we should at some random moments face alpha-rollouts, comment on them and wait until the next ones, but that we should broadly discuss how the feature will look like first. Wikidata is a good example of a perfect rollout without much trouble, and the main reason was that it had a broad community support - there were (and still is a lot of discussion, there were ambassadors, there were always people in the community who could help with things, and, in the worst case which did not happen so often) one could always ping Danny and Lydia and get a quick answer to the point. I think we should try to achieve this degree of support of FLOW in the community, and I am afraid this is not exactly where we are currently moving.--Ymblanter (talk) 08:39, 6 September 2014 (UTC)

@Erik Moeller (WMF): Erik, I have already talked in several occasions about those different models at this talk page. Of the two models you present, I personally prefer the first one for Wikipedia, the document-centric approach- although I agree a hybrid approach should be explored (the Teahouse has shown that it can be made newbie-friendly, and I think the expert community could handle a marker-based approach the same way it can manage templates now). It's a real shame though that this conversation didn't take place before all development on FLOW started.

It has been clear for some time from your comments that you favored that change of model as your vision for the new system. The essential problem with your approach to this project is that you never acknowledged the possibility that we could prefer the document-based model, but several editors (myself included) have stated just that, without using this terminology. The list of benefits you posted I see as "nice to have", maybe, but none of them I see as essential. On the other hand, changing away from the document model would lose many possibilities and quirks that thousands of power users depend upon for their daily workflows.

Now, don't get me wrong, those benefits may be a great way to build new communities around them, they're just not a good fit for this already existing, mature community. Wiki software has a long tradition of good practices on how to handle conversations, and the communities that depend upon them have come to rely and benefit from those. Full accountability, flexibility and deep equality of all participants on the final result are expected properties of the system, which the "structured comments" model doesn't have. We have already seen how the new system fall short on them, with people not being able to change other people's comments or see the list of all changes to a board; by the time you rebuild all these essential features in the new system, you'd be mostly back to an ad-hoc, incomplete, bug-ridden, slow document-based model again.

This is not an "old" way to do things, merely different from the mainstream; but this way is what makes the community tick and acknowledge ourselves as such, and what allowed us to build a project that is different from what any other company like Google or About.com tried but couldn't accomplish; and now you're requesting us to throw away all that and turn us into something different; perhaps offering to re-build from scratch a few of the lost features that a small percentage of the user base rely upon, but never recovering the full possibilities of the previous model. Maybe a huge company like Google could accomplish such feat, at the cost of a huge impact to their reputation; but there's no way a "small company, pretty short staffed on UX research, QA, and data analyst support" could manage to execute such change to the essence of a large, working community. The way I see it, you're running a locomotive full-steam against a solid mountain, and a crash ten times huger than the VE and Media Viewer combined is on the horizon.

What hurts more is that you have single-handedly decided that the existing participation model must conform to the new paradigm. Instead of building your own new project where to test those assumptions, you will hijack the tools on which the existing community was born and evolved, and such fundamental change to the essence and nature of participation in the project has been presented as fait accompli, something that will happen whether we want it or not.

If it's true that community input is welcome, acknowledge the possibility that "Structured conversation" is not what we want or need, and plan accordingly. Drop this narrative that Flow *must* replace current talk pages in the end, which is seen as a menace to the core of the community. If you make a strong stance to limit Flow to side projects, you may find the welcoming, collaborative atmosphere you wish for. The end result may very well be that the community finally accepts the change to the new model for all conversation; or it may be that we reject it altogether. But that acceptance only can happen organically, with people here and there realizing and accepting that it's indeed a better model. So please, chase the core narrative and let the goals of the process be community-driven, as a sign of respect to the community that you want to serve. Diego (talk) 09:39, 6 September 2014 (UTC)

+1 I'll say it explicitly: I prefer a document model. For the record, I was a newbie fairly recently (6 months ago) and, after a quick read of the relevant page, I had no problem participating in wikitext-based discussion. What took acclimatisation was the community norms, but any community will have those. I still think the way to decrease participation barriers is to make VE work (and it's nearly there) and look at talk page editing with it. Click where your message goes, indent appropriately, type and presto! (but how does VE manage edit conflicts?) BethNaught (talk) 10:08, 6 September 2014 (UTC)
In fact, this page is not the right place to be having the overarching discussion either. This is only one language and only one project. The obviously correct place for this discussion would be at mw:talk:Flow but for some reason that seems to be an unattractive option. Deltahedron (talk) 15:46, 6 September 2014 (UTC)
Right, okay. I've struck my comments and will unwatch the page. So much for trying. Victoria (tk) 15:51, 6 September 2014 (UTC)
I have already replied to Victoria personally to apologise abd make it clear that I did not wish her to feel unwelcome. The point I was making was that the MW page is Flow-enabled, and for some strange reason even Flow developers and WMF staff prefer to use this page for their discussions.
@Victoriaearle: I think you post here is very much to the point and I do not see any reason why you should cross it out.--Ymblanter (talk) 16:03, 6 September 2014 (UTC)
I've unstruck, and thanks to Deltahedron for the message - I had misunderstood. Thanks, too, Ymblanter, for the comments - ultimately I believe what I wrote is to the point, but after reading the discussion on the mailing list you linked, I realized this discussion is simply cosmetic. The decision has been made; and in my view it's a decision based on a severe lack of hard data in terms of how content editors use article talk space. And I felt it particularly patronizing that Erik Moeller wrote the comments above without (apparently) the intention of responding. Because, as we now know, there's not a response. We're to get a structured system in article space, whether we like it or not, whether or not it facilitates content writing or building encyclopedic material, and what to me is deeply depressing is that my time spent here during the past some years is apparently considered of such little worth that if I disagree at all, if I suggest that perhaps pinning down user requirements might be a place to start, I'm told where the door is. I've basically decided to take that option and walk through the open door. I believe, strongly, the divide between paid WMF staffers and unpaid editors is now too great and too divisive. Victoria (tk) 16:19, 12 September 2014 (UTC)

Please don't fix talk pages, they are not broken. Chillum 15:44, 6 September 2014 (UTC)

It appears to be a Board level decision: The development of Flow, a discussion and workflow engine. Discussion (talk) pages are the backbone of collaboration in Wikimedia projects, and simplifying participation in any conversation on our projects is an important counterpart to improving the editing experience. In addition to the discussion experience, Flow will provide the structural support for simplifying many workflows that have evolved over the years in Wikimedia projects which depend on copy and pasting cryptic markup from one page to another. We anticipate that Flow will not only make our projects easier to use, but will significantly reduce the workload of our volunteer community. I doubt that Erik or Lila have the authority to change direction, but you could put that question to the Board at m:Wikimedia Foundation Board noticeboard. Bear in mind that the Board chair is perfectly prepared to see us all leave the project if we do not agree with the Board's direction of travel [22], as I noted below under "Strike". You might also want to note Jimmy Wales's statement "We are no longer in an era where voting to disable key software features is accepted." [23] Deltahedron (talk) 21:33, 6 September 2014 (UTC)
A nice story, and very touching. The difference with Flow is that, to pursure the analogy, the kids did not have the option of getting rid of the mother who didn't like her present and getting another mother who did. Here, the WMF Board chair has explicitly stated that people who don't like the new way of doing things should leave. Deltahedron (talk) 09:05, 7 September 2014 (UTC)
  • Talk pages are complicated and confusing. True, because writing an encyclopaedia, and all the other projects, require a complex variety of processes, especially since Wikipedia largely relies on behavioural constraints as a proxy for editoral policy. Flow can be designed in two ways to respond to this: to simplify the processes, which have evolved for a purpose, and with no obvious way of replicating the required workflows; or to replicate the processes, requiring a huge amount of work for no obvious benefit.
  • Wikitext is difficult to use in the way those conventions require. I don't think so. The elementary aspects of markup are not hard to master. It's the conventions which are arcane, although probably needed, and to the extent that Flow replicates them, it will precisely fail to address them. What it will do is to hugely increase the demand in developers whenever processes need to be changed or replaced.
  • Experienced editors are horrid to newcomers. Yes, and Flow is not designed to do anything about that.
Incidentally there is no evidence that any research at all has been done on these workflows, or how they might influence the design of Flow. This is quite remarkable considering that these ideas were being discussed on this page a year ago. Perhaps given the reboot that's underway, and the arguments above, the right thing to do is to say that Flow was a dead end, incapable in principle of resolving the real problems of editor retention, and that it needs to be stopped right now. Deltahedron (talk) 20:05, 9 September 2014 (UTC)

Solving a problem by creating another

I hope that the patch to solve the notifications problem is intended as very temporary? It isn't really a solution.

I was testing (it's a test page!), adding a standard talk page header to the header of the test page. The first random page I encountered was Talk:Nuk-luk, with a rather standard talk page header (not the smallest one, but nithing exceptional or outrageous). I can't add it, message "The content is too large. Content after expansion is limited to 25600 bytes." Right... Second one, with only one project, worked, third one was Talk:Chesma (ship), failed. Fourth, Talk:Pyaar Kiya Nahin Jaatha, belongs to two projects, failed.

But we are on a Wikipedia talk page, perhaps I need to focus on Wikipedia talk headers? First one, Wikipedia talk:Manual of Style/Accessibility: I omitted the miszabot and archive templates (although we need the latter), but still no success. Wikipedia talk:Copyright problems.

It only works with simple things like Talkheader (note how this and other templates interpret the header as a redirect though, not good either).

I understand that some typical talk page templates will need to be reworked to work on Flow. But it still needs to be possible to put them in a header of course, and currently we can't. Fram (talk) 12:11, 12 September 2014 (UTC)

Hi Fram, right now the team is focused on the basics -- commenting, search, getting the watchlist/notifications distinction right, etc. That's why the use is at such a small scale. The post size limit should help in the context of small scale testing but may need to be revisited later, for the reasons you give and others.--Erik Moeller (WMF) (talk) 15:48, 12 September 2014 (UTC)
And those basics have taken what, a year and a half now (a year since the first release)? But in every roadmap and planning we get, in three months time huge progress will be made, and large amounts of things have been "finished" according to every roadmap, but still need small scale testing to get it somewhat workable, eventually, perhaps. Why are there three test pages on Wikipedia since February, when in September we are still doing small scale testing of the basics? Isn't that what mediawiki and test can and should be used for instead? I have no problem with the fact that you need to get back to the drawing board, but then do so, and don't continue the tests here as if this is ready for further deployment when the current deployment isn't even working as it should. Fram (talk) 17:03, 12 September 2014 (UTC)