Wikipedia talk:Flow/Archive 13

Archive 10

Archive 11

Archive 12

Archive 13

Archive 14

Archive 15

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)

@DannyH (WMF): After two more weeks, I'll assume that this question is being deliberately ignored. That does not bode well for a constuctive engagement between the developers and the rest of the community. Deltahedron (talk) 20:27, 27 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) [1]

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) [2]

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) [3] and again 19:55, 5 September 2014 (UTC) [4]

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) [5]

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) [6]

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) [7]

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) [8]

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) [9]

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) [10]

Another list

Some more questions that have disappeared, or are otherwise going unanswered. Deltahedron (talk) 07:09, 28 September 2014 (UTC)

Passed milestone

"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? [11] 07:04, 29 August 2014 (UTC)

Interesting software

Decisions are based on a lot of factors, including active work with community partners and stakeholders, feedback from community members [12] Who are these partners and how are you engaging with them? [13] 21:25, 12 September 2014 (UTC)

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 ([14],[15]), 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)

Wouldn't it be nice if...

I thought it might help to start a section for suggestions along the lines of "Wouldn't it be nice if ..." Deltahedron (talk) 11:22, 28 September 2014 (UTC)

• On reaching the bottom of the page, while waiting for another chunk to load, a little message appeared saying something like You have reached topic number 123 out of 456, now loading numbers 124-156. Deltahedron (talk) 11:22, 28 September 2014 (UTC)

• There were a sinple visual indicator that a comment has been changed after it has been replied to. Deltahedron (talk) 11:23, 28 September 2014 (UTC)

Okay, here are some of mine:

