Wikipedia talk:Flow

Lacks an experienced, non-sticky persona

All the personas listed are sticky. In my present guise, I'm not. Over the years, from time to time, I became involved with a page and made substantial contributions. I know the basic markup inside out, and I've gradually become familiar with the most important editorial templates and the policies these enforce. I actually use Wikipedia to survey subject areas I'm learning about for my personal and professional purposes. If I'm being thorough in my research, this often takes me into the darker reaches of unloved articles, where I'm quick to spot various kinds of breakage. I'm usually happy to invest five minutes to bump an article in the right direction. It can be anything from fixing broken markup, copy editing, adjusting balance, splitting an overgrown lead, or plumping up an insufficient lead (the lead is the most frequent problem area I find myself fixing in the musty article space). I believe the majority of my edits serve Wikipedia editorial policy, but I don't hang around to polish my surgeries; I'm hoping others will come along with more investment in that subject area for the smoothing out (always leave a nickel for the next guy). Though my attentions are brief I strongly believe in leaving explanatory tracks. If the template reason field or the edit comment don't suffice, I generally leave a paragraph on the talk page; sometimes all three. In the rare case where my edits are reverted, I don't return to the scene of my crime to contest the issue: I'm okay if 90–95% of my edits make it through infancy unscathed. It's more efficient to be a little on the edge than to second guess myself. Generally I'm an experienced seagull editor who drops a note into a conversation and then bubbles off. I'm not antisocial. If someone challenged one of my edits on my talk page, I would surely respond. I find in software development projects it's always good to model at least one persona who doesn't love what you're building as much as you do. A non-sticky persona might be a good add. Also, I've often added comments to talk pages where I suspect the talk page won't be viewed again for weeks or months or years. I'm quicker to make edits on the pages where editorial velocity and conflict are inherently low. That's another aspect you might wish to model: semi-retired editors who mainly stick to infrequently traveled back roads, where topics created are more like messages in a bottle to record intent than to solicit active engagement (attached to pages where I might not have much of an interest or opinion on its future evolution). I've been around long enough to hold an opinion about the kinds of edits a less experienced editor (say 300 edits) might be afraid to take on, for fear of ruffling some previous contributor's feathers. It's my intent, anyway, that some of my more savage edits lower the permission barrier for such a person (in fly-by-night mode, I rarely delete existing text unless it's extremely out of line, as this strikes me as rude). I would wish to monitor my topics to make myself available to provide clarification about my original motivation. But generally I don't wish to monitor these topics for forward developments. I sure hope the new discussion system doesn't end up conveying the implication that whenever someone opens a new topic that they plan to stick around and set up a tent. I'm a batcher, who edits mainly in passing, usually with external agendas in tow. The last thing I wish to bring into my life for my efforts is a rolling notification feed, though I do believe in showing up to account for my past actions, if I wasn't clear enough in my original note. Those are a few dimensions people might consider if you decide to enlarge your persona roster.— MaxEnt 08:13, 19 August 2014 (UTC)

That's a great perspective to add, and well-explained. Thank you. (and with my volunteer hat: "I like how you roll", as the kids say. ;-) ) Quiddity (WMF) (talk) 00:08, 23 August 2014 (UTC)

I don't think I understand this. I think you're talking about a watchlist trimmed with time. But, perhaps, one of the features of WP:FLOW was to be an enhanced WP:NOTIFY whenever one of your comments was replied to, in which case, yes, you need to be able to turn that off. — Arthur Rubin (talk) 16:20, 23 August 2014 (UTC)

Are we talking about the personas at Wikipedia:Flow/MVP and if so, what does sticky mean in practice? Dougweller (talk) 18:45, 23 August 2014 (UTC)

@Dougweller: I'd imagine it refers to how often an editor looks at a talk page. Some editors read an article's talk page every day while others may glance at it once and then never read it again. @Quiddity (WMF): Pardon my cynicism but one point in the personas really stuck out for me as making things easier for the developers rather than accurately describing roles. No, Watchers don't want to hide inappropriate comments, they want to delete them, like you have Admins listed as doing. I'd wager the good majority of talk page deletions now are done by non-admins. --NeilN ^{talk to me} 20:07, 29 August 2014 (UTC)

@NeilN: Agreed, and they're now planning on making "Hide" work more like "undo" does (as well as being accessible from the History pages), by not leaving the comment extant and expandable on the page anymore, but instead just leaving it in the history. Quiddity (WMF) (talk) 02:04, 5 September 2014 (UTC)

I believe MaxEnt is using "sticky" to describe someone that wants to keep close track of everything that goes on, when they leave a comment or make an edit - For example using the "Add pages and files I edit to my watchlist" user-preference (or manually ticking the "Watch this page" box, abundantly). MaxEnt is asking that we take the opposite persona more clearly into account - someone who doesn't want to spend more time collaborating and discussing articles and other aspects of the site, unless strongly needed.

The main way someone would do that on a standard talkpage, is to simply not watchlist when posting, and to rely upon Mentions or Talkback templates or direct Usertalk threads when their attention is needed. In Flow, we currently automatically watchlist the individual topics we start/reply on, and can additionally choose to: A) unwatchlist the topic afterwards, or B) watchlist the entire Board. There are ideas (discussed further below and elsewhere) about splitting (B) in two, so that users could either: just watch new-topic additions, or watch every edit/action on a page. I'm not sure how we could further assist a non-sticky persona? What other in-page-options, or special:preferences options, would be helpful? (particularly for non-sticky personas, as the needs and frustrations of the more standard sticky persona are being discussed in threads below.) Quiddity (WMF) (talk) 02:04, 5 September 2014 (UTC)

Problems accessing mediawiki flow page - and too many Echo notifications

I see some people have been able to access the Flow comments page on MediaWikiwiki, but I've not been able to do so for a day or two, regardless of what computer I'm using. It times out and/or never fully loads. Systems used: Win7/IE9, Win7/FF, Win7/IE11 (most current versions of all the browsers). Risker (talk) 13:14, 26 August 2014 (UTC)

I don't edit on Mediawiki any longer, and am even less inclined to do so now that they seem to have ruined Echo through Flow (without changing my preferences, I now have gotten 23 echo notifications for Flow discussions in 3 days time). Great job, WMF, the only good new feature you created in the last few years (Echo) now made useless (at least in the default settings) by another oops-it's-harder-than-expected development. But I am able to access this page quite easily: is that the one you mean? Fram (talk) 13:45, 26 August 2014 (UTC)

That's the page, but after 2 minutes of the "blue circle" whirling around I closed the window; it hadn't fully loaded. (That's on my slower computer with IE9.) But I agree with you about the number of notifications being received, my mailbox has been flooded in the last few days and that's actually what spurred me to look at the mediawikiwiki page again. Flow should use the same standard as regular talk pages: echo notification for the first "new" edit and then no more until one visits the page/thread being watched. Risker (talk) 14:10, 26 August 2014 (UTC)

Yeah, we're trying out a new way to handle notifications for Flow pages. The new system just launched on Thursday, and I'm really glad that you've brought up the problems. To be honest -- we haven't done any work on the email notifications yet, because we've been focusing on changes to the notification panel. But clearly we need to retune email notifications very soon.

So -- now that we've ruined the world -- Fram, can you tell me some more about your 23 in 3 days experience? Questions that I have: Which pages/conversations were you watching? Were the 23 notifications in email, or in the Echo dropdown? What's the volume you would have expected?

If you can give me some more details, that'll help me come up with a fix for it. Thanks! DannyH (WMF) (talk) 00:45, 27 August 2014 (UTC)

And Risker -- sorry about the blue circle -- did you happen to file a Bugzilla ticket for that? If not, I can create one. Thanks for the report... DannyH (WMF) (talk) 00:46, 27 August 2014 (UTC)

Well, I set my "echo" notifications back to zero yesterday (the number in the red circle you see at the top of every page your user name and "talk"). Today, it is back up to 15. When I open them, at the top I get in big red "No formatting defined for notification". WTF? The first notification is [https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Flow&curid=39332539&diff=622886755&oldid=622886022#Problems_accessing_mediawiki_flow_page_-_and_too_many_Echo_notifications Too many notif... 98.165.42.183 responded on [No page]. 21 hours ago Two other notifications, one after another: *Notifications? Jay8g and 1 other responded on Talk:Flow. 13 hours ago | View board *Notifications? Jdforrester (WMF) responded on Talk:Flow. 13 hours ago | View board

Then I get all the new topics on Talk:Sandbox and Talk:Flow (the only two pages responsible for these echo flood). I would expect to only get notifications when I am pinged, and perhaps once when one or more topics are started on a talk page I follow.

But first and foremost, I would expect any page where I tick the "green star" to REMEMBER THAT CHOICE. It is extremely off-pissing to remove Talk:Sandbox from the watchlist, only to get it added back immediately when I return there. It turns out that I have to remove the main page (Sandbox) from my watchlist, and that the green star, even though it changes its appearance, doesn't do anything. Anyway, I want it to behave like any other talk page does that I have on my watchlist, not to bury me under notifications. Just imagine someone having WP:ANI on his watchlist in Flow... Fram (talk) 11:43, 27 August 2014 (UTC)

Gentlemen: I have some 4000 pages on my watch list at the German Wikipedia. Among them 'all high traffic talk pages for admins and editors. Do you really intend to "notify" me by raising up the echo counter for every single edit anyone does on any of those pages? Don't! Or what you've seen with MV will be some light April breeze against the storm you will face. As I mentioned time and again: Have you ever tested Flow in a high traffic environment? Maybe a lively discussion with -say- 400 contributions by -say- 25 different editors in -say- 15 subchapters all stemming from one root posting? Now multiply that by 8 current threads plus 15 older ones. And imagine I have been away over the weekend and now try to catch up. The current system can deal with this situation. And I can, too. Does Flow? --h-stt !? 12:40, 27 August 2014 (UTC)

I would agree that sending a notification for every action on every Flow page on your watchlist is overkill. Flow notifications should be reserved for when someone posts on a topic you've posted on (or maybe even just for direct replies). The notify-for-everything system drowns out important notifications in a flood of less vital ones:Jay8g [V•T•E] 17:18, 27 August 2014 (UTC)

A compromise way to deal with this would be to split the existing Flow notifications option in preferences into "Flow reply" (direct replies to your posts or comments on threads you have commented on) and "Flow subscription" (all actions on threads you have subscribed to), with the latter probably off by default:Jay8g [V•T•E] 19:12, 27 August 2014 (UTC)

Right now, Flow notifications do not ping you separately for every message on a page. The model that we're moving towards is to have one notification item for every discussion thread. The notification items (when they work properly, which is maybe 80% at the moment) roll up multiple posts into one notification item.

So if there are three active conversations that you're subscribed to on a board, the most notification items that you should get at one time is three. That is true even if one of them is super crazy active, with dozens of new posts every minute. You still only get one notification item in the Echo dropdown, and the number in the red circle is 1.

This is a big change, and an interesting one, and we knew that some of it would be awesome and some of it might not be, but often it's hard to tell what the biggest problems are until you try it out and see how it feels. This new system has been out on Mediawiki.org since last Thursday, about six days. We've found some surprising bugs -- like the weird "no formatting defined" error message that just appeared yesterday. Also, I wasn't paying enough attention to email notifications, because I've been heads-deep trying to get the Echo flyout to work. That obviously needs to get fixed soon.

But this is the kind of bold experimentation that you can do while the feature is basically on five pages on Mediawiki.org, one of which is a sandbox and another is specifically about Flow feedback. We're not going to send the new Echo code on the release train to English WP tomorrow, because it's not ready -- we need another week to fix some bugs, and it's good to do that work before it affects more than five pages.

There are a ton of different points and questions raised above, and I'll try to respond to all of them, but first I have to write a couple bug tickets. :) I'll be back. Thanks as usual for your thoughts and questions. DannyH (WMF) (talk) 19:50, 27 August 2014 (UTC)

Actually, before I go -- I want to address the concerns raised by h-stt and Diego about whether Flow is ready for high-volume talk pages. It is not. That's why we're not testing it on high-volume talk pages yet. :)

We're currently being super deliberate and thoughtful about the plans for development, testing and rollout. We're starting by working on the simpler use cases, and learning from there. You are absolutely right when you say that the feature as currently released on Mediawiki.org will not scale to the Village pump. We're not going to get there for a little while.

First, we need to nail the simple use cases. We haven't even done that yet. :) There's no way that we could try out some of the interesting experiments that we want to try, and expect it to instantly scale to Village pump. There's a lot of time and thought and work between now and then. The job for today is to make it scale to four medium-volume pages and a sandbox. So you don't have to stress too much today about suddenly seeing the current form anywhere other than where it is. The world is not ruined yet. DannyH (WMF) (talk) 20:07, 27 August 2014 (UTC)

Oh, also -- what are you watching the Sandbox page for? Even I'm not watching the Sandbox page. :) DannyH (WMF) (talk) 20:23, 27 August 2014 (UTC)

To clarify, Flow can be enabled in non-talk namespaces? I had been led to believe that it was talk pages only. BethNaught (talk) 20:26, 27 August 2014 (UTC)

Also, I hope being "super deliberate and thoughtful" about testing and rollout includes gaining community consensus for the rollout of Flow. BethNaught (talk) 20:34, 27 August 2014 (UTC)

Super deliberate and thoughtful definitely includes lots of involvement with lots of people in the community, including and especially the people who care enough about it to post on this page right now, while we're still on five pages. You will be allowed backstage access.

Currently, Flow is deployed on a single page basis, and I believe it can go anywhere. The next places we're working towards are some help & mentorship spaces on English and French WP, but we've got more discussion and work before we actually get to that step. DannyH (WMF) (talk) 20:55, 27 August 2014 (UTC)

From your avoidance of the word consensus I can only assume that, after a lot of discussion, the WMF still intends to force it on the community whether it wants it or not. Also, you say we will be allowed backstage access – the WMF shouldn't be presuming to give and take access to the most major change to the wiki interface for a long time. BethNaught (talk) 10:47, 28 August 2014 (UTC)

While I appreciate that you only get one notification per thread, on most threads that means one notification per action, and if you are watching a page, you are subscribed to many threads which all send out separate notifications, so it still feels like it is flooding Echo:Jay8g [V•T•E] 21:51, 27 August 2014 (UTC)

• DannyH, you've not thought this through. If someone wants to know that a new thread has been started on a page that is important to them, they have to watch the page. Watching threads, while a cool idea and certainly an important improvement, is secondary to the effect of being able to watch an entire page. I have, today, received a notification for every single action on the mediawiki Talk:Flow page. The choice you are giving us seems to be "Know about new threads but get pinged for every action" or "Don't know about new threads". This is exactly what I mean by Flow actually having a negative effect on discussion. My mailbox is full of junk messages right now, and anything not related to that page is totally buried in my Echo list. The only way I can stop the flood is to stop watching the Flow page, or to turn off notifications for it. I've gone for the latter. But I only go to Mediawikiwiki when I get an email notice that something has happened on one of the pages I watch there, so my participation on the Talk:Flow page is guaranteed to be reduced now. This is not an example of "Better methods for collaboration will improve collaboration, which will improve all of the projects." (Incidentally, there's no evidence of that correlation. Lots of our better articles have nearly-empty talk pages and we're already rather overwhelmed by articles that are horrible or battlefields because of, effectively, too much collaboration.) Risker (talk) 23:24, 27 August 2014 (UTC)

(Note: This following idea has been suggested before, but needs more feedback/research/design/feedback, and also feedback.) (See also the "Separate notifications ..." thread below)

• A few people have suggested, that we will need (and have really wanted for many years) at least 2 levels of watching a talkpage.
  E.g. 1) not watching. 2) just watching new topic creations. 3) watching everything.
  Or an option where I could have a page appear in my watchlist, but not get any notifications?
  And possibly an option where I could watch a page, but not it's talkpage? (I'd love to watchlist all the Manual of Style subpages, but not the associated talkpages for most of them)

We need something with sensible defaults, that can be adapted/tweaked for different wikis, or namespaces, or use-cases. (e.g. a very active noticeboard could default watchlist me at level#2, but most article talkpages could default watchlist me at level#3).

What ideas haven't been mentioned yet? What options would be powerful enough for our needs (and even satisfy our wants) ? (without requiring an instruction manual as some of the userscripts do) ? What is your dream setup, a few years from now? Quiddity (WMF) (talk) 02:53, 28 August 2014 (UTC)

It seems to me that you're no longer talking about Flow here, you're talking about Echo/notifications and/or watchlists. Is Flow supposed to take over both of them as well? I'm very serious about this, the Mediawiki page on Flow is so horribly out of date that the community has no way of knowing what its actual objectives are or what it's really intended to do. Risker (talk) 03:19, 28 August 2014 (UTC)

@Risker: The broad mw:Core Features team is responsible for Echo, and some of the developers who originally worked on Echo are still on the team. They're broadly responsible for what some staff are calling "messaging" - on-wiki communication via talkpages and notifications. Additionally, Flow is (obviously!) responsible for whatever it puts into the specialpages/feeds (RC/watchlists/contribs/history/logs). It's not going to "take them over" in any way, but having Topics as individual pages means they need (or at least could have) some sort of slightly tweaked entries, particularly for watchlists. Hence we're asking what your preferred scenario would be. Would One additional option be sufficient, and if so how might you want it to work? Jay8g has one good idea below.

I'm used to watchlists, and I can just about use the "25 changes since your last visit" to read through VillagePump updates, but I'd really like some better tools, available for both me (who can find/install userscripts) and for everyone else who wants more options.

(Tangentially FYI: there are separate and completely-unrelated-to-Flow efforts to improve RC and watchlists, eg mw:watchlist wishlist and user-specific page lists RfC, and a few more specific bugs listed in the userpreferences RfC, that you might be interested in). Quiddity (WMF) (talk) 19:44, 29 August 2014 (UTC)

Well, separate settings for watchlisting something and notifications-listing it would be nice. That way, you could have some things be watchlist only (current wikitext watching system) and have some things be notifications only, and some things even be watchlist + notifications (current Flow watching system) (though I don't know why this would be needed...). That way, people could get notifications for things that they consider extra important (normal and Flow pages) and just watchlist entries for things that they don't consider as important (again, normal and Flow pages):Jay8g [V•T•E] 03:39, 28 August 2014 (UTC)

Can you please make sure that whatever new version of Flow gets deployed on Wikipedia, the Echo bombardment is not included. I just looked at my mw page again, and I got 11 notifications again, all from the Talk:Flow page. Bringing this to Wikipedia will only cause people to remove the Flow pages from their watchlist, without any actual benefits. Fram (talk) 07:17, 28 August 2014 (UTC)

Yeah, the current version that's on Mediawiki is going to change, thanks to the feedback that we've received here. We just had a team planning meeting, where we talked about changes that we're going to start on next week -- changing "subscribe to a board" to give one-time notifications for new topics rather than automatically subscribing you to new topics 1, and a couple of steps to limit the number of email notifications 2. I have to have a couple more conversations about email notifications, because I think there's some more work that needs to be done besides what's on that card. That'll happen over the next couple days.

There are going to be a lot of changes and experiments to come; that's how this kind of software development works. We've got a very limited number of test pages running, most of them on Mediawiki.org, because we need to have the flexibility to try out a new element, see how it behaves on production, and then make further iterations as we go along, based on feedback and observation. We're holding back the latest version of Echo so that it doesn't deploy on Wikipedia this week, so we can fix some bugs and make some more changes. Thanks for telling us how it's working for you; you're giving us exactly the kind of feedback that we need.

It's true that the project page isn't getting updated enough -- many of these changes are happening on a daily basis, and it's mostly getting recorded in Trello, Bugzilla and the mailing list. If you want to stay up to date with the team, feel free to join the Editor Engagement mailing list; there's a lot of interesting work coming up. DannyH (WMF) (talk) 19:42, 28 August 2014 (UTC)

So basically, you're saying that in order to "keep current", the average editor would need to find the applicable Trello (I can't find any links to it), follow bugzilla and carry out regular searches for Flow bugs (but of course not add anything non-technical to bugs, or they'll be given a hard time), and subscribe to another mailing list. Do you understand what the challenges are here? Meanwhile, none of those are going to tell us what the objectives of Flow actually are. There's no big picture here. You can't get to where you're going unless you know where you're going. Right now I'm not getting a sense that anyone knows what the objectives are here; I'm assuming good faith that they aren't being deliberately obfuscated. I'm more getting the sense that there's a lot of pie-in-the-sky dreaming and adding in ideas and features without having a solid master plan in place. There are no measurable objectives here. I urge you to consider that the lack of clearcut, easily articulated objectives is by itself a reason to pull this project off the front burner, because after almost two years of following Flow, I still have no idea what you're trying to build here, and nothing I'm seeing coming from the WMF perspective tells me that you've really worked that out either. Risker (talk) 20:16, 28 August 2014 (UTC)

I think a lot of the big objectives are actually handled pretty well on the Wikimedia project page. What I've been responding to on this page for the last couple of days are some concerns that people have about specific items in last week's code release. We use an agile software development process that prioritizes making lots of small changes, being flexible in the short-term, and testing assumptions by trying things out and then iterating. In the short-term view, this process can look chaotic. Taking a broader view, it's actually the most effective way to plan a project. You don't waste a lot of time creating pixel-perfect specs for an enormous grand vision, and then realizing a year into production that you've made some mistakes. Instead, we make our mistakes in real-time, and we adjust quickly. You're not under any obligation to follow this process on a weekly basis; I wouldn't if I were you. But those tools are available, for anybody who's super interested in how the sausage is made. DannyH (WMF) (talk) 21:33, 28 August 2014 (UTC)

DannyH, I don't see what you're seeing. I see seven "deliverables", two of which already exist, four of which could be written in the Mediawiki interface (avoiding the need to force users to learn another editing interface, two for editing and one for discussion), and one of which I've never found any evidence of anyone asking for ("Rigid predictable technical restrictions on who can edit what" - in fact, anyone who's dealt with a vandal knows that is contraindicated). None of those deliverables are "eliminate watchlists" or "send an echo notification every time someone edits a watched page", yet based on vague discussion points it's pretty obvious that's where you're going. Some of this is a failure to understand the benefits of existing processes and the weaknesses of new ones. There's a huge leap from the passive watchlists, which whisper to a user that something happened on a page they're interested in but make no demands on their attention, to getting a big flag waved at them every single time a page on their list gets any kind of activity. (For many other wikis, there's the intermediate option of receiving a single email the first time a watched page has some activity, which isn't repeated until or unless the user visits the page while logged in. It has this very nice diff-link that shows them all the changes since the last time they viewed the page. It's not active on large wikis because apparently it would have killed the mail servers, although that might be able to be revisited.)

In other words, there's barely been a case made for developing an entirely new editing interface specifically for "discussion". There has been a good case made for improving the mediawiki interface to do a lot of the things that are on the deliverables list here. (Example: remove the option to sign with anything other than one's username. Would take a few lines of code, or more likely removal of a few lines of code. Just wait until the broader community realises you're taking that away.) Now I know it's a lot of work to clean up mediawiki and improve it, and starting with a brand new interface is easier and a lot more fun, but you've go so very, very little user feedback on what you've created to date that I'm really questioning the basis on which decisions and prioritizations are being made. Risker (talk) 22:28, 28 August 2014 (UTC)

Flow was in development for a while before I joined the Foundation in April, so it's absolutely possible that somebody during that history suggested that we wanted to get rid of watchlists or ping people for every single edit on a watchlisted article. All I can tell you is that I don't have any plans to do anything like that. A lot of the discussion that we've had lately about what subscribing to a Flow board should mean has specifically been about making sure that we don't break watchlists.

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. The second goal is to make wiki discussions more efficient and more pleasurable for experienced people. That's the thing that we're working on now, and there's still a lot of interesting work to do. You may not agree that that's a worthwhile or an achievable goal. I think it's worth a try. DannyH (WMF) (talk) 03:42, 29 August 2014 (UTC)

"One is to make discussion on wikis more accessible for new people. That part was easy; we passed that a while ago." Quite a bold statement. Any actual evidence? The few real live test cases I have seen have actually less activity than before they were Flow-enabled. Obviously, they are still just as hard or easy to find as they were before Flow was introduced. Once you have found them, they may be somewhat easier to contribute to, once. But IMO they are harder to actually follow than standard Wikipedia discussions (or than most threaded discussion formats on the internet, with the exception of mailing list logs and IRC logs probably). So what do you really base the "more accessible for new people" on? Fram (talk) 07:04, 29 August 2014 (UTC)

@DannyH (WMF): I'ld really like an answer to this, as it is rather fundamental. Fram (talk) 20:16, 29 August 2014 (UTC)

@DannyH (WMF): Easy like Sunday morning? Any reply to this? Fram (talk) 07:35, 4 September 2014 (UTC)

@DannyH (WMF): I'd be interested in seeing evidence for this significant milestone in the development of MediaWiki messaging. --Anthonyhcole (talk · contribs · email) 13:47, 5 September 2014 (UTC)

Deletion

1. A flow talk page can't be deleted directly. Why?
2. When deleting the non-talk page part, e.g. Wikipedia:Flow/Developer test page, one gets the option to delete the talk page anyway: this is not consistent with point 1 above
3. After deletion, one gets an error: [589656fd] 2014-08-26 13:54:07: Fatal exception of type MWException
4. It is impossible at that time to create the talk page (even though talk pages without non-talk page should be possible, e.g. for user pages or some subpages)
5. After restoring the main page, the talk page automatically reappears
6. The page then had 22 "deleted revisions" at [1], but after restoring them, they seem to have simply gone from the logs (they can't be found in the history, which is of course still deficient).

All this is rather counterintuitive and not really internally consistent. It still looks suspiciously as if Flow pages can be used as large balck holes to get rid for things once and for all... Fram (talk) 14:03, 26 August 2014 (UTC)

This is an element that we don't need right now -- it's not important for the next set of use cases. We're focusing on the features that we need to build for the next stage, and then move on. So what you're seeing in your test isn't an indication of how this will work later on. This is a huge project that's going to take a little while, so we're being deliberate about what elements we need to build for each iteration. DannyH (WMF) (talk) 19:27, 28 August 2014 (UTC)

Just like with "move" below, you are going at this backwards. If you can't get basic existing functionalities to work, it's hardly useful to add new ones already. get move, delete, history (!!!) to work, and then start thinking about more fancy stuff. Fram (talk) 06:59, 29 August 2014 (UTC)

Separate notifications for flow updates and user events?

I see a problem in the way the new notification system conflates the functions of Echo and the Watchlist. The previous system issued alerts only for rare events that directly affect the user (direct mentions, comments at your talk page, reverts, links to pages created by you, etc), so I knew that I should review any warning appearing in it. The use case for watching threads is different; I'll have a huge number of watched threads, and I'm not really interested in reviewing everything that appears in it, all the time, only in skimming through it to find something to work on.

Unfortunately, as H-stt explains above, the system doesn't scale to high volume "follow lists": the important warnings risk getting buried among the long list of trivial thread updates.

Now, I can see the benefit of having a single stream for both types of notifications. Is it possible to have it without losing the benefit of the current Echo notifications? What I want is a way to tell apart when there are updates from separate channels, so that I can know when there are new important warnings. Maybe alerts should be highlighted with different colors for warnings (red) and updates to watched topics (green or blue?). Diego (talk) 13:47, 27 August 2014 (UTC)

There are a few ideas along those lines:

mockup from #1

1. At mw:Compact Personal Bar#Design V2 there are ideas (and 2 Mockup images) around having separate flyouts for each of the 3 main standard workflows - 1) Watchlist 2) "Talk messages" 3) Alerts.
   So #2 would cover all of the "discussion" types of notification (replies, mentions, usertalkpage posts). This option has been partially discussed amongst the Flow dev team, and the current "2 tabs in 1 flyout" (as seen on mediawiki, if you have Flow contributions there) is just a temporary setup until a better long-term solution is determined.
2. At Wikipedia talk:Notifications/Archive 5#Granularity, there was an idea to separate each of the Notification-Types into a separate icon, and only have the icon appear if there was a fresh Notification of that specific type.
   For a really active editor, it could look something like: 1 3  15   2 
   And then if I had 0 new notifications, it would be the default single number/icon on grey.
3. At Wikipedia talk:Notifications/Archive 5#Color-coding the dot, there was a related idea to just color-code the badge/number background, but that's complicated by cultural-nuances of colors, and color-blindness, etc.

(Personally: I really like #1, although I want words in addition to icons. I really like some aspects of #2 but I also worry about the variable-width and the potential number of icons if I had many types of new alerts. In the end, I suspect we'll need a combination of #1 and/or #2, plus another option for levels of "watching" a Flow board, which I'll explain in the "too many Echo notifications" thread.)

Of the 3 ideas above, what do you think are the best/worst aspects? And what other options are there? Quiddity (WMF) (talk) 01:53, 28 August 2014 (UTC)

The best idea is no drastic change; flow updates come in the watchlist, just like every other kind of update. There is no need to invent the wheel again here. Give me an echo if I get pinged on Flow, of perhaps when a topic I started gets deleted or hidden or whatever; but that's it. Color-coding the dot is definitely the worst idea of them all (having multiple dots would at least be better than that). Fram (talk) 07:12, 28 August 2014 (UTC)

All the notifications will slow down work, even if you can turn it off. At least I will not turn it off (I am too curious) and I will check every time... As it is now - if its really important it is posted on the user talk page (or somebody ping you, or thank for an half year old edit)... Christian75 (talk) 11:25, 28 August 2014 (UTC)

Move doesn't work

Why can't a Flow page be moved? This will need to be corrected before this can be used (if ever). Fram (talk) 07:20, 28 August 2014 (UTC)

You're right; this is a piece that we have to build. It's not at the top of the list right now, because we won't need it until we move on to a later deployment stage. DannyH (WMF) (talk) 19:22, 28 August 2014 (UTC)

Let's reverse that, shall we? You should not move to a next deployment stage (however small) unless this is in place (and a few other things, like the rights setup, and some finished idea of how the watchlists and notifications should work, oh, and perhaps finally a history that is working, and ...). Thinking about further deployments should be the last of your worries now. Fram (talk) 06:58, 29 August 2014 (UTC)

Need or no need, the point is that if you want to convince the community Flow is useful then it will need to actually be functional (as Fram says) before being deployed to a high volume area, as people will notice the missing functionality. BethNaught (talk) 07:10, 29 August 2014 (UTC)

That is absolutely true, and that's why it's not going to a high volume area yet. Right now, the two use cases we're focusing on are the French WP Forum des nouveaux (their version of the Teahouse), and a new mentorship project on enwiki that just got grant funding. Those are going to be the next stage of Flow deployment, possibly with a third mentorship space that we're talking to. For those projects, there are features that they absolutely need (table of contents, searching on a Flow board, a way to generate new Flow boards on subpages, an update to the hide topic feature), so that's what we're prioritizing for the next month or so. Those projects don't need to move Flow boards, so we're putting that off until the next stage.

But I totally understand the confusion. I just updated the project page here, I'll start a new thread to explain... DannyH (WMF) (talk) 17:16, 29 August 2014 (UTC)

"It is absolutely true", but we'll deploy it further anyway. Please, don't agree with me when I say that "you should not move to a next deployment stage (however small)" and go on to tell me that you'll do just that anyway. Testing new software on a new mentoring project is about the worst idea I'v heard here. What they need is a stable environment, where the focus can be on the mentoring. Using such a project as the testing ground for software (which doesn't need a testing grond as there are plenty of show-stopping bugs noted already anyway) is a recipe for disaster. Fram (talk) 19:59, 29 August 2014 (UTC)

I trust the developers that there will eventually be a "move" function, and that Flow will probably not be rolled out on a wide basis until it's there (although not necessarily working correctly, as some edge cases probably won't be tested). However, the ability to copy between Flow messages and _WikiText_ (not just VE) is a minimum requirement, with most WikiText, including complicated templates, working correctly. I see no indication that that's in the plan. I see they claim it works. I need a test page on en.Wiki to verify. — Arthur Rubin (talk) 01:50, 30 August 2014 (UTC)

Rights

A. Who has the rights now to put an enwiki page in or out of Flow-mode?

B. Who will have the rights to put an enwiki page in or out of Flow mode in the future? Fram (talk) 11:51, 28 August 2014 (UTC)

Special:ListGroupRights and Special:GlobalGroupPermissions (for stewards, sysadmins and staff) mention Flow, but not about activating flow mode, as it were. I suspect this is currently at database level? BethNaught (talk) 12:05, 28 August 2014 (UTC)

Right now, only the Flow team can enable/disable Flow pages, which is not sustainable in anything but the shortest of short-terms. The next step is for us to have a special page to enable and disable Flow on pages, which will be tied to a user right. We've done some planning work on this, and we're looking into some ongoing WMF database work that might be blocking this development. DannyH (WMF) (talk) 19:19, 28 August 2014 (UTC)

History and watchlist

At the moment, neither the history nor the watchlist really work for Flow. Any indication when this rather basic functionality will work? Without it, any work on developing Flow is useless, as it is impossible to follow discussions in an easy way. Flow has been prematurely deployed in, what, February, so half a year later one would expect that these most basic of things would be working most of the time. But at the moment, I don't get changes to Flow pages in my watchlist at enwiki, and I do get them in mediawiki, but when I try to see the history from my watchlist, I get a "Fatal exception of type Flow\Exception\FlowException" error.

Problems with these things have been raised from day one, and while the actual problems have changed of the months, they have never really improved, never mind been fixed. This seems to indicate basic flaws with either the concept or the development of Flow. The current "Echo" bombardment problems are only the umpteenth example of the struggle you all seem to have with this. Could you please get back to your drawing board and get this really fixed (I note at Trello that this was opened before Flow was enabled at enwiki, and supposedly solved in April already; I can't remember any time when this truly worked though, you have just replaced one set of bugs with another set... Fram (talk) 07:30, 29 August 2014 (UTC)

Thanks for reporting the bug about the history link in the watchlist. I just checked it out -- it's actually only happening for hidden topics (as far as I could tell). Other history links in the watchlist work correctly. I filed a bug ticket for this, and it'll be fixed soon.

However -- I am seeing topics that I'm subscribed to on my enwiki watchlist. They're now in the form "Topic title on Talk:Board name" -- maybe you're looking for the old-style items? Let me know what you see -- it might be a bug that isn't happening to me, for whatever reason.

In more general terms, bugs are always a part of software development. It's absolutely impossible to build software that doesn't get at least occasional bugs, especially during a stage when there's fast-moving, active development. They're not good, obviously, and they need to get tracked down and fixed, but they're also not a harbinger of disaster. :) I appreciate that you're helping us identify bugs when you see them. DannyH (WMF) (talk) 17:07, 29 August 2014 (UTC)

I note that you are copying the style of testing that the VE people from the WMF also use. Not a good development. Generally, you are rapidly losing the trust that the earlier WMF people discussing Flow had slowly built.

The bug about the history link is not only happening for hidden topics (which would be bad enough), it happens for e.g. this topic when I click "hist" in my watchlist. Note also that in general, there is no possibility to see the state of a topic (never mind a complete talk page) at a certain moment in time anymore. Not good... But on the plus side, we get countless "topic" links, one on every line of this page, which are utterly useless since you are already at that topic. Good UI!

"I am seeing topics that I'm subscribed to on my enwiki watchlist". Good for you. I'm watching Wikipedia talk:Flow/Developer test page, the whole page, like I have done since the start, and I don't see anything on my watchlist except for my own attempts to delete it. Ah, and now my edit to the header as well. Anything else? Nope, no new topics, nothing. Isn't the purpose of adding a page to your watchlist that you see when e.g. a new topic or section is added?

In more general terms, I have to agree, major bugs are alwayzs a part of WMF software development. "Fast-moving, active development"? Well, I don't see much "fast-moving development", and "active" development is rather superfluous, passive development would be a novelty.

VE had the same "thanks for noting the bugs, don't expect us to draw any conclusions or change or plans accordingly though" attitude. Hasn't the WMF learned anything from VE, MV, and so on? Fram (talk) 19:54, 29 August 2014 (UTC)

So, for the sake of clarity: I have Wikipedia talk:Flow/Developer test page on my watchlist. I don't get any update when anyone edits the page, apart from my own edits there (which I am aware of, thank you). Not when someone replies, not when someone creates a new topic (which I can't yet have watchlisted anyway), ... So no, as far as I am concerned, Flow doesn't work with the watchlist, and so is not acceptable for further rollouts. Fram (talk) 09:36, 30 August 2014 (UTC)

Note that Flow also corrupts the watchlist counter. My watchlist on mediawiki claims "Below are the last 7 changes in the last 12 hours, as of 4 September 2014, 07:32.", but it only shows four. Looking at the histories, I note that this comes down to 6 changes to Flow pages (of which 3 are shown in the watchlist), and a non-Flow page. Apparently the watchlist is hiding some Flow changs (luckily, even though it is very far from perfect yet) but counts them anyway.

I still get an error when trying to access one of them (not a deleted or hidden page) from the watchlist. Flow pages don't get the "bold" when not yet visited indication. There is no indication whether something is a new topic or a comment. And so on, and so on...

Updated information

I've just updated the WP talk:Flow page with a lot of new information, including the rough plan of our quarterly goals for the next year.

I have to apologize -- this is a page that we updated on Mediawiki earlier this month, with the intention that we'd mirror the new version here, and I forgot to actually do that, because apparently I am a genius. So I was very confused yesterday, when Risker said that the page here didn't have information about what we're working on. I thought I'd already copied over the updated version.

So -- I'm very sorry about the confusion there. Totally my fault, and I feel vaguely foolish about it. On the plus side -- lots of updates on the page! If you're interested, please take a look, and I'm happy to hear what you think and answer questions. Thanks! DannyH (WMF) (talk) 17:22, 29 August 2014 (UTC)

"Done Subscribing to Flow board = notifications for new topics on that board" Doesn't work

• "Done Roll-up notifications for activity, one notification item per topic" Not wanted (next ones all related, so...)
• "Done Log item improvements for Watchlist and Contributions" Doesn't work, never did

Simply showing all changes to a board since last visis is still impossible. Simply getting the watchlist to display whether a Flow board has changed since the last visit is impossible. These aren't planned for the next year apparently. Are people at the WMF even aware that these are a problem?

A rollout to articles on enwiki in Q4 is a completely absurd idea but a very good way to create the next WMF-community clash. The WMF devs still seem to live in cloud-cuckoo land, or they have to meet some unrealistic deadlines to keep their jobs, or some other unsavoury reason lies behind all this, whatever, but this is just the same old nonsense. Has any destructive testing been done yet? I know I have done it once and broke the watchlist of a serious number of people here, with an act that any vandal could have done very easily. Is it really that kind of untested software that you want to release to talk pages or a brand new moderation project? Please no. Fram (talk) 20:15, 29 August 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 [2] -- 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)

• Seems to be working at mw:Talk:Sandbox now, thanks. Deltahedron (talk) 20:30, 10 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)

Wiki misconceptions

There are some important issues in the current design of Flow related to talk page mechanics which I would like to bring to people's attention:

1. Maximum level three indent. Almost every discussion in Wikipedia goes past that level and if it bottoms out at three then separate threads in a conversation become lost and hard to work through. The assumption that such threads should be split off is often not true.
2. No custom sigs. There is no evidence I've seen that they are causing a problem. Personally I'm ambivalent, but they are a popular and longstanding feature and any attempt to remove them will cause a massive stink.
3. No refactoring of posts except by admins. This could cause serious problems – what if a serious issue arises in a post and it needs to be redacted (legally dangerous libel, highly offensive and upsetting personal attacks) but there's no admin around? How can individual comments by a banned editor or a troll be removed? I am aware there is a hide function, but that is not total removal and that doesn't account for editing. In the words of Jimmy Wales (with whom I do agree on this matter) it "is a bad idea for a lot of very deep wiki reasons".

I think the community needs to discuss the reality of wiki discussion mechanisms here more to help the WMF develop a more effective model for Flow, and the WMF needs to be less keen on major talk page dynamic changes without community approval – since it is the community who will be doing discussion with it. BethNaught (talk) 21:57, 29 August 2014 (UTC)

Commenting on BethNaught's issues above:

1. I agree completely. Indentation in discussions is incredibly useful to knowing who is responding to what, and reducing the threading level to three may not be helpful, even when it's just a small number of people talking. Even back-and-forth between two just two editors can go beyond three levels.
2. I did see that the team brought up some arguments here about HTML causing display and formatting issues. Have signatures ever been enabled on Flow and if so, what problems did you find? I acknowledge from usability standpoint, the fact that links to user/talk page/contributions can appear in different places in one's sig is a bit strange, but all a new editor has to do is click on it to see where it takes them. There is also a very human element to signature customization that would be an unfortunate loss from a community standpoint.
3. I think the question of who can refactor things is still somewhat open, and I don't think any permanent decisions have been made about that just now. In fact, here under Post moderation, they write:

"Hide", "Delete" and "Suppress" - analogous to revert, revision-deletion and oversight - are current features for Flow, and will be present before the first deployment on Wikipedia. Users will also have the ability to delete/suppress entire threads.

with the addition comments of:

Flow currently includes a version of these features (as of August 2014). However, we're not completely satisifed with how "hidden" and "deleted" discussions are displayed on the Flow board; we'll come back for another revision before the end of the year.

So, it seems there is a plan to make sure comments can be deleted by editors, not just admins. It looks like they tried to implement this in an earlier stage, but it wasn't working so well, so they are probably back at the drawing board for the time being. I, JethroBT ^{drop me a line} 22:56, 29 August 2014 (UTC)

Hi, Beth -- I think I can answer some of those concerns.

First, just to clarify why we're prioritizing some pieces ahead of others -- There is a big list of features and requirements for Flow, if it's going to do all of the things that we'd like it to do. You can see some of that on the Wikipedia:Flow page under the quarterly goals -- but even that is a condensed list. We have lots of ideas. So for this next stage, we've chosen specific places where we're talking to the community about trying out Flow. The two places where we'll (almost) definitely roll out are the French WP Forum des nouveaux (the French version of enwiki's Teahouse) and a new mentorship project called the Co-Op, an enwiki community project that just got grant funding. There are a couple similar mentorship spaces around the wikiverse where we're talking to the folks who work on them. So with those use cases in mind, we're working on features that they need (search, table of contents, a better version of the moderation actions, the ability to create Flow boards as sub-pages), and we're putting off building features for other use cases.

So, for example -- people have pointed out that Flow isn't good enough to be on a Village pump right now, or an RfC-style structured discussion, or other high-volume areas. That is correct, and that's why we're not planning to go there until we've passed through several of these use case stages. RfCs is actually one of the most complex use cases, so it'll be a while before we tackle some of the features that we would need. Basically -- we're building Flow to handle the simple conversations first, and once we nail those, we move on to more challenging areas.

Here's where we are with the three items you mentioned...

Indented replies: There are two big reasons why we use indenting on wiki talk pages. One is a workaround for a deficiency in wiki talk pages -- most discussion systems automatically display people's posts in a way that makes it clear visually where one person's message ends and the next one begins. Using colons to indent is a workaround that has become the culturally accepted default. In Flow, we don't need to use indenting in order to separate people's posts visually -- the board does that automatically.

The other use for indenting is, as you said, to allow for branching discussions on big, complicated conversations, especially RfC-style consensus/voting conversations. That is a very important part of those kinds of complex discussions, and we won't be able to use Flow for those kinds of use cases until we have a way to handle those branching discussions better. The level of indenting that we have right now is appropriate for the simpler one-on-one and group conversations that we're focusing on in this stage. We have some big-picture ideas for how to handle the more structured branching discussions, but it's a ways off.

Custom signatures: Custom sigs are another beloved workaround that grew because the system doesn't sign your posts for you. The basic system that you see on Flow right now automatically signs and dates a message, which at least means we don't have to deal with the headache of unsigned templates and teaching newbies to add four tildes.

But one of the good things about custom signatures is that you get to change the name that you sign -- for example, my personal account is User:Toughpigs, but my custom signature is [[User:Toughpigs|Danny]]. We are definitely talking about building a "preferred name" into Flow signatures, possibly something like Danny (Toughpigs) in my case, where Danny comes from a preferred name field that I fill out somewhere. The only reason why we haven't planned for that yet is that a preferred name would be useful for a few different Wikimedia projects, and we have to discuss it with some other product teams to make sure it works for all of us.

The other stuff that people use in their custom sigs -- colors, sparkles, catchphrases, etc -- that's a very controversial subject among the Flow team. Those elements can add a lot of personality and fun. They can also get really annoying if they're not done right. So we're punting on those until we get a clear mandate from the people. :)

Hiding/refactoring: There's a few different elements here. The basic functionality that we absolutely need to provide (and we don't quite do it correctly yet) is the ability of any user to take obvious spam and vandalism off the page. That stuff happens, and the best way to deal with it is the way that wikis always have -- if you see something bad on a page, then you hit the edit button and clean it up, without having to go and report it to someone else. The bad thing is still accessible in the history, and people have the ability to undo your edit if it wasn't actually that bad after all.

So we've got a Hide function right now, and any user can hide a bad topic, or a single bad message within a conversation. The problem is that the first version that we built doesn't actually hide things enough -- it leaves a big clickable button on the page that basically shouts "come look at the bad thing!" The next version, which you'll probably see in a few weeks or so, will actually take the hidden thing off the page, so that it's still accessible in the history but not on the page anymore. We're also going to add undo and rollback functionality on the thread and board history pages.

The other piece is the ability to edit other people's messages. Flow doesn't allow this right now, but I know it's something that we have to address. The most basic use case is that somebody includes a link that doesn't work, and it's nice if someone else can fix it. We're talking about a few different ways that we can address that, but we haven't found the perfect idea yet. It would be great to talk to you more about it, if you're passionate on that subject. I'd love to have another person to bounce some of these ideas off.

Anyway -- I hope that was a helpful look behind the scenes a little bit. As we get into the next stage of development, I'm going to be doing a lot more of this kind of thing -- getting ideas, answering questions, bringing interested people into the process more. If you're really interested in the ins and outs, we're using the public EE mailing list for a lot of discussions about what we're working on. You should feel free to join that list, or let me know what you think here on the wiki. Thanks! DannyH (WMF) (talk) 23:19, 29 August 2014 (UTC)

Thanks for the detailed reply, I will keep looking at the test pages to see the new functions. BethNaught (talk) 07:20, 30 August 2014 (UTC)

DannyH (WMF), what's so difficult about indenting to more than three levels? That's really, really, really basic functionality others have solved long ago. Look at Reddit. My advice would be don't even think about bringing anything to the community until you have replicated that functionality. You'll be a laughing stock or worse, and rightly so. Andreas JN466 00:40, 30 August 2014 (UTC)

Jayen466: Infinite indentation simply does not work in a mobile context. In order for Flow to be successful (e.g., "meet its design goals"), it needs to work for the future, and not only for the past. --Jorm (WMF) (talk) 00:47, 30 August 2014 (UTC)

Is "more than three" synonymous with "infinite"? Deltahedron (talk) 09:32, 2 September 2014 (UTC)

In computing, typically yes :-) It's the limit at which the programmer decides that the behavior should be implemented as a procedure that can handle arbitrary size. Diego (talk) 09:56, 2 September 2014 (UTC)

Odd that we spent all that time discussing numbers between 3 and infinity then. But the point is whether Flow has been designed to work the way people want, or the other way round. The casual assumption that the programmer decides that is revealing. It may be implemented as being capable in principle of indefinite indentation internally but nonetheless restricted to some specific limit (possibly depending on workflow, application or platform) in the code. I suppose the question is, what is the design goal here, and where can we go to read the explanation of why it was chosen that way? We know for a fact that alternatives such as 8-12 and 30+ were being discussed at one stage. Is there documentation that explains why they were rejected? Exposing that now would save having to have that discussion all over again, or alternatively annoying people with a flat those are the design goals. Deltahedron (talk) 10:16, 2 September 2014 (UTC)

Please don't infer too much from my tongue-in-cheek comment. I meant to convey the idea that, once you create generic code to allow for arbitrary nesting all levels will therefore be shown in the same way, whereas if there's a custom-made limit, different levels could be made to look and behave differently.

This doesn't imply anything about the state of the design process, of which I'm not aware. AFAIK, designers were still open to experimentation and haven't discarded any possibility, yet they are testing the possibilities of limited nesting. IIRC they promised a new design for the next version using user feedback gathered from the working prototype. Diego (talk) 12:15, 2 September 2014 (UTC)

This discussion is quite interesting, especially the part under the heading 8-12 levels of nesting. There are three comments from WMF staff saying that it wouldn't work for mobiles, and one user saying OK. That's not quite such a compelling consensus against indenting beyond 3 as one might have wished. But still, the design goal is fixed now. Deltahedron (talk) 18:08, 2 September 2014 (UTC)

So Flow is designed for mobile use? Do you expect people to do encyclopedic work while standing in the subway with their mobile phone? Fair enough, occasionally one might want to fire off a talk page reply in such a situation, but then I think it would be rather better to cater for that situation by having mobiles display the talk page indents differently, perhaps with micro indents. Does anyone know what Reddit threads look like on a mobile? Andreas JN466 01:46, 30 August 2014 (UTC)

Having borrowed a mobile, I find that Reddit looks much the same there as it does on a desktop computer. And it's perfectly usable, infinite indentation and all. (By the way, one thing I really like about Reddit is that when two people go on and on replying to each other ad infinitum, eventually, after 10 indents or so, Reddit will just put an arrow link to a new subpage.) I honestly don't see the problem. Andreas JN466 02:05, 30 August 2014 (UTC)

@Jayen466: At Reddit, just replace the "www" with "i" to get their mobile version. Interestingly, they don't display as many levels in their mobile site: see desktop and mobile comparison of the same thread - 10 levels are shown on desktop, and only 5 in mobile, despite the indent-width also being reduced. Quiddity (WMF) (talk) 23:37, 2 September 2014 (UTC)

Thanks, Quiddity (WMF). I found both the mobile version and the desktop version of Reddit usable on a mobile. So yes, smaller indents might work on a mobile, and it would surely be possible for Flow to host five or more, and then use a similar system to Reddit on mobiles to follow longer subthreads. It's a problem they've solved, so why shouldn't WMF be able to? Even if this is solved (and it should) there are of course further problems, such as how to allow communal editing of a chunk of Wikitext, using tables etc. You have your work cut out, guys. If I were you, I'd look at keeping the underlying structure of talk pages the same, but bolt an optional interface on top that allows people to reply without having to insert colons, asterisks and signatures manually. Andreas JN466 16:45, 3 September 2014 (UTC)

Do we not have a separate interface for article pages on mobile devices? Why was that option was rejected for talk pages? Incidentally, could somebody link to the design goals and, if possible, please point to the design documents that explained the reasoning behind the design decisions? Thanks. Deltahedron (talk) 17:06, 3 September 2014 (UTC)

Seconded. Andreas JN466 13:03, 5 September 2014 (UTC)

@Quiddity (WMF): I think you have just acknowledged that there needs to be different functionality for desktop users and mobile users. It's common practice, at least with database driven sites, to use a combination of responsive design and logic to present different content arrangement and interface elements for desktop and mobile users. One only has to look at this very talk page to see why multiple indents is so important. The design FAQ suggests that reducing the number of indents is conducive to "healthy discussion", and that flat is better than nested. I'm skeptical, but here's an experiment you can do: Edit this page to replace all of the sequences of four or more colons with three colons, and then see how healthy the discussion is.- MrX 17:20, 3 September 2014 (UTC)

Jorm, Flow needs to work best for the vast majority that edits talk pages from non-mobile, not for the tiny minority that wants to edit talk pages from a mobile device. If you want to provide options that make talk pages look or behave different when opened on mobile devices, fine; but making your editing environment suck for the majority of editors, for the benefit of the few, is not designing for the future.

Then again, in it very telling that you equate "being successful" with "meeting the design goals", and not with "being the best possible solution for as many editors as possible", no matter what the original design goals were. WMF seems very bad at responding flexibly to changing circumstances, to reality checks, to problems that arise from earlier goals and choices; it just sticks to what was decided years ago, no matter if that is the best thing to do or not. VE, MV, Flow, the list is getting quite long. All the words about community input, working together, listening to the users, and so on, seem to be just as hollow now as they were a few years ago. Then again, most of the people uttering them are the same, so why should we except any improvements? Fram (talk) 14:02, 1 September 2014 (UTC)

DannyH (WMF), I have a hard time thinking of a clearer "mandate from the people" that WMF has received than that this limit of three levels of indentation is unacceptable. I can't recall a positive comment from a user about it, although I can remember Maryam saying that she doesn't like infinite indentation and Jorm complaining that he doesn't want to implement it. It's not a particularly special function: I hit over that on my user talk page frequently, and it happens on nearly any contentious discussion. Why would you wait for a mandate from the people about signatures? WMF has proven itself perfectly content to proceed without it when it comes to software development, and shows little compunction about intentionally and purposefully contravening such user mandates. What makes signatures special?—Kww(talk) 23:03, 31 August 2014 (UTC)

@DannyH (WMF): Replying to some things: Indenting: You say that your revision of Flow as it stands is built for small conversations, for small talkpages. Herein lies a fundamental problem in the way that the WMF perceives Flow and the community. Sure, most talk pages will only be confined to little discussions, but on all pages, no matter how big or small, someday there will be an edit war, there will be an RfC, and the software must be ready for that. Consider a dam. Dams are not built to hold what the engineers think will be the minimum capacity, but rather the maximum. I think that it is a testament, not a design problem, to the way that Wikipedia discussions draw so many people and opinions.Also consider this talk page. Mostly discussions fall within the "three indent limit". But this discussion is a monster. How will Flow handle it? Not very well.Custom Signatures: As mentioned above and below, people with names with non-latin characters will have problems. You mention that it has been much a subject of debate among the Flow devs. Not so among the community. It illustrates once again the fundamental divide between devs and the community. I see also the problems that hiding, refactoring, and editing other people's comments have given you. While I am sympathetic, these are things that text editors should be built around, not added later. Fram also mentions in another section issues with deleting talk pages. This can be put off as not an essential function, but going back to the dam allegory, the time and capacity will come to use it. Also, deletiononly hats the posts. How will RevDel work? This could have implications for BLP should an editor decide to post libelous materialFinally, I think the project has turned into a skycraper with no foundation. They are so worried about indents and sigs that they forgot to add editing and removing posts, a fundamental feature. --KonveyorBelt 17:34, 3 September 2014 (UTC)

On the point of signatures there is the case of people who have non english usernames especially those in non-latin scripts. For example User:烈之斩 User:सर्वेश मिश्रा, User:ליאור. These are becoming increasingly popular since the introduction of single user login. Often these use a latin name to sign themselves for example User:ליאור signs himself as Lior and User:ברוקולי signs as Broccolo. Without the ability to sign using a recognisable script it becomes hard to distinguish these users.--Salix alba (talk): 06:21, 30 August 2014 (UTC)

My signature on other Wikis points to my user and user talk pages here; until we have interwiki Notification, if someone wants to contact me, they have to leave a message on my talk page here, not meta, WikiSource, Wiktionary, de.Wiki, es.Wiki. — Arthur Rubin (talk) 06:32, 30 August 2014 (UTC)

There seems to be a lot emphasis on accommodating mobile users, while making design compromises that might adversely affect non-mobile users. This obviously supports the notion that there is an uptrend in mobile browsing, but has anyone done an analysis of user's talk page participation from mobile devices? Jayen466 makes good points about indentation and Reddit as model for such, although I don't advocate unlimited indents. I find Reddit very usable using Android with Dolphin browser.- MrX 17:34, 30 August 2014 (UTC)

LOL, thanks for mentioning me (User:烈之斩). I just changed my name to English, Chinese Character is really annoying TBH.--fireattack (talk) 22:22, 31 August 2014 (UTC)

@DannyH (WMF): "the ability of any user to take obvious spam and vandalism off the page. That stuff happens, and the best way to deal with it is the way that wikis always have -- if you see something bad on a page, then you hit the edit button and clean it up, without having to go and report it to someone else. The bad thing is still accessible in the history, and people have the ability to undo your edit if it wasn't actually that bad after all. " No, the most common occurrence when you see something bad on a page is to hit the "undo" or "rollback" button. Oops, these no longer exist in Flow. Why? No one knows. Now, if someone makes multiple bad posts in Flow, you'll have to hide them one by one, instead of simply doing rollback. Or instead of doing "undo" on many edits in someone's contributions, you'll have to open every discussion, find the right post.... While the hide option is good, and it is nice that it is somewhat easier to get rid of one bad post when reading a board or topic, it is abosuletly bad that you have made it a lot harder to get rid of problematic posts across multiple pages (spam and the like). Fram (talk) 08:28, 1 September 2014 (UTC)

Misconception: Mobile editing is the future for talk pages

According to Jorm from the WMF (above): "Infinite indentation simply does not work in a mobile context. In order for Flow to be successful (e.g., "meet its design goals"), it needs to work for the future, and not only for the past."

Reality? Of the last 500 edits to the talk namespace (i.e. Article talk), 1 (yes, one was made from a mobile device, according to the tags): [3] Of the last 500 edits to the Wikipedia Talk namespace, none (nada, nil, not a single one) got a "mobile edit" tag: [4].

You can compare this with the article namespace, where 26 out of the last 500 edits got a "mobile" tag[5].

So, why are "we" (the WMF, that is) building a tool "for the future" that is aimed at a non-existant market, with smaller screen size, less indentation, and so on? Who has made these decisions, based on what research? And who will revert these decisions and inform their devs that the future of talk page editing is not "editing from mobile devices" and that mobile editing considerations should be given much less weight from now on? Fram (talk) 16:50, 1 September 2014 (UTC)

I will add here that on the few occasions where I have participated in lengthy discussions on Facebook, not being able to tell which post anyone is replying to is an absolute pain. And the discussions we have here are different in nature from the typical Facebook discussion: they concern sometimes intricate points of detail and argument, comparisons of source wordings and so on, where you need to be able to see the logical thread bright and clear in order to be able to follow what people are saying at all. Unquestionably, Wikipedians sometimes argue too much and too interminably. But if you make it physically impossible to engage in a sustained conversation, you're chucking out the baby with the bathwater. Andreas JN466 19:41, 1 September 2014 (UTC)

Both during Wikimania and just now I tried browsing a selection of articles on a mobile device, and found that I can't actually work out how to get to the talk page without going through search or similar. That might explain the imbalance. Beyond that, I agree with Andreas. Nikkimaria (talk) 01:11, 2 September 2014 (UTC)

Strange enough, nothing in Flow (so far) helps any editor in finding the talk page, everything that has been developed is about what happens after you found that page. This seems to be another major oversight. Fram (talk) 06:36, 2 September 2014 (UTC)

Agreed: I tried it today on an Iphone 4S in Safari on the mobile website and couldn't find the talk page either -- and I knew it was there, and was looking for it. Deltahedron (talk) 19:27, 3 September 2014 (UTC)

@Jorm (WMF): "Infinite indentation simply does not work in a mobile context. In order for Flow to be successful (e.g., "meet its design goals"), it needs to work for the future, and not only for the past." - There may be a fundamental problem in this approach which maybe isn't immediately visible to those who focus on software development: As Wikipedia has grown, the focus of encyclopedic work has shifted away from quick, rough content additions and towards creating an encyclopedic resource that can be taken seriously and where the content is thoroughly verifiable through references. Many people have great trust in Wikipedia (often too great, they should question us more) and this creates great responsibility. In-depth working at such a resource simply doesn't happen on mobile devices: When I work on a complex article (I'm active mainly in German Wikipedia), it may involve switching between a dozen of tabs with literature, and it may also involve complicated discussions with others. I don't want to do this on a mobile device, and the basic reason for this is very physical - screen size and handling, so I doubt that this will change with more advanced mobile devices in the future. Mobile editing is great for correcting typos and doing simple things that don't require discussion, but have you ever written a fully referenced article like de:Tynset (Roman) (an example of my newer work) on a mobile device? I think - this goes also to @Erik Moeller (WMF): - that it's very good to optimize Wikipedia for mobile reading, as well as to add options for easy mobile editing, but this should never unnecessarily obstruct more in-depth editing that isn't possible with mobile devices limitations. And, by the way - we're living (and editing) neither in the future nor in the past, but in the present :) Gestumblindi (talk) 20:41, 5 September 2014 (UTC)

This is an excellent post, and I think Gestumblindi has hit the nail on the head. The question, beyond all the user specs and requirements, which need to be determined, is whether Flow is being developed so that people can just simply dip into a talk page when they have nothing better to do and are waiting for a train, mobile device in hand? If so, then talk pages will quickly become forums. But Wikipedia is first and foremost project where content editors write (for the most part without pay) content for others to read. Often this is done alone and there's little talk page work. Other times it's done in collaboration and quite a lot happens on a talk page. So I'd want to know from the developers (i.,e Jorm (WMF)) whether Flow will be able to support the kind of work that that's been going on at a page such as Talk:Beaune Altarpiece? Thanks in advance for answering. Victoria (tk) 21:45, 5 September 2014 (UTC)

Deployment venues

I think this warrants more attention: test-deploying Flow on pages heavily used by new editors is really not a good idea. I realize why you're doing it, but it's not worth it at this point. It would be a bad idea if Flow were less buggy, because it would essentially be forcing new editors to learn two interfaces at the same time - not just technically, but also culturally. This is confusing to them, not to mention contrary to nearly every help or guideline page relating to discussion they're likely to be pointed to, and is likely to create extensive extra work for all editors. Editors who actually work with newbies will need to be explaining and troubleshooting an interface that they themselves have little experience with. Other editors will be needing to clean up after newbies who, becoming accustomed to Flow, attempt to follow the same customs on non-Flow pages. I was training new editors around the time that VE first rolled out, and let me tell you, it was twice as hard than normal training, even though the interface was supposed to be so much easier.

Given all that, deploying the current version of Flow, with its identified bugs (particularly those that separate it even further from how the rest of the wiki works, like history and watchlist issues), is not really something I would see as justifiable. Costs far outweigh the benefits, really. Nikkimaria (talk) 02:49, 30 August 2014 (UTC)

You really haven't thought this through, have you?

Apart from all the other problems mentioned above and in the archives, there seems to be a rather major flaw in the choice of pages for the proposed further rollout ("Right now, the two use cases we're focusing on are the French WP Forum des nouveaux (their version of the Teahouse), and a new mentorship project on enwiki that just got grant funding. Those are going to be the next stage of Flow deployment, possibly with a third mentorship space that we're talking to.")

Now, go to e.g. our tea house, and take a good look. One of the main things one needs to be able to do easily is display wikicode, so people can show what they do, or be shown what they have to do. See e.g. Wikipedia:Teahouse/Questions#Citing the same reference twice.. But without an easy way to show wikicode, and without an easy way of looking at the code that someone else uses, you are making such pages a lot less user-friendly for newbies. The exact opposite of what Flow was supposed to do... Fram (talk) 07:24, 30 August 2014 (UTC)

@Fram: Have you tested this? The <nowiki> and <code> tags work in Flow, which is what I've generally used in the Teahouse to show wiki markup, so I don't think this is a problem. I, JethroBT ^{drop me a line} 07:32, 30 August 2014 (UTC)

More interestingly, when VE becomes viable and is rolled out again (which, hopefully, shan't be too far off) all the newbies will ask how to do stuff in VE which we old fashioned wikitext editors won't be able to help with. But that's a side topic. BethNaught (talk) 07:39, 30 August 2014 (UTC)

JethroBT, and how are newbies supposed to know this? Oh, they can find them in "advanced", and then the icon of "W" in a "forbidden" circle. Or at least, that's the explanation you can give them in wikitext. In Flow? "You can type nowiki" and so on? Yeah, that's user-friendly... As for VE, I have used it a lot for testing. Loads of things inside VE still require wikitext knowledge (so people now have to learn two or three editing environments, quite an improvement). VE and Flow? Two negatives make a positive? Nice to see that at least in this regard, the WMF supports the mathematics editors ;-) Fram (talk) 08:10, 30 August 2014 (UTC)

Why would newbies need to know how to use nowiki tags? We must be talking about different things. I'm talking about how mentors show other editors how to do markup like in the Teahouse because that's what you brought up. Either way, as a host, you'd use things like nowiki and code tags regardless of whether it's Flow or standard talk pages. I, JethroBT ^{drop me a line} 08:26, 30 August 2014 (UTC)

"Hi, I tried to do X, but when I try to save it I get an error". "Can you show us what code you used?" Um, no, not in Flow, I wouldn't know how... And obviously, as mentor as well, having to type nowiki and so on is rather old-fashioned and unfriendly of course. There is absolutely nothing in Flow that helps you as an editor, no matter if you are a new one or an old hand, and newbies need it the most of course. So yes, you would still use "nowiki", but it would be in a rather unwelcome way. What I would actually do is invite the other editor to another, non-Flow page. Oops, that wasn't the purpose probably... Fram (talk) 08:48, 30 August 2014 (UTC)

Perhaps I was wrong. If one can copy/paste between Flow and WikiText editing, there's little problem, although even VB experts can probably not reproduce the keystroke sequences that resolve problems. I was lead to believe that that functionality was implemented. If not, I agree with Fram. Flow is not even ready for beta in regard talk pages which might require detailed WikiText (or VB) descriptions of what is wrong with a page or how to fix it. That would include the Teahouse on en.Wikipedia, but I don't know how fr.Wikipedia operates. — Arthur Rubin (talk) 16:43, 30 August 2014 (UTC)

Arthur Rubin: After testing it and looking at what others have been doing over at mw:Talk:Sandbox, Flow and Wikitext editing can be copied/pasted with very few issues at this point (one thing they're working on fixing is math formulae). Fram, if a new editor encounters an error like that, any host worth their salt would actually go and check out their contributions to see what happened and address it accordingly. We don't demand a new editor to write everything out again. This just doesn't seem like a realistic scenario. I, JethroBT ^{drop me a line} 22:01, 30 August 2014 (UTC)

If, as described above, the person got an error, then no, it won't be visible in their contributions. And what is the deal with copying between Flow and Wikitext? How does that help? Fram (talk) 08:20, 31 August 2014 (UTC)

The use case which was discussed a year ago [6], in the special context of mathematics, but of course it applies more generally, is the need to be able to collaborate on a chunk of text on an article talk page. For example, to copy-paste wikitext from the article onto the talk page, work on it there, and then copy-paste it back into the article without loss of fidelity. In the case of mathematics, that was crucial since discussion were likely to be about presentation and layout as well as content. But the need exists in complete generality of course. A related and simpler case is when a user finds a problem with a piece of wikitext, or asks on the talk page how to do something in wikitext, other editors can craft a response which can be copy-pasted into the article. Presumably there's some page or document where all these cases are captured, assessed, prioritised, resolved and desgined for, but I don;t know where that would be. No doubt the Flow developers can point you to the list of use cases that they built up as part of their "pretty good idea". Deltahedron (talk) 11:21, 31 August 2014 (UTC)

• We were assured a year ago that the Flow team "have a pretty good idea of what our existing users need" [7]. Deltahedron (talk) 18:02, 30 August 2014 (UTC)

How to inform about new topics

According to User:DannyH (WMF) at mw:Flow, there are only two possibilities how to handle new topics for people subscribed to a board.

"Yeah, we're going to have to retune the way subscribing to a board works. There were two possible definitions of what "subscribing to a Flow board" would mean -- a) You get an Echo notification that a new topic has been created, or b) You get automatically subscribed to every new topic created on the board. "[8]

Really? Why not simply put a line on the watchlist every time a new topic is created? No automatic subscription, but no Echo either, which should be kept for more important things. It seems as if the Flow developers are hell-bent on getting rid of the watchlist, or for some other reason refuse to use it. Why? You can, as far as I am concerned, keep the user-defined option of "subscribe me to every new topic", but why not go for the simplest and least intrusive solution as the default? Why, especially, not even consider it as a third option? None of the three certainly is even worse, but that is what happens at enwiki now; watching a flow-enabled page does absolutely nothing apart from showing changes to the header... Fram (talk) 08:07, 1 September 2014 (UTC)

Strangely, at the above mw-discussion, this is exactly what Helder (from the portuguese Wikipedia) proposed ("see the edit which creates new topics appear in their watchlist, but edits to the subpages of those topics will not appear in their watchlist"), but DannyH seems to not understand the concept of watchlists or the difference between a watchlist and Echo, "We're going to make a change within a couple of weeks that makes subscribing to a Flow board work the way that you described -- you'll get a notification when new topics are created." No, DannyH, not a notification (which is Echo, your A option), but a line on the watchlist. Please make it clear in your responses what it is you really mean, and please make the distinction between watchlist and Echo clear in them. And read what people are actuallu suggesting, and not what you want to hear. Above, in another discussion on this page, you made the same kind of "yes you are right" statement followed by one that contradicts or ignores it. That is not helpful. Fram (talk) 08:15, 1 September 2014 (UTC)

Seeing changes since the last visit

What is the method in Flow to see all changes to a board (not to a topic) since the last time you visited it / from a certain point in time? You can see the changes to a topic since you last visited it, or you can see the whole board, with recent active topics at the top, but seeing (by diff, or colour indication, or whatever) what is actually new or changed on a board seems to be impossible. This is standard functionality on current pages (you know, all the green "updated since last visit" indications on a page history), but has been completely abandoned here AFAICT. On e.g. WP:AN, after the weekend, you easily have changes to 5 topics and 10 new topics. Having to open these one by one is tedious (and having 15 notifications for that page alone is madness). Why isn't Flow integrated in the current mechanisms for history and watchlists, with where needed additional options and features? Fram (talk) 16:01, 1 September 2014 (UTC)

I asked that same question at the beginning of Flow development, as it's one of the essential features why the Watchlist and History pages exist - to review recent changes of conversations related to a given article. IIRC the answer was that they'd have to develop it from scratch because of the way they have structured the Flow data model on top of the Mediawiki software, with a separate wiki page for each [topic] comment - not one for each board. Last time I checked it didn't seem to be very high in their list of priorities. Diego (talk) 16:45, 1 September 2014 (UTC)

I know, most major problems and flaws in Flow were there from the start. That's why I don't get their intention to deploy it to more pages, confronting especially new editors with it. Probably they have to meet some deadline to get their bonus (or keep their job), but that's not really a good reason to continue on this path. Or they genuinely believe that they are doing great, which is something that has lead to previous WMF deployment disasters. Just look at e.g. Wikipedia talk:Flow/Archive 7#Please disable Flow from enwiki, the list of missing things I got there from a very first test after they went live. I can copy that complete list here, verbatim, but we are more than 6 months later and according to the WMF, everything goes great and we can roll this out further! Fram (talk) 17:05, 1 September 2014 (UTC)

I need to be able to go into the history and compare 2 times, just as I do now. Dougweller (talk) 17:12, 1 September 2014 (UTC)

Deployment

On the roadmap, I see for this month: "The Co-op mentoring project (w Jethro, Jake, Siko & Aaron)" According to Jethro, the deployment there wil be for December at the earliest, so no idea why it is listed for Q3.

For Q4, I see a possible deployment to "User talk on Product-friendly projects". What are product-friendly projects? Then, the third line, is "Possible opt-in user talk test?" What's the difference with the "user talk" of the first line? It's still a bad idea (and unacceptable without the necessary admin tools for it).

The fourth and final lines again are duplicates, "Expand rollout of WikiProjects/article pages" and "More WikiProjects on Wikipedia, possible rollout to articles in those areas". You are aware that Projects don't own articles, and that many articles are in the scope of multiple projects, which may not all support Flow (yet). So please don't go to e.g. Wikiproject Hampshire and ask them whether you may set their articles to "Flow", as they don't get to decide that (their input is welcome of course). You'll need community consensus to deploy Flow to more things, like articles or user talk (as an opt-in for other people). If you really need to deploy it further, use it on WMF pages on enwiki (the talk pages of the WMF people, the talk pages of WMF pet projects), before rolling it out to other pages. Of course, first fix the many major bugs and deficiencies. That will probably make the Q3 and Q4 dates impossible though. Fram (talk) 08:09, 3 September 2014 (UTC)

Yup, that's how it works. That's why it says, at the top of each section: "Possible deployment: 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."

You can't actually predict in June 2014 what the product will be like in June 2015, at least not with any specificity. For planning, you have a good idea of what you're going to do in the first quarter, and a general notion of where you'd like to go in the second quarter. Third quarter is entirely guesswork, and fourth quarter is just a direction you'd like to travel. We're actually doing pretty well on meeting our first quarter goals, and we've learned a lot. We'll do a more realistic update on Q2 goals at the end of this month. DannyH (WMF) (talk) 14:39, 3 September 2014 (UTC)

I am not discussing what you are planning for June 2015. I am discussing what you are planning for July to September 2014, i.e. at the last this month. A planning you posted here on 29 August 2014. Are you seriously saying that you didn't really know what you would be doing in September 2014 at the very end of August 2014? Could you, in the future, just respond to the question instead of going on complete strawman tangents? It's a very annoying habit. And perhaps WMF can use the standard quarters, i.e. Q1 for Jan-Mar, Q2 for Apr-Jun, and so on, instead of what you used now? Then you would have noticed that I was discussing the standard Q3, Q4, and so on (which you could easily have seen by seeing my references to actual months, or by comparing my quotes with the roadmap), not the uber-user-friendly WMF quarters (let's start Q1 in July!). Fram (talk) 17:04, 3 September 2014 (UTC)

Uhm, Q1 does start in July. We're on a business year, not a calendar year. --Jorm (WMF) (talk) 17:25, 3 September 2014 (UTC)

"We"? Again, as usual, keep your in-company stuff in-company and out of Wikipedia, and discuss things here (and present them on the Flow page) in a standard manner. And like I said, everything in my post made it clear what I was talking about, certainly for the product manager who had posted the very roadmap. But of course, it is easier to focus on the Q1 vs Q3 discussion than on the many relevant points made here (scroll up, and up, and up, and you'll see tons of remarks, questions, problems, ... no one has replied to). Fram (talk) 17:48, 3 September 2014 (UTC)

I'm not sure if there's anything anyone can say to you, Fram, that isn't going to be rejected immediately. The fact of the matter is that we operate on a Fiscal year and thus our planning documents are built around that. It's a very common practice. I'm sorry that you didn't understand that, but yelling at me isn't going to change that.--Jorm (WMF) (talk) 18:09, 3 September 2014 (UTC)

If you want to try saying something that has an improved chance of acceptance, perhaps you could try addressing the original posting, which was about planning for certain specific items in July to September 2014? Deltahedron (talk) 18:17, 3 September 2014 (UTC)

I'm sorry, I was actually confused by Fram's original post. Now that that's cleared up -- conversations with the Co-op are happening this month, and we're going to put up a test page soon so that the people who will join the Co-op program over the next month will have a place to try out Flow and give us specific feedback based on what that project will need. That decision was made in a meeting at the end of last week; I haven't updated that Goals page yet.

The questions about October to December are spot on -- I believe I wrote those items in June, and a lot has happened since June.

But -- the big question that's coming up in a bunch of threads here over the last week is: Why aren't you updating this information more? And my answer is: You're right, I should be, and I'm going to work on getting better about that. Honestly, there's been a big uptick in people's interest in the project in the last couple weeks, since we did our last release and also started sending out more information on the Wikimedia EE mailing list. For the last few months, it didn't seem like very many people actually cared enough to pay attention to the Goals section. It looks like that's changed, which is great. That means Nick and I need to be updating that documentation more often. You'll see more of that soon, and I'm sorry that it took me this long to recognize that as a problem. DannyH (WMF) (talk) 18:32, 3 September 2014 (UTC)

Thanks. You haven't indicated why you feel the need to roll this out to inexperienced people already having some trouble with editing; it won't help them, and it isn't necessary for Flow development at the moment, there are more than enough problems, open questions, bugs, ... to keep you busy for months to come. That to me is a much more important question than why the info isn't updated more regularly, although that would be good as well (certainly better than posting information at the end of August which is already outdated at the time). As for people not caring: no, people noticed that nothing wsa happening, and probably assumed that the team was working on the issues raised in (mainly) February. Now people notice that this isn't really the case, and that the WMF is again on a self-supporting path of wishful thinking, with goals reached, improvements done, progress for the future, but only on paper, not in reality. People don't care, people are worried. Fram (talk) 07:22, 4 September 2014 (UTC)

Fram puts it well. People don't care (though they should, the community needs to come up with a clear policy and response on Flow usage); people saw the rollout of MediaViewer and came here in an effort to raise problems in order to prevent another software rollout disaster, one which will have a much greater effect that any software change for a long time. Given the lukewarm response to certain critical issues raised (deletion, moving, and the whole Watchlist/notification confusion) my concern has not abated. BethNaught (talk) 07:32, 4 September 2014 (UTC)

(ec, reply to Jorm) What Deltahedron said (most importantly), and please just think about it: what does it matter to anyone at enwiki who is interested in Flow that you (the WMF devs) work according to a Fiscal Year (never mind why you plan your releases around a fiscal year)? Can't you see that using Q1 for the period July-September in your communication with users (editors) is just slightly confusing, as evidenced here? That it in reality has no advantages to use that here, but all kinds of disadvantages? But if you prefer, just ignore this side-discussion, and focus on the actual questions. Fram (talk) 18:33, 3 September 2014 (UTC)

Nevertheless, thanks to DannyH for his commitment for better communication. Deltahedron (talk) 18:35, 3 September 2014 (UTC)

• DannyH (WMF), quite a few people who have been following this topic were aware of the change in leadership for the product, ad then were told that there was a lot of redevelopment of both the front and back ends of the code, which we (reasonably, I think) assumed would accommodate a lot of the issues that had been surfaced over the past year. In other words, people gave some time and space for you to get acclimatized and for the redevelopment to take place. Now that you've been here a while, and the deployments have happened, we're back... Risker (talk) 13:45, 4 September 2014 (UTC)

  Just for the record, I was opposed to the deployment of FLOW in principle, and I remain opposed. My main point has never been addressed - this is the first important deployment without the opt-out option, and I believe the idea of FLOW is flawed, to the point I will probably stop editing talk pages if FLOW gets installed. I believe I am not the only user who feels like this. I feel that we are moving towards a revolt and possibly towards a serious instability within the movement. I am pretty much disappointed that WMF consistently fails to address this point, trying to solicit reaction to cosmetic improvements instead.--Ymblanter (talk) 16:10, 4 September 2014 (UTC)

  I agree. The WMF has failed to establish that there is agreement for this nuclear change. The back/forth conversion functionality which is being developed could well end up in a wheel war being site admins and WMF staff beyond anything of the likes of VE and MV. Naturally, this is why Möller jumped at the excuse to add superprotection to the software. BethNaught (talk) 16:16, 4 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 [9] "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)

• That's helpful, thanks. I have to say, though, that the situation today looks very similar to what it was a year ago when I last took a close interest in Flow: major decisions still to be taken, free-form discussions underway with various members of the community, mathematics not working properly, ... . Is this a reboot? Deltahedron (talk) 05:58, 4 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)

Why roll this out to other pages at enwiki?

The question (like many other rather important ones) has been asked a few times above, but hasn't goten a real answer AFAIK.

There are many, many remaining problems, bugs, design choices to be made, fundamental issues to solve, ... with Flow. Many of those have been raised from day one, more have been added since. Very few have been solved. So what is the purpose and what the benefit of rolling out Flow to more pages on enwiki? Will it help the people (mainly inexperienced editors needing mentoring or having questions about editing) at these pages? Will it make the development of Flow any faster or easier (and if so, how?). Will it solve any of the open problems (at the moment, at Bugzilla, 338 open Flow bugs)? Will it do anything that rolling it out to more pages at e.g. mediawiki won't solve? Fram (talk) 07:33, 4 September 2014 (UTC)

The Law of Unintended Consequences

When you look at someone's contributions, you can select a namespace, and check the "associated namespace". So you can e.g. see all changes someone made to articles and their talk pages.

With Flow, this no longer works, since talk page messages now get their own namespace, Topic. Which, as an aside, makes me wonder how the talk page of WP:AN would look once WP:AN is Flow-enabled.

The good news is that you can of course check all contribs to the "topic" namespace. But (hey, it's Flow, there is always a but, and usually a dozen of them), they have been made the most uninformative possible. [10] shows

• All posts as new (N)
• All sizes as "+1"
• All edit summaries as "‎(→‎Taken over by Flow)"
• All statuses as "Current"
• All descriptions as " Topic:Rzi5r14uxfclgfdw", " Topic:Rzi5e3sjta2n7h8r " or " Topic:Rzi5dgyw1s0v58p9 "
• No entry when a post is edited
• No diff

So, what do we see on the roadmap?

•  Done Log item improvements for Watchlist and Contributions

Yes, let's roll this out to more pages, it is so ready! Or, alternatively, first do your homework, remove all offensive "done" checks from your roadmap, rewrite the roadmap, drop all plans to roll this out to other pages, and come back once you have a system where the basic functionality, front- and backoffice, works. Fram (talk) 07:57, 4 September 2014 (UTC)

• Agreed! It's a wonderful idea to roll this out to newbie pages, that way we can replay the VE and MediaViewer rollouts, or the (much cursed) abolition of the toolserver (may he rest in well-deserved peace), which resulted in useful tools like Citationbot to slow down to almost being unusable and Reflinks to disappear altogether. Man, are we having fun here! WMF, this is another disaster in the making, can't you learn from previous experiences and please slow down? Fram, I much appreciate your engagement on behalf of the community here! --Randykitty (talk) 10:53, 4 September 2014 (UTC)

New topic notifications change

Okay, a change in Flow notifications went out with today's release. As of now on Mediawiki.org, subscribing to a Flow board will only give you a notification that a new topic has been created; you won't be automatically subscribed to new discussions on that board. This will help to cut down on the repetitive notifications that people were getting.

We're also going to try out bundling "created a new topic" notifications, when there are multiple new topics created on a board that you're watching. Rather than going directly to the topic page, the bundled "new topic" notifications will take you to the board, sorted by newly-created topics. The plus, obviously, is that you get fewer notifications; the minus is that you may need to scroll down on the board to make sure you don't miss something.

We're also working on bundling email notifications, and giving the emails a more helpful subject line. So that's also a thing. DannyH (WMF) (talk) 00:05, 5 September 2014 (UTC)

So, if you are not automatically subscribed to new topics, do you still get watchlist entries for posts etc on all topics on watchlisted pages? If not, this change is not helpful:Jay8g [V•T•E] 00:42, 5 September 2014 (UTC)

Yeah, I know. We have to figure out something else for watchlist-only people. The saga continues. DannyH (WMF) (talk) 01:48, 5 September 2014 (UTC)

So, the feature that was live on mediawiki and most people complained about (was anyone happy with it?) is now being rolled out to here as well. Are you (plural) being deliberately obnoxious or what? Why don't you use the watchlist for this, and keep echo for the important stuff? Echo = this may need your attention first, Watchlist = you may want to check this out in your own time. A new topic on any of the thousands of talk pages I am watching is not something I want an echo about, but something I may want to see on my watchlist. You have provided the exact opposite. Great! Fram (talk) 07:13, 5 September 2014 (UTC)

@DannyH (WMF): Just revert this as quickly as possible. Really. Right now, basically. It just makes my life worse, not better. Apart from the things already mentioned, couldn't you perhaps have realised (after, you know, testing this as a real editor) that "messages" are less important than "alerts" to everyone but Flow developers? Now, if I get an alert, I open Echo, and I don't see them. Oh, I get the unimportant "messages" by default, and have to go to "alerts" to see the things that are of most interest. I have to do this even when the messages are all read and the message counter is zero, so not even that excuse (weak as it is) can be used. You are trying to force-feed Flow with disregard for any negative community feedback (i.e. 95% of the community feedback you get). The only result is that Flow will be loathed from the very start, with no chance to recover from that position, and that the people who try to push it through anyway may be facing the Erik Möller treatment (not how he acts, we wouldn't do anything as bad as that, but how he has been treated here and at the German Wikipedia). I can't imagine that being in your planning for this Fiscal Year. Fram (talk) 09:57, 5 September 2014 (UTC)

@DannyH (WMF): Indeed: just take it back to mediawiki wiki and make it work properly before you try to make us use it. You worked at Wikia: you should have noticed that the skin changes there drove away communities. Indeed, your determination to push this through makes it look as if driving away inconvenient old-timers would be a pleasant side effect for you. BethNaught (talk) 10:13, 5 September 2014 (UTC)

Notifications galore, and editing "deleted" topics

Apparently everyone who is mentioned on this deleted topic gets an echo (with the wrong date?) every time someone replies to that discussion, even if they have not been named in the reply, and they haven't watchlisted this page, board or topic. This is clearly unwanted behaviour.

Furthermore, it is way too easy for administrators to edit deleted topics, this is clearly unwanted (not their specific posts there, we are only testing, but the option in general). Something that is deleted should remain unchanged until it is restored, otherwise you create admin-only discussion areas and a greater rift between admins and non-admins than we already have. Fram (talk) 07:22, 5 September 2014 (UTC)

I got two echo notifications this morning that someone mentioned me here 7 months ago, and have now twice (I think) been notified that someone created a new topic on that page 13 hours ago ... Andreas JN466 13:00, 5 September 2014 (UTC)

I am getting the notifications too, although I'm not sure who mentioned me and where. BTW, I have never participated in Flow discussions. Δρ.Κ. ^{λόγοςπράξις} 15:14, 5 September 2014 (UTC)

@Fram: I've filed bugzilla:70449 for locking deleted content. Thanks.

Regarding the notifications for old topics, that must be a bug. @Jayen466:, what was the other notification that you got this morning? (so that I/we can try to diagnose/reproduce the error). Thanks.

It seems what happens is that when you click on the red number, you're always shown the "notifications", even if what you got was an "alert". (I linked the page in question above. All three notifications refer to the same page.) Just make it so that if there are zero new notifications, but 1 or more new alerts, you are shown the alerts, and not the notifications people have seen already. Andreas JN466 18:42, 5 September 2014 (UTC)

@Dr.K.: If you have any of the pages watchlisted, you'll currently be getting "New topic created" notifications. The idea is that we can then watchlist the individual topics, if we want to follow them. If we are watching the individual topic, then we get notified when there are updates to it. This configuration is just a first pass, and will definitely need A) some ongoing tweaking, and B) probably some additional userpreferences. What additional changes or features, might be helpful? Quiddity (WMF) (talk) 18:38, 5 September 2014 (UTC)

Thank you very much Quiddity. I have unwatched the pages involved and it seems to be working, since no new notifications have come up. As far as other features, I haven't given this much thought so I cannot comment on this issue. Take care. Δρ.Κ. ^{λόγοςπράξις} 21:41, 5 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)

• Endorse Fram's actions. Not a single person has approved of using the Teahouse as a testing space and one user, an engineer, suggested there wasn't an MVP (which I agree with). Even in your own post at WT:Teahouse you admit some essential features are missing, and Fram has demonstrated plenty more. You ought to have learned at some point that presenting people with a fait accompli will only piss them off. If it was just a test page, there are plenty to use already, which means it is plain you want to take over the Teahouse by any means necessary. BethNaught (talk) 08:33, 5 September 2014 (UTC)
• Endorse Using pages that are heavily frequented by newbies for experiments with (at best) beta software seems to me the worst idea since Windows Vista or New Coke. --Randykitty (talk) 08:43, 5 September 2014 (UTC)
• Endorse Really bad idea to use Teahouse. @Fram:However, it can be deleted. I just did it as a test. Um, it's gone, gone, gone and evidently never coming back. I can't undelete it. Sorry guys. Dougweller (talk) 09:35, 5 September 2014 (UTC)

  Deleted which page? I can still see Wikipedia:Teahouse/Questions/Flow_test. BethNaught (talk) 09:40, 5 September 2014 (UTC)

  I stil can see it as well. However, your deletion has moved the logs to the "deleted" section: [11] Which is interesting, because it appears some actions were done by "Flow talk page manager", but that user doesn't exist and can't be blocked (I know, I tried;-) ). So now we have a total lack of accountability, log actions not related to any editor. Down the drain with Flow! — Preceding unsigned comment added by Fram (talk • contribs)

  True. The deletion log says I deleted it twice, but it's still there. Dougweller (talk) 13:21, 5 September 2014 (UTC)

• Endorse - (Not the get lost part). I assume the best intentions from WMF, and I'm hopeful that Flow really will improve collaboration at some point. Unfortunately, the Teahouse is probably one of the worst possible places to test Flow. Pre-alpha software should never be deployed into a production environment.- MrX 12:39, 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)

• 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. Eg. The teahouse editors discussed it in June, and the Co-op creators have had 2 meetings with the Flow team specifically about this.
  There are no plans to add any more pages at Enwiki at the moment. Quiddity (WMF) (talk) 17:18, 5 September 2014 (UTC)
  • • • Second note: This was mistaken and badly explained. See explanation below. :( Quiddity (WMF) (talk) 23:58, 7 September 2014 (UTC)
  • Let's see, from that Teahouse discussion:
  • Cullen: "If Flow is debugged and functioning smoothly, then perhaps I will be happy to see it implemented at the Teahouse. But I think that the Teahouse is a really bad place for beta testing of a highly complex new feature. "
  • Anne Delong: "I agree with Cullen328. While FLOW may be great for the Teahouse in the long run, a discussion page for inexperienced users is not the place to test something new which may need adjustment."
  • VQuakr: "it is a logical place to "combat evaluate" Flow once alpha testing is complete and the software is effectively bug-free. "
  • NeilN: "Let's not confuse new editors further with a UI which is completely different."
  • WritKeeper: "What Cullen said, pretty much word-for-word. "
  • Technical13: "I agree with Cullen as well at this point."
  • JohnUniq: "As others have explained, testing Flow here would be undesirable. "
  • Risker: "it's not ready for prime time yet."
  • Dougweller: " I don't think using it here would be a good idea. "
• So, Quiddity, I don't know which discussion you have seen at the Teahouse, but the one you linked to it is pretty clear that they don't want it. So, you had the input from the project, and you totally ignored it. Why do you think I started a section with "Get lost, WMF"? You are only reinforcing that opinion. Fram (talk) 17:53, 5 September 2014 (UTC)

  That discussion was regarding using Flow as a direct replacement for the existing /Questions page, which has not been done, and would not be done without the Teahouse hosts' support. Quiddity (WMF) (talk) 19:02, 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)

• If the page is merely for editors "who want to brainstorm and test potential gadgets and scripts to work with Flow", why would they not be able to use one of the pages already in existence such as mw:Talk:Sandbox? Deltahedron (talk) 18:25, 5 September 2014 (UTC)

  The Co-op project plans to create some unique gadgets, and wanted to be able to test various changes and additional features, without confusing regular Flow testing. There's further discussion about the Teahouse test page, at Wikipedia talk:Teahouse#Flow test page. Quiddity (WMF) (talk) 19:02, 5 September 2014 (UTC)

  I see no non-WMF comments in favor of that, either, although there was one which wasn't opposed. Still, no pre-beta release should be installed where newcomers can easily get to it. Flow is probably up to alpha. — Arthur Rubin (talk) 22:48, 5 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)

So funny it hurts

So, after fully protecting Wikipedia:Teahouse/Questions/Flow test, I switched to my non-admin alter ego User:EngFram t osee whether protection actually works with Flow. Well, not really.

The good news: you can't create a new topic anymore.

The bad news:

• if you try to create a new topic, you first can edit as much as you like, but on saving, you get a smallish pink box with the message "Blocked". Blocked? Oh, I'm not really blocked, I just can't save my new topic.
• If you want to reply to existing topics, no problem! You can reply to topics on fully protected pages. Which means that protecting a Flow-enabled page has very little effect and won't do a lot to stop vandals and the like. Yes, this is completely ready to be rolled out to more pages. Fram (talk) 08:17, 5 September 2014 (UTC)

Is it still blocked? I've been able to create a new topic right now. Diego (talk) 10:58, 5 September 2014 (UTC)

Apparently, after it was "deleted" (which didn't work), the protection was lost. Which was not logged in the page log... The more you test this, the worse it gets. I've reportected it, normally (hopefully) you won't be able to create a new topic on that page any more. Fram (talk) 11:10, 5 September 2014 (UTC)

Right, now it is like you reported. I can't create new posts (shows Blocked when I try to Add topic), but I can reply to the existing one. Diego (talk) 11:49, 5 September 2014 (UTC)

There's a patch for that, written yesterday. It was a fresh bug. Quiddity (WMF) (talk) 16:28, 5 September 2014 (UTC)

ToC

Perhaps (probably) this has already been discussed, but I just had a look at Wikipedia talk:Flow/Developer test page and noted that there is not table of contents at the top of the page. So if I want to see whether a certain subject has been discussed, I need to scroll through the whole page? --Randykitty (talk) 08:41, 5 September 2014 (UTC)

Flow is a memory hole: there's no TOC, no archive functionality, no search feature. This is just one reason why deployment to high volume pages, like, umm, the Teahouse, is a crap idea. BethNaught (talk) 08:51, 5 September 2014 (UTC)

And that would also apply to my own talk page? OMG!! That would lead to a huge talk page (look at the archives I have) and make it impossible to revisit older discussions... Nononononono! --Randykitty (talk) 09:18, 5 September 2014 (UTC)

But you can always check the history! Well, at least the 200 or so most recent edits, all the older ones are at the moment irretrievably gone. See e.g. [12] and try to get at any history from before 10 June (the page went live in February). You can find it topic by topic (if the topic doesn't have too much history of course), but not as a whole... This has been noted months ago, but hasn't improved yet. Fram (talk) 09:24, 5 September 2014 (UTC)

That alone makes busy talk pages almost useless. Dougweller (talk) 09:40, 5 September 2014 (UTC)

Only started to look into this yesterday, I'm here to edit, not to bicker about software. Seems like that was a mistake. Based on what little I have seen, I don't see any improvement to our current system. If it ain't broke, don't fix it! --Randykitty (talk) 09:43, 5 September 2014 (UTC)

@Randykitty, BethNaught, Dougweller, and Fram: There is a ToC coming. There are 2 current designs for that: the slightly older floating ToC on the siderail, and the newer a ToC at the top of sections (This semi-interactive draft version mixes 2 ideas: a ToC at the top of the sections, and a ToC in a fixed header ala Winter. It's likely that we'll see the simpler version soon, which will be basically the same as the existing ToCs. I'm advocating for it to be uncollapsed by default, but that would require some design reconfiguring.

Search is also coming, they're working on that with the 2 search developers right now,[13][14]

The historypage needing pagination is also being worked on.

Quiddity (WMF) (talk) 16:20, 5 September 2014 (UTC)

Good to hear. Thanks. Dougweller (talk) 16:37, 5 September 2014 (UTC)

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)

• Before striking, it might help to note the following comment by Jan-Bart de Vreede, chair of the WMF Board, though speaking in a personal capacity [15]:

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)

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)

Please be so kind as to respond to some questions

I asked some questions of general interest to the community at large. So far they have not been answered, or even acknowledged, by WMF staff. If you are not going to answer them, it would be polite to at least say so explicitly. For reference, they were:

• (In the context of an exchange about three levels of indentation versus infinite indentation) Is "more than three" synonymous with "infinite"?
• Is there documentation that explains why [alternative indentation choices] were rejected?
• Do we not have a separate interface for article pages on mobile devices? Why was that option was rejected for talk pages?
• Incidentally, could somebody link to the design goals and, if possible, please point to the design documents that explained the reasoning behind the design decisions?
• 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?
• (When Brandon said "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?

Thanks in advance. Deltahedron (talk) 19:55, 5 September 2014 (UTC)

Re: Threading/indenting: There have not been any recent decisions on indenting, and it is one of the major issues to be re-examined in the near future. Nothing has been rejected. There are a lot of pros and cons to each of the various options, and Danny wants to compile those details so that we can discuss it anew. I'm hoping for some test pages/instances so that we can demonstrate the pros and cons in-action, and compare side-by-side, but at worst we can create demo's with :::indents. (Personally, I like the roughly ~10 levels that wikitalkpages and reddit use, so that's my bias, and are why I originally put together that listing used in the old major discussion. But I understand the benefits of flat&chronological discussions with selective "quoting" as gmail/forums/bugzilla uses, and I'm looking forward to discussing it again.)

Re: design decisions and documents: so far, the wireframes and mockups generally get attached to the trello cards, or discussed in meetings (and in person and in IRC and in the various mailing lists and CC-threads). However, per Wikipedia:Flow/FAQ#Components of the discussion system, most of the ideas are still experimental, and they've been working to get them into a functional state precisely so they can be tested and extrapolated upon, and (in the near future) discussed with all of us (and the communities at the other wikis) using real working examples rather than just textual-descriptions or static wireframes/mockups.

The abstract design goals are the 3 bullet points at the top of the main project page; I believe that is what Brandon was referring to. Danny did a large overhaul of the primary documentation page at the beginning of August, and there'll be a bunch more work on that and the other pages, next week. Quiddity (WMF) (talk) 23:58, 5 September 2014 (UTC)

Thank you for that. Before commenting further, perhaps someone could enlighten me, please — what on earth is a "trello card", and where on earth would I find it? Deltahedron (talk) 06:36, 6 September 2014 (UTC)

It's a project management tool used by the team; you can see the current sprint here, for example. The presentation can take some getting used to but is a pretty standard way to manage software projects.--Erik Moeller (WMF) (talk) 06:38, 6 September 2014 (UTC)

Thank you. I now realise that I don't know what "wireframes" and "mockups" refer to in this context, and perhaps I am not the only person in that lamentable state of ignorance. Could you enlighten us further please? Deltahedron (talk) 08:08, 6 September 2014 (UTC)

A mock-up is a higher fidelity representation of a user interface, whereas a wireframe is used to primarily describe the interaction logic and rough layout in a design and lacks visual detail. Here's an example card where the team discusses a simple design change, using mock-ups to illustrate it. You can look at the previous sprints board, as well, to see many examples of both design and functionality changes.--Erik Moeller (WMF) (talk) 08:26, 6 September 2014 (UTC)

Once again, thank you. Deltahedron (talk) 10:07, 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)

View deleted

I was wondering whether "view hidden" (for [autocofirmed?] users), "view deleted" (for admins), and "view suppressed" (for Oversighters) will be implemented. It seems a minimal effort to ensure transparency among those who could see the material, to allow them to do it without making it visible to all. — Arthur Rubin (talk) 00:22, 6 September 2014 (UTC)

Well, you should definitely be able to access anything through history or contributions, if you have the user right to see it. We're going to be doing some more work on all the hide / close / delete stuff. We need to at least match the functionality on wiki talk pages, which it doesn't yet. DannyH (WMF) (talk) 01:25, 6 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 [16], 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:

• Display comments in arbitrary order, arbitrary threading style
• Search comments across date ranges
• Search comments by author
• Track comments as comments, not as diffs
• Monitor changes at any part of a comment thread
• Display comments independent of a given document (e.g. email, cross-wiki, etc.)
• Display comment metadata in different formats easily (e.g. timestamps)
• Update author names after a username change without having to update documents
• Enables third parties to build new UIs (think Wikiwand for comments) more easily
• Ability to tag/categorize individual comments/threads
• No edit conflicts
• and more.

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

• It preserved "headers" on top of the threaded conversation as community-editable wiki-like spaces
• It had a full history model for the thread itself, not just comments
• It preserved comments essentially as individual wiki pages, with their own history
• It had a built-in notion of thread summaries, collaboratively written, for closing comments

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 [17], and MediaWiki.org for its support desk [18], 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 [19] [20], 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 [21] is in development by Andrew himself.

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

• Flow doesn't pretend that comments are "pages", instead using its own separate tables to manage them. This is architecturally important to give us more flexibility on how to store, version, query, search, and describe comments.

• Flow is built from the start to store comments in a central datastore, to make it easier to display comments and relevant notifications cross-wiki.

• Flow users Parsoid's HTML underneath, to prepare it for VisualEditor.

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)

• We were pointed to mw:Flow/Architecture, so presumably that's still valid. Almost the first thing we read there is Big ideas -- Flow is about workflow management. A "discussion" is a type of workflow – a very simple one. Is that still the case? I seem to remember that a year ago -- and presumably that is where the design process is back to after the reboot -- there was an ambition to capture many of the workflows on many of the projects and corrall them all under Flow. Is that still the grand plan? How many of those workflows have been captured and documented? Or are you focussing back in on discussion? Can it really be true that Flow is still struggling with the "very simple" discussion workflow. — Preceding unsigned comment added by Deltahedron (talk • contribs) 11:09, 6 September 2014 (UTC)
• Hi Erik, thanks for presenting these two scenarios. As a content creator, I'd have to say the first model is the way to go. From my perspective I consider the function of article talk space to be a blank page/file/document which does the following: displays banners for wikiprojects (templates); displays DYK/PR/GA/FA article reviews and article history (templates); provides a scratchpad of sorts to capture ideas, unofficial reviews (those that don't get transcluded at DYK/PR/GA/FA), edit requests for protected pages, and a means to discuss/collaborate in terms of content/sourcing/formatting/image use and so on for the article. The indenting isn't ideal, but it's superseded by the flexibility of what currently can be done on a page. Beyond that in article talk space, when discussion are stale or finished sections/threads can be archived but always kept to refer to. History is vitally important so as to pull out diffs, particularly in contentious discussions. Additionally, article talk space is used for RfCs (template) which require both the ability to have a straw poll and a threaded discussion. Currently a discussion that goes off track can be collapsed with {{hat}} & {{hab}} or a discussion can be closed with {{archivetop}} {{archivebottom}}. These are just off the top of my head. The downside is that edit conflicts do happen, but only in very fast and often angry conversations, and sometimes edit conflicts slow down the dialogue which isn't all bad. This, however, is only from a single editor. One thing might be to try to capture some really hard data by running a Surveymonkey type survey. The trick with those is not to ask leading questions (how do you think talk pages can be improved? > suggests improvement is necessary) but rather to find out how talk pages are used. With what frequency do editors post to them? How often does a post include a template, blockquote, file, etc.? I read on the Mediawiki page that people on Quora were asked about article talk space (with a leading question): I'd suggest the place to ask how that space is used would be in the projects, i.,e here for en.wp. The next issues, is what is the purpose of the redesign? If it's to bring in new editors, what will those editors be doing? Will they be doing the things I've mentioned above, or simply adding comments to threaded discussions? Anyway, sorry, this is very long, but I decided to respond to your query. Victoria (tk) 14:47, 6 September 2014 (UTC)
• I will leave here the link to Erik's post at wikimedia-l [23]. Whereas the post is the same as his message above, the replies hit important points and may be of interest to read to thos who are not subscribed.--Ymblanter (talk) 15:34, 6 September 2014 (UTC)
  • Thank you Ymblanter for linking that. It's pretty annoying to see the conversation at two places. I could have save a lot of time and effort and not bothered to post here at all! Victoria (tk) 15:43, 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)

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

• @Erik Moeller (WMF): It seems that the majority of replies (both here and at the list thread, not to mention during these discussions in general) are "We'd prefer what we've got now, thanks anyway." Could you please address that directly with what the WMF's plans are if that remains the answer, as I don't see that answer changing any time soon? Seraphimblade ^{Talk to me} 20:49, 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 [24], 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." [25] Deltahedron (talk) 21:33, 6 September 2014 (UTC)

• I was copy/pasting a response I made to Erik on Wikimedia-L, but after I saved it, I realised it is way too long for this page. Instead I've moved it to User:Risker/About Flow as of 6 September 2014 for anyone who is interested in reading it. Risker (talk) 01:40, 7 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)

• I have come to the conclusion that the whole Flow project as currently proposed is fundamentally mistaken. The prime mover is make it easier for new editors to participate in discussions. There seem to be three main obstacles adduced here: that talk pages are complicated to use with a confusing variety of conventions, tags, templates and workflows; that wikitext is difficult to use in the way those conventions require; and that other, more experienced editors are horrid to newcomers. It is not quite clear how Flow is going to resolve any of these.

• 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)

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)

Effort justification

I see the following problem. Until (and unless) Flow is almost satisfactory for all processes used on talk pages, we (or at least I) will be unable to speculate as to whether it will ever be a satisfactory replacement. (The fact that templates are now substituted, as a gloss on the Parsoid modality, suggests that templates will always be substituted, which is completely inappropriate for any page which may need to be used to discuss tests of use of templates. There are other problems for which I cannot see viable solutions, which would prevent it being appropriate as a replacement for article, user, or template talk pages. There may be other problems I haven't thought of which would make it essentially unusable for most other types of discussion pages.)

As an aside, it appears that some WMF people have misinterpreted what I said was part of a MVI; that most templates be usable as templates (and copy/paste as templates) which displays more-or-less as they would in article-space. "Substitution" is not satisfactory.

That being said, the WMF teams will have to put a lot of effort into Flow before (I, at least) could support its rollout, except on some specialized discussion pages. Then effort justification steps in. The teams (and possibly WMF management) will be reluctant to admit that they have spend a lot of time and effort on something which cannot work, so they may force it into use.

Is there any process in place at WMF to counter this tendency? If not, I would vote for the immediate termination of the project, as, even if it cannot work, it's likely to be put into effect. — Arthur Rubin (talk) 11:47, 6 September 2014 (UTC)

Indeed, this reboot would be the appropriate time to have considered terminating the project. I wonder whether that was ever explicitly discussed? If not, then that would be strong evidence for AR's analysis. If it was, then it would be interesting to know which stakeholders were involved in the discussion and to see some documentation of the outcome. Deltahedron (talk) 12:33, 6 September 2014 (UTC)

Reference does not support contention

So I just watched this video File:WMFUsability_highlights_explain.ogv which is listed as a reference purporting to support the need for flow. If there's anything about talk pages in it, I missed it. NE Ent 12:04, 6 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)

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. NorthAmerica¹⁰⁰⁰ 04:50, 7 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)

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. Monty₈₄₅ 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)

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)

Communication and action

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

• Revert the Flow Echo change? (Note that, even ignoring the general unwantedness of the whole change, it is really causing problems for people, see e.g. Wikipedia:Village pump (technical)#dead-end message
• Delete the new Flow test pages?
• Respond to the many questions asked here the past week?
• Explain your view on what happened here?

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)

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)

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 ([26]). But these can not be found in the user contributions when searching for the Topic namespace (e.g. [27] or [28] or [29] 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. [30] or [31] or [32] - 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, [33], 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)

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)

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:

• Flow is not at all ready for being exposed to new users. There's still a lot of time to discuss, develop, test, fix and deploy any new watchlist/notification system (in that order!), if one is deemed useful at all.
• If new users should learn how to use Wikipedia, they need to learn how to use their watchlist. Echo can help with that, for example by giving notifications for new watchlist entries in the beginning when those are rare, offering links to the watchlist, to a watchlist tutorial and a way to turn off this type of notification (and please make the links look like links!). But Echo should not be used instead of the watchlist for Flow activity, that's unpedagogical for new users and confusing/annoying/disrupting for anybody else.

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)

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" [34]

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)

Formal request to roll back the change that introduced the "messages" to Echo

Formal request.

Since [35] (early September 2014), notifications (Echo) was changed to introduce a new default "messages" page for Flow notifications. Flow notifications are enabled by default in your preferences. Because this produced problems and errors for a number of people, while having little to no benefit for most others, the WMF is asked to undo this change (not patch it, simply reverse it) and to keep it off enwiki until there is consensus to enable it again. Fram (talk) 17:17, 8 September 2014 (UTC)

Background

Problems with the new Echo for Flow have been noted here, on my talk page (User talk:Fram#You mentioned me?, User talk:Fram#Echo valley, User talk:Fram#Flow testing, User talk:Fram#Flow and notifications, and at WP:VPT#dead-end message (perhaps elsewhere, these are the ones I easily know of).

The first complaints were raised before this was rolled out, after user-testing at mediawiki, e.g. WT:Flow#Problems accessing mediawiki flow page - and too many Echo notifications. User:DannyH (WMF), Product Manager for Flow, answered there on 27 August: "Yeah, we're trying out a new way to handle notifications for Flow pages. The new system just launched on Thursday, and I'm really glad that you've brought up the problems." But a week later, this was rolled out (in a slightly less buggy version) anyway. DannyH said on 28 August "We're holding back the latest version of Echo so that it doesn't deploy on Wikipedia this week, so we can fix some bugs and make some more changes. " but it was then deployed anyway without getting any consensus, and with complaints from multiple people. Just scroll to the above page and look for Echo or Notifications... The deployment was announced on 5 September by DannyH in WT:Flow#New topic notifications change. There was immediate protest. DannyH has not responded to this though. Fram (talk) 17:40, 8 September 2014 (UTC)

Discussion

• Oppose this use of Echo. It is very irritating to see Flow stuff there and essentially makes Echo useless. I only want to see watchlist stuff on my watchlist, not at Special:Notifications. --Stefan2 (talk) 17:29, 8 September 2014 (UTC)
• Turn off the default, keep the option. I honestly haven't found the notifications issue to be bothersome, but others have, so I'm not opposed to turning off this default setting, particularly as it's not useful for most folks right now. There aren't that many places to tinker with Flow anyway and only a handful of editors are actively testing it. That said, I'd like there to be an option to keep this setting (or rather, its upcoming patch per DannyH (WMF)'s comment below) on in preferences rather than reverse it wholesale for the sake of local cases that are still using it and willing to provide feedback (i.e Wikipedia talk:WikiProject Breakfast, Wikipedia talk:WikiProject Hampshire and the testing page we have operating at the Co-op). I, JethroBT ^{drop me a line} 20:28, 8 September 2014 (UTC)
• Turn off by default until it functions more sensibly The simple act of being pinged from a flow page resulted in a modification of my notification drop down to by default show the flow notification, even when I have no remaining flow notifications and have regular notifications. I had to disable it to restore functionality. Why can't flow messages just go through echo like every other message? Speaking as a software developer it is better to use an existing system than the duct tape another system to the side of it. Chillum 04:41, 9 September 2014 (UTC)
• Disable or at least default to off. I got a confusing message that said Fram had mentioned me in a deleted conversation. When I figured out it was Flow, I disabled Flow notifications in my preferences. I thought that would be the end of it, but then I had the same problem as Chillum. Annoying the userbase with buggy beta features is not going to help retain users. NinjaRobotPirate (talk) 02:22, 12 September 2014 (UTC)

Current status

We released a new version of Flow/Echo code to enwiki earlier than we should have. There are bugs, and features that aren’t fully cooked. I’m sorry that we pushed this out too fast, and created some irritating distractions that got in the way of people’s editing work.

Having read lots of feedback and seen the reported bugs, we talked as a team about whether to roll back the latest version, or move forward with bug fixes and retuned features. Rolling back would probably cause more problems than it would solve -- some of the reported bugs are already fixed on Mediawiki, so we can get things on enwiki fixed faster if we deploy those, rather than roll back to a week ago.

Our plan is to backport some more fixes to Mediawiki later today, and if those are stable, then we’ll move them to enwiki tomorrow afternoon.

Meanwhile, there are two things that you can do if you’re finding the current system too distracting right now:

• There is and will be a lot of testing done on the test/sandbox boards. If you’re getting bothered by notifications to those boards, it’s probably a good idea to stop watching them for now.
• You can also turn off Echo notifications for Flow in your preferences. (There’s still one bug that shows up even if you’ve turned them off -- it’s in the list below.)

Here’s the current status, as I know it right now.

The following items are planned for Mediawiki later today, and then enwiki tomorrow:

• Make the Alerts tab the default when you open the flyout, unless you’ve only got new Messages notifications and no new Alerts.
• Email notifications bundled per topic, limited to once every four hours.
• Bundling “created a new topic” Echo notifications, so you don’t get multiple notifications for the same board at once.
• “No formatting for notification” errors displayed in the notifications flyout.

Other bugs we’re fixing, but may not be out tomorrow:

• If you’ve never had Flow notifications, don’t make the Alerts link clickable.
• Swap the color of the Messages and Alerts tabs, so the clickable link is blue. The active tab shouldn’t be clickable.
• Monobook: Can’t hide topics, because the modal dialog is grayed out.
• When you create a Flow topic and mention a user in the first post, that user gets two identical notifications.
• With Flow notifications turned off in preferences, a mention on a Flow post still sends a notification.
• Monobook: Messages/Alerts text in flyout is too small.
• Monobook: Page tabs are not clickable on Flow boards.
• Monobook: Watch star on Flow boards is in the wrong place.

There’s a balance between responding to questions and actually getting fixes and features tested and out -- so we might be slower in answering some questions. We’ll keep everybody updated as much as we can, and we really appreciate all of the feedback, ideas, and bug reports. DannyH (WMF) (talk) 20:10, 8 September 2014 (UTC)

Okay, it's the end of the day -- here's the list of fixes that are on MediaWiki.org now. Assuming it still looks stable tomorrow, these will get pushed to enwiki tomorrow afternoon (PST):

• Alerts tab is the default when you open the flyout, unless you’ve only got new Messages notifications and no new Alerts.
• Bundling "created a new topic" Echo notifications, so you don’t get multiple notifications for the same board at once.
• "No formatting for notification" errors are reported, but not displayed in the notifications.
• When Flow notifications are turned off in preferences, user doesn't get notification for Flow mentions.
• Email notifications bundled per topic, limited to once every four hours.

The other items listed above are still being worked on, and the plan is to get those out later this week. Thanks to all of the people who've posted bug reports, and I apologize for the distractions and inconveniences with this release. DannyH (WMF) (talk) 01:39, 9 September 2014 (UTC)

"we can get things on enwiki fixed faster if we deploy those, rather than roll back to a week ago." How is it faster to patch some bugs than to rollback the change completely? Is it so hard to roll this change back? Apart from that: "We released a new version of Flow/Echo code to enwiki earlier than we should have. " How is that possible, after the feedback you received, and the explicit requests not to release this? What is the purpose of anyone testing and giving feedback, if you are going to ignore it anyway, and only wil reply after you get a formal RfC on it? This really isn't workable. Please, just roll it back, patch it on mw, and ask to roll it out here once you think it is workable. Fram (talk) 04:36, 9 September 2014 (UTC)

"Having read lots of feedback and seen the reported bugs, we talked as a team about whether to roll back the latest version, or move forward with bug fixes and retuned features. Rolling back would probably cause more problems than it would solve -- some of the reported bugs are already fixed on Mediawiki, so we can get things on enwiki fixed faster if we deploy those, rather than roll back to a week ago." Can you indicate what problems would be caused at enwiki by rolling this back? Otherwise, this is just FUD.

"There is and will be a lot of testing done on the test/sandbox boards. If you’re getting bothered by notifications to those boards, it’s probably a good idea to stop watching them for now." If having a talk page with lots of traffic causes the echo's to explode, then the system of notifications is wrong. People are not going to unwatch AN or ANI or popular talk pages or GA/FA discussion pages or whatever. Similarly, I (and many other editors) have many, many pages on my watchlist. Getting echo's from all of them would be a disaster. When I look now at my watchlist, I have, from the last 72 hours (and showing every page at most once!):

• 16 changes to the talk namespace
• 88 changes to user talk
• 28 to Wikipedia talk
• 1 to Mediawiki talk
• 4 to Template talk
• 3 to Category talk

While not all of these would appear in Flow echos probably (but a number o non-talk pages would, like An and ANI), it still indicates how the system of Flow echos would swamp the standard, working Echo system.

Why are you patching something that most people seem to think is unwanted and fundamentally wrong?

"There’s a balance between responding to questions and actually getting fixes and features tested and out -- so we might be slower in answering some questions." If you would have tested (or listened), you wouldn't have had this many questions since. Please don't complain that your own mistakes and refusal to correct them have created extra work for you.

Please provide a compelling reason, apart from bruised egos, why reverting this change to Flow-Echo is so hard and out of the question. Fram (talk) 06:46, 9 September 2014 (UTC)

Note that, whe ngoing back to mediawiki after 1 week, I have 32 notifications for one page. Madness lies this way. Fram (talk) 06:49, 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)

Killer features

User:Erik Moeller (WMF) presents what he believe are or will be three killer features of Flow: [36] (for his full text, please read this link, the below is just a selection)

1) Fast interactions. The process of responding on a talk page is ridiculously slow (edit section, find place, indent comment, write comment, sign comment, preview, save, worry about edit conflict ..).

Problems: most of the problems given for old style talk pages are only applicable to the high-speed talk pages, for which Flow is particularly ill-suited (not enough indentation, no subsections, no indication of which post you are replying to, not enough flexibility and possibilities, much harder to keep track of pages on e.g. a daily basis, ...). Finding the right section is often harder with Flow than with normal talk pages. For most low-traffic talk pages, you don't get problems with find place or edit conflicts and so on.

2) Centralized conversation spaces. Flow's architecture is already cross-wiki; its UI is not. As pointed out, there are multiple cross-wiki discussions as well as mailing list discussions about this very topic. Wil suggested "Pick a conversation space and stick to it!". Well, wouldn't that be nice - if it worked in our universe. Except that we know it rarely does. People want to have discussions in their "home wiki", and we use mailing list threads like this for good reasons as well.

Cross-wiki discussions are the exception and are rarely needed. They also have their own set of problems, e.g. who are the admins on such a discussion, what with users blocked on one participating wiki but not the other, and so on. I have the feeling that it is not just the UI that isn't ready for this... A cross-wiki watchlist would solve most of the need for cross-wiki discussion spaces anyway.

3) Tags. The team hasn't decided if/how to implement tags yet. My own bet is that they could be a killer feature. Let people add/edit those right below the thread title with one click and see if they start using them.

No obvious reason why they can't be introduced in existing talk pages, if they are wanted. The suggested use seems to duplicate much of what certain templates already do. Has lots of potential problems though.

In any case, after more than 6 months of being live, only one of these has materialized, and its success seems to be limited: yes it's fast and easy (when you have found it, and it doesn't crash, and you don't want to add e.g. any wikimarkup), but in real life, it turns out to be way too limited and simple (in the negative sense). And it is extremely poorly integrated in the existing wikipedia structures (namespaces, history, contributions, administration, ...) So why would we have any confidence that the much more complex cross-wiki would be workable? We can't even do something simple as rename a Flow page, and it takes days to find someone to delete a Flow-enabled page... Fram (talk) 12:38, 9 September 2014 (UTC)

Fram, to be fair, there's a very obvious technical reason why those features can't be developed on top of current talk pages in an equivalent way - wiki text is not structured, so it's next to impossible to identify individual comments in a reliable way so as to copy them or associate tags to them. I agree that the Flow technology is poorly integrated with the existing mediawiki, though I hope that can be solved with enough time and effort. I'm waiting for a technical reply from Erik that would clarify to what degree Flow can be made to collaborate with existing wiki technology instead of completely taking its place. Diego (talk) 13:41, 9 September 2014 (UTC)

But Erik Moeller isn't suggesting hanging threads to individual posts either, he wants them "right below the thread title", which would be "right below the section header" in the current system. The system has no problem identifying sections (TOC, edit section), so it should be able to find all tags between a section header and the next header. Fram (talk) 13:47, 9 September 2014 (UTC)

Right, but that would make the possible functionalities more limited than what can be achieved with Flow. For example, a watchlist/stream that showed "all comments that newbies have tagged with the word 'help'" can't be achieved with templates. Diego (talk) 14:01, 9 September 2014 (UTC)

Cross-wiki discussions have additional problems not mentioned above:

• If a discussion on "wiki 1" also appears somewhere on "wiki 2", then you might accidentally reveal your IP address if your third-party cookie settings prevent "wiki 1" cookies from being accessed on "wiki 2". As an example, my third-party cookie settings prevent "wikipedia.org" projects from accessing "wikimedia.org" cookies, and vice versa.
• If "User:X" refers to one person on "wiki 1" but to a different person on "wiki 2", then participants in the discussion might find it unclear which "User:X" they are talking with. If mw:SUL finalisation ever happens, this problem will automatically go away. --Stefan2 (talk) 14:28, 9 September 2014 (UTC)

If it isn't going to be clear who you are replying to I can imagine there could be all sorts of problems. Is that really going to be the case? Dougweller (talk) 18:48, 9 September 2014 (UTC)

See mw:SUL finalisation#Status for their latest status. They're aiming for completion of the required tools, by the end of September. Actually unifying/renaming all the conflicting accounts will take a while longer, as it has to be done slow&surely with human oversight and attempts to contact all conflicting accounts. (I think they're roughly estimating Q3, so early-to-mid 2015, but it will take as long as it takes). Quiddity (WMF) (talk) 21:57, 9 September 2014 (UTC)

The real killer feature is genuine permanent links. Right now, links break when pages are archived. Oiyarbepsy (talk) 17:38, 11 September 2014 (UTC)

The real killer feature is that Article space = Talk space. This makes Talk pages a fully functional work zone rather than a crippled chat page. Alsee (talk) 13:38, 12 September 2014 (UTC)

Yes. --Pi zero (talk) 14:02, 12 September 2014 (UTC)

I don't see it a good thing that pages with completely different purposes work identically. For example, the "fully functional work zone" doesn't even have the basic function of permanent links. Not to mention that, once fully operational, wiki markup will work in post, so not sure what the advantage of the old way is in that case. Oiyarbepsy (talk) 14:48, 12 September 2014 (UTC)

I assume you don't perform a lot of maintenance tasks and keep track of large numbers of pages? When working on a huge amount of unrelated content, having a homogeneous set of tools that you can rely upon to be always available is essential to achieve efficiency. When all pages are based on a wiki model, you can always check for recent updates by comparing diffs between revisions, organize them with categories and templates, and create new complex workflows by combining those atomic tools in novel ways. All that will disappear with the current discussion-based model on which Flow is based.

They may or may not rebuild a subset of those tools that now are in frequent use (and given their very limited approach to storing diffs, it's most likely that they won't), but even if they do those tools will definitely work in a different way and such homogeneity will be lost. Diego (talk) 15:06, 12 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)

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

• How was it done? Was the page converted to non-Flow and then deleted? Were the Flow tools (deletion) temporarily enabled? Something else?

• The result is rather worrying. The edits to the page are no longer visible, not even to admins, and also don't appear in people's deleted contributions. This is obviously not good.

• Even worse: the edits to topics on that page still appear in e.g. a watchlist, and can be seen. E.g. this seems to be available to all (can a non-admin confirm this). Which means that deletion of Flow pages basically isn't working at all, you remove the edits from people's contributions but keep them visible and accessible, which is the opposite of what is wanted.

• Ah, I see from the logs that the page had been converted to non-Flow, and then deleted. The conversion seems poor (at first glance e.g. hidden comments are totally lost, as is the header) and loses all of the history, so no, the conversion tool isn't ready.

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)

• The usual method of deleting the Topic: portions of these claims to work, but then the page is still there (see deletion log. — xaosflux ^Talk 17:08, 10 September 2014 (UTC)
  • So even deleting the page (board) and the separate topics doesn't help. This gets better and better... (No offense to you, xaosflux, you are just doing what I would have done and have no responsability for the completely botched result). Fram (talk) 17:29, 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)

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)

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)

I am making a prediction.

This so-called "feature" is what is going to make the fork happen. I am predicting it. I don't want this on my talk page, or the talk pages of any articles I edit, as it is ugly, I can't see the source, it has this infinite scroll crap, I'm unable to customize my archives, I can't search the flow archives, if I want to demo complex wikicode on the talk pages, I am unable to. This just takes away so many features, and for what? So new editors can participate better? It's not that hard, you just type in your heading, and what you want to write. You don't even need to sign anymore, as Sinebot does that! {{ping}} is very helpful to use, yet this goes too far. This will be the straw the breaks the camel's back. Grognard 123chess456 (talk) 14:06, 10 September 2014 (UTC)

Actually, one of the key benefits of flow is that it will eliminate archives, so you'll have no need to customize them at all. You can create a link to a topic on a discussion like this (Can I opt-in at my talk page?), and unlike archiving current talk pages, the link won't break. As far as wikicode, I'm not sure why you need talk pages for that when you have sandboxes and user pages, and with flow, you generally won't need complex templates on talk pages. As far as eliminating signing, don't forget that the current system makes it very easy to impersonate other editors, something that will be essentially eliminated with flow. On the other hand you might be right - Spanish Wikipedia forked over the mere rumor of advertising, so I wouldn't put it past English Wikipedia to do something just as stupid. Oiyarbepsy (talk) 14:37, 11 September 2014 (UTC)

"As far as wikicode, I'm not sure why you need talk pages for that". This was explained at mw:Thread:Talk:Flow_Portal/Maths#Maths_32131 a year ago. It's because Flow is a device to, among other things, help people collaborate on writing encyclopaedia articles. Deltahedron (talk) 20:39, 11 September 2014 (UTC)

And how are you supposed to browse old discussions? Searching, yes, but that can't take you to a particular time (or, if it would, we don't know that because the WMF hasn't built the damn thing yet). You can't get a sense of the discussion history. At the very least, pagination of Flow boards with a functional TOC is the minimum required for past thread navigation.

As to forking – who'll host it? At any rate though, many users will boycott it. I already don't donate to the WMF because I don't want my money to be spent on this monstrosity. Then again, as we all know, kind old Jan-Bart doesn't care if people leave over Flow. BethNaught (talk) 14:44, 11 September 2014 (UTC)

I'm inclined to agree Flow will likely finish the sisterhood under the auspices of the WMF. If they play their cards cleverly (not that they've been clever about it so far), perhaps they can demoralize the community in small stages, and thus avoid a fork until the spirit of the movement withers and dies (like the urban legend about boiling a frog). There are imaginable scenarios in which, sooner or later, they effectively abandon Flow, but while imaginable, those scenarios don't look likely atm. --Pi zero (talk) 15:17, 11 September 2014 (UTC)

You browse old discussions same way as any news comment board - keep scrolling down and older posts load as you go. Pages don't "archive" as they do now, so if you need to refer to a discussion, you can use the topic wikilinks and they will remain valid forever (while current talk page section links break as soon as the page is archived). There is still a history tab if you're looking for a particular date but you're not sure what discussion it is. Oiyarbepsy (talk) 18:29, 11 September 2014 (UTC)

Have you ever tried doing such a thing while on a slow connection? Let's just say, I'm not a big fan of infinite scroll. This has been discussed several times by now, so I'm not going to repeat it all. Pagination and a table of contents do have some advantages and for some use cases a search engine alone will probably have some difficulty providing help. AFAIK pagination will have to be in place as a fallback for non-javascript environments anyway, so, why not at least offer it as an option to everyone (I'd be interested in seeing what will be used more)? --HHill (talk) 20:23, 11 September 2014 (UTC)

Good point. I personally have no problem with splitting into pages for people who want that option, as long as it's automated. Oiyarbepsy (talk) 20:34, 11 September 2014 (UTC)

Talk pages are not news boards, and many times I don't browse them as such. I rely heavily on the table of contents to skip all about subjects that don't catch my attention, and often jump randomly throughout the archives of an old long talk page to get a sample of the kind of discussions that are typical for such article. Sequential access is awful for those use cases.

Having permanent links that work from day one and don't break is certainly a nice addition. There's no drawbacks to that. Diego (talk) 15:16, 12 September 2014 (UTC)

@all: Pagination is already available for non-JS users (it's not beautiful yet, but it does allow loading 10 topics at a time).

The infinite-scroll default is going to be re-examined, but it ties deeply into a number of things such as archiving and topic-sorting, so Danny wants to get the upcoming ToC and Search into place, before looking at it again.

There is a ToC coming, in some form or another.

There are plans to examine the various ways we currently archive things (beyond my 2 sets of notes), as well as ways we might want to add to that ability. (Eg. the currentkly hackish {{DNAU}} for "sticky posts" and User:ClueBot III/ArchiveNow for "insta-archiving")

Everything marked "Experimental" in Wikipedia:Flow/FAQ#Components of the discussion system (and more!) is still completely up for discussion, and a few of them will be changing for sure. There's good news coming soon, on some of these other long-running questions. Quiddity (WMF) (talk) 01:04, 12 September 2014 (UTC)

@Quiddity (WMF): I've added a few navigation use cases that aren't well served by infinite scrolling+autoarchiving+search, see below. Diego (talk) 15:31, 12 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)

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)

Bots

Just a question, does this mean that message-leaving bots (antivandalism bots, bracketbot, message-delivery bots) will all need to be rewritten to use flow as well? And how will this be in the intermediate time, when some users use flow and others still the old talkpages? --Dirk Beetstra ^{T C} 09:10, 11 September 2014 (UTC)

In the long term, yes, as the WMF expects that the new software will replace current talk pages. In the meantime, bots will need to detect if a talk page is created as a Flow page or a Mediawiki page and use different APIs to change them. Diego (talk) 10:59, 11 September 2014 (UTC)

Facepalm. And detecting earlier warnings to editors (do we still have a 'history' to retrieve)? {{nobots}}? ... --Dirk Beetstra ^{T C} 11:03, 11 September 2014 (UTC)

The last I've heard is someone suggesting to keep a separate "meta" page with wiki format, for keeping track of all such content that needs to be archived for attribution and tracking of milestones; the proposal seemed to be well received by the development team. Which is an advance, since at the beginning of the project one developer in particular was adamant that editors would be forbidden from using the old style talk pages. Diego (talk) 11:31, 11 September 2014 (UTC)

... was adamant that editors would be forbidden from using the old style talk pages. I would like to see the link for that if you have it please, Diego. BethNaught (talk) 11:54, 11 September 2014 (UTC)

Thanks for asking that, I am also curious. Is (was?) that an argument similar to deployment of the MediaViewer? --Dirk Beetstra ^{T C} 12:11, 11 September 2014 (UTC)

Name the sin, but not the sinner. The scuffle happened in the context of a discussion where a couple of experienced editors commented that they always would have the option to ignore Flow and keep creating talk pages for discussion instead, and this developer implied that this shouldn't happen, ever. I have to correct myself though; I had misremember the exact strength at which the developer defended the replacement (he considered using both systems a bad, unfeasible idea, but didn't ever threaten to forbid it), but he made it absolutely positive that Flow was clearly intended as the only option for discussions in the long term.

As for bots, reviewing the archives I've seen a comment implying that bots should be able to handle Flow through the same existing API for editing comments; I don't know to what extent bots will need to be adapted, but if it supports the same interface, the change should not be as radical as I thought. Diego (talk) 12:38, 11 September 2014 (UTC)

From the current WP:Flow page: "At some point in the future, once the software is stable and a significant portion of active Wikimedians have had a chance to trial it and offer their feedback, we may mandate Flow on all discussion pages, but we have a lot of work ahead of us before that happens." (emphasis mine) So it looks like they hope that mandatory Flow will happen, but realise that stating that in such terms may not be universally welcomed... Fram (talk) 13:40, 11 September 2014 (UTC)

I'm disappointed you didn't provide the link; however, this different thread WT:Flow/Archive 2#WMF intends for Only VisualEditor to be usable on Talk pages under Flow; representative states he would "dearly love to kill off Wikitext". is instructive. Apparently we are supposed to have "Zen acceptance" that change is being forced upon us when we don't necessarily want it. That statement is offensive. BethNaught (talk) 13:47, 11 September 2014 (UTC)

@BethNaught: Wow, I'm pretty sure we'd all dearly want to kill off wikitext, for it is utter garbage, and replace it with a sane markup system that was designed (in the good way) and thought-out, rather than grown on top of its older incarnations like mold – but it is also clear to everyone that we can't do that without a massive effort and pain that makes it very much not worth it. That looks like an offhand remark and it sounds like really bad faith to treat it as "offensive statement". (For a technical correction, both possible Flow backends – wikitext and HTML – support templates as we know them and can be seamlessly converted to each other; I'm not going to dig down deep enough to find out if Jorm was wrong or if his words were misinterpreted, but such a conclusion is clearly incorrect.) Matma Rex talk 17:59, 11 September 2014 (UTC)

@Matma Rex: I was talking about the part where he told us to have "Zen acceptance", because I find it offensive to be told by someone who is supposed to work for us to suck it up when we're given something nobody has even asked us if we wanted. In any case, I disagree that wikitext is garbage – the only hard parts are tables and template syntax (as in parser functions and the like). BethNaught (talk) 18:11, 11 September 2014 (UTC)

When compared to other statements made by that particular contributor, it does not seem like an "offhand remark". Instead, it seems to reflect his attitude towards the rest of the community:

::And there you're wrong, and this may be why you seem to have difficulty communicating. Let me disabuse you of a notion: We are ''not'' your servants and never have been. --[[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 01:09, 15 October 2013 (UTC)

172.56.38.251 (talk) 18:32, 11 September 2014 (UTC)

It is not a problem, as long as it does not override old functionality: XLinkBot (one of the bots I operate) loads the last # diffs of a page, and parses the edits to find the 'highest' level spam-related-warning left and when (either by the bot or by humans - if a human left a {{uw-spam4im}} or the bot a {{uw-spam}} in the last hours and the editor continues, then WP:AIV is alerted and no warning is left; if there are none, the bot will be more friendly with the 'spammer'). Parsing the text of a page is useless - editors regularly remove warnings (their full right, it means they noticed the warning at least, the more reason to use a higher level warning). As long as the flow (no pun intended) can be parsed by a bot it is fine with me (well, sigh, I have to figure out HOW to parse it). Also, having a possibility to have a personal 'template' at the top would resolve the {{nobots}} issue. --Dirk Beetstra ^{T C} 11:52, 11 September 2014 (UTC)

Actually, the task you describe above would probably be a lot simpler since user would no longer be able to delete the warnings, as I understand it, so you probably wouldn't need to check the history at all. Oiyarbepsy (talk) 14:44, 11 September 2014 (UTC)

• Flow was originally intended to be not just a talk page system, but a workflow management system (hence the name). A year or so ago, there was discussion here and a summary "in terms of loosely-structured workflows, breaking them down to their components, and optimizing for the best possible outcome with software... and actually writing a workflow engine for every non-article page on Wikipedia. The former is what we're currently doing with Flow. The latter is where I don't want us to go; at least, not yet" [37]. So Flow is intended to cater for all the common components of work at a discussion page, which would currently implemented by bots, templates and so forth. Under Flow, all these ad hoc mechanisms devised over the years by the various communities will be replaced by components within Flow. The need for research into what these workflows might actually be was due to start a year ago. I see no evidence that it has actually been carried out: no substance has been added to m:Research:Wikipedia Workflows for two and a half years and mw:Requests for comment/Workflow was last updated eight months ago. The conclusion is that for the last year the Flow team have known they would need this information to design and implement Flow as a workable platform for discussion pages, and yet have done nothing to gather it. The result is that they simply cannot know what it is they are designing for. I have to say that this is merely what I can see as an outsider looking in, so would be happy to see that the research is finished, documented and ready to show to the community for review and acceptance. I would assess that even to document and redesign the workflow processes on one sort of Egnlish-language Wikipedia talk page will take some weeks of effort, and there are hundreds of languages and a dozen projects to follow. This seems ... ambitious. Deltahedron (talk) 18:48, 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)

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)

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)

Window Usage

Maybe it's me, but I dislike how Flow only goes halfway across the page. The usual rage page format goes all the way across, so I have two and a half inches left over on a laptop with Safari. Origamite^{\(·_·\)(/·_·)/} 16:17, 11 September 2014 (UTC)

See WP:Flow#Design FAQ. I know, I don't like it either. What would be good is if the WMF allowed it to be customised with user CSS. BethNaught (talk) 16:21, 11 September 2014 (UTC)

Also, I think that the "Watch page" star should be near the view history again, instead of at the top of the topic. I had to look for it. However, if the majority finds that preferable, okay. Origamite^{\(·_·\)(/·_·)/} 17:02, 11 September 2014 (UTC)

That is a fun read. I like best that the annoying whitespace is not only deliberate, but also an attempt to reduce my stress level. Maybe we can get pictures of cute puppies instead of whitespace to reduce our stress levels even further. —Kusma (t·c) 18:47, 11 September 2014 (UTC)

No! No! That's a horrible idea!! It should be kittens!! --Randykitty (talk) 19:30, 11 September 2014 (UTC)

Sheep would be more appropriate. --NE2 19:39, 11 September 2014 (UTC)

Lemmings (yes, I know, it's a misconception, which makes it doubly appropriate :-) ) Fram (talk) 20:37, 11 September 2014 (UTC)

The WMF could just set the default system font to Comic Sans. It's an extremely popular font, and should help with New User Retention. Alsee (talk) 22:53, 11 September 2014 (UTC)

@BethNaught: nothing should be stopping you from customizing it with your own CSS...

.flow-board, .flow-board-header { max-width: 1800px;}

worked for me, but it might need some tweaking. Legoktm (talk) 22:24, 11 September 2014 (UTC)

Bug with flow links and hovercards

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)

Development principles

Need a good laugh? Read WP:Flow#Development principles, and compare it to reality.

• "[...] we're keeping two things in mind while we're developing the Flow software. First: we are partners with the community on this. " Not. The WMF are the deciders, we are the cheap labour force.

• "Before and after we build things, we'll open a conversation about the feature. " Really? An annuoncement is not a conversation. In a converation, you listen to one another, you don't simply present a non-negotiable plan, and you asnwer questions.

• "Second: a lot of the work we're going to do, at least initially, is experimental: we don't know if it's the right implementation of a feature. If it's not, we'll be happy to roll it back." ...but the WMF are the only ones that can decide whether it is the right implementation of a feature (or even whether it is a feature at all), so even if everyone asks for it, they'll not roll it back when they don't want to.

Your roadmap is wrong, your rationale is sorely lacking, and your development principles are not worth they pixels they are shown on. Community engagement is dead, communication is (with one exception) a one-way street, priorities are dubious or non-existant. We have a Product Manager that with a straight face can declare that a bug is brand new, and when pointed out that it dates from February reply "I can't really speak to bug reports that were filed in February". Of course, how could we be so stupid, Flow people are unable to read archive pages, it doesn't fit in their worldview! They are probably equally unable to see the right side of the screen, or anything but the colon of their superiors. Fram (talk) 08:22, 12 September 2014 (UTC)

That last one about colons was uncalled for, Fram. BethNaught (talk) 08:24, 12 September 2014 (UTC)

You're right, I've removed my previous reply and struck the offending part, it's not worth it. Fram (talk) 11:31, 12 September 2014 (UTC)

Hey Fram -- regarding changes based on feedback: There are things we're already planning to revisit (indentation, editability of comments, others) based on feedback. Other than missing functionality/bugs we need to get to over time (and leaving aside for this purpose the discussion between whether a structured discussion system is a good idea or not -- that is a bigger conversation, and one I intend to continue to be part of), what do you see as the main pieces of feedback that have been ignored?--Erik Moeller (WMF) (talk) 15:57, 12 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)

Some use cases for non-linear navigation

Here are some workflows that I typically perform at talk pages and which are not well suited for infinite scrolling, though relatively easy with numbered pages. Let's see if Flow design can be made to support them well.

• Find the period of time when a talk page was most active throughout its history (for example, to track a time of fast article development and/or a controversial discussion). I often do this with a manual binary search through the archives.
• Get a random sample of topics that were discussed throughout the whole life of the page.
• Read the archives from oldest to newest (a simple reversal of the current ordering would allow this, but it seems developers didn't think it would be necessary - they even listed this requirement as a problem!).
• Read in order all the threads that were visible at the talk page on 31 Aug 2010 (i.e. those that were not archived at that particular time). This is useful when there is a period of large activity and you want to find out the most important discussions that took place around that time, without being distracted by those that were manually archived. Also, reading them in order is important because many discussions span several threads in sequence. Flow design, with their detached topics (that are automatically reordered) and no subsections, does not take this into account. (Although, thinking about it, something similar could be achieved by allowing threads to be displayed by chronological order, jumping to a particular date, and skipping discussions that were closed and summarized).

The infinite scrolling is clearly simpler than the current one, but for those needs it has been made too simple - those workflows are impossible to achieve through scrolling or simple search. Diego (talk) 15:27, 12 September 2014 (UTC)

Related question: will we have pagination for really long TOCs, like we do have paginated archives now? Or do we get the same problems of infinite scrolling and no random access withing the TOC? Diego (talk) 15:55, 12 September 2014 (UTC)