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)

@DannyH (WMF): After yet another week, I'll add my support to this request for justifaction of this remarkable assertion. Deltahedron (talk) 19:32, 12 September 2014 (UTC)

Mathematics problems

Tracked in Phabricator
Task T72187

Is mathematics supposed to be working? At mw:Talk:Sandbox, I found myself unable to reply (clicking reply did nothing) with a <math>...</math> formula: I could create a comment with maths in but the formula doesn't appear in the comment. This looks rather like the situation from last October [1] -- 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): [2] Of the last 500 edits to the Wikipedia Talk namespace, none (nada, nil, not a single one) got a "mobile edit" tag: [3].

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

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)

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 [5], 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" [6]. 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. "[7]

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 [8] "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. [9] 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: [10] 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. [11] 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,[12][13]

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 [14]:

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

The Flow architecture [21] 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)
• <s>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.</s> Victoria (tk) 14:47, 6 September 2014 (UTC)
• I will leave here the link to Erik's post at wikimedia-l [22]. 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)

I've unstruck, and thanks to Deltahedron for the message - I had misunderstood. Thanks, too, Ymblanter, for the comments - ultimately I believe what I wrote is to the point, but after reading the discussion on the mailing list you linked, I realized this discussion is simply cosmetic. The decision has been made; and in my view it's a decision based on a severe lack of hard data in terms of how content editors use article talk space. And I felt it particularly patronizing that Erik Moeller wrote the comments above without (apparently) the intention of responding. Because, as we now know, there's not a response. We're to get a structured system in article space, whether we like it or not, whether or not it facilitates content writing or building encyclopedic material, and what to me is deeply depressing is that my time spent here during the past some years is apparently considered of such little worth that if I disagree at all, if I suggest that perhaps pinning down user requirements might be a place to start, I'm told where the door is. I've basically decided to take that option and walk through the open door. I believe, strongly, the divide between paid WMF staffers and unpaid editors is now too great and too divisive. Victoria (tk) 16:19, 12 September 2014 (UTC)

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

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

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 [34] (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: [35] (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)

It's also fundamentally preferable to discuss technical issues with an article on a page where one can, routinely and without having to think about it, reproduce exactly the effect of any article markup under consideration for the article, and copy-and-paste between the two. --Pi zero (talk) 16:03, 12 September 2014 (UTC)

Well, we'll always have Draft space, I guess. In other wikis, it's a common technique to mix commentary with the knowledge that is being compiled in the page. Diego (talk) 19:21, 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)

Don't know much about programming, but I bet that this can be solved pretty easily by having a bot update any broken links. We don't need Flow for that. (Far as I can see, we don't need Flow for anything). --Randykitty (talk) 16:02, 12 September 2014 (UTC)

It appears that User:ClueBot III might do just that when it archives. But most of archivebots don't, and as far as I know, nothing is dealing with the thousands of broken archive links already around. Besides, bots are a hack, and something like this should be part of the software. Oiyarbepsy (talk) 02:57, 16 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)

Brandon is quite right: the WMF staff are not our servants. They do, however, work for us, the users who share and create knowledge [36]. Deltahedron (talk) 11:14, 14 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)

Easier .. the bot needs to check page histories on pages itself, it is hence built in, easier would be to leave it as is so I do not have to 'write' two different mechanisms for the two different namespaces. So it is not 'easier'. --Dirk Beetstra ^{T C} 03:31, 14 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)

My post at LilaTretikov's talk page has an overview of recent feedback that has been ignored. The posts of early February (archive 8, I think) also contain lots of feedback that has been ignored. Examples: admin tools (or the total lack thereof), history and watchlist issues, requests for explanations (from DannyH and others), Flow headers and their problems, subsections in Flow threads, undo and rollback, roll-outs and their reversal, testing (or the apparent lack thereof on the WMF side), ... Just look at this page, and look at all the discussions that had either no WMF involvement or where the WMF dropped out after some initial replies, often despite being explicitly pinged with further questions. Not just from me, often from others as well. Most of these are about either fundamental issues, or about serious bugs, so its hard to see why no replies are given. See sections like "Misconception: Mobile editing is the future for talk pages", "Why roll this out to other pages at enwiki?", "The Law of Unintended Consequences", "Communication and action", "Deletion of Wikipedia:Teahouse/Questions/Flow test", "A possible fundamental reason for many of the problems", but also e.g. the end of "Problems accessing mediawiki flow page - and too many Echo notifications", and so on. Occasionally missing a question, or perhaps mistakenly believing that a discussion has been answered or doesn't need an answer, can of course happen. But this is systematic. Fram (talk) 16:54, 12 September 2014 (UTC)

A list of comments awaiting response

• In answer to Erik's question "what do you see as the main pieces of feedback that have been ignored?" let me speak for myself. Here are some comments which have not been addressed. Hope that helps. Deltahedron (talk) 18:15, 12 September 2014 (UTC)

Thanks for the various responses. Deltahedron (talk) 06:29, 13 September 2014 (UTC)

Use cases

• 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". 11:21, 31 August 2014 (UTC) [38]

The main list of previously documented use-cases are at mw:Flow/Use_cases. The index of all Flow documentation is at mw:Flow/Pages. Quiddity (WMF) (talk) 23:30, 12 September 2014 (UTC)

Thanks for that. I see that the list was last significantly updated 14 months ago. Is this the list that the team is working from? Do you wish for further input or comment -- and if so where, I note that the talk page there is empty -- or do you regard it as complete? Deltahedron (talk) 06:29, 13 September 2014 (UTC)

Documenting design decisions

• 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. 18:06, 3 September 2014 (UTC) [39]

The index at mw:Flow/Pages, and the discussions on the talkpages, are the main onwiki repositories. I was initially trying to keep mw:Flow/Prior_discussion-thread-roundup updated, but that didn't work for long - partially because it was so time-consuming, but mainly because we all discuss a multitude of different issues in each thread. :-/

In addition to all that, there are the mailing lists (both public and private), the IRC discussions, the scheduled meetings (that I can attend as remote staff) and the unscheduled hallways conversations, plus discussions on Bugzilla and Trello (and formerly Mingle).

The good news is, we're migrating to mw:Phabricator over the course of the next few months (First RT and Bugzilla, then later on Trello and Mingle. Then eventually, Gerrit and Jenkins.) - that system will be tied into SUL, making Wikimedians' discussion of software much easier, and getting making things simpler for the developers. (In the short-term, it will make thing harder for some of the Product managers, because Phabricator's interface isn't as polished or complex as that in Trello/Mingle. But Phabricator is open-source, so feature-requests will be filed, and patches submitted. So it goes.) Quiddity (WMF) (talk) 23:30, 12 September 2014 (UTC)

I suggest that whem informal meetings and IRC chats produce decisions that are beyond the purely short-term, they need to be captured, for the benefit of the teram and the stakeholder community. Deltahedron (talk) 06:34, 13 September 2014 (UTC)

Mobile interface

• Do we not have a separate interface for article pages on mobile devices? Why was that option was rejected for talk pages? 17:06, 3 September 2014 (UTC) [40] and again 19:55, 5 September 2014 (UTC) [41]

I'm unfamiliar with mobile. (I don't even own a smartphone! Madness, I know...) Afaik, they had problems getting talkpages to work effectively, because of the header-templates, and the HTML definition-lists that we're using/abusing to create these indents. That's just a hazy memory though, I'll ask for confirmation. Quiddity (WMF) (talk) 23:30, 12 September 2014 (UTC)

Thanks, I look forward to it. Deltahedron (talk) 06:38, 13 September 2014 (UTC)

Wikitext isn't going anywhere

• I'm genuinely confused 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"? 20:27, 6 September 2014 (UTC) [42]

Much closer to the latter, but without the "end of time/heat death of the universe" clause. :) Quiddity (WMF) (talk) 23:30, 12 September 2014 (UTC)

Thanks for that. Deltahedron (talk) 06:34, 13 September 2014 (UTC)

Was termination discussed

• 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. 12:33, 6 September 2014 (UTC) [43]

This discussion from #Effort justification continued at #Substituting templates. I'll re-enquire for a listing of the pros/cons (technical and social) of live template updates. Quiddity (WMF) (talk) 23:30, 12 September 2014 (UTC)

Maybe so, but this question was not about templates, and that may explain why it went unanswered the first time. It is about the project in general, and it is not answered by that comment. Was terminating Flow explicitly addressed, and fi so, who was involved in the discussion and could we see the documentation please? Deltahedron (talk) 06:37, 13 September 2014 (UTC)

Fundamental flaws

• 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. 20:05, 9 September 2014 (UTC) [44]

Zero-tolerance for bugs on production wikis

• 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. 16:41, 10 September 2014 (UTC) [45]

Workflow research

• 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. 18:48, 11 September 2014 (UTC) [46]

The best overview I've seen of the abstracted idea of workflows, is Maryana's 2013 presentation (~30 min long) (slides). This seems to indicate that we don't need a huge quantity of workflow modules, we just need a few distinct but flexible modules that can be hooked together as needed by the local communities. (rather than re-creating the huge mess of modules/templates/categories/bots that Enwiki uses, at every other language (or sister project) that wants to grow and work in a similar way). I agree that it would be good to get this more detailed research going again, at least at a gentle pace. Quiddity (WMF) (talk) 23:30, 12 September 2014 (UTC)

I thought that was the case, but didn't want to comment without clarification. I have to say that this lack of research seems to me the single biggest risk to the entire project. Indeed I would go so far as to say that without a clear understanding of what the major workflows are and what is required to support them, then you literally do not know what you are doing. (I don't mean that as a comment on your competence, but on your strategy.) The slides you point to are nice, and have some good ideas, but they are the start not the end of the research you need: they have not been discussed with the community, who are after all the people who bult and operate the workflows. It is frankly astonishing that for over a year nothing has been done to gather this vitally necessary information, and no less astonishing that you feel so relaxed about doing it some time in the future, albeit "at a gentle pace". Without this knowledge, you have already failed. Deltahedron (talk) 08:28, 13 September 2014 (UTC)

Security loopholes

• [...] adding security loopholes rather than fixing existing ones seems an odd way to proceed. 21:44, 11 September 2014 (UTC) [47]

What's missing? A working communication process

@Erik Moeller (WMF): A mayor request that has made little impact is having a process in place that would ensure that requests from community members are being heard, AND allows those members to get timely feedback on whether and how they have influenced the development process (or not). For a project that attempts to improve communication within a huge community, it's ironic that information about development is being transferred in both directions in such chaotic and confusing way. There was a welcome improvement in tone with Quidity appointment as community liaison, but there's only so much one person can do. Sometimes it helps a little that the design and project tracking is held in the open, but links to Trello boards only go so far - that's a very low level view of the software evolution, one feature at a time and with lots of operational which is only relevant to the developers, and little in terms of explaining the purpose of such changes or ensuring they reflect the community feedback.

Ways to improve such communication have been suggested at this page in several occasions, but it has been most recently discussed at the wikimedia-l list this week. There Wil Sinclair posted a good analysis and suggestion for a way forward, though there's no evidence that it will have any further impact. Meanwhile, a couple of posts there set a tone that reflects the sentiment of many editors who follow the development closely ([48],[49]), and the outlook is not pretty. Diego (talk) 21:19, 12 September 2014 (UTC)

I just want to point out that I have been involved with beta tests and alpha tests before, and this is the only such project that has had any dialog whatsoever. Previously, I might submit a bug report, never hear what happened to it, occasionally get a thanks for finding it, but I've never had actual dialog with the developers as I do here. It is also worth noting that a lot of the unanswered questions weren't posted all that long ago. Can't a guy get 3 or 4 days to responds? Oiyarbepsy (talk) 00:47, 13 September 2014 (UTC)

That said, it would be helpful to have a better way of tracking or listing the issues brought up and their responses. A page like Wikipedia talk:Flow/user comments or the like that summarizes requests/bug reports and gives the current status of where they're going. Most of the existing flow project pages are far from providing this. Oiyarbepsy (talk) 00:47, 13 September 2014 (UTC)

Solving a problem by creating another

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

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

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

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

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

Hi Fram, right now the team is focused on the basics -- commenting, search, getting the watchlist/notifications distinction right, etc. That's why the use is at such a small scale. The post size limit should help in the context of small scale testing but may need to be revisited later, for the reasons you give and others.--Erik Moeller (WMF) (talk) 15:48, 12 September 2014 (UTC)

And those basics have taken what, a year and a half now (a year since the first release)? But in every roadmap and planning we get, in three months time huge progress will be made, and large amounts of things have been "finished" according to every roadmap, but still need small scale testing to get it somewhat workable, eventually, perhaps. Why are there three test pages on Wikipedia since February, when in September we are still doing small scale testing of the basics? Isn't that what mediawiki and test can and should be used for instead? I have no problem with the fact that you need to get back to the drawing board, but then do so, and don't continue the tests here as if this is ready for further deployment when the current deployment isn't even working as it should. Fram (talk) 17:03, 12 September 2014 (UTC)

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)

Simply a view from a Flow page at one specific point in time would be a basic requirement. As far as I can tell, one can't see how Wikipedia talk:Flow/Developer test page looked 4 days ago or 3 months ago. That's not even asking for "compare two diffs", the difference between the page at time A and time B. Fram (talk) 17:14, 12 September 2014 (UTC)

I have no hope that requirement can be ever achieved, as there's no such thing as a Flow "page" - as far as I can tell, the way they've built flow is by creating a new wiki page for each comment. However, finding out what comments have appeared in a board since the last time you visited any of its topics should be achievable, and showing just those comments while hiding the rest (the closest possible thing to a diff on a Board); after all, they need to detect those comments in order to update the Echo notification. Diego (talk) 19:38, 12 September 2014 (UTC)

@Fram: This should be fairly easy to implement, since all we need to do is hide all posts after a given date. -- Ypnypn (talk) 19:47, 12 September 2014 (UTC)

• I think this raises the interesting question of the balance between the extent to which Flow is intended to duplicate existing talk page structures and systems and the extent to which it aspires to control them. Is it a design principle that every workflow in existence will continue to be possible under Flow, with only minor technical modifications -- or will the Flow team take the opportunity to radically simplify, prune, remove, merge or otherwise rewrite existing workflows? In other words, how often are we going to see an exchange along the lines of "I'd like to be able to do X for purpose Y" "No, we've decided you don't need to do that"? Deltahedron (talk) 20:06, 12 September 2014 (UTC)

During development we'll see a lot of "I'd like to be able to do X for purpose Y" (with varying Yes and No answers), but if it reaches "final deployment" that's pretty much the end of that. No one is going to initiate an impossible effort to get developers to rewrite the code every time someone get an idea to experiment with something new. Our current methods are organically grown out of clay. Our fundamental workflow is to build articles out of Wiki, to build discussions out of wiki, to build workflows out of wiki. Flow takes away our clay home and attempts to impose metal hallways that resemble our current workflows. But the fundamental workflow of building and reshaping things out of Wiki is broken. Alsee (talk) 21:18, 12 September 2014 (UTC)

This comment [50] suggests that design, development and deployment are being taken in an order different to the one I would have employed. Deltahedron (talk) 21:28, 12 September 2014 (UTC)

I guess this highlights the power of the wiki-model. The software does very little: a page of text with markup stored as successive revisions. With this model the use-cases are determined by conventions of the users of the software. Its relatively easy to implement a new use-case all it takes is a new page of policy. While some tasks may take a little longer to perform most tasks as possible. This offer great freedom for the users, and shows the simple idea which has made wikis successful. I'm a little worried that we are forgetting the the spirit of wikis and the freedom it allows.--Salix alba (talk): 22:02, 12 September 2014 (UTC)

You might want to strike out "we" and replace it with WMF. Alsee (talk) 01:25, 13 September 2014 (UTC)

Workflow research 2

There are a number of workflows, standardised actions, messages and so forth that are currently handled on various kinds of talk page by a variety of templates, bots, social conventions and so forth. Flow is going to have to make it possible to perform all those actions, although not perhaps in the same way. Given the desire to roll Flow out to a variety of production wikis by the end of December (Q2 in WMF-speak), it must surely be the case that the Flow team are confident that all the major workflows on those pages will have been incorporated. It would be interesting to see the working list of what those workflows are, what the dependencies are, and what actions will be required of the participants, bot maintainers, template authors and so on. The reason I suggest this exposure is that contributors here and in other locations may be able to help if, as is within the bounds of possibility, the list is not quite complete, accurate or up-to-date. Deltahedron (talk) 19:43, 12 September 2014 (UTC)

Note: Discussed further at #Use cases and #Workflow_research above. (This section retitled to fix duplicate). Quiddity (WMF) (talk) 20:57, 15 September 2014 (UTC)

Interesting software

And an interesting commentary [51] about the roadmap: This is a process of discovery, learning and growth. That's how interesting software gets built. Considering that Flow is going to be imposed on us all, whether we like it or not, and we are going to have to use it to build an encyclopaedia and numerous other projects, I'm not sure that being "interesting" is high on my agenda. Could we have well-built, effective and efficient, please?

However, one concrete question. Decisions are based on a lot of factors, including active work with community partners and stakeholders, feedback from community members Who are these partners and how are you engaging with them? Deltahedron (talk) 21:25, 12 September 2014 (UTC)

Roadmap update

I updated the documentation page with a more realistic version of a roadmap that gives a more accurate expression of how building a project like this works. I know that people on this page (and in discussions elsewhere) want more honesty from me as a PM. That's actually how I want to live, being more natural and real about the work that we're doing. I've gotten more distant and "professional" over the last couple weeks, because that's what happens when people are angry at you, like, all the time about everything.

I'm sick of the way these conversations have been going lately; I'm sure everyone here is. It's boring and awful, and we don't get anywhere. So I'm doing a bit of a reboot in my communication style, and I'll see how it works.

So, the roadmap. Like I said, this version is more realistic, and actually reflects the current state of play. I've been a product manager working on ambitious user-facing features on a MediaWiki platform for about five years, and I've built big crazy features like this. The roadmap is more of a discovery process than a strict plan. I can talk intelligently about what we're working on for the next couple months. Beyond that, I know the general direction that we want to go, but the actual details get fuzzier the further out you go. This isn't a trick. This is actually how it works.

I want to talk more with the people who are posting on this page, for several reasons. For one thing, it's just fun, and it's a part of my job that I really like. Also -- you guys have good questions and ideas, and you challenge me, and that's productive and cool and it makes everything better. But I can't do that if I'm just going to get yelled at, and if everything I say is picked apart. It just doesn't work. I'm not feeling sorry for myself here, or expecting anybody else to feel sorry for me. This is my job; I choose to do it, and this is part of the job. I'm just saying that I can be as honest and real and receptive as the conversation allows for. I'm going to hit save right now, before I talk myself out of it. DannyH (WMF) (talk) 21:32, 12 September 2014 (UTC)

Hi, DannyH (WMF).

I've thus far taken the academic route to Computer Science, myself, but a friend who went into industry advised me if I wanted to know what it's like, read Dilbert, that's exactly what it's like. Of course, that's industry, with its authority-drive hiearchy; wikis are a bit different, with a bottom-up structure (recalling the old Cold War-era saying, that in capitalism man exploits man, whereas in Communism it's the other way around). And you have the fun of working for an authority-driven hierarchy that sees itself as in charge of a collection of wikis whose communities consider themselves to be in charge, which presumably means you get to enjoy the disadvantages of both, at point blank range.

I do notice you claimed, in your 'roadmap' edit, that there isn't a "plan". That's probably how it looks from inside. Indeed, speaking for myself, I'm skeptical that there'd be a "plan" in the sense of an Evil Plot spearheaded, no doubt, by Dr. Evil; that sort of "plan" is close kin to the kind of supposed conspiracy that usually can't work in real life. However, there's another kind of conspiracy-like phenomenon that's pretty common: organizational machinery moving in a direction that gets going and then has legs, resulting in something being imposed despite nobody specifically wanting it; surely there'd be a Dilbert about that.

I know of one, pretty ironic, context within the wikimedian sisterhood where Flow would —if sufficiently improved— possibly be an improvement. On English Wikinews, each article has two associated auxilliary pages: a "collaboration" page and an "opinions" page. The collaboration page is an ordinary wiki page, used for discussion in the construction of an article, and we've got a strong consensus that it should be an ordinary wiki page; that's internally the Talk: page. The opinions page is for readers of the article to discuss the issues raised by it; and that uses LQT. We all hate LQT with a passion, except that it really is a great improvement for the opinions page. Before LQT, the opinions pages were ordinary wiki pages and Wikinewsies had to pour a lot of time and effort into cleaning up the mess created by readers who, for the most part, had no idea how to use wiki markup and had neither time nor motivation to learn how; why should anyone have to learn how to use wiki markup simply in order to discuss the issues raised by an article? If they want to contribute to the wiki, then and only then is there a reason for them to learn wiki markup.

We've discussed Flow, and whether or not it would actually be an improvement for our opinions pages to use Flow instead of LQT. The current sense seems to be that we're better off with LQT than with Flow; but with improvements to Flow, who knows. And this is ironic because the Foundation is notorious amongst the non-Wikipedian sister projects for not giving those sisters software support. (Wikinews does techically demanding stuff that relies heavily on all the customized semi-automation we've got, and badly wants more; for my part, I've put three years and counting into developing the sort of tools I reckon we, and the rest of the sisters, need.) --Pi zero (talk) 23:08, 12 September 2014 (UTC)

Pi zero, I don't have any experience with Wikinews and having an extra Opinion board next to our Talk pages. Could you please give your opinion on what would happen if the current Flow roadmap proceeds? Specifically, if the Talk page and Opinion page were merged into a single Flow page and placed next to the articles for Republican Party and Democratic Party? My guess is that work on those pages would become impossible. Alsee (talk) 02:21, 13 September 2014 (UTC)

I believe there's a solid consensus at en.wn that using Flow for collaboration would be a disaster. I'm inclined to agree with your assessment that it would make it impossible to collaborate. And yes, those two pages do look like pretty good examples of why. --Pi zero (talk)

A lot of people think you're on the wrong track, and it's not something that can be fixed with some tweak the current Flow project. Here on Wiki we're creators and builders. We want flexible tools. We need a collaborative environment. Wiki is the clay we use to build articles, to build discussions, to build workflows. We build it and reshape it. It's like you see that we built a car and house out of legos, so you come along and take away the legos and try to give us a cast-metal car and a cast-metal house. Instead of trying to take away Wiki work&discussion areas, how about offering us interesting new tools, and letting us figure out how (and if) we want to use them. Alsee (talk) 01:57, 13 September 2014 (UTC)

Alsee, do you think this might be an interesting direction for tool development? --Pi zero (talk) 02:52, 13 September 2014 (UTC)

Pi zero, Yep. Anyone with the skills/interest can build or modify something, and if it's good, everyone else can copy/use it. Pure Wiki. Alsee (talk) 03:08, 13 September 2014 (UTC)

DannyH, first, thanks for engaging. Like your Biblical namesake, walking into the lion's den takes courage.

You say "Beyond that, I know the general direction that we want to go." The crux of the biscuit is, What does "we" mean?

This is the only question that really matters. The rest is mundane technical detail. Short Brigade Harvester Boris (talk) 03:45, 13 September 2014 (UTC)

This^. The "we" being used is a few WMF managers. The community-we see fatal problems in YOUR direction, WMF. Your direction is not our direction. Alsee (talk) 03:14, 14 September 2014 (UTC)

• Speaking for myself, I have no problems with plans: they have served me well. A plan is a framework to hang the engagement wth the community on. Naturally much of the discussion takes place round the WMF water-coller in San Francisco, or IRC chat rooms. If that is the planning process, then the vast majority of the stakeholders are going to be, and feel, disenfranchised. Collaborating together on the plan is the very expression and instantiation of stakeholder engagement. A plan also holds the team to account. If the plan is simply to deliver whatever the team feels able to deliver, then they can't fail -- which is another way of saying they can't succeed either.

I was struck by the comment Anybody who tells you that there's a hard and fast plan for a project like this is probably trying to sell you something. Well, the team is trying to sell us something -- it's trying to sell us Flow. In one sense we have no option: WMF have decreed Flow and when it's implemented we will have no choice but to use it, so selling isn't necessary. Or is it? Because, you see, we do have a choice: the choice to leave (and Jan-Bart has made it clear that he's happy for us to do so). If the team fails to sell Flow to the users, and the users leave, then they may succeed in delivering the product but fail at the goal that the product is there to achieve, which is editor retention. Deltahedron (talk) 07:02, 13 September 2014 (UTC)

I think Flow will succeed or fail based on the quality of the feature, and the feature has a lot of work ahead. It is absolutely true that the feature as it currently exists today is not good enough to deploy much further than test pages. But the feature will get better, and people will see that as it happens.

I completely understand the fear that WMF will deploy a devastatingly insufficient version of Flow, too far and too fast. That's a perfectly reasonable reading of what happened with the VE and Media Viewer releases, and it makes sense that people are looking at Flow with the same kind of dread.

If the question is, "What are you going to do when you impose a broken feature that ruins everything, and the encyclopedia collapses?" -- then there's not really a way that I can respond to that. I understand where it's coming from. I can't fix that right now. All I can do is be honest about the work that my team is doing, and work on improving the feature. DannyH (WMF) (talk) 18:15, 15 September 2014 (UTC)

A different direction

Suppose, just for a moment, that Flow, rather than being an alternative mode for a page, were something that could be embedded on a page. That is, one would have an ordinary wiki page, and somewhere on it one could have some markup (for example, perhaps a magic word) to embed a Flow discussion forum. Each community would then have the option of deciding whether, where, and how to embed such things.

This, hypothetically, could be a win–win: For the wiki communities, it could transform Flow from a straightjacket that would prevent the community from functioning, into an additional degree of flexibility that the community could explore using to enhance its functions. For the Foundation, it could transform the Foundation–community interaction on Flow development from adversarial to mutually supportive, with both sides looking for ways to make Flow more useful. If Flow isn't made sufficiently useful, it doesn't get used, and that wouldn't be fatal for the communities or for the wikis or for the Flow project itself: it would just mean looking for ways to make Flow more useful, a process in which communities and developers would be on the same side.

Issues that immediately leap to mind:

• How to arrange that a flow forum would look natural both when it was the only thing on a page and when it shared the page with other material.
• How to arrange for a TOC on a wiki page to include content from a flow forum. Likewise for something akin to an archive menu.
• Whether it should be possible to have more than one Flow forum embedded on a page.

--Pi zero (talk) 13:32, 13 September 2014 (UTC)

This would be tricky to get right, but may be viable. Certainly better than what they're planning now (a dangerously misdirected chat board with a crippled undefined "scratchpad" to be bolted on.) It also reminds me of the various requests that Media Viewer be changed into something that can be embedded into a page, perhaps with an image gallery attached. Alsee (talk) 03:22, 14 September 2014 (UTC)

(edit conflicted!) Pi zero this is one of the most sensible ideas I've seen on this page. As soon as the "Discussions cannot be embedded yet." condition goes away, should be trivial for a page to have a Talk: and perhaps a Flow: page, and just embed the Flow page on the talk page in a frame if you wanted it. — xaosflux ^Talk 03:27, 14 September 2014 (UTC)

Very good idea. Various embedded discussion tools (Flow as a structured discussion, or maybe a poll tool) could be used in addition to what we have now. That way, Flow would not have to destroy the flexibility our current talk page system has, while still making some discussions easier. (In my mind, flexibility is more important than structure, but I understand that some people disagree with that). —Kusma (t·c) 06:53, 14 September 2014 (UTC)

What use would the Flow page, or part of the page, be likely to be put to? If Flow hinders or makes impossible the various modes of working that are required to collaboratively write and edit articles, then all that work would remain at the wikitext part of the page, and the Flow page would become a sort of chat room for people to discuss the article topic at large. I believe that this is exactly how Wikinews works, but not Wikipedia, where this is explicitly not what the article talk page is for. Is augmenting an encyclopaedia article with a chat room likely to make it easier to write the encyclopaedia, or to assist in the goal of retaining old editors and attracting new ones? Deltahedron (talk) 09:18, 14 September 2014 (UTC)

I don't know. But it is certainly better than replacing the current discussion pages with a chat room. To be useful for anything other than chatting, Flow would need to offer features that make it a superior tool for things like RfCs. I can't imagine something like a Requested Move discussion (which has "votes" and "comments" that belong to each other in some way) in the current Flow software. —Kusma (t·c) 09:32, 14 September 2014 (UTC)

That we can agree on. By the way, the use cases are at mw:Flow/Use cases: Requested Move do not seem to be listed. Deltahedron (talk) 11:02, 14 September 2014 (UTC)

(edit conflict) In principle, Flow shouldn't need to work as a chat room; this is just the way the development team has decided to build their discussion application on top of the platform. Technically, at its core Flow is a collection of individual comments, each one with its own individual history of edits. The way these comments are related to each other is called a definition; they're thinking of building definitions for polls, RfCs, and other discussion workflows, but not for collaborative editing of the page as a whole.

We have to convince developers that we really need a "wiki definition" that allows us to work with content they way we're used to, with a common history for edits from all editors, as the functions of a wiki are essential to the existing methods by which we build and maintain the encyclopedia. Diego (talk) 11:13, 14 September 2014 (UTC)

What the Flow team need as a matter of urgency is a workable description of some of the major wiki ways of working on en.wp. The Use cases page I pointed to is woefully underpopulated. Perhaps contributions from here would be helpful. Deltahedron (talk) 11:19, 14 September 2014 (UTC)

If the developers do not already know that, then the best-case scenario for Flow is that it is a huge waste of time and money that will never be widely rolled out. —Kusma (t·c) 15:46, 14 September 2014 (UTC)

In practice, Flow's current incarnation will make the pages more like a chat room then anything else, and maybe there is use for it; by having the talk space support BOTH flow and traditional talk (perhaps side-by side layout style, especially with Flow wanting to limit its pixel width) - slow moving discussions, notices, tags, etc could stay in a prominent location while also allowing the chat style flow---and in my opinion a page should default to not having the flow at all, but having an easy way to 'start a flow' alongside the general talk would be a better introduction to any of the benefits of flow that are not being considered right now. — xaosflux ^Talk 14:08, 14 September 2014 (UTC)

Why don't we use talk pages for most of Wikipedia and flow for those pages meant to be a chat room... oh wait, no part of Wikipedia is supposed to be a chat room. How about we just stick with the talk pages that have worked great for the last decade? Chillum Need help? Type {{ping|Chillum}} 15:58, 14 September 2014 (UTC)

I tend to agree with you, but if Flow is inevitable I'd rather see if be a bolt on instead of a complete replacement for what works so well. — xaosflux ^Talk 16:03, 14 September 2014 (UTC)

• DannyH (WMF) and/or Quiddity (WMF) any feedback on this section? Would this type of use even be entertained (as opposed to "Flow or Fork")? — xaosflux ^Talk 04:17, 15 September 2014 (UTC)

We definitely need a way for Flow to exist alongside other page elements. Right now, I'm thinking about approaching it the opposite way -- to have editable wiki areas as elements within a Flow topic page. But it's early days on that concept, it's still just speculation at the moment.

Flow also needs to have a way to support votes, as Kusma mentioned. The RfC-style use case is one of the harder ones to approach, and there's still fairly basic elements to build, like a table of contents. So it'll take a while before we get close to the RfC functionality.

As I wrote in the thread just above, I totally understand why people are afraid that the current version of Flow will suddenly be deployed on RfC pages, and why you're asking me to respond to the threat of forking. There's lots of work still to come before it would be ready to go anywhere outside the test pages. DannyH (WMF) (talk) 18:57, 15 September 2014 (UTC)

Hi, DannyH (WMF). Some thoughts on flow-embedded-in-wiki versus wiki-embedded-in-flow. (Where I'm coming from: I'm a CS PhD with one foot in hacking and the other in theory, dissertation in programming language design, who's spent the past several years approaching the problem of wiki-enhancing software design by immersing myself in the wiki I want to enhance. What I came up with as a concept, which I see as potentially invaluable to all the wikis (not just my home wiki) once the i's are dotted and the t's crossed, is described at n:Help:Dialog.)

There are two ways to approach flexibility, the general road and the specific road.

Wiki markup takes the general road. One of the key reasons it's so successful (sic: wiki markup isn't the cause of any of the modern flaws of the movement) is that it's pretty much infinitely maleable. Someone else here has been comparing it to clay, which imho is apt. What you can do with it is limited mainly by your imagination. And that includes what you can do in a discussion on the talk page of an article; I'll come back to that point in a moment. When you add feastures to the system, your purpose is to add power, withoug bolixing up the flexibilty of the whole.

From what I understand of Flow, it takes the specific road. A system like that tends to start out powerful in some particular way, but inflexible. When you add features to it, they're typically meant to add flexibility as much as power. And you'll never get to the sort of flexibility that the general road starts out with. No matter how many "use cases" you come up with, there's always something else left out; you're stuck perpetually playing catch-up, trying to add parts of the intrinsic flexibilty of a general system. When using wiki-markup talk pages, any time an unusual case comes up, you simply use the natural maleability of wiki markup to achieve whatever is needful — and there's no way to anticipate everything that might come up. A specific-road system can't duplicate the sponaneous flexibility of a general-road system.

Particular features within a general system, such as wiki markup, are —well— particular. But a successful particular feature within such a system preserves-and-enhances the flexibility and versatility of the whole. It tends to require deep insight to fashion a new feature so that it will synergize that way with the whole; it's easier to just tack things on for particular purposes, which has too-often happened in the past of wiki markup; but that's at least as likely to happen, perhaps more so, when features are added to a specific-road system. And the system on the specific road has a starting handicap on flexibility that it could never fully compensate for even if all its added features were wonders of elegant design.

Hence, I reckon Flow can't get to where it needs to be by replacing the wiki structure and then trying to add stuff back in; it needs to find a way to fit itself into the wiki structure — and then really work on making itself fit smoothly within that structure. So to me, Flow-embedded-in-wiki is the option that has the potential to lead somewhere good (though nobody's claiming this will be easy). --Pi zero (talk) 22:06, 15 September 2014 (UTC)

@DannyH (WMF): This talk page has laid out some well-founded arguments of why Flow, even when it reaches its feature-complete status and fulfills the vision that the development team has presented, will still not be an adequate match for our needs. Some editors participating in the discussion have solid professional knowledge of software development and the principles of groupware, and we can analyze and evaluate the possibilities not just of the current tool but of what it can become. Your words are well meaning, but do little to dispel our worries. The fact remains that you misunderstand our concerns as mere evaluations of the current status of the tool (which are not) and you haven't acknowledged the reasons why we prefer a different approach to Flow, instead of the one that has been laid out so far.

I have a background in information architecture and knowledge capture, and I completely subscribe to Pi zero's analysis of the benefits of a flexible tool that follows the "general" approach, and the advantages of a true wiki as the basis for such platform; certainly, n:Help:Dialog looks much more promising than Flow from a philosophical point of view. Yes, that approach may look like heresy to a developer well-versed in industry standards, but then those standards evolved to satisfy the needs of corporate applications with a few predefined business workflows, not world-class collaboration platforms trying to capture the world's knowledge. ;-) Let me add that a tool which allows representation of unstructured an semi-structured content will always be a better match for knowledge capture in its early stages than a fully structured tool: having to match the structure imposes a burden on users that can leave some knowledge outside of the system, because of the friction entailed in adjusting to the expected format. Wikis, as friction-less tools for capturing knowledge, are the most advanced systems that humanity has devised for knowledge and content capture (only on par with the empty page and ink), as the structure of information can be built incrementally instead of imposed by the software.

We have suggested ways in which Flow could be made to conform to our expectations as users experienced in the usage of the tool for collaboration and coordination; unfortunately it seems impossible to reach you and make you recognize and value these suggestions, as you provide no feedback that these have been heard; and everything suggests that the decision on how to build Flow was made long ago, without input from the community and before initiating the project to understand the particular ways that we use talk pages, and that there's no way that early decision can be influenced by what you find along the way.

You ask us to trust you that you'll be able to develop a capable tool, yet give very little on what to base such trust. Please, address at least the concerns about the communication between the community and the development team, and improve the channels we use to follow track of the project, as we have repeatedly asked. Start by designating a single centralized official forum on which all decisions are communicated and all doubts can be asked (which are now scattered between this page, mediawiki, the mailing lists and the bug tracker), and update it thoroughly with your current understanding of the requirements and the existing community processes. Make a priority to improve your understanding of the existing flows for both new and experienced editors, above any development of new features, and make all decisions subordinated to gathering data that can support those decisions - maybe using some partial development as a prototype to gather some new knowledge, but not as a final feature. This is the only process I foresee that can followed so that we gain your trust. Diego (talk) 23:11, 15 September 2014 (UTC)

I totally understand what you're saying, and I wish that I had time to fully engage with this discussion. Unfortunately, right now I've got limited time for large-scale philosophical discussions. We're a very small team, working on a very large and complicated project. Quiddity and I are fielding feedback at multiple wikis and mailing lists, as well as triaging bugs, testing code-updates and getting some more features designed, built and out the door. We're reading everything, but we can't scale to reply to every comment.

A lot of the philosophy and architecture for Flow was hashed out with Jorm and others over the last couple years. My job at the moment is to take the current philosophy and architecture, and turn it into a working feature. I think the way that I can be most helpful to this project right now is to actually do more work on the feature, so that we have more to talk about. DannyH (WMF) (talk) 00:33, 16 September 2014 (UTC)

Thanks, Danny, that's the kind of honest answer that we needed. At least we now know that our concerns were heard, although there's little that can be done about then. With this confirmation of what we suspected, it's clear there is little use in trying to push Flow to meet our expectations in the medium term. I hope there will be a later revision, after the current minimum viable product is rolled out according to the original, limited plan, and that there will be time in the future to embrace this talk about the possibilities of the software, that is meant to completely replace the tools we have now but which was never debated as such. Diego (talk) 06:26, 16 September 2014 (UTC)

@Pi zero: Thanks for this analysis, it's a very interesting read and I agree with most of it, though not with the final conclusion: I don't see a principal difference between flow-embedded-in-wiki and wiki-embedded-in-flow in terms of the practical functioning of a page. There are technical limitations at the moment (we don't have scratchpads in Flow yet and the ones in the making are limited by parsoid), but that's a problem with the currently existing code, not with the general idea.

Plus, IIRC the plan for Flow is not only to develop additional workflows besides the simple conversation module we see now, but also to implement a way to modify and add workflows on-wiki, without need for software upgrades (@DannyH (WMF): correct me if I'm wrong). So at that stage Flow could do everything our current talk pages can do (by having each topic a wiki-scratchpad), plus it could do more, plus it would have additional flexibility for teaching it even more.

That said, once Flow is in reality developed enough, such that flow-embedded-in-wiki and wiki-embedded-in-flow makes no difference from a user's point of view, then it doesn't matter which one we use, so I don't oppose either model. But I realize that's the far future we're talking about here. I don't know which variant would be easier to implement and/or more useful as a mid-term solution. — HHHIPPO 07:29, 16 September 2014 (UTC)

@Hhhippo: Well, there's a clear practical difference between wiki-inside-Flow and Flow-inside-wiki that makes the former more limited, which should be easy to understand and doesn't depend on philosophical lucubrations: a wiki scratchpad embedded within a Flow board will not enjoy any of the purported benefits of the structured platform - no content ownership, no clear separation of individual contributions, no avoidance of edit conflicts, no notifications and subscription to just a part of the updates, no automated or semi-automated reordering, filtering and classification. The idea of the scratchpad as it has been suggested amounts to exactly what we have already, with the same reliance on old unadorned wikitext, just presented within a new context surrounded by forum-like threads. If there are no improvements to the collaborative writing experience, why should we care about it? It's clear that this option is easier to implement by developers and that they will favor it along the way, but it's not the best fit for our needs; a structured board where each comment is a wiki scratchpad does not allow for all the possibilities of current talk pages.

On the other hand, the capability to embed Flow comments and threads within a wiki page would open a large range of possibilities for a groupware tool: real time collaboration, review comments embedded alongside article content, those are options that have been suggested as welcome applications that would provide a real enhancement to current talk pages (or even article and draft space!), but they require that Flow content is subordinate to a free-form whiteboard structure, not that it imposes its own.

With respect to the planned workflow-building module, everything points toward it being oriented to communication and community-building workflows (the points of pain of our current wiki talk pages), but there are well-founded doubts that it will be flexible enough to support the other types of current workflows, as Pi zero has explained well. Diego (talk) 10:34, 16 September 2014 (UTC)

Snapshots

This comments on two threads above, so I thought I would start a new one.

On Wikipedia, it's relatively easy to see what a talk page looked like at a given time (although changes in templates may change appearance).

In Flow, it's relatively easy to see what a message looked like at a given time (although whether it was hidden or no at the time may require a separate search); in the present configuration, the "template" problem.

An approximate look as to what a thread looked like at a given time would be to "remove" all messages after that time (ignoring actual message editing, which the Foundation seems to be doing), but, determining which of the remaining messages were hidden is difficult. [On the other hand, if messages were hidden for good reason, there could be a problem.]

Determining what the entire talk page-equivalent looked like at a given time is, because of the additional level of complexity, would be almost impossible.

But that last is what would be required to determine whether the article reflected the consensus at the time. — Arthur Rubin (talk) 19:40, 13 September 2014 (UTC)

Tag this one as a bug We need history links for every page, including talk page. The links in the page history don't actually link to the page version, but to the topic namespace, which is completely against expectations and against how every other wiki page history works and not as it should be. Oiyarbepsy (talk) 01:02, 16 September 2014 (UTC)

BOLD edit to main page. Flow does not encourage meaningful conversations that support collaboration.

The main goals for the Flow project are:

• to make the wiki discussion system more accessible for new users

 Confirmed

• to make the wiki discussion system more efficient for experienced users

 Inconclusive /  Unlikely

• to encourage meaningful conversations that support collaboration

 Not possible

• It appears the Community and WMF employees generally agree that putting a chatboard on articles will draw a large volume of unconstructive posts.
• Every proposal to deal with this issue involves some method to suppress voices you consider unhelpful.
• Opposing sides routinely consider each other unhelpful.
• If opposed sides stop listening to each other then collaboration and consensus building become impossible.

• Result: Endless edit warring, or majority POV dominance with wild POV flipflops whenever the balance shifts.

Does my edit draw any support? Does anyone feel a need to revert and discuss? Alsee (talk) 21:28, 15 September 2014 (UTC)

Just pointing out the message box at the top of the page is now incorrect... BethNaught (talk) 21:41, 15 September 2014 (UTC)

Good point, I missed that. If anyone restores my edit, or otherwise edits the page, the infobox should be updated. Alsee (talk) 22:18, 15 September 2014 (UTC)

I do, and did. WP:Flow is a WMF page, basically; its purpose is for the WMF to describe their goals, progress, etc. with Flow. It's not for the community to voice their displeasure with or objections to it. There are lots of other pages for that; this one, for example. Writ Keeper ⚇♔ 21:52, 15 September 2014 (UTC)

First, I note that you did not disagree with the content of my edit. Second, if the WMF does not wish to engage in collaboration and consensus seeking, then perhaps they shouldn't be posting on Wikis. Third, if this page is "owned" by the WMF then you had no more business editing it than I did. As far as I'm aware ENWikipedia has no policy nor mechanism to give WMF employees an exclusive lock over any page. I am not going to revert war with you, but perhaps someone who considers my edit productive will restore it. Alsee (talk) 22:12, 15 September 2014 (UTC)

I didn't say it was owned by the WMF, I said that its purpose is to provide the WMF a place to say things about Flow. Mixing community opinions into it dilutes that purpose. There is value in allowing the WMF a place to provide to us their official party line, for us to better critique it. Writ Keeper ⚇♔ 22:19, 15 September 2014 (UTC)

BRD is a proven method for breaking logjams and trying to develop a consensus. There are a significant number of editors who agree with the general content of my edit. Having someone outside the WMF revert the edit utterly defeats the process. Alsee (talk) 22:30, 15 September 2014 (UTC)

Huh? That doesn't defeat the process, that is the process. You boldly edited, I reverted, and now we're discussing it. That is how BRD works, is it not? Writ Keeper ⚇♔ 22:39, 15 September 2014 (UTC)

No, our conversation is clogging the page discussing process. It is not productive towards the underlying issue. Alsee (talk) 22:58, 15 September 2014 (UTC)

If you wanted to start a discussion on whether Flow is a good solution for those goals, maybe you should have, y'know, just started a discussion about it, instead of inserting your assertions into a page that's not set up for discussion. Writ Keeper ⚇♔ 23:16, 15 September 2014 (UTC)

((edit conflict)x3) I would suggest that the second point (that you've marked as "Inclusive/Unlikely") should instead be marked as "Too early to tell" - There's a hell of a lot of work to do, before we'll all know if the modular workflow plan will bear fruit. See mw:Flow/Release planning for many of the planned features, and various ongoing mailing list threads at wikimedia-l (particularly "Let's fix templates", "To Flow or not to Flow", "To Flow or not to Flow -> it does not flow", and "To Flow: on featured article discussions"). If we're just talking about 'who can edit a post', that's likely to change as soon as there are designs/code available for better transparency in the post, of who exactly edited the content (ie. original author, or someone else - like LQT does but better. Which will be better than the current impossibility of knowing whether something has been edited, from the talkpage itself.).

For the third point, I'm not sure what exactly you're concerned about, though I would guess it is to do with the hide-button; please elaborate? (I'll add that they plan to insert "Hide" links in the same place in History pages as "Undo" would be, and to make the content actually disappear from the page, as "undo" does. Danny explained some of this above at #Wiki misconceptions in the Hiding/refactoring section, with updates to that plan at https://trello.com/c/V8Flrczl/)

I also join in encouraging discussion here, rather than inserting commentary directly into the documentation page. Please and thank you! Quiddity (WMF) (talk) 22:31, 15 September 2014 (UTC)

We are getting close to WP:POINT here. The edit look a lot like trying to prove/illustrate a point. You could, uncharitably, characterise it disrupting the purpose of the page. As the software is still very much in development reviewing where it has met its goal is premature, fine to have this discussion on the talk page, but not yet on the project page. A review section on the main page or a subpage like the Wikipedia:VisualEditor/Known problems page might be appropriate.--Salix alba (talk): 22:56, 15 September 2014 (UTC)

@Quiddity (WMF), I had already read almost all the links you provided, and did just check the two new ones. No help. Try putting a Flow chat page next to the Democratic Party page, or Republican Party page, or Obama's page, or the Fox News page, or Evolution. You will rapidly get hundreds or thousands of unproductive or inflammatory posts per day. People arguing the topic, or merely wanting the page to present a totally one sided partisan view. Put a Flow page next to a page like Expelled:No Intelligence Allowed when it was a fresh release and you'll get THOUSANDS of rabid posts per day. The only proposal you have is to hide/mute/whatever posts that look like crap. Aside from the impossible labor needed to sort through and hide all the crap, editors will be hitting other editors they consider unhelpful, and newbies will get hit, and everyone who gets hit will be enraged for being "censored". Unless you have some NEW idea, replacing Talk pages with Flow appears to be incompatible with a collaborative place to develop pages. Alsee (talk) 23:29, 15 September 2014 (UTC)

Everyone keeps asserting this without evidence. I don't think it's the case. First and foremost, everything I've seen says that talk pages will remain explicitly separate from article pages, flow or not. So, the flow page will not be "next to" any of these articles. We're not placing them at the bottom of the page like news sites do, we're keeping it separate. Inappropriate posts are rare now, and in flow, we would deal with them the same way as now - either delete outright or just hide, or some other possibility might be developed. Finally, most people can see the tone of a discussion board and choose what they post accordingly, which is why Slate and YouTube's discussions are so radically different - here, hiding will set the tone, and users seeing nothing but productive posts will mostly follow suit. I just don't see your nightmare situation happening. Oiyarbepsy (talk) 00:55, 16 September 2014 (UTC)

The problems with the article feedback tool reinforce the above statement, rather than undermining it. The article feedback tool was placed at the bottom of the article, which invites those who just finished reading to spout whatever garbage is in their brain. Scrolling back to the top requires extra effort and deters the morons. Oiyarbepsy (talk) 00:57, 16 September 2014 (UTC)

@Quiddity (WMF): Thank you for your candid statements. I'd like to talk about what you said here:There's a hell of a lot of work to do, before we'll all know if the modular workflow plan will bear fruit. If it doesn't, Flow is sunk as as it stands it can never support RfCs, RfAs, the proposed warning/blocking interface, and all the other workflows which need easy customisation, refactoring, sectioning etc. Should that be the case, there would be no point in rolling it out because at some point every talk page may need a non-chat workflow. This is why I think production wiki rollouts are premature – we don't even know if Flow is viable yet. BethNaught (talk) 07:40, 16 September 2014 (UTC)

• I have disliked the concept of flow from the moment I laid eyes on it and still do not understand how it is beneficial to wiki. Do the good outweigh the bad? If so how? - Knowledgekid87 (talk) 02:30, 16 September 2014 (UTC)