• If topics posted on another user's talk page automatically appeared on your own? (Many similar ideas are worthy of its own section, actually)
• That a post stated the number of users that thanked the poster, making it similar to "like" or "+1"? (Actually, I can see people disagreeing, but please start a new section for this, don't put it here)
• That very long post titles were automatically shortened when hidden or collapsed (like this one)?
• That the heading on the topic page was identical to the wikilink to it (you know like every other page on Wikipedia)? Oiyarbepsy (talk) 15:53, 28 September 2014 (UTC)

Bug reports at mw:Talk:Flow

I have reported a number of bugs at mw:talk:Flow, but it isn't clear whether or not the reports are being picked up. Quite often there's no comment at all, or comments only from other users; and a couple of them seem to have been fixed but without any feedback to say that they have even been addressed, let alone resolved. I would have thought it was common courtesy to acknowledge such reports, prefereably with a Bugzilla or similar reference, and again to mention when they have been resolved. Perhaps I am wrong in assuming that developers want bugs reported at that page? If so, perhaps we could be told where the reports should go. Oh, and please don't tell me to do it on Bugzilla. Deltahedron (talk) 18:38, 27 September 2014 (UTC)

Update: I have been told at mw:Topic:S350su8j3v2p0e3d that recent bus reports can be tracked at this url. Apparently the Flow team are backlogged on replying to bug reports in various venues. Deltahedron (talk) 18:48, 28 September 2014 (UTC)

Compact nesting

I wrote up some thoughts about nesting here. I think it is possible to display complex discussion threads in a way that fully preserves their logical structure, but doesn't need more horizontal space than Flow uses now. Comments are welcome! — HHHIPPO 15:02, 28 September 2014 (UTC)

Nifty concept. Andreas JN466 21:04, 29 September 2014 (UTC)

I heartily endorse Hhh's concept. Oiyarbepsy (talk) 21:57, 29 September 2014 (UTC)

Very nice. In a final version, we'll need clearer visual cues, but the concept's great. -- Ypnypn (talk) 22:03, 29 September 2014 (UTC)

We just got hit by a live example Flow Failure Case

A hyper-partisan website with substantial traffic just LINKED DIRECTLY TO ONE OF OUR TALK PAGES because it wanted its own ATTACK-PIECE inserted into our BIO OF A LIVING PERSON.

The current talk page is currently struggling to sort out what, if anything, should go into the article. The issue here is not about the specific content. I hope I don't have to explain to anyone why this is event is a Very Bad Thing, how this would become common if Talk were ever replaced with Flow, and how the impact would be catastrophic under Flow. Alsee (talk) 14:07, 21 September 2014 (UTC)

I'm not the hugest fan of Flow in its current form, but I can't see how that's a flaw of the new technology. Our talk pages have always been public access, and external sites linking to them for engaging their followers is not unheard of. Do you mean that with Flow it would be easier for readers to participate in the talk page? That could be dealt with semi-protection, the way we do now with current talk pages in such cases. Diego (talk) 14:18, 21 September 2014 (UTC)

That's exactly the point. Having a modest barrier of technical competence does have the advantage that mobs can't be driven to swamp talk pages so easily. I agree that protection is a solution, but that requires the canvassing be noticed more quickly lest there be serious disruption. Moreover, with Flow we don't seem to have proper deletion/reversion yet, just glorified hatting, so as it stands the mob would at a minimum succeed in scarring the page. BethNaught (talk) 14:29, 21 September 2014 (UTC)

Protecting the article merely freezes in place whatever version is there when the issue is noticed. And lets assume the article page is rolled back to an earlier version. A Flow talk page would be utterly unusable if there were hundreds or thousands of posts per day from an attack mob, all screaming a radical attack position claiming "consensus". These people HATE Neil_deGrasse_Tyson. They want nothing more than to turn the Bio page into a rabid attack piece. I'm saying these sorts of things will spill over to any related pages. I'm saying it will become an unrelenting problem on any remotely controversial page. I'm saying it will be a problem on any normally non-controversial page that some oddball website decides to link. And even without links, I think Flow chat pages will draw a very disruptive level of people more interested in pushing their pet agenda than in building a Neutral Reliable Verifiable Encyclopedia. Alsee (talk) 16:52, 21 September 2014 (UTC)

This is what Flow is intended to do: to make it easier for all and sundry to edit talk pages. You may think that's a Bad Thing: I may think that's a Bad Thing: but WMF think it's a Good Thing. Indeed, the WMF Board chair has expressed his concern that Other internet projects (not limiting ourselves to websites) are passing us by left and right [16] and [17]. Deltahedron (talk) 16:55, 21 September 2014 (UTC)

I suspect that we all agree that we want to make the system easier (or, "more efficient" rather) for good faith contributors. The complexity arises in how we dissuade the bad-faith contributors from even trying, or, preferably, educate them into becoming good-faith contributors, with minimal effort on both our and their part. This is the origin of essays such as WP:CIR (and pages in the see also), and dozens of Civility essays/guidelines, from WP:BITE onwards. How much patience should we have, with newcomers who aren't tech-savvy, or aren't policy&guideline-savvy? They have to be willing to follow our policies, but are they also obliged to (immediately) learn how to decipher this wall of text in the editing window?

Technical competence (or a willingness to learn the intricacies of deciphering wikimarkup) is not necessarily correlated with "someone who will be a good contributor to an online knowledge curation project", nor with "someone who wants to point out a mistake, but is too cautious to edit the article, and too overwhelmed to edit the talkpage". This technical barrier (and a too often/rapidly hostile & confrontational linguistic environment) is the usual explanations behind the gender-gap (and to a lesser extent the age-gap), and also the systemic bias that we've always had problems with.

Does the technical barrier stop more stubborn and irredeemable fools (the type who blunder along until something either works or breaks), or does it stop more hesitant people who might've become good (regular or occasional) editors but don't want to commit to reading a manual (and suspect they have/ought to) before changing anything?

[two imperfect generalizations, as generalizations tend to be, but you probably get what I'm trying to say :) ] Quiddity (WMF) (talk) 23:06, 22 September 2014 (UTC)

The website is partisan, sure, but not trolling, and reading the article, I'd say the author has a point. Back to flow - I'm curious how many of the contributions to the talk page consists of signing posts, fixing colons, and moving comments from top to bottom. Oiyarbepsy (talk) 17:47, 21 September 2014 (UTC)

If you're talking about Tyson's, I haven't analysed it. (I didn't realise you meant his talk page at first.) However, I just analysed the 50 edits to this page immediately preceding the edit I am currently making. 40 were to post a comment, 7 were to self-edit a post (a feature Flow doesn't have), 2 were by archive bots, and one was a reply/sign-unsigned combination. BethNaught (talk) 19:05, 21 September 2014 (UTC)

Oiyarbepsy The website is a wild troll. It directly attacked our Talk page while describing us as "Religious Fanatics", attacking an individual editor while stalking and linking to their Userpage here and their offsite pages. Furthermore he goes on to flamewar a stream of random internet commenters at the Fark message board. That's not Journalism, that's a half-baked blog with a mentally unstable author flamewarring at random internet nobodies. The fact that his previous blog-post was flaming at someone Notable doesn't elevate his stature. @BethNaught Flow does support self editing comments. Alsee (talk) 00:13, 22 September 2014 (UTC)

It doesn't look like there were a lot of outside commenters anyway, the discussion was mostly civil, including most of the IP comments which likely are from the Federalist, so the fears seem totally overblown. Totally moot and doesn't tell us anything about Flow or Wikitalk. Oiyarbepsy (talk) 19:12, 22 September 2014 (UTC)

"It doesn't look like there were a lot of outside commenters" - Thanx for confirming the very argument I was making. Only handful of people malevolently attempted to disregard and violate virtually every Wikipedia policy on a Biography of a Living Person. I find it utterly ASTOUNDING that you think a high traffic website could link to a flow chat board and the number of malevolent posts wouldn't increase. I EAGERLY invite a test. Throw up Flow boards next to all our Talk pages and see what happens. We can run this test right now. As long as the Talk pages are still in place there is no problem tossing up incomplete-functionality Flow boards. Alsee (talk) 13:12, 25 September 2014 (UTC)

Modest barrier of technical competence

"Having a modest barrier of technical competence does have the advantage that..." Wait - doesn't a barrier of technical competence go against everything that "free encyclopedia that anyone can edit" stands for? Oiyarbepsy (talk) 18:59, 27 September 2014 (UTC)

This is the contradiction at the heart of Wikipedia. We proclaim that Wikipedia:Competence is required but that only refers to the arcane behavioural rules and conventions which on Wikipedia stand in for the largely absent editorial guidelines and policies. In particular, subject matter expertise is not required, or even actively deprecated (see this satire). The WMF seems to desire many more editors, not only irrespective, as heretofore, of any expertise on what they are writing about, but also now lowering the bar on the ability to place text on the page. That's the direction things are going in. Ignore it or loathe it, you can't like it. Deltahedron (talk) 19:23, 27 September 2014 (UTC)

It is true that anybody can edit Wikipedia. It is also true that people cannot reasonably expect to be able to stroll up here, read not a word of help pages, editing advice or content guidelines, and write a good encyclopaedia article in the Wikipedia manner. The WMF is very keen on building tools like VE (which, for the record, I do support, as it will help newbies with genuine skills) and Flow, which on the whole encourage not the inculcation of quality values and mission commitment but drive-by editing. Flow is like a chat room or forum: good for chatting, not good for complex discussions about how to improve an article, let alone other community processes. If (when) Flow comes in, bringing an influx of half-literate netizens and canvassed mobs, we could well face our own Eternal September. BethNaught (talk) 19:59, 27 September 2014 (UTC)

TL:DR Everybody can edit, but they will always need to learn how first. BethNaught (talk) 20:00, 27 September 2014 (UTC)

• I don't think it is helping our case to make editing, in particular editing of talk pages, artificially difficult. The type of technical competence that helps with operating our editing systems is not necessarily correlated with the social competence and subject matter expertise that helps making main space edits or talk page comments constructive. That said, with a lowered barrier for editing, we have to make sure all necessary admin tools are implemented before any roll-out to actual production pages.

Yes, Flow is not good enough to replace all our talk page workflows yet, that's why we don't use it for that. We can spend our time and energy complaining about this, or we can try to make constructive suggestions, and help Flow to become what we need. It's in a way like Wikipedia itself: some people like complaining about how this or that article is wrong and how unreliable Wikipedia is. Others come here and build an encyclopedia.

Instead of being afraid that Flow will let too many strangers into our sacred halls, we should make sure that Flow will support us in welcoming the constructive strangers and ignoring the trolls. — HHHIPPO 21:09, 27 September 2014 (UTC)

I agree with you that technical skills ought not to be the primary requirement for writing this encyclopaedia, which is why I support VE – to be sure, many content contributors have been turned away by wikicode. I have also suggested that VE be used to help people edit talk pages more easily. But to make talking in Flow even easier than making a YouTube comment... seriously? I think the WMF's strategy of encouraging huge masses of occasional casual contributors instead of focusing on attracting committed subject experts (not that I am one, but I still can write a decent article from time to time) will not help the quality of Wikipedia. BethNaught (talk) 21:17, 27 September 2014 (UTC)

How is Flow easier than YouTube? I agree that a flood of nonconstructive comments would make it difficult to have constructive discussions. But again, if we want to limit the number of contributors, is the requirement of certain technical skills to operate the discussion system really the right filter? Are the trolls really those who are even stopped by that filter? Do they care if the convention is top- or bottom posting, signing or not, or how to indent their comments? Or is it not the potentially constructive people who don't post their comments, because they're not sure how to do it right, and they'd rather be silent than doing it wrong? — HHHIPPO 21:47, 27 September 2014 (UTC)

One way that Flow is easier than YouTube is that you don't have to register first. On the other hand, registering hasn't done anything to increase the quality of discussion at YouTube, 4chan or autoadmit. More significant is what the community will tolerate. Those three websites have horrible discussion forums since they can basically do anything, which won't be the case here. Oiyarbepsy (talk) 00:13, 28 September 2014 (UTC)

Beth, where you are wrong about "casual contributors" is that the distinction between casual contributors and committed editors doesn't really exist (experts fall in both categories). Yesterday's casual editor is today's committed one, and in some cases a committed editor will scale back involvement and become more of a casual editor. It's a spectrum, and every editor drifts from one end to the other, so the best way to get committed editors is to get casual ones, and encourage them to edit more. Oiyarbepsy (talk) 22:06, 29 September 2014 (UTC)

I suppose I did create a false dichotomy there, and you're right, it is probably preferable to attract a hundred people who write one article per month than one who spends all their time on Wikipedia. Time commitment doesn't really matter in content creation, the amount and quality of content created is what matters. However, I still believe that Flow will open the doors to people using WP as a forum and extra admin work (by a decreasing number of admins) will be needed to stop them, while the workflows and processes of the community will be hindered unnecessarily. Also, to attract content creators, surely the best thing is to first finish VE, to help them add it? BethNaught (talk) 06:38, 30 September 2014 (UTC)

Actually, finishing visual editor before flow would probably be the worst possible combination. Imagine hundreds of new editors that can edit pages but can't discuss them. That would create a series of revert wars - actually, I've been in revert wars from users who probably didn't understand talk pages. Flow should have come first. Oiyarbepsy (talk) 14:37, 30 September 2014 (UTC)

You have a valid argument, although I maintain VE could be used on talk pages to maintain useful document model workflows but allow easier participation in discussions. At any rate, I'm going on a break in a few days, so I'll see where things are at when I return. BethNaught (talk) 21:24, 1 October 2014 (UTC)

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

Formal request.

Since [18] (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)
• Fram, [[User:|DannyH (WMF)]]I think that we should just remove Topic:* namespace from watchlist by default for those users who chose to enable Flow notifications. Gryllida (talk) 00:03, 26 September 2014 (UTC)
• Oppose Per Stefan2. --Rsrikanth05 (talk) 11:26, 2 October 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)

Internal error on a topic link

Tracked in Phabricator
Task T73377

When I go to Topic:S2mti8w8pww07s5t, I get this error: "[b308df48] 2014-09-30 14:38:07: Fatal exception of type MWException" - needless to say, I can't view the topic. Oiyarbepsy (talk) 14:39, 30 September 2014 (UTC)

Incidentally, why are all exceptions of Type MWException? It would be nice if error messages displayed useful information, rather than just saying "problem". -- Ypnypn (talk) 15:36, 30 September 2014 (UTC)

Not useful to us. I'm sure the developers can see a lot more detailed messages than that. Oiyarbepsy (talk) 00:59, 1 October 2014 (UTC)

That's bugzilla:71377, and is something to do with a cache error - there are 2 patches in code-review for it right now. The error can be temporarily fixed by the devs, and I'll nudge them right now for that instance. Quiddity (WMF) (talk) 18:29, 2 October 2014 (UTC)

How will rev/del and oversight work?

The discussion above reminds me to ask this question (which may have been asked before, even by me, but if so an update would be nice). I sometimes have to use rev/del for text, edit summaries or addresses, as does Oversight. How will that work with flow? Dougweller (talk) 20:53, 27 September 2014 (UTC)

No response? Dougweller (talk) 16:27, 2 October 2014 (UTC)

@Quiddity (WMF): @DannyH (WMF): This is important. BethNaught (talk) 16:32, 2 October 2014 (UTC)

As of 13 June, the answer was [19]

They plan to implement standard revdel functionality. Here's the trello link, which is related to a few other cards, e.g.. I'm not sure if there's an ETA; will ask. Quiddity (WMF) (talk) 06:54, 13 June 2014 (UTC)

The Trello card referred to says From the main granular suppression card: On reviewing the implementation steps, we figured out that this was going to be a very long project, to address a need that isn't a top priority right now. We're going to move this back to the backlog. I suppose that following the reboot, the response to all such questions is not "how" but "whether". Deltahedron (talk) 16:58, 2 October 2014 (UTC)

I would think that the Foundation legal department would demand that WP:Oversight be available in any namespace, even for an alpha release. I suppose it's possible for the developers to remove a page, but deletion of a Flow page is not yet working. — Arthur Rubin (talk) 18:20, 2 October 2014 (UTC)

I would have thought so too, but revdel and oversight are not mentioned at mw:Flow/Use cases, which lists "the most prominent use cases in discussion-based namespaces". Deltahedron (talk) 18:37, 2 October 2014 (UTC)

• Some months ago (I believe well before even Quiddity was involved in this project), there was some work on suppression which I tested on some test wiki somewhere or other; while it "sort of" worked, it was significantly suboptimal, as I reported at the time. We (i.e., the oversighters) insisted that there had to be suppression available on this project for the live test to continue, given the past history of other "trial" software getting plenty of suppressible edits, and it has been applied here. I have just suppressed a statement on the test page, under the heading "Clicking on a title". For me, there is now a grey line of text saying "This comment was suppressed by Risker". I do not know if this is visible to others; it shouldn't be, because the suppression log is a private log, including the identity of the oversighter. (Keep in mind oversighters clean up some really vile and hateful abuse, and some have been harassed in the past by the same editors who inserted the initial abuse. It's accessible to AUSC and the Ombud Commission, as well as all the other oversighters, so that we're all kept on the straight and narrow.) Risker (talk) 19:31, 2 October 2014 (UTC)

I see no evidence that there was ever a posting on that topic: in particular there's no indication of anything being suppressed, let alone by whom. Deltahedron (talk) 19:38, 2 October 2014 (UTC)

Suppression & deletion do currently work at an "all or nothing" level. Flow does not yet have "granular" suppression/deletion - that work is still planned, but still no ETA. (Benny was working on it, but he left the WMF at the beginning of September.) It's apparently a complicated change, but moderation improvements are part of this quarter's goals (including things like: removing deleted/suppressed content from the board view (just leaving them in history, as per normal) so that admins/oversighters don't have to see the previously moderated content), so I'll ask again what the status is. Quiddity (WMF) (talk) 20:17, 2 October 2014 (UTC)

Thanks for reporting that, Deltahedron. There was indeed a post there, I still see the "grey text" which I think we can now assume is only visible to oversighters, and the fact that the post is not visible in any way to you means that the recommended 'fix' we suggested got applied at some point. It is now also present in the suppression log [19:26, 2 October 2014 Risker (talk | contribs | block) suppressed a post on Topic:S3529auswuu84azj (suppressing for test) ], which seems to be an improvement from previous as well. The word "post" is wikilinked from the log, as is the topic number, and both go to the right topic/post. The topic number isn't all that helpful, but at least it's linked. Risker (talk) 20:24, 2 October 2014 (UTC)

• Well, there is a subtle indication that a comment was supressed/deleted: there is no comment, and it's not possible to start a topic without also posting a comment. But this is of course a special case where the removed comment was the only one in the topic.

But it reveals an interesting hidden feature: where other topics have an n comments field under the title, this one says Be the first to comment!. Two points about that: 1) it's not true: you can see this if the first comment (by the topic creator) was removed, but that doesn't make you the first to comment. 2) Seriously? Be the first to comment!??? Does anybody expect a constructive discussion to spawn from that?? You should comment if you have something to say and not just to be the first to comment. How about simply 0 comments? How about a little less "best" practices and a little more Wikipedia? — HHHIPPO 20:45, 2 October 2014 (UTC)

Functions v. Features (was: History and diffs)

Dear devs:

By now, I think I have read almost every design document about Flow and I think very important information is missing. Therefore I will tell you about fundamental functions Flow has to perform in order to allow meaningful discussions on and about Wikipedia. They are more important for admins because we do "forensic" tasks more often, but basically every editor needs them at least occasionally.

I do not demand a certain workflow, because I am perfectly willing to change workflows, particularly if the underlying functions are improved by Flow. But - and please take note of this - the functions as such are mandatory. Without them, Flow will never be able to replace current model, meaning it will never be implemented.

As an admin in two big projects (deWP and Commons), I perform three basic functions every day and Flow must allow them, preferably in an improved way compared to our current system:

1) I need to find all edits by a user in their chronological order. From a timestamp A to a timestamp B (while B usually is current) - This is done now by the "user contributions" function.

2) I need to see a diff of all edits to a page between a timestamp A and a timestamp B. This can be just a diff for one edit, this can be clicking diffs one edit a time forward or back. This can be a diff over several consecutive edits by the same editor. Or this can be a diff over any number (up to several hundreds!) of edits anywhere in the history, but usually from a timestamp A to the current version. This is up to now done by diffs in the history of a page.

3) I need to be able to see a whole page in the version at a certain time. This is important to understand what a user saw when he or she looked at that page at that time. And I need this function to search (by iteration) for the editor who inserted a certain information and the time he or she did that. This currently is a basic function of the page history.

Please notice, that functions 2 and 3 work exactly the same in articles, on functional pages in the WP- and WT-namespaces, on article talk pages and on user talk pages. My needs as an admin are the same all over Wikipedia. This is one of the reasons, why using wiki pages for discussions is not as foolish as it might look in the first place!

Function 1 demands that every edit is permanently recorded and linked to a certain user and to a timestamp, in order to sort them chronologically. This seems to be a function of Flow.

For function 2, we need the watchlist to record edits to pages. When my watchlist tells me, that there has been at least one edit since I looked at a page for the last time, I can go from the watchlist straight to the history and call the diff from there.

Important for functions 2 and 3 is that I can find every edit associated to a) pages and b) timestamps or timeframes because we as users go to pages to edit articles or participate in discussions. As admin it is my job to keep current about every discussion on a number of function pages in the WP- and WT-namespaces and a few more (eg Portal, Portal talk, Mediawiki, Mediawiki talk, ...). Even after a weekend away or a few days of absence due to real life priorities. This is the reason for huge diffs on high traffic discussion pages.

So basically functions 2 and 3 demand that edits are recorded to the pages they were done, not just in the "topic" within a page. And to allow a diff across "topics". And yes, that is mandatory, because on high traffic pages, ten or more "topics" can have edits since my last look and I need to look at all of them.

Can you please acknowledge these functions as important. --h-stt !? 09:56, 17 September 2014 (UTC)

For the TLDR crowd - We need diffs and history to work in Flow. Contributions already does. Oiyarbepsy (talk) 14:42, 17 September 2014 (UTC)

"Contributions already does. " That's news to me. Didn't work last time I checked, about a week ago. Fram (talk) 06:58, 18 September 2014 (UTC)

So, they have apparently repaired the bug from last week. Flow contributions now appear in your contributions list, actually finding the exact contributions still is complicated. I mean, when I want to see what you said here, I can just use "diff" on [20] (to see the actual diff), or click on the timestamp to see the page as it was at that time. But for your Flow contributions? I can see the current status of the topic or page, but the diff? I have to use the history, and then find the right entry, and then I can see either the post you made without any context, or the post you made indicated in the current page. I have no way of seeing the page as it was then, which is often important.

Basically, contributions isn't as broken as it was last week. But I wouldn't equate "not as broken" with "working". Fram (talk) 07:59, 18 September 2014 (UTC)

I stand by my statement that contributions works. What doesn't work is the link to history and diffs, and that's because those don't work. Oiyarbepsy (talk) 22:34, 18 September 2014 (UTC)

@Quiddity (WMF):, @DannyH (WMF): - One week ago I asked you, the devs, to acknowledge the importance of some basic functions for each and every replacement of talk pages at Wikipedia. Please check my text and the reasons. I still want you to answer on my assessment of the fundamental necessity of those functions. As admins we absolutely must be able to a) follow all edits by an author b) follow everything that happens on a page and c) see any page the way it was at a certain time. Can you please affirm that you understand the importance of those functions? --h-stt !? 13:03, 25 September 2014 (UTC)

@H-stt: Your assessment is correct, we do need better diff functionality in the various feeds and views (history pages/watchlist/RecentChanges/contribs/diff views), and they do plan on improving those to be more consistent with what we're used to.

Function 2 and 3 are somewhat complicated, and I'll need to confirm with a developer on Monday as to what exactly is possible. As far as I understand it, Topics each have a distinct database entry, and are therefore much more like the systems that are used at various French, Italian, Danish, and Portuguese high activity pages (and possibly more), where each main page is made up of transcluded content (either individual threads or daily pages). As with those pages, so in Flow, I believe it would be possible to merge together the various database entries chronologically, but I'm not sure how simple it is.

I generally understand the needs for these features, but I'd like to get more details (and specific examples) on how you (or anyone) uses the Function 2 example of "a diff over any number (up to several hundreds!) of edits anywhere in the history, but usually from a timestamp A to the current version" - I've often used this to keep track of ongoing discussion changes, e.g. I can click "10 changes" in my watchlist to get this diff (although that won't show if someone has edited a comment (their own or otherwise), I'd have to go through diff-by-diff to learn that) - but how else do you use this function, particularly for admin work?

Thanks. (And sorry for the delay. My backlog increases continuously.) Quiddity (WMF) (talk) 02:57, 27 September 2014 (UTC)

@Quiddity (WMF) and H-stt: I think the question is not so much what's possible, everything mentioned here is possible. The question is how expensive features are in terms of both development effort and server load, and how useful/important/urgent they are. The challenge will be finding a consensus of what we want and a good compromise between our wishes and the technical effort. I agree we need better diff/history functions than Flow has now, but I don't think that reproducing the exact functionality we have on wikipages is the best solution. That system has the mentioned deficiencies of ignoring transcluded content and not showing where there have been intermediate steps, and it's also just a pain in the ass to follow activity on a page like this by reading diffs.

The most important feature I would like to have on a talk page is a way to see what's been going on since my last visit. This can then easily be expanded to work on arbitrary time spans, not just "between my last visit and now". The most common activity will be new comments, which I'd like to read in the rendered version rather than markup, but clearly marked as new. One could for example show the normal Flow page, but with all new comments and topics marked by a green sidebar, like the post-permalinks Flow has now. Posts that have been edited during the time span would be marked by a yellow sidebar, even if the first and final version are identical. The actual edits would be accessible through the post's history. Deleted (hidden) items would be marked with a red sidebar, again with more details in the history. This layout would make the most common task (find new posts) very comfortable, while keeping more details within easy reach. Additional bells and whistles one could think of are automatic (un)collapsing of sub-threads as appropriate and buttons to scroll to the next/previous changed item.

About snapshots (how did a page look at a certain time): I would guess that can be implemented, and even better than on wikipages now, with full support for transclusions. But I would also guess that generating such a snapshot would be quite some load for the servers. One could think of running such requests at low priority, that is slow, or using the replicated database at tool labs, or restricting access to this function (e.g. to admins). — HHHIPPO 13:52, 27 September 2014 (UTC)

I don't think it was ever envisaged that Flow would reproduce every existing workflow exactly, merely that it would make equivalent workflows possible and indeed easier. Unfortunately issues such as this, about what workflows exist and which of them are regarded as necessary or important is part of the research that should have started a year ago, has not been done, and might be started at some point in the future, albeit "at a gentle pace" [21]. That seems underwhelming, considering that questions such as this are arising right now, and need to be answered before any serious design work can be undertaken. Deltahedron (talk) 16:18, 27 September 2014 (UTC)

As mentioned above, my original statement in this thread was not about workflow, not even about history and diffs, but about functions. We need those "forensic" functions. They are mandatory for every user/contribution/page/topic. And they are basically the same on articles as well as on what today are talk pages. Admins probably use them most, but every one needs them at least occasionally. --h-stt !? 10:33, 29 September 2014 (UTC)

Today is a wonderful example for the diff over many versions: It is Lunch time on Monday now here in Germany and I have been away for not just the weekend, but a long weekend including last Friday. Now I try to "catch up" with some things that happened on Wikipedia since. Here on this very page, I did a diff from Thursday 14:12 (UTC) to current found your answers on my last statement and request and now I am answering to them. That diff spans 27 edits. Later today I will take a similar look at the equivalent of WP:ANI on deWP. There I can expect many more edits, probably between 150 and 250. I will only scan that diff, ignore most topics but look at some with more intensity. As admin I think I should understand about the active lines of conflict at any time, because only then I can react to incidents individually. Someone who is involved in conflict for the first time or only occasionally will be treated differently from a regular on our incident pages. A topic that is heavily contested or has recently flashed up must be taken more serious. So I need to know the big lines of events during the weekend. A full record of contributions in connections to a page/topic is mandatory as well for finding a certain contribution by a certain user. How am I supposed to call on somebody, without citing his or her edit I refer to? If Flow will allow users to edit other people's contributions (which is of course important for collaboration), not every contribution will be marked by signature and timestamp, so searching for an individual edit will continue as task. Above I used the term "forensic" for some functions of tasks. If you think of it this way, you will understand the needs I describe. --h-stt !? 10:33, 29 September 2014 (UTC)

I fully agree these functions are needed, I use the same method. But I think the "mark recent activity" function I suggested above could provide all that in Flow, in an easier to digest way than current diffs, and revealing more details. For example, in the big diff you describe, a post that was both written and changed (possibly by another editor) during the time span of the diff will look exactly like one that was just added in a single edit. In the suggested color coding scheme for Flow, that post could be marked yellow, indicating that it has been edited and that a closer look might be worthwhile.— HHHIPPO 10:56, 29 September 2014 (UTC)

Look, as I said now time and again: This is not about history and diffs. This is about recording edits by user and by page/topic and accessing them by page/topic and timestamp/timeframe. I don't care if it is done the current way with a history and diffs, or any other way. I demand the function! My understanding of the technical side of Flow is, that it will be extremely hard to implement this function, because the devs did not think of these functions and didn't know about the tasks I called "forensic" for users and admins. So the designed Flow's basic framework completely different (with solitary contributions, soft linked to threads) and it will be hard to implement the functions. But as they are mandatory, the devs need to know about them now. It is late, but talking about this later will certainly not make it easier to implement those functions. In the worst case, when they decide that it is not possible or at least viable to implement those functions, then its better to abandon Flow now, than to continue for more months or years. --h-stt !? 12:56, 29 September 2014 (UTC)

Re: Edits: Flow should make it easier to see if something has been edited (and by whom). AFAIK, the work is just waiting on Design to give us an equivalent of mw:Thread:User_talk:Quiddity_(WMF)/sandbox2/Lorem_ipsum (top-right corner indicator in LQT).

Re: New content, per Hhhippo's suggestion: That's definitely possible - e.g. If I hack together any post's permalink with the &fromnotif=1 string (as given in some links from Notifications) I can create something like this topic link which highlights everything newer than the permalinked post. That can also be expanded to a page link, though I don't believe it was designed with that intent. Obviously it needs to be refined, and tested for scaling/performance, particularly on large changes which would overlap the infinite scroll (yes, another point against that, though the 10-topics currently used as the default is one variable that could also be experimented with), but it definitely has potential. Quiddity (WMF) (talk) 23:51, 2 October 2014 (UTC)

Moderated Topics - update

In today next week's update, the main change is that a Moderated [Hidden/Deleted/Suppressed] Topic will no longer be visible on the Board (where it was too attention-grabbing), but now only in the History page (per normal page-edit moderation-actions). The Topics can still be accessed by themselves, via the usual permalinks, for users that have rights to view them (e.g. this currently hidden topic on MediaWiki). The same change will be implemented for individual Posts, in a following week. Please let me know what bugs you find, that I/they/automation didn't catch. Thanks. Quiddity (WMF) (talk) 00:54, 3 October 2014 (UTC)

Thanks. This a great improvement. -- Ypnypn (talk) 01:13, 3 October 2014 (UTC)

If there is something NEEDS to be taken off the page (like personal information etc etc etc) then obviously it should not be accessible in the history or via direct link. So the only use for this is discretionary vanishing of posts that are arbitrarily deemed to be "unhelpful" by whoever is running around vanishing stuff. I think there's a teensy weensy chance that people will scream censorship when things are vanished, and become more disruptive. It would have made things even worse if we had a Flow page AND we started massively vanishing talk page posts in TheFederalist attack campaign against us. This does not help with the problem of a Flow board crapflooded by non-editors. Alsee (talk) 13:39, 5 October 2014 (UTC)

What Quiddity describes is exactly what we have now on wikitext talk pages, why should that be a problem with Flow? — HHHIPPO 15:17, 5 October 2014 (UTC)

The issue is that if you put up a typical internet chatboard it will draw non-editors using it as a typical internet chatboard, and screaming and voting for changes in wild violation of our policies. That will be a critical problem on any remotely controversial page (including science pages!), and that it will be catastrophic when some partisan-warrior website links to a Flow-based article talk page. In case you missed it Wikipedia_talk:Flow#We_just_got_hit_by_a_live_example_Flow_Failure_Case this incident further up the page. If it was a Flow page we'd have been toast, and trying to vanish the crap would have inflamed and amplified the problem.

People who are here to build an encyclopedia pick up the basics of editing, because they need to for article pages. Some level of competence is required if someone is going to edit. Talk pages are a natural low-filter that is essentially zero cost for anyone who is actually going to edit. People who are not here to build an encyclopedia rarely try to post on Talk pages. Alsee (talk) 16:07, 6 October 2014 (UTC)

It's a bit funny how on the same page, people are arguing that wikitext talk pages pose no barrier and that we need a barrier. If we'd follow both arguments, we'd have to at least semi-protect all talk pages on all wikipedias, or all hell will break loose... I don't think so.

Yes, I've seen the thread you linked, I replied there ten days ago and those replies are still valid. This thread is about moderating topics, and I just don't think an argument like "Comments are too easy to post, therefore they should be impossible to remove" will fly.— HHHIPPO 06:44, 7 October 2014 (UTC)

As I see it, "hidden" is the equivalent to {{collapse}}, and useful for stopping off=topic posts or personal attacks, and for this kind of thing, we want users to see that they've been pulled off the page. I personally think only admins and above should be able remove a topic entirely, which would be equivalent to deletion. Oiyarbepsy (talk) 14:29, 7 October 2014 (UTC)

But you can only hide a complete topic or an individual post, not part of a topic (or you have to hide it one by one), while collapse, hat, all that kind of stuff works on a self-selected group of posts. Fram (talk) 14:36, 7 October 2014 (UTC)

@Oiyarbepsy: In the version Quiddity describes, "hiding" is pretty much equivalent to removing text from a wikitext talk page: there's no sign of it left on the page itself, but you can find it in the history (might need some digging on wikitext pages, but should be a pretty clear log entry with Flow). To get an equivalent of "hatting"/{{collapse}}, we would need the ability to collapse threads/subthreads and to set a default state for that, as Fram suggested earlier. I think we need both, hide and collapse, just like we have them now.

@Fram: I think the idea is that when you hide a post in Flow, that hides also all the replies to that post. I just tried on mw:Topic:S310a293lvt45j9y#flow-post-s310a298a94263fa: it's not really hiding the child, and only hiding the text of the parent, but both are kind of greyed out, so I assume in the next version they will both be hidden. Of course in wikitext one can do more flexible hide operations in a single edit, but I think hiding a side-chain covers most use cases.

Regarding collapsing of multiple posts, that could work the same way, by collapsing a whole side chain. It could e.g. be done like this, even without the 'compact' aspect. Again, it wouldn't be exactly what we have now, but very close, and quite easy to operate. A nice feature would be a way to add a visible comment when "hatting", but I'm not sure how we'd like that to work. — HHHIPPO 19:00, 7 October 2014 (UTC)

But how will Flow know which posts are replies to which posts? yes, when you start at the level 1 indentation, that will work, somewhat. But tangents are often at lower levels, and it is impossible now to see there who has responded to what (a major shortcoming of Flow), never mind hiding the right posts in one go. Take a look at [22] and try to get a post at the level where I tried "hidden" together with all the replies to it. It is not possible (well, one by one of course). And if I hide the post by SPage on level 2, all the posts beneath it are greyed out but not hidden, while the SPage post is hidden. No idea what that is supposed to do (and perhaps it is an admin-only thing), but it seems to work in mysterous ways at the moment... Fram (talk) 07:18, 8 October 2014 (UTC)

The problem on that topic (and any discussion apart from the most trivial ones) is the limitation to three levels of indentation, which hides most of the structure of the discussion. (At least to the human eye, the database might know more. But then, the structure being invisible to users means they stop caring about it and just press one of the many reply-buttons that essentially all do the same, so even if the database keeps track of something, it will not know the actual logical structure.) We definitely need a better nesting system which doesn't disallow structured discussions. I wrote this proposal, which would allow virtually unlimited logical levels with a horizontal space consumption of seldom more than three levels. So that's possible in principle, but not in what exists now. I agree that without implementing something like that, all the moderation functions won't be very useful.

I consider the current greying out thing a bug, since that's in most cases not what we want. At least we need an option to hide an entire side chain rather than only its root post. (It's not admin-only and neither author-only.)

In general, when I say "that could be done like this", I don't mean it's possible in the current implementation of Flow, I rather mean it would be possible if other suggestions were implemented as well. I'm not so much thinking of the next incremental change, more of how I'd like the whole thing to work. — HHHIPPO 11:28, 8 October 2014 (UTC)

Suggested terms: Collapse would reduce the discussion to just its title, but it would remain on the page. Remove would remove the topic from the page, but could be restored by any editor. Delete would be like remove, but would be an administrator action. Suppress would be like delete, but an oversight action. This way, the terms use by flow would match what we say now on wikitalk, and these names would be mostly intuitive. The exception to intuitive is collapse, and if someone has a better idea what to call it, I'm all ears. Oiyarbepsy (talk) 14:22, 8 October 2014 (UTC)

Sounds good. I think "collapse" is just fine. After all we now use a template with that name for that function. It would of course be more intuitive if you had to click a well-known collapse icon (triangle) for it rather than somewhere in the title. All of those should also work for individual posts or side-chains, not just whole topics. Oh, and if a post is removed it should be possible to view it from the history page without restoring it for everybody. The same for deleted and suppressed posts, for those who have the rights to view them. — HHHIPPO 15:27, 8 October 2014 (UTC)

Redirects

Redirects to Flow pages don't show up like they normal do when you follow them, i.e. at the top of the target page. Wikipedia talk:Flow/Test page is a redirect to Wikipedia talk:Flow/Developer test page, but when you follow it, you don't get the normal "(Redirected from X)" that you find when you follow a redirect to non-Flow pages. This means that things get less transparent, and that it is much harder to change the redirect to a non-redirect if wanted. Another method to find the redirects, [23] (click on "External tools: Show redirects only") also doesn't work (404 error), but that seems to be a general problem, not a Flow related one. You can still reach it using [24], but that's less intuitive and easy. Fram (talk) 07:03, 10 October 2014 (UTC)

Known bug, see Topic:S2n8v8tnlfrk509z and also [25]. Oiyarbepsy (talk) 07:17, 10 October 2014 (UTC)

Hah, I'm now combining two bugs. I had tested your latest report (about small view of the Flow page, and then following the permalink), and I still had the page on small (collapsed, TOC-like) view. When I then follow your topic link above, I only see the title and can't open it. So your bug about permalinks is worse than it at first loks (which was bad enough). Thanks for noting the existing bugzilla, but I'm glad that my duplicate report has lead to another finding anyway :-)

Free-form Wikitext talk pages a barrier to new users?

We also know that free-form wikitext talk pages present a significant barrier to new users

The first reference, "User test results", only documents user testing of the new Flow interface, not free-form wikitext talk pages.

The "WMF Usability study highlights" videos only show user discussions about article editing, not talk page editing. – Wbm1058 (talk) 17:20, 4 October 2014 (UTC)

OK, I see how if one recognizes that both article and talk pages use "free-form wikitext" then studying the former might shed some light on the latter. However, many of the user complaints were specific to article pages (e.g., one doesn't need to learn how to put reference citations on a talk page). So, I'll concede that these references may have some limited value in confirming the statement made. Wbm1058 (talk) 16:21, 5 October 2014 (UTC)

References

I think WP:blue applies here. In the last week I've dealt with two or three editors who have been editing for years that don't understand how user talk pages work. I won't even get started on what I see from new editors. Oiyarbepsy (talk) 18:36, 4 October 2014 (UTC)

<squeeze>As there is no difference between a page and any sub-page like talk now: Please define "how it works". You can't mean syntax, as that's the same everywhere now, and as veteran editors they have to know it. If you're talking about conventions: I fail to see how that is affected in any way by the choice between flow and current state. --♫ Sänger - Talk - superputsch must go 07:47, 5 October 2014 (UTC) </squeeze>

Okay - by how it works, I mean that they don't know what page to post on, they don't know to sign their posts. So, by how it works, I mean the absolutely most basic levels of talk page use. Oiyarbepsy (talk) 01:33, 6 October 2014 (UTC)

And how is that getting any better with flow? Finding the talk page: exactly the same. Using it for cooperation: Very hard to do, as it's just fit for blah-blah after quite some time of "development".

I very much doubt that after next to nothing evolved from Flow after so much development (and the head-start with LiquidThreads, that did the same before), anything useful will ever come from it. Or did they invest just some meagre person-hours in it all the time, as it looks like, and just begin to develop it?

And regarding signing: That's something that should be build in the VE, as well as indentation: No posts on talk pages without the question, if the (high-lighted) sig is in the right place. --♫ Sänger - Talk - superputsch must go 17:25, 6 October 2014 (UTC)

No, (the sky is) blue is applicable to a statement like, "the Wikimedia Foundation is headquartered in San Francisco." It is not applicable to opinions about usability of any particular software. Wbm1058 (talk) 01:00, 5 October 2014 (UTC)

Well, okay, but Wikimedia's testing pretty much confirms that the wikitalk is awful to new users, and sucks for an experienced guy like me too. Oiyarbepsy (talk) 01:33, 6 October 2014 (UTC)

Okay, fixed. First one added is mw:Flow/Research, including such statements as "None of the tested users were able to intuitively grasp anything about the use of User_talk pages" and "On average, it takes new users around 15 minutes to grasp the basics of user talk messaging". Also, mw:Flow/Research/User Test Data, which details the struggles of new users who mostly gave up entirely. Oiyarbepsy (talk) 18:46, 4 October 2014 (UTC)

Help:Talk pages. If only we had a landing screen on account creation to tell people the basics... oh wait. BethNaught (talk) 19:55, 4 October 2014 (UTC)

Well, in that case, after spending 20 minutes reading that page, it would then take them 30 minutes to grasp the basis. I'm pretty sure that there is no editor who has ever posted on this page that read all that "before your edit" stuff before they edited, and it's never gonna happen. Oiyarbepsy (talk) 22:30, 4 October 2014 (UTC)

This all just sounds like opinions and conjecture on your part. How do you know it would take 20 minutes to read that help page? And not 5 minutes? Or 25 minutes? Was a study done where a statistically significant number of randomly selected people were given that page to read, timed on how long it took them to read it, and then given a test of their understanding? If not, then all we can do is speculate. Wbm1058 (talk) 01:00, 5 October 2014 (UTC)

Your assumption that anyone will read the help pages first is also opinions and conjecture. Oiyarbepsy (talk) 20:02, 6 October 2014 (UTC)

Regarding the two new citations you added in response to my {{failed verification}} tag:

• MediaWiki Flow research

  OK, I see that on this page they have drawn some rather sweeping conclusions: None of the tested users were able to intuitively grasp anything about the use of User_talk pages. On average, it takes new users around 15 minutes to grasp the basics of user talk messaging. Anything? Literally they understood nothing about the function of the page? We can turn this around. I've spent a bunch more than 15 minutes on Flow, and I have yet to intuitively figure out how I'm supposed to request a page rename or make a protected edit request using Flow.

• New user test data

  Oh, I see. I guess it's in the section mw:Flow/Research/User Test Data § Talk page user tests – that wasn't immediately obvious, I was looking for something that disambiguated "talk page" to " free-form wikitext talk page" (versus "Flow talk page"). Sigh. I now see several, less obvious, links to videos, but unlike the two big Flow-test video links, none of these work for me (have they expired?), which is a shame. Wbm1058 (talk) 01:00, 5 October 2014 (UTC)

– Wbm1058 (talk) 01:00, 5 October 2014 (UTC)

@Wbm1058: Re: the video links, they all still work for me. (Both the 2 hosted videos on Commons, and the 7 videos hosted on usertesting.com linked via username) I'm not sure what plugin the latter are using though - they download as MP4 files if I right-click and "view video", but possibly the embedded version is something else?

Re: the 2 workflows (page rename and protected-edit-request) - neither of those currently work, because they require categories. Supporting categories is tracked at bugzilla:57512, and is crucial for supporting the existing workflows, which are generally all implemented from a mixture of [template+categories & sometimes bots]. Overhauling those workflow systems (or rather, creating an abstract/modular system so that each wiki community can easily create the systems it needs, for itself), is the more complex stage of development that will start once more of the basics are complete. Quiddity (WMF) (talk) 22:20, 14 October 2014 (UTC)

@Quiddity (WMF): Thanks, I was able to download one of the 7 MP4 files, and then watch it. The embedded version still doesn't work for me though. Wbm1058 (talk) 22:54, 14 October 2014 (UTC)

Not a valid comparison - The cite says 15 minutes to understand the basics. Page renames are not the basics. Protected edit request is not the basics. The basics is posting a message and replying which on flow would generally take 15 seconds to figure out. Also, it takes more than 15 minutes to get the basic, and nothing is intuitive - these are two distinct statements. Some of the users did figure out the basics in 15 minutes but it still wasn't intuitive. Oiyarbepsy (talk) 01:29, 6 October 2014 (UTC)

Nope, the basis is finding the talk page, which is just as hard with Flow as with current wikitext talk pages. Once you've found the page, it isn't that hard. And everything you learn on wikitext talk pages will come in handy when you want to edit an article, and vice versa; the same can not be said for Flow. I don't care about intuitive if it is intuitive but very limited, like Flow, in circumstances where you need much more than Flow allows.

Let's say, for the sake of argument, that a newbie knows how to post on a Flow page after 15 seconds. Good, and now he wants to actually discuss an article. Linking? No idea. Adding a pointer to anything at all? Layouting? Quoting someone else's post? ...

Basically, you not only have learned the basics of Flow after 15 seconds, you have learned nearly every bloody thing you can do with it, as it is useful for nothing but posting plain text, preferably as a new topic or as the first reply. After that, the thing becomes totally useless. That's what we get after what, 18 months of development now? I prefer a page that may be a little harder to learn how to use it, but which you can then truly use in a meaningful way, not just for an AFT-style comment. Fram (talk) 16:10, 6 October 2014 (UTC)

Considering that the vast majority of wiki markup works within a flow post, nearly everything you said above is wrong. All of that stuff you just claimed is impossible in flow is actually possible by putting wikimarkup in your post. And you've been testing it, so you should know better. (On a side note, perhaps some elements of visual editor could eventually be incorporated into flow) Oiyarbepsy (talk) 19:57, 6 October 2014 (UTC)

Also, your statement that once you find the talk page it's easy is completely wrong. Wikimedia's testing gave these new users links, and actually said "click here", so they all found the talk page, yet they struggled with the basics. This bears out with the experienced users I mentioned that struggled, since in all those cases, they did actually post, but got all the technical requirements wrong. Oiyarbepsy (talk) 19:57, 6 October 2014 (UTC)

And Fram, you're never gonna convince Wikimedia to cancel this project with such obvious blatant falsehoods. Maybe you should try sticking to fact-based criticisms, as there is plenty of criticism to level that doesn't require lying. Oiyarbepsy (talk) 19:59, 6 October 2014 (UTC)

No, Oiyarbepsy, not "nearly everything I said above is wrong", you are approaching my response suddenly from the point of view of an experienced editor, but the question (and my reply) is about talk pages as "a barrier to new users". Putting wikimarkup in your post is not realistic if you are a newbie, don't have a toolbar and don't have the ability to see how other users do all that fancy stuff in their posts. A new user is left completely in the dark about all that on Flow. Please don't accuse people of "blatant falsehoods" when you don't seem to know what we are talking about anyway. Accusing people of "lying" is a personal attack, so please read WP:NPA; even if you think I am mistaken, you should stay well clear of such accusations unless you are very, very certain that a deliberate lie is being spread, and not something expressed in a way that you have misunderstood completely. Fram (talk) 06:44, 7 October 2014 (UTC)

I apologize for the personal attack. That is a good point that you wouldn't expect a new user to link with wikimarkup - but you don't need to make a link to discuss a topic and be productive. Unless a user completely butchers the title, simply typing its name will make it clear what they are talking about even if unlinked as in "The Barack Obama article is biased" where you know who I'm talking about without a link. A new user can discuss an article and contribute usefully without links or pointers, and most of the "layouting" is only necessary because we use an article markup for discussion pages, but again, they don't need layouting to discuss an article intelligently. Much of this could be dealt with by incorporating some elements of visual editor into Flow. Finally, in my experience, one of the biggest problems with new users is that they don't mention what page they're talking about at all, which there is no technical fix for. Oiyarbepsy (talk) 14:37, 7 October 2014 (UTC)

Thanks. Please don't get me started on VE though :-) Fram (talk) 14:38, 7 October 2014 (UTC)

What about adding a "view source" button for each flow post (put it in the menu, you know) Oiyarbepsy (talk) 14:29, 8 October 2014 (UTC)

Agree, there should always be either an "edit" or a "view source" function, just like on wiki pages. — HHHIPPO 15:30, 8 October 2014 (UTC)

Both those changes are coming. The "view source" function is already written (which will be needed for protected pages, and closed/locked Topics) is just waiting on an icon and product-review (links via trello). Afaik, the "edit someone else's post" function is just waiting on a design spec (notes at trello). Quiddity (WMF) (talk) 22:20, 14 October 2014 (UTC)

Table of Contents?

I just tried the Flow test page. One thing I noticed is that there isn't a table of contents. The lower information density (increased whitespace) makes it far more difficult to scan the page for items of interest, so having a TOC is really important. Apologies if this has been covered before. Short Brigade Harvester Boris (talk) 16:31, 5 October 2014 (UTC)

There is apparently one in development (hell knows which Bugzilla bug or Trello card it's on), but that's what you get with premature software rollouts on a production wiki. BethNaught (talk) 16:38, 5 October 2014 (UTC)

Off-topic and not helpful

By software rollout, Beth means two pages that are primarily used for testing, which, BTW, is not how I defined a software rollout. Oiyarbepsy (talk) 01:35, 6 October 2014 (UTC) If we hadn't put our foots down, it would by now (and since months) been rolled out to many projects, as an opt-in to talk pages, and so on. Note that it is not only rolled out to 4 (not two) pages here, but also to pages on other wikis. And let's not forget that the roll-out to live projects was promised as a temporary, reversible test, but that 8 months later we still can't (technically) revert a Flow roll-out; we can't make a page un-Flow, we can't move the Flow page to a different name and put a non-Flow page in its place, we can't convert Flow pages back to standard wikitext pages. Basically, they promised us something they knew they couldn't deliver. And then they wonder why we have no trust in them. Fram (talk) 16:13, 6 October 2014 (UTC)

As I've replied to Short Brigade Harvester Boris at the other thread: Yes, part of the team is working on a ToC at the moment. Details (and some rough wireframes) are at mw:Flow/Table of Contents spec, with a few of the questions/complexities noted in the bottom section. Quiddity (WMF) (talk) 20:22, 6 October 2014 (UTC)

Thanks Quiddity. I don't know what a "wireframe" is but it's good to see that this is being worked on. Short Brigade Harvester Boris (talk) 23:17, 6 October 2014 (UTC)

I'll quote Dannyh, who wrote "Wireframes are not mockups -- they express a rough approximation of the layout, so that it can be easily understood and discussed on a spec" - in contrast, a mockup or design specification (spec), is intended to depict exactly how the final thing should look, often at a pixel-specific level. See Website wireframe for details on the former. Most software that outputs "wireframes" use purposefully non-straight lines, and comic sans font, to emphasize that it is not a final spec. Basically one step above a napkin sketch. :) Quiddity (WMF) (talk) 23:08, 14 October 2014 (UTC)

Topics on multiple pages

So, what's the status on getting Topics to appear on multiple pages? I see this as one of flow's key killer-apps, as am constantly seeing cases where this would be ideal. For example, my user talk page has a recent discussion relating to Talk:Accidental gap and Talk:Pseudoword, at User talk:Oiyarbepsy/2014#Pseudo-words and accidental gaps. I posted at the two article pages telling people to read my user page, but it would be so much better to just have that single topic appear on those talk pages instead. All of these constant "go here for a discussion" message would become pointless wastes of time and could instead be replaced by a single discussion appearing on multiple pages. Oiyarbepsy (talk) 04:23, 16 October 2014 (UTC)

Probably way too many maintenance problems still to make this feasible at the moment. Let's say you have a discussion at your talk page which is also embedded in two article talk pages. One of the article's editors decide it is off-topic, and locks / hides / collapses it. Is it then locked at all three pages? Do you have to close discussions at each page separately (largely defeating the "profit" of having only one discussion)? Can it only be closed at the "mother" page? ... there are countless other similar questions to be asked and answered before this would ever be ready for implementation. Fram (talk) 06:31, 16 October 2014 (UTC)

Well, in my mind, that's why "hide" should be changed to "remove from this page." Selecting remove would only remove it from the current page, and leave it on other pages, or if left on no pages at all, automatically categorized as an orphaned topic. Collapsing would only be for content that isn't useful at any pages, but that doesn't require deletion, such as jokes or personal attacks. Locking would be like closing a discussion, so locking would apply to every page it appears on. Deletion and suppression would also apply to every page it appears on, for obvious reasons. Oiyarbepsy (talk) 14:20, 16 October 2014 (UTC)

"Automatically categorized as an orphaned topic". Considering that at the moment, we can't categorize Flow pages no Flow topics, this may be one of the reasons that such more complicated issues aren't on the radar yet. The other issues all need discussion, analysis, before development can even be considered. I doubt that they are more urgent than getting standard Flow to work properly though. Fram (talk) 14:33, 16 October 2014 (UTC)

Community Liaison job openings at WMF

There are currently 2 job openings, and I hope someone here might be interested. Specifically:

• Community Liaison - this position will initially focus on working with the Flow team and also with the Editing (VisualEditor) team, mostly at non-English wikis; however, a lot of smaller or short-term tasks continually come up (e.g. I'm currently working on about 8 other things), so the WMF is particularly looking for someone who is adaptable, and with diverse interests.
• Community Liaison (Part time contract) - this part-time position will primarily focus on working with the Mobile teams, as the link explains.

Please pass it along, if you know someone who might be interested or a good fit for the Community Engagement team. Thanks! Quiddity (WMF) (talk) 02:09, 21 November 2014 (UTC)

What's the definition of "community liason"?

Is it a salesman to sell the botched software fiascos of the WMF to the communities, who want to block them, and sugarcoat the oligarchic process currently done against the communities?

Or should s/he be an advocat of the communities, to give the real bosses, that's the communities, better access to the ivory tower decision process in SF, to break up the disconnected in-group and rejoin them with the community?

--♫ Sänger - Talk - superputsch must go 09:46, 21 November 2014 (UTC)

I've answered in depth, at the meta thread. Quiddity (WMF) (talk) 23:14, 21 November 2014 (UTC)

Implementing Flow concept on wikitalk pages

I've done some brainstorming as to how wikitalk pages could be upgraded to have many of the features of Flow. Please give it a read at User:Oiyarbepsy/Wikitalk: The Next Generation. And yes, I would like @Quiddity (WMF): and the gang to have a look. Oiyarbepsy (talk) 05:32, 20 November 2014 (UTC)

Of the five Key Elements you list at the start, only Elements 1 and 5 are really needed, the rest is user preference.

• "Better archiving" does not necessaruly mean keeping the topics on the same page. The current archiving system works fine if you like it, and not if you don't like it. But the links to discussions should keep working (which is your correct point 1).
• Top posting or bottom posting is a habit, both have advantages and disadvantages. It is not a necessary element.
• Please, not VisualEditor or a visual editor. Presenting multiple editing environments to the editors is not making things easier, it is making things harder. Provide extra functionality, fine, the same has happened with wikitext often enough (and could have been a lot better if the WMF had spent their time and money there instead of on VE and the like). Things like "new topic" already exist in current talk pages, by the way. Fram (talk) 08:14, 20 November 2014 (UTC)

I'm with you that better archiving doesn't have to mean keeping topics on the same page, but I think it make sense to do that. Having the discussion on a separate topic page essentially guarantees that the link will never break, unless explicitly deleted. Added a permalink concept to our current pages would still be potentially error-prone. Oiyarbepsy (talk) 15:19, 20 November 2014 (UTC)

If the archives will remain on the same page, top posting is essentially required for the system to make any sense. It's the logical progression, the most active (usually the newest) on topic, and gradually working to older posts, and then to archives. Oiyarbepsy (talk) 15:19, 20 November 2014 (UTC)

The archives probably couldn't remain on the same page, because they'd still run into the natural size limit, of pages being slow-as-hell to load once they get over a few hundred KB. Quiddity (WMF) (talk) 02:03, 21 November 2014 (UTC)

I see no good reason to exclude a visual editor. Keep the edit source button for the old-timers who never want to change. Oiyarbepsy (talk) 15:19, 20 November 2014 (UTC)

I've been (occasionally) coding websites in a raw text editor since the late 90s. The source has a great allure, for more than just wiki-old-timers. ;) However, I think there are some good possibilities for accommodating both preferences, even the people who occasionally want to use both. There are also some planned features of VE that fill me with joy (the last newsletter mentioned "dragging columns to different places [within tables]", which if you've ever tried to rearrange columns/rows in a table, you'll know is a world of pain), but on the other hand I'll always appreciate the ability to look at the wikisource, as well as the htmlsource, in order to diagnose problems easily. But mainly because my fingers can still hammer out wikimarkup more rapidly than they can be retrained to remember keyboard shortcuts and templatedata dialog windows. However, all things are possible, given enough time. Quiddity (WMF) (talk) 02:03, 21 November 2014 (UTC)

One problem with topics instead of talk page messages is that you either will get a massive increase in watchlist entries (and I mean really massive, just imagine all the AN and ANI sections being separate watchlist entries), or you will need to manually check every new topic to see whether it should be in your watchlist or not (a bit like you have to do now with AfD discussions). Neither seems to be acceptable, they certainly both are a huge step backwards compared to the current system. Any idea what the limit is of the number of entries in a watchlist before it grinds to a halt? I now have 33K pages in my watchlist, but many of those are deleted pages so don't show up too often. If every talk page section would be a separate entry though, it would be in the hundreds of thousands. Fram (talk) 15:40, 20 November 2014 (UTC)

Obviously the watchlist would have to be smarter (and the same applied to Flow, the watchlist is pretty dumb about it). For talk pages, you would get the option to automatically watch every new topic that appears on the page, to only notify of new topics, or to pick and choose individual ones. The watchlist would be smartened to see thinks like "3 new topics on admin notice board" or "4 new posts on Topic:Vandal problems (1)", instead of the current way, and the watchlist link would show those new posts. As far as number of pages, doesn't WP:Don't worry about performance apply? Oiyarbepsy (talk) 15:58, 20 November 2014 (UTC)

No, don't worry about performance means that we shouldn't worry about breaking the servers (although we have occasionally done, e.g. by deleting or restoring pages with too many reversions). The problem is that very long watchlists take much longer to load. That may not break the servers, but it slows the response I get considerably down. I have already had to cut down my watchlist once for performance reasons, I don't want to do this too often. Fram (talk) 07:44, 21 November 2014 (UTC)

I also agree that points 2 to 4 are not necessary. I would be happy with 4 (VE on talk), though, because it will help newbies communicate while maintaining the flexibility of the system, and this is what I have advocated for a while. Same-page archiving would make talk pages stupidly long but I recognise that coming up with a different permalink-friendly solution may take a lot of thought. On having new topics at the top, I still am not convinced that it is causing a problem on wiki, and I'm speaking as someone who used to receive many messages from newbies as a recent changes patroller. Change for the sake of change, perhaps? BethNaught (talk) 15:57, 20 November 2014 (UTC)

Same page archiving wouldn't be the entire archive, just the most recently archived entries, to clarify. Oiyarbepsy (talk) 15:59, 20 November 2014 (UTC)

A few aspects of Option 1 are already used in a few wikis, on highly active pages; e.g. at the French villagepump, the Italian villagepump, the Danish villagepump, and the Portugese villagepump. All 4 seem to use different code-systems. It doesn't scale very well because of all the setup required at each page, plus it's slightly more confusing for newcomers to learn, hence only the villagepumps are using it (as far as I know?). That's exactly the type of thing that Flow aims to take the good ideas from and further-improve-on, so that all the hundreds of wikis and millions of pages can benefit.

The "Tangents" idea is interesting. Some sort of better way to indicate that "this topic forked a tangent, which appears over here now", would be interesting. Sort of a cross between the {{tracked}} template and the "See also" sections in bugzilla itself.

I like some of your other ideas in Option 2, and there were some related discussions amongst developers on the mailing lists a few months ago; I'll see if I can find out what happened to those. Quiddity (WMF) (talk) 02:03, 21 November 2014 (UTC)

My concept for both options is that the WMF developers would do the setup, so all that each page would need is to click an activate button. And, of course, with WMF developing the software, they could click a button when ready and apply it everywhere. This would resolve the scale problems. The use of "new post" buttons, etc, and smarter transcluding would solve the newcomer learning problems. Oiyarbepsy (talk) 04:20, 21 November 2014 (UTC)

As an observation, you practically reinvented liquid threads. that's not necessarily a bad thing. A low tech LT reimagining would be quite nice IMO. With regards to the watch list clutter Fram mentioned, would being able to hide pages that haven't changed since your last visit solve that issue? I think it would.Martijn Hoekstra (talk) 08:53, 21 November 2014 (UTC)

The problem isn't watch list clutter, it's watch list performance. Perhaps it no longer is an issue, but at least in the past refreshing your watchlist became a very slow process once it became very long (over 30K entries?). If all watchlists would become, what, 10 ten times as long due to all the topics that get added, this would become a real problem for many long-term editors. Fram (talk) 09:55, 21 November 2014 (UTC)

Ah, that makes a lot of sense, actually. I'll sleep on it. Martijn Hoekstra (talk) 13:28, 21 November 2014 (UTC)

I didn't re-invent Liquid Threads, based on testing how it works. I was unable to get to wikitext in liquid threads, for example, and the discussions on Liquid Threads don't look like wikitext discussion. My concept is talk pages as a container for wikitalk discussions and a visual editor for wikitalk discussion. Oiyarbepsy (talk) 18:21, 27 November 2014 (UTC)