Wikipedia talk:Flow/Archive 6

This is an archive of past discussions on Wikipedia:Flow. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

←

Archive 4

Archive 5

Archive 6

Archive 7

Archive 8

→

Archive 10

I read with dismay at the design FAQ that you've decided in your initial design to pass without the table of contents, open only to experimentation if "the search system is insufficient"; this is what I feared the most since the very first moment that Flow was announced. I can tell you right now that lazy loading of content through scrolling breaks most of my reading habits for talk pages.

I use the page index to get an overview of all the available topics, performing a quick scanning of the titles, deciding which ones to read and which ones to skip. "Infinite history" scrolling is a design that prevents this scanning, as there's no way to get an overview of the titles available. It's not true that "the concept of a table of contents doesn't scale" - you can easily paginate the TOC, or even lazy load it; the key differences that make it useful and are not available in Flow (but might be) are: 1) that topics are shown in a compact table format, and 2) that only the titles are loaded - the topic contents are loaded upon request for only the particular topics selected from the table (thus not polluting the page with any topic that I skipped).

My usual workflow is to enter a talk page, scan the TOC and open the topics I see interesting in new browser tabs, to read later in random order and jumping back and forth between them. The current Flow design makes this workflow impossible; even if all topics were collapsed and only loaded upon unfolding them, I'd still need to keep scrolling the page up and down to find the next topic I want to read. Having a TOC ordered by creation date also provides a sense of temporal and spatial relation between topics (i.e. an earlier/later ordering), which is essential to track which topics I have already processed (either by reading them or by deciding that I don't want to read them); the "flowing text" paradigm where topics are reordered every time someone updates them makes it very difficult for me to track what I've already processed and what I didn't.

Every HCI textbook shows that searching and browsing have complementary strengths (related to the recognition vs recall abilities of the brain), and you can't wholly substitute one for the other except for the most trivial tasks. When Aza Raskin popularized the infinite scrolling, it was designed as a solution for search results. It may also be a reasonable technique to apply to blogs, with usually have a separate column organized by date (i.e. a TOC), but it only works well when items in the list are unrelated and you may be potentially interested in seeing all them, in order, without skipping chunks; therefore I believe it is a bad general solution for the kind of content available at Wikipedia talk pages in my experience, where each topic is usually related to other topics above and below.

The main problem with infinite history is that it prevents scanning of titles - my experience is that it forces you to load all the intermediate content by manually scrolling before showing the titles of later posts, which is a slooow process (Wikipedia long talk pages are essentially paginated by the archive tools, so it's easy to skip to certain dates and pre-load selected reasonable sized chunks of content -in the 30Kb to 200Kb range - for quick scanning', without manually scrolling through them all while waiting for new topics to load).

So please, PLEASE make sure when iterating the software design that the final solution can build indexes for all the topic titles in a range of dates (ordered by topic creation) and that one can jump to any topic in random order.

I hope this text is enough to explain the reasons for why a solution providing the functions of a TOC is needed; if you need clarification of some point, please ask for it, and I'll gladly elaborate. Diego (talk) 09:12, 11 October 2013 (UTC)

Would it be feasible to provide each Flow with a "watchlist" so that new discussions, or discussions with new comments, are highlighted. Possibly in a table of some kind? At the top? With contents? Spectral sequence (talk) 09:35, 11 October 2013 (UTC)

As I understand the design, Notifications take care of highlighting new content. Though that only solves the case of being updated of new additions, but sometimes you also want to review old content; Wikipedia talk pages have high archival value, being often referenced and consulted either to find unresolved requests for the page or discussions where some particular consensus was achieved. The Flow structure doesn't seem at all adequate to support those use cases, as the only tool to dig into the past are permalinks to specific topics (not to the whole ordered page contents at a particular time) and maybe keyword search. Diego (talk) 09:49, 11 October 2013 (UTC)

Diego Moya, I added your comment to Wikipedia talk:Flow/Design FAQ – we're trying to keep design-related discussions mostly on that page, and reserve this one for general questions/discussion about Flow features/strategy/rollout, etc. (it's totally okay to have some overlap, but I think it helps to have a separate page where we can get into the nitty-gritty implementation detail discussions). Maryana (WMF) (talk) 19:08, 11 October 2013 (UTC)

I'm curious, how do you classify and separate between design and discussion of functions? For me, having a table of contents is a feature / required functionality. A design discussion would be how to style that table of contents when available, how many items to show, which controls, etc. Diego (talk) 21:54, 11 October 2013 (UTC)

Not speaking for the team, but: I'd classify that as design in the sense that functionality is "the ability to do a thing" versus "how that thing is implemented". So "a heuristic for deciding what I should/should not have to pay attention to" is a feature/functionality. "Oh, we can use a TOC for that" is a design thing. Okeyes (WMF) (talk) 23:01, 11 October 2013 (UTC)

I probably would've posted it here, thinking of it as a "feature" not an "aesthetics" aspect, but it's an abstract/subjective distinction, depending on definitions/interpretations. Huzzah for confusing/complex language! Quiddity (WMF) (talk) 06:50, 12 October 2013 (UTC)

In such case, wouldn't "being able to communicate with others" be the only "feature", with everything else counting as "design"..? --Martynas Patasius (talk) 19:36, 13 October 2013 (UTC)

The features aren't just "being able to communicate". People also use talk pages to:

• Check whether an issue has already been discussed and decided
• Understand the background to a long-running discussion
• Look for links to a specific article or source
• Research the arguments made in the past by key participants
• Prove that they predicted a problem years before anyone else did
• Hunt for long-forgotten statements they hope will discredit potential admin candidates, WMF liaisons, etc.

Give such a wide range of uses I wonder whether we're paying sufficient attention to the volume of data on talk pages. For example, imagine the last nine years of Village pump (technical) ported to Flow. There's the current page with 42 topics on it, plus 168 archived pages (A–AX plus 1–118) with (average) 108 topics per page. That's over 18,000 topics. If that was presented as a "table of contents" on my screen it would be 438,000 pixels high, which is over 300 feet at 120dpi. There's no way a TOC can cope with that. - Pointillist (talk) 21:52, 14 October 2013 (UTC) Oh, by the way, if you're thinking that user talk pages don't attract many topics, check out User Talk for Iridescent, SandyGeorgia, Newyorkbrad, Eric Corbett, DGG, and Jimbo Wales. - Pointillist (talk) 22:07, 14 October 2013 (UTC)

Good point. It raises the question of what the unit of presentation would be for a Flow structured discussion. That applies both to the table of contents and also for the results of searches. Spectral sequence (talk) 20:40, 15 October 2013 (UTC)

Oops, minor correction to my last: When I referred to "the volume of data on talk pages" I was of course intending to include discussion pages in the "Wikipedia" space too. It would be rather strange to enable Flow on the "Wikipedia talk" pages without using it in new-editor-oriented places like Help desk, Teahouse questions, Editor assistance requests, Media copyright questions, and the Village pumps. - Pointillist (talk) 12:43, 16 October 2013 (UTC)

That is still communication (provided that we define "communication" broadly enough): it's just that in this case users communicate not with each other in the present, but with random strangers (still users in many cases) from the somewhat distant future (and this communication is one-way only). My point is that difference between "features" and "design decisions" is very artificial and not very useful... --Martynas Patasius (talk) 18:24, 21 October 2013 (UTC)

The current version of the Labs Sandbox implements what some comments already hinted at. It only allows replying to the original post, not to any replies to it. This is no longer a discussion but a "post your opinion and disappear" format. The ability to have subsections seems not to be incorporated into Flow either, which seems counterproductive. Grouping related discussions (related in time and topic) is one of the benefits of section/subsection. Why remove this? Fram (talk) 11:43, 11 October 2013 (UTC)

At least you can reply to the main comment -- I can't. It allows me to enter a reply, but nothing happens when I click the green Reply button. Similarly I can't add a new topic. And yet strangely I can change the title someone else has given to a discussion. That seems odd. Spectral sequence (talk) 16:22, 11 October 2013 (UTC)

The hazards of watching development work happen in real time :) Replying to posts/other replies is just a separate chunk of code that got finished but hasn't yet been deployed on ee-flow... should be there by the end of today! Maryana (WMF) (talk) 18:46, 11 October 2013 (UTC)

So here's an interesting feature. <math></math> displays as expected in the header (well done!) but when I come to edit the header again, it isn't there! (I'm using wikitext editing throughout, my browser isn't advanced enough to try VE.) Spectral sequence (talk) 21:42, 18 October 2013 (UTC)

Yup, there are some bugs with editing content - something to do with a roundtrip error, iirc. It is/was happening with comments, too (all except the first in each topic, are currently uneditable, once saved). Thanks for the bug-report though!

(also I added the templates currently listed at Wikipedia:Flow/Top_templates#Other_needed_templates, so {{math}} works now, too. :) Quiddity (WMF) (talk) 22:03, 18 October 2013 (UTC)

Sorry, {{math}} still isn't working. Whatever the argument, it produces <span class="texhtml"><nowiki>{{{1}}}</nowiki> which shows as {{{1}}}. Spectral sequence (talk) 06:25, 19 October 2013 (UTC)

I think that's related to Template:Math#Use of equals-sign and absolute value bars? The tests I've made all seem to work - I'm just copying examples from the template documentation due to non-familiarity with the topic. If you have a specific formula that isn't working, paste it below (or in my sandbox), and we'll see if we can work out what the problem is. Quiddity (WMF) (talk) 19:19, 19 October 2013 (UTC)

Ah, I think that's it: ${\displaystyle 2+2=4}$ is rather hard for {{math}}. {{math|1=2+2=4}} generates the correct display but still generates an unfamiliar wikitext <span class="texhtml">2+2=4</span>. But {{math|1=\sum_{n=0}^\infty 2^{-n} +2=4}} still does not render correctly. Both formulae render correctly inside <math></math> but as I reported above, disappear from the text. Spectral sequence (talk) 19:59, 19 October 2013 (UTC)

That doesn't seem to work here at enwiki either:

{{math|1=\sum_{n=0}^\infty 2^{-n} +2=4}} outputs as: \sum_{n=0}^\infty 2^{-n} +2=4

From what I can determine, {{math}} and <math></math> are not simply swappable containers. The formulas often need to be entirely rewritten. Help:Math#TeX_vs_HTML seems to be a good glimpse at the issues involved.

(Again, apologies for my unfamiliarity with the nuances of the topic and the templates. I'm just copying&testing with the examples I find in the documentation, or in articles.) Quiddity (WMF) (talk) 20:30, 19 October 2013 (UTC)

Ah! {{tmath}} is what is required for that. {{tmath|1=\sum_{n=0}^\infty 2^{-n} +2=4}} outputs as: ⁠${\displaystyle \sum _{n=0}^{\infty }2^{-n}+2=4}$⁠ I'll import that template to ee-flow, in just a moment. Quiddity (WMF) (talk) 20:36, 19 October 2013 (UTC)

Noted. But the requirement of the users is to be able to enter a formula such as ${\displaystyle \sum _{n=0}^{\infty }2^{-n}+2=4}$, have it display correctly, and then edit again later. Whether that be via {{math}} or {{tmath}} or <math></math> is one level of detail too deep. At this precise moment I see no useable way of entering mathematics markup in the current trial version. How developers choose to instantiate it is not something I want to prescribe right now. All I say right now is that neither of the obvious methods works. Spectral sequence (talk) 20:42, 19 October 2013 (UTC)

This is the "roundtrip error" bug. Sorry I don't have a clear technical explanation for the bug (I'm not a developer, and the devs are off enjoying their weekend!). From what I understand, it is currently saving things correctly at first, but then if we re-edit the (comment/header/content) it displays the html output rather than the markup as it should. This is a known bug (and it happens for all templates/markup, not just math, as mentioned in the subthread below), and is being worked on. (The same goes for the current lack of a [preview] button). HTH. Quiddity (WMF) (talk) 20:47, 19 October 2013 (UTC)

Indeed: {{tmath}} displays the formula correctly, but then disappears from the wikitext, just like <math></math> does, presumably because it wraps the formula inside math tags. Probably best to concentrate on fixing that round-trip problem first. Spectral sequence (talk) 20:51, 19 October 2013 (UTC)

I see that templates are being expanded into wikitext on a one-way trip: thus {{cite book | author=J. Smith | title=The Book} generates <span class="citation book">J. Smith. ''The Book''.</span><span title="ctx_ver=Z39.88-2004&rfr_id=info%3Asid%2Fee-flow.wmflabs.org%3AFlow&rft.au=J.+Smith&rft.aulast=J.+Smith&rft.btitle=The+Book&rft.genre=book&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook" class="Z3988"><span style="display:none;"> </span></span> which is (i) quite different (ii) incomprehensible (iii) impractical to edit further. Spectral sequence (talk) 06:30, 19 October 2013 (UTC)

Yup, that's what I meant above when I wrote "some bugs with editing content - something to do with a roundtrip error". Sorry for being unclear. It's being worked on. Quiddity (WMF) (talk) 19:18, 19 October 2013 (UTC)

It seems that we need a more precise language to hold the various conversations about Flow. Without a clear understanding of what it is we are talking about those conversation are likely to go nowhere. Indeed, I think we have seen examples of that happening here already.

Even "Flow" has several different meaning:

• The overarching project broadly conceived to formalise a set of structures for discussion and user interaction across the various Wikipedia and Wikimedia communities
• The formal project as a structure within the WMF work programme
• The group of people within WMF working on that project
• The software which will generate the discussion structures
• The software which will deliver the discussions to the users
• The user interface for the discussions

All of these might reasonably be referred to as "Flow".

Also referred to as Flow are

• Discussion structure, that is, a formal description of a discussion within a workflow, occurring in both in "source" and "executable" form

One might imagine that these would have names such as FreeFormDiscussion, GeneralRFC, AFDDiscussion, ... .

• Structured discussion, that is, an instance of a discussion with a given structure thought of as actually taking place somewhere.

It would be considerably clearer if we said, for example

• "Flow software will be implemented on page Foo, and the discussion structures allowed will be FreeFormDiscussion, GeneralRFC." rather than "Flow will be implemented on page Foo"
• "What discussion structures are needed for AFD and how should they work" rather than "Will Flow work for AFD"
• "In what discussion structures, if any, would editing another user's comments be useful" rather than "Should Flow allow a user to edit other users' comments"
• "Some discussion structures will allow users to modify their own comments. How will the Flow user interface present the changes in an easily understood format and what constraints does that put on the sofware" rather than "How will Flow cope with user changing their own comments"
• "Some discussion structures will allow certain subgroups of users to modify other users' comments. How will the Flow user interface present the changes in an easily understood format and what constraints does that put on the sofware" rather than "How will Flow cope with user changing other users' comments"
• "The overarching Flow project is over-ambitious in scope and the project team is under-resourced" rather than "Flow is too big and Flow is too small"

Maybe this will help structure our own discussion here. BTW please note that these are examples of topics already being discussed, not my personal views! To discuss any specific topic, whether using this wording or not, please start another thread! This thread is for discussing and hopefully agreeing a useful terminology. Spectral sequence (talk) 07:06, 13 October 2013 (UTC)

I like this a lot! I'll try to incorporate this lexicon into the main Flow portal page. Maryana (WMF) (talk) 23:11, 15 October 2013 (UTC)

Will the Flow software be freely available? What licensing conditions will be imposed? Is open sourcing likely in the future? Spectral sequence (talk) 06:23, 14 October 2013 (UTC)

A condition of employment with the Foundation is that all software is released under an Open Source license, so yes. Flow is licensed under the GPL, as is most of our software. --Jorm (WMF) (talk) 17:59, 14 October 2013 (UTC)

Thanks for that -- I think it's a point well worth emphasising in this project, even if applies more generally, because it will be relying on a significant amount of work by the community. Spectral sequence (talk) 18:35, 14 October 2013 (UTC)

It's a good point to make. I just had a sit-down with both Brandon and Maryana (well, I ran over to their desks and went "what do you think of...") about the idea of crediting people who help with the process of building, say, the workflows extension, in the extension documentation proper so there's a tangible outcome for users who help with this (beyond Flow working). Looks like that's what we're going to do :). Okeyes (WMF) (talk) 18:15, 15 October 2013 (UTC)

Glad to hear it. It's also consistent with the spirit of CCA on attribution, so would be what contributors primarily of content might be expecting. Spectral sequence (talk) 20:38, 15 October 2013 (UTC)

A few quick notes:

• Signup at WP:Flow/Newsletter if you'd like occasional condensed overviews of updates and requests for specific input.
• We'll be holding an IRC office hours session in #wikimedia-office at 18:00 UTC on 17 November to talk about Flow as a whole. (And more, in the future).
  • The most uptodate documentation pages are currently WP:Flow/MVP and WP:Flow/Design FAQ. Looking through those (if you haven't already) before the office hours, would be ideal.
• Oliver and I are still putting together a list of action items, per the request/suggestion from Guy Macon and Spectral sequence and others, to put in something like a {{to do}}. Ie. Items that particularly need community feedback, or items that we'd love assistance with such as populating example discussions - for the latter example, we're just waiting on a few core features to be fixed/added in the prototype, such as "reply-to-a-reply" (which should be in the next day or two), and waiting for me to transwiki more templates.

More news, and more specific details, soon and often. Quiddity (WMF) (talk) 21:54, 15 October 2013 (UTC)

Due to multiple-human-error (the best kind of error!) the Office Hours meeting was announced with the wrong month. The logs for today's (quiet) meeting, can be seen at m:IRC office hours#Office hour logs.

The updated time and date of our next IRC office hours meeting is: 18:00 UTC on 24 October. Thanks, and sorry about the mixup. Quiddity (WMF) (talk) 21:51, 17 October 2013 (UTC)

Thanks for putting the MVP together, having a tl;dr is always great. I should mention that I haven't really bothered reading any other flow discussions, so if my questions have been answered elsewhere, please trout me and I'll find them on my own. :)

A few things I didn't see in the MVP and was wondering about:

• Search: I assume everything will work normally?
• Moving "topics": if a user starts a discussion at AN, that should be on AN/I, how would a user move it?
• Under "Parsoid compatibility", it states that "most templates" would be usable. I'm not sure how it would work technically, but what is the planned distinction on a template that will work and that won't work?
• Opt-in/out: LQT had a #useliquidthreads function thingy to turn it on or off. Will flow have something like that?

Thanks, Legoktm (talk) 22:19, 15 October 2013 (UTC)

• Search: I assume everything will work normally? Depends on what you mean by "normally" :) The Platform team is currently working on an overhaul of Mediawiki core search functionality, so we're waiting on them to come to a good stopping point before diving into how this will hook into Flow. But yes, the goal is for site search to work on Flow objects, too.
• Moving topics. This isn't a feature we've built yet, and I don't anticipate a super strong need for it in the first WikiProject release. But it's definitely on our longer-term roadmap, since it'll be important to have before we roll out to spaces like AN(/I).
• Parsoid compatibility. Check out the Parsoid limitations docs for the list. The tl;dr is that the kinds of templates Parsoid can't handle are extremely rare. 99.9% of what users currently do with templates in article and talk namespaces will work just fine.
• Opt-in/out. For the first release, we probably won't have a publicly accessible config/function thingy, since we'll only be enabling Flow on a small number of pages (and monitoring them carefully, so we'll be able to turn it off quickly if anything goes haywire). But for wider releases, we'll definitely need to work out an easier method to enable/disable. That's still TBD :)

HTH! Maryana (WMF) (talk) 20:16, 16 October 2013 (UTC)

• Right, but I want to know if it will be included in the MVP. Really it should just hook into whatever the existing search system is. Flow shouldn't be dependent upon CirrusSearch or whatever the future is. Not being able to use search will be a huge loss of functionality, and a blocker IMO.
• Sounds good.
• Ah, that link is what I was looking for. I'll try and integrate it into the page to make it more clear.
• If you turn off Flow, what happens to the discussions that were using it? (In LQT they just disappear) Will existing discussions be converted when it gets turned on?

Thanks, Legoktm (talk) 17:33, 17 October 2013 (UTC)

A gentle reminder that Parsoid compatibility is not just about templates: it includes "advanced wiki syntax (math, IPA symbols, etc.)" as part of the MVP. Spectral sequence (talk) 20:25, 16 October 2013 (UTC)

Right, I just wanted to know about templates though. Legoktm (talk) 17:33, 17 October 2013 (UTC)

Hey all

So, as the deployment/engagement plans both say, the first release is going to be in a sandboxed environment - probably a MediaWiki copy on Labs. We're doing a lot of work to try to make it as close to enwiki as possible - copying things like site-specific CSS and JS over, the relevant extensions, gadgets, so on and so forth. Obviously one thing here is copying templates.

We've made a list of the top 250 templates in the Wikipedia talk namespace and copied them over: that's done. There are going to be some that are just as important for discussions, but maybe not used so commonly. We'd be most grateful if you could let us know of any you're aware of so we can import them to the Labs machine :). The existing templates (and the space for the ones we missed out) are both here; thanks in advance! Okeyes (WMF) (talk) 23:46, 15 October 2013 (UTC)

As long as you use Labs with its terrible privacy policy, I'm not going to help a lot, and certainly not test it there. Why not the testwiki instead? Fram (talk) 07:38, 16 October 2013 (UTC)

What's the privacy problem? - Pointillist (talk) 12:45, 16 October 2013 (UTC)

[1]: "By creating an account in this project and/or using Labs Services, you agree to comply with the Labs terms of use for Labs Services and acknowledge and agree your IP address will be made publicly available and not be treated as confidential regardless of whether you create a user account. You also agree that Labs volunteers will have access to any data you submit. This can include your IP address, your username/password combination for accounts created in Labs services, and any other information that you send. Labs volunteers are bound by the Labs terms of use, and are not allowed to share this information or use it in any non-approved way. Since access to IP address and other information is fundamental to the operation of Labs, these terms regarding use of your data expressly override the Wikimedia Foundation's privacy policy as it relates to the use and access of your personal information."(bolding mine, the rest isn't much better). There is no reason that people helping to test Flow should be treated like this, certainly when they may well be unaware of this (it isn't easy to find a labs pruivacy policy, I have to say). Fram (talk) 13:17, 16 October 2013 (UTC)

Thanks - very illuminating. - Pointillist (talk) 13:28, 16 October 2013 (UTC)

You're welcome. In the meantime (literally!), the privacy policy has been added to the main page of Flow at Labs[2], so at least the concern of "it isn't easy to find" is somewhat reduced. Fram (talk) 13:30, 16 October 2013 (UTC)

It should probably at least be added to or linked from [3] as well (hint for the unknown Flow editor :-) ). Fram (talk) 13:33, 16 October 2013 (UTC)

This is certainly a lot wider than is ideal :/. I'm going to try and hunt down someone to explain precisely why it works that way. Okeyes (WMF) (talk) 16:20, 16 October 2013 (UTC)

So, that privacy policy is evidently to deal with the fact that some instances on Labs are going to be run by volunteers, and it's possible to reconfigure MediaWiki to make such data publicly available. It shouldn't be interpreted as relating to the EE-Flow instance - technically it applies, but you're not actually at any more risk, in the sense that the people maintaining that instance (and, therefore, the people with access to that data) are precisely the same people who maintain and can access, well, enwiki. Okeyes (WMF) (talk) 17:00, 16 October 2013 (UTC)

Interesting. Does that mean that the enwiki sysadmins have access to plaintext passwords? That's not exactly best practice. - Pointillist (talk) 17:33, 16 October 2013 (UTC)

Ah, no, but I don't see plaintext passwords mentioned above either (am I missing something?) MediaWiki happily and correctly hashes and salts the living hell out of passwords. Okeyes (WMF) (talk) 17:36, 16 October 2013 (UTC)

Well, the blurb says "your username/password combination for accounts created in Labs services" and as it was written by the Labs project lead I wondered whether something mysterious was going on. As it happens, I don't re-use passwords, but some cockeyed optimists do... Anyway, thanks for the prompt reassurances. You might want to tweak the notice that Fram mentioned on the Flow labs main page, btw. - Pointillist (talk) 17:59, 16 October 2013 (UTC)

[off-topic]: Okeyes: Not really, it's still using md5. bugzilla:28419. Legoktm (talk) 19:01, 17 October 2013 (UTC)

If you need a medium-sized community to test Flow, how about the English Wikivoyage? We are quite close to Wikimedia and probably know Bugzilla/Gerrit/etc more than other communities. We were the first non-Wikipedia content wiki to get Echo, and early adopters for Wikidata too. Nicolas1981 (talk) 09:45, 16 October 2013 (UTC)

That sounds fun to explore :). @Maryana (WMF): what do you think? Okeyes (WMF) (talk) 16:21, 16 October 2013 (UTC)

Sounds fantastic – let's do it :) We've got an IRC office hours session tomorrow (Thursday 10/17) where we're hoping to chat about user needs for the trial release. Nicolas1981, can you let the Wikivoyage folks know that they're welcome to attend? Maryana (WMF) (talk) 17:36, 16 October 2013 (UTC)

When discussing VE, it has always been said that wikitext would remain available as is and nothing would change if you wanted to use wikitext. However, for FLOW (i.e. venetually for all talk pages), other claims are being made. Wikipedia:Flow/FAQ#Will Flow support wikitext or use the VisualEditor?. Why would we, for those pages that are more about text and less about templates, images, ... than e.g? mainspace pages or user pages, specifically promote a WYSIWYG editor instead of the existing, more text based editor? You basically don't need WYSIWYG in Flow. Is there any indication, at all, of what features are supposed to be available in VE for Flow that will not be available for Wikitext in Flow (even though, underneath VE, all pages are stored in Wikitext anyway basically)? Or is the FAQ just making statements from some misguided principle, even if there is no good reason to push VE here to the detriment of wikitext editing ("This editor will possibly be limited to accepting a subset of the wikitext language (e.g., it will likely balk at complicated templates or things like parserfunctions). I am not sure about tables.")? See also Wikipedia:VisualEditor/FAQ: "For editing Flow, there are plans to create a new "fallback" source editor with somewhat limited functionality." Baffling... Fram (talk) 10:36, 17 October 2013 (UTC)

My understanding, based on discussions I was involved with a couple of months ago, is that the underlying database will store its material directly as HTML5+RDFa; that this will cope with advanced markup such as mathematics; that Parsoid is capable of handling the conversions between that format and wikitext format; and that this covers the vast majority of what people may expect to write in discussions. However, that is simply my interpretation of what I was told by various WMF staffers at various early stages in the design process, and I very much endorse the request for an authoritative confirmation, or otherwise, from WMF staff, and for further details as well. Spectral sequence (talk) 16:29, 17 October 2013 (UTC) For the gory details on mathematics markup under Flow, see Wikipedia_talk:WikiProject_Mathematics/Archive/2013/Aug#Is_it_time_for_mathematicians_to_leave_Wikipedia? Spectral sequence (talk) 16:34, 17 October 2013 (UTC)

I'm going to rustle up someone who can explain in more detail - just popping in to say that I think there is an argument for WYSIWYG in Flow. Ignoring the debate over whether wikitext is better than the VE in ExampleSituationX (or vice-versa), people are actively using both systems in the mainspace and userspace; I think we have an obligation to maintain some sense of parity between namespaces in terms of what input methods are available. Okeyes (WMF) (talk) 17:03, 17 October 2013 (UTC)

It is extremely hard to edit mathematics markup in a WYSIWYG editor: it is reasonably easy to edit LaTeX markup in a text editor. Removing the ability to use a text editor to edit markup directly implies removing the ability to edit mathematics. I would say that establishes that there is an argument for wikitext editing in Flow. Please just say that you intend to keep it. Spectral sequence (talk) 17:12, 17 October 2013 (UTC)

Sorry; I was replying to Fram :). Fram: So, Erik Bernhardson (one of our Engineers) reports that both wikitext and the VE will have the same capabilities and permitted code, since both are being rendered through Parsoid. So there's no actual difference in functionality, it's just about making both input methods available to the end user. I assume it'll be controlled via a preference (maybe the existing VE preference would make sense?) so we don't have to bother people who don't want WYSIWYG editing. Spectral sequence: we are keeping some form of wikitext editing. What that looks like, I'm not quite sure - the Engineer I spoke to seemed to think wider support would be possible than Brandon's comment in the FAQ says, so I'm going to kick off an internal discussion about it and let you know when we have something consistent. Okeyes (WMF) (talk) 17:18, 17 October 2013 (UTC)

Thank you -- I look forward to hearing what your plans are. Spectral sequence (talk) 17:21, 17 October 2013 (UTC)

Looks like the answer is "we're going to burn that FAQ down and start anew". Quiddity will no doubt poke people when the new one is live :). Okeyes (WMF) (talk) 19:57, 17 October 2013 (UTC)

OK, thanks! Fram (talk) 06:54, 18 October 2013 (UTC)

A quick note that Wikipedia:Flow/FAQ has been significantly updated, and an additional point added to the design FAQ.

Also, a reminder that the IRC office hours meeting is: 18:00 UTC on 24 October. :) -Quiddity (WMF) (talk) 01:36, 23 October 2013 (UTC)

Has any thought been given to how editnotices will work on Flow-enabled talk pages? ☺ · Salvidrim! · ✉ 19:35, 22 October 2013 (UTC)

No, but that's a good point to raise! So, AFAIK, editnotices are used to:

1. convey information about what things not to post in a new topic (e.g., warning to newbies not to post their email or other personal information in questions on WP:Help desk)
2. let people know additional steps in the new topic workflow (e.g., that you have to notify a user after reporting them to WP:AN/I)
3. make sure the user is posting in the right place (e.g., Talk:Main page gets a lot of traffic from people who might actually want the help desk, etc.).

Does that sound about right? Are there use-cases I'm missing?

So, for 1), I think a lot of the basic how-to stuff could go away, because we're making it easy and intuitive to post new comments, and making it equally easy to moderate sensitive material (e.g., hide a post that has an email and let the user know directly that they shouldn't post it unless they really want to share that with the world). We could even build in a little wizard for new users who are posting to a Flow page for the first time, which would include a bullet point on what not to post. They could see it once, click a "got it" button, and be done with it. For 2), this would be something we'd just automate in the software. E.g., if we enabled Flow on AN/I, we'd let you add some people to a new message, and {{aninotice}} would get added to their user pages (or something to that effect). For 3), we'll be working on a fast, easy way to move threads that have been started in the wrong place to the right place, so this shouldn't really be a big deal.

My general feeling (supported by the user tests I've seen where newbies are asked to edit) is that editnotices are much abused and therefore pretty useless: they're so overloaded with text, warnings, tips, links, and clip art that they're impossible to process. If we actually want people to follow specific steps in a workflow, a wall of text above an edit window is not the best way to do it – it's much better to have messages appear briefly, in context, and only when they're vitally important to what the user is trying to accomplish. Maryana (WMF) (talk) 22:16, 23 October 2013 (UTC)

I kind of agree that IMO, most talk-space editnotices can be replaced with a header with directions and/or with usability to "fix" things after the post is live when needed. I'm racking my brains to come up with an example of a talkspace editnotice begin irreplaceable and I'm coming up with nothing, but I assume there's something I'm forgetting or ignoring. For example, while the WT:VG editnotice (which I hadn't really read until now) provides simple directions that can generally be considered "common sense" but could be genuinely useful to newer editors, I don't think it is irreplaceable by a header template.

In any case, since the post happens on the same page as the rest of the Flow board (as opposed to loading a new gateway page to make the edit as it currently the case), headers with directions will naturally replace most editnotices. Pop-ups are generally not something I'd recommend unless extremely justified. ☺ · Salvidrim! · ✉ 23:52, 23 October 2013 (UTC)

There is an article at http://www.technologyreview.com/featuredstory/520446/the-decline-of-wikipedia/ that touches upon Flow and other WMF software initiates. Key quote:

"The main source of those problems is not mysterious. The loose collective running the site today... operates a crushing bureaucracy with an often abrasive atmosphere that deters newcomers who might increase participation in Wikipedia and broaden its coverage. In response, the Wikimedia Foundation, the 187-person nonprofit that pays for the legal and technical infrastructure supporting Wikipedia, is staging a kind of rescue mission. The foundation can’t order the volunteer community to change the way it operates. But by tweaking Wikipedia’s website and software, it hopes to steer the encyclopedia onto a more sustainable path."

Like any magazine article, it has flaws and gets some things wrong, but in my opinion it also makes some very good points. --Guy Macon (talk) 01:17, 24 October 2013 (UTC)

I read it and very much agree; it seems to be going in the right directions. As someone in engineering, though, I'd say that the software is not the be-all and end-all; when we're out of the current bottleneck of technical debt I'd love to see us push effort into enabling volunteer efforts to reform the "crushing bureaucracy" or "abrasive atmosphere" (examples could be helping with things like research and A/B testing so we can look at if a proposed workflow helps or hinders). That's some time in the future, but it'd be good to do. Nice to see outside recognition of our work, though! Okeyes (WMF) (talk) 16:13, 24 October 2013 (UTC)

As I have said before, I think you are basically on the right track despite my sometimes acting as The Loyal Opposition. :) To my way of thinking, there are different classes of problems that deter newcomers, each requiring a different approach. Some new editors are put off by the edit screen with all the tildes, colons and square brackets. That's something that can easily be fixed in software. Some are put off by all of the WP:TLAs.[4] That could be addressed in software with some sort of shortcut expansion scheme, but it really requires a culture shift. Some are put off by the fact that something that seems as obvious as "I am an eye-witness, so I should be able to add my experiences to a Wikipedia page" is not allowed. In that case no software or culture change can help; the new user needs to be educated as to why we are not like Reddit and Slashdot. I think you are on the right path as far as fixing that which is fixable is concerned. Except where I disagree with you, of course. In those cases I am right, everyone else is wrong, and the sooner they accept my infallibility the better. :) --Guy Macon (talk) 17:45, 24 October 2013 (UTC)

TLAs: My favourite shortcut/essay is still WP:OMGWTFBBQ. :)

Re: "crushing bureaucracy" - one of the WP:Help Project's main goals is to reduce the instruction creep, but it's a monumental, complex/nuanced, and never-ending task. Additional patient and methodical people are always welcome!

Re: infallibility, see the very last grook on this page. (See also Piet Hein (scientist)). –Quiddity (talk) 23:23, 24 October 2013 (UTC)

And, from me, Re Loyal Opposition: I always joked, in my political work, that having an overwhelming win would be excellent for the politicians and terrible for the country. There's a grain of truth in that joke - I'm glad to have you here keeping us honest :). Now, back to working on that documentation you asked for! Okeyes (WMF) (talk) 23:24, 24 October 2013 (UTC)

My apologies if this has been discussed, but it seems that it would be helpful if some protections were generally cascading, but could be changed. In theory, protection could be done separately at the board, topic (and scratchpad), or post level. And it could be useful to separate "create new object" protection from "edit" protection.

I don't know what you're considering, but I was thinking of something like:

Board protection instance includes board scratchpad protection, new thread creation level, default thread protection levels. Thread protection includes 0thread scratchpad protection (as I've mentioned before, full Wikitext support, per-thread (or per-post) scratchpad, or inclusion/embedding of scratchspace items in posts needs to be part of the MVP), new post creation level (within thread), default post protection level, and possibly close thread or hide thread protection. (Delete should probably be restricted to Admins.) Post protection includes edit, hide. (Delete should probably be restricted to Admins.)

In some cases, the object creator (thread, post) might be able to edit protections, in addition to Admins.

Again, it may be too complicated to implement, but many file protection schema have cascading protections, and this system is supposed to be more modular than the existing discussion system, so one might expect protection to be modular.

Throwing this open for discussion; I don't consider it necessary for the MVP, but it might be necessary to build it in early if it were ever to be implemented. — Arthur Rubin (talk) 00:07, 25 October 2013 (UTC)

• Re: Generally cascading, but with a toggle: That sounds potentially useful, but can you find/think of a specific example or two? Diverse and explicit use-cases are the best motivations for feature-development!
• Urgency: It's definitely not needed for WikiProject discussion pages (the MVP target), but that's a good point, and I'll ping the devs to read this thread just in case underlying architecture is needed early.
• Further discussion: Definitely. And again, sharing existing examples of where this (or any feature) already does exist, or where it really should exist and we'd love it if it did, are ideal ways to bat the idea around. :) –Quiddity (WMF) (talk) 19:59, 25 October 2013 (UTC)

I'm trying to develop analogies from existing file-protection systems, in which a directory can be protected, but subdirectories might not be; and "traditional" BBSs, in which the ability to create threads, add to threads, and edit posts may have different userrights required; and threads can be locked (requiring "moderator" or "admin" rights to add to posts.) Specific workcases for granularity:

• In the rare event that a talk page (board) is semi-protected because of IP disruption, it might be desirable for some threads to be unprotected.
• A project might want to have some "announcement only" threads which can only be added to by a project manager. (Now, there is no need to build in "added to only by a specific editor" into the system, but it could be implemented by having an admin look at requests, as per {{editprotected}}.) This almost looks like having a "moderated thread", depending on whether the protection levels include "moderated".
• Even if posts would normally be protected, a user might want certain posts on his talk page to be unprotected, or all posts on his talk page to be unprotected. Conversely, even if posts would normally be unprotected, a user might want certain announcement posts on his board to be protected, or possibly all posts in a thread or his board be protected. (At present, users are given a fairly free reign for protection within their userspace; I don't see why that free reign shouldn't be granular.)

I don't have good workcases for inheritance, and I also don't see any reason why a board's "create thread" and "default add to thread" protections should be different, but I've explained why many of these options would be useful. — Arthur Rubin (talk) 19:10, 28 October 2013 (UTC)

Also, unless otherwise restricted, a user should be able to edit protections on his own talk board, per current en.Wikipedia protection guidelines; or, at least, the option should be built in to any protection scheme. I don't know if user talk subpages would also be implement in Flow, but that protection applies even more (under current en.Wikipedia guidelines) to talk subpages. — Arthur Rubin (talk) 19:19, 28 October 2013 (UTC)

• There are some interesting ideas for new features in there. On the one hand, I think we would want to be hesitant/careful about adding new restrictive features though, as the wiki-default/current-standard is just the 3 levels of non/semi/full protection for a page. Eg. "'announcement only' threads which can only be added to by a project manager" - I can see how that might be useful, but it requires creating either a new level of user-right, or some sort of list of "permitted editors", either of which would require a request/election process, and would reduce the openness of the wiki-process. On the other hand, this page of mw:Flow Portal/Functional Specifications/Moderation, Protection, and Refactoring from late August, agrees with you completely! (but does emphasise that it would very very rarely be warranted)
• Regarding current user-page protection policy, Wikipedia:Protection policy#User talk pages (and the "User pages" section below) seems to suggest that usertalkpages are only/rarely/temporarily protected in cases of further-abuse-prevention, and userpages can be protected at the owner's whim - but I'm not sure if that's exactly accurate...?
• Sub-pages are not planned to be included by default in Flow. (But we'll be able to switch it on in specific sub-pages, when wanted.)

HTH. –Quiddity (WMF) (talk) 19:41, 29 October 2013 (UTC)

I am just wondering if Flow will fix some of the problems in this thread (for example): Wikipedia_talk:In_the_news#Bringing_up_past_nominations_or_postings It is so long and convoluted, but if I try to print it to view later, all I get is small samples of the thread once the indentation is a few levels deep. XOttawahitech (talk) 15:16, 4 November 2013 (UTC)

I tried printing it with FireFox. The edit window expanded so that it showed all of the text, but the deeper threads had one word per line along the right edge. Firefox then cut off text on the right. From what I have seen so far, this is not going to be an issue with Flow. The developers are still in the gathering requirements / prototyping stage, but I will put printing deep indentation on my list of things I plan on testing. --Guy Macon (talk) 16:29, 4 November 2013 (UTC)

Hopefully printing won't be an issue; to be honest, I don't think we've put much thought into it directly (priority at the moment is making it functional, and then handling paper/accessibility for people with eyesight problems/browser compatibility, etc). The prototype version is going to include reduced levels of indentation which should help, but that's an experimental feature we'll switch off if there's an overwhelming need for more indent levels, so the problem may reoccur. Okeyes (WMF) (talk) 18:58, 4 November 2013 (UTC)

We did not have it a decade, we don't need to take yet another step in the Facebookication of Wikipedia for another decade. --Matthiasb (talk) 02:48, 16 November 2013 (UTC)

Sorry, but I don't think you chose the best approach...

First, "Nobody does need Flow" is inaccurate: WMF does seem to need it. Perhaps to justify their relatively great expenses, perhaps to avoid the loss of face, perhaps because they naively think this project will create "Heaven on Earth"... But in any case, WMF does not count as "nobody".

Second, this is not going to persuade anyone from WMF. You did not list any arguments and you do not have overwhelming numbers behind you at the moment. And I am afraid that the ones who push for "Flow" actually like "Facebook"... Yes, that might be tasteless, but you won't correct that tastelessness by one sentence.

Third, such outbursts might serve as pretexts for WMF to pretend that the opposition to "Flow" is irrational. That actually hurts our case.

And yes, I am telling you that as someone who does not happen to like "Flow" and WMF that much.

So, please, no more emotional outbursts. Tactics do matter. --Martynas Patasius (talk) 03:15, 16 November 2013 (UTC)

Sorry but I need Flow. Having a discussion where you post on my talk page and I reply on yours? That is so clumsy.

Leaving a comment on an article talk page and having to check back every wek or so to see if there has been a reply? Also clumsy.

Having every response to my comments on one page, where I can find them and reply to them; that would be great. filceolaire (talk) 08:15, 16 November 2013 (UTC)

I need Flow, and I still use Gopher on a regular basis.[5] See http://gopher.floodgap.com/overbite/ --Guy Macon (talk) 10:31, 16 November 2013 (UTC)

Ditto, as a frequent IRCer (although obviously, as a WMF staffer I'm just trying to justify my salary ;)). Okeyes (WMF) (talk) 19:11, 20 November 2013 (UTC)

What I needed (badly!) was a Wikibreak, and now that I look back here, I'm happy to see how peaceful this talk page is! --Tryptofish (talk) 21:39, 20 November 2013 (UTC)

Personally, I do not find Flow intuitive after becoming familiar with the current format of Talk pages. I think if it is released it will alienate many experienced Wikipedia contributors. The great thing about the current Talk system is that it functions identically to articles. This means -- if you can edit a Wikipedia article, then you should have no problem contributing to a Talk page. Current Talk pages use Wikipedia:Wikitext, lending to amazing flexibility and sophisticated usage. I would much prefer WMF simply patching the current system.

Talk pages are not supposed to function as forums do. The open talk format (Wikipedia:Wikitext) discourages lengthy threads and flame-wars.

67.252.103.23 (talk) 01:03, 21 November 2013 (UTC)

I'd agree and disagree. So, some degree of adjustment is to be expected with any new system, and I don't begrudge you for not finding it intuitive as someone familiar with the status quo (I didn't, to start with). Are there any specific things you can point out that we need to improve on?

I also agree that talk pages are not supposed to function as forums do; that's not really our goal (when I think "forums" I think highly structured content existing in completely discrete locations) - we just want to make talk pages more intuitive to use. At the moment, as you say, wikitext is the primary hurdle to cross when using both articles and talk pages, but it's not the only hurdle by a long way; having to learn two different systems will increase complexity, but hopefully the cognitive load of learning to use talk pages overall will be reduced. Okeyes (WMF) (talk) 17:48, 21 November 2013 (UTC)

I just hate to see the use of Wikitext be discouraged. You can do pretty incredible stuff with categories, substitutions, templates such as

foo

 Question: bar

and other stuff that I fail to see how Flow will support effectively. It feels like Flow cuts itself off from the rest of the MediaWiki ecosystem.

24.97.221.98 (talk) 20:33, 21 November 2013 (UTC)

I think that is a potential problem (although it's worth noting Flow does support wikitext, and will continue to) - I guess the plan is to look at a less syntactically complex way of achieving the same things.  Question: is necessary to specify a question, but what if the workflows system supported "question-adding" as a potential task? Discussions wouldn't need templates to nearly the degree they do now. Okeyes (WMF) (talk) 23:17, 21 November 2013 (UTC)

(edit conflict)Templates and wikitext all generally work as-per-usual in Flow. I imported a few hundred templates to the prototype server, and tested some of them at my talkpage there. The first release on production wikis (mediawiki and English Wikipedia) (which will only happen after the sandbox release and request for feedback which is coming soon), will have only wikitext as the input method; in future months, a VE input method will be added as an option, so that editors who like/prefer that, can use it. There are no plans to discourage wikitext. (I adore wikitext. Many of us do.)

What's coming initially, is just the core user-to-user discussion system, with the bare minimum of feature-sets. Then over the course of the following months, (we/they) will all be working out exactly what else we need, and want, to add to it, so that it can be built up into the something that we all want to use, and that integrates discussion and collaboration into mediawiki in equal and better ways than we currently have. –Quiddity (WMF) (talk) 23:23, 21 November 2013 (UTC)

Hey all

So, a couple of things I'd really like some feedback on:

• For the sandbox release (that's "have everyone hammer on it on a labs instance, where it can't do any damage if it breaks, and try to break it") we've written up a semi-compressed release and engagement plan here I'd be very grateful if you could let me know what I've missed out, and how people feel about the plan.
• I've written up the first draft of the new contributors survey. What's missing, what's wrong, what else needs to be asked? Let me know (User:Liz, This Means You ;p). Okeyes (WMF) (talk) 00:11, 13 November 2013 (UTC)

I'll do what I can. ;-) Liz ^{Read! Talk!} 00:15, 13 November 2013 (UTC)

P.S. You know, through all of my academic endeavors, I've never run into people who use the word "tranche" except for Wikipedia. We just usually say test group, cohort, class, segment, etc. L.

Yeah, I'm used to using "cohort" or "bucket" - I'm not sure where in the movement gestalt "tranche" came from, but it's taken hold of my brain. Okeyes (WMF) (talk) 01:15, 13 November 2013 (UTC)

OK, I am not Liz, but I also like the idea of using data instead of just guesses to find out what the supposed beneficiaries of the system need. So, some comments about the current state ([6]) of survey draft:

• The goal "How they understand the purpose of talkpages" is useless, unless we use it correctly. The wrong understanding of the goal of discussion system simply means that all other answers of the given user are irrelevant to us. After all, "Flow" is not supposed to change the purpose of discussions in Wikipedia.
• Other goals are fine.
• "That's fine for experienced users, but a hurdle for newcomers, many of whom haven't used talk pages before (or have had difficulties doing so)." - please do not poison the well. The survey simply gives us a larger and "more random" sample; there is something to be said in favour of survey of "experienced users" as well.
• The sample is taken from "users who have registered in the last 2 weeks, and made at least 5 edits during that period, and not been blocked" - why not a month..?
• Out of options for distribution the second one ("We can liaise with the Growth team to display a notification or message to users falling within that class for a certain time period.") is the only one that is acceptable. "More of that delivery process would be automated (automated is good!) but it requires engineering time, either from Growth or Core." - yes, it often takes some effort to do things right. Did you imagine anything else will be the case for "Flow"..?
• Then, the questions... "If you wanted to start a discussion with other users on Wikipedia, do you know where you could do that?" - well, sure - in a pub! OK, here you want to find out if users have noticed the talk pages, thus you must formulate the question in a way that rules pubs out. Maybe you could show some images that highlight talk pages and ask if they are familiar with, well, talk pages..?
• "Which of these types of discussions do you think are appropriate to have on a Wikipedia discussion page?" - "Wikipedia discussion page" might be understood to mean a discussion page in Wikipedia namespace, like WP:ANI. Change it to "article talk pages" or just "talk pages" (the term should be introduced in a previous question).
• "Asking for help" is ambiguous. It might be help related to Wikipedia or help related to some homework...
• "Have you tried contributing to Wikipedia's talk pages?" - "contributing"..? Just "using".
• "I find it easy to discover when other people have replied to a conversation I am participating in" - OK, I know you want to get answer "No" and use it as evidence in favour of "Flow", but new users are rather unlikely to have the opportunity to get replies in just 2 weeks...
• What you should be asking is "Was anything hard while using the talk pages?" and "Are there any specific reasons why you did not use the talk pages?". The answers must include something like "I had nothing useful to say.", "The subject of discussion was hard to understand.", "The participants of discussion seemed to be hostile or impolite.", "It was hard to find the discussion.", "It was hard to express my opinion in English.", "It was hard to write using the technical means being used in Wikipedia."...
• If you have a goal to find out "How good or bad they find the current system", ask the question about it.

Maybe that should be enough for now... --Martynas Patasius (talk) 09:40, 16 November 2013 (UTC)

In order:

1. Well, yes. That's why we're asking how they understand the purpose of talkpages.
2. I'm not sure how that's poisoning the well (or has any impact on the survey; that's not included in the survey)
3. A month is perfectly valid - I'll expand to a month tomorrow when we've given some time for replies to filter in.
4. Why are the other two methods not valid?
5. That doesn't seem to be a valid interpretation; see the clause on Wikipedia.
6. Talk pages are problematic: people may not know them as "talk" pages (it's the same problem that "discussion pages" has, just from the other direction).
7. Possibly, but frankly things like the refdesk means that already exists and is a use case we have to support. Since we're limiting the pool to people who've made >5 edits I suspect the users who are being questioned aren't here for that kind of assistance.
8. I'll reply when you can phrase it in a way that doesn't assume bad faith.
9. A good suggestion, but we're hoping long-form questions about this will provide more interesting data. "It was hard to understand" doesn't tell us why - is the text hard to read? is it difficult to distinguish comments?
10. We do. Okeyes (WMF) (talk) 19:24, 20 November 2013 (UTC)

Thank you for the answer. Now, in more detail:

1. OK, it's nice to see we agree.

2. Well, I do find constant rather pointless "pro-Flow" propaganda (true, I am not sure who is supposed to be persuaded by it - that draft won't be read by many) rather annoying. You just do not have to repeat and repeat and repeat that talk pages are "a hurdle". And I'd say that a draft (and the survey questions) should stay neutral, not "pro-Flow" or "anti-Flow".

3. OK, I see we agree here too.

4. I did not say the other methods are "not valid". They are just significantly worse. Why? For example, as the survey draft itself says: "The problem with this is twofold; first, it increases the chance of "junk" data from people other than the intended recipient filling out the survey. Second, it undermines the neutrality of the data provided by forcing everyone to, one way or another, experience discussion pages in a highly limited way.". And the problems with the third method have been explained on the talk page by Kudpung ([7] "I'm not sure about the legal/ethical issues of extracting email addresses and mailing users direct. It would perhaps also be interesting to know how many new accounts actually provide an email address, and how many have enabled the "Email this User" feature."). The only significant listed disadvantage of the second approach is cost (in money, in time, in effort). And I advise you to disregard it. If you really want to save money that badly, cancel the "Flow" outright (whatever you think, it is not going to be free). Closing down "Funds dissemination committee" (sounds like "Waste of money committee", doesn't it?) would be another better method to save money, if that is needed that badly...

5. OK, do you want the respondents to ponder what does that sentence really mean ("How is 'on Wikipedia' different from 'of Wikipedia'..?"), or do you want them to answer your question..? Especially when you want to find out if the "less bright" newbies (who cannot figure out "wikitext" on their own) want..? That sentence needs to be simplified. It doesn't have to be defended, unless you'll be there to "defend" it from respondents. That's all.

6. That's why I have recommended using images to show what do you mean by "talk pages". However, "talk pages" have no competing meaning and "discussion pages" might have one...

7. "Possibly, but frankly things like the refdesk means that already exists and is a use case we have to support. Since we're limiting the pool to people who've made >5 edits I suspect the users who are being questioned aren't here for that kind of assistance." - you assume too much. Of course, you also assume that "Flow" will not be a disaster... And someone else assumed that "VisualEditor" will not be a disaster... And... Well, I guess you should see the pattern...

8. "I'll reply when you can phrase it in a way that doesn't assume bad faith." - Wikipedia:Assume the assumption of good faith... I was assuming that you like "Flow", want it to succeed and want the opposition to calm down (and using this survey might be seen as a way to do so). Those things might be tasteless and silly, but I wouldn't say they count as bad faith, bad intention. Do you claim they do..? (Hint: it is not in your best interest to answer "Yes!", even in jest.)

9. "A good suggestion, but we're hoping long-form questions about this will provide more interesting data. "It was hard to understand" doesn't tell us why - is the text hard to read? is it difficult to distinguish comments?" - answers to open-ended questions are notoriously hard to interpret (do you think you will not get "It was hard to understand." in the answers to your questions?). And they make any statistical analysis much harder. Also, I am not saying that such multiple-choice questions should replace the original ones. They can be used together.

10. "We do." - no, you do not. There is no question that asks "Did you like it..?". "What parts of discussion pages work well", "What parts of discussion pages work poorly" or "I find discussions easy to contribute to." are close, but not close enough.

I guess that is all for now... --Martynas Patasius (talk) 03:56, 22 November 2013 (UTC)

2: the survey questions are neutral. The draft survey is neutral. You're talking about an introduction intended to provide context to people reading it, not something included in the survey :).

4: there aren't any legal issues (we've done this before without problems).

7: I think that stating that I want Flow to succeed to the point where I'm trying to drive something neutral - namely a survey, which as with most forms of research isn't valid unless it's as unbiased as possible - in a direction in line with particular views is an assumption of bad faith. Namely, you're assuming I'm motivated by something other than Getting It Right. Okeyes (WMF) (talk) 17:37, 22 November 2013 (UTC)

Let's see...

2. Yes, I know. And, as one fourth of users who have actually read the draft and commented on it (I have counted you, Liz, Kudpung and myself, unless there is one more venue for discussion), I still feel a bit annoyed and not a tiny bit persuaded...

4. Nice to hear that there are no legal issues. That still leaves all other problems.

7. (actually, it should have been 8., right?) "I think that stating that I want Flow to succeed to the point where I'm trying to drive something neutral - [...] - in a direction in line with particular views is an assumption of bad faith. Namely, you're assuming I'm motivated by something other than Getting It Right."... It's "assume good faith", "assume good intention", not "assume the intention that is perfectly and purely aligned with Wikipedia's goals". And I doubt it is reasonable to assume that you are not "motivated by something other than Getting It Right". If you were motivated by that and nothing else, you would be trying to get more criticism of the survey out of me, to find more ways to improve it. Instead, you are mostly defending the survey draft and looking for something "procedurally wrong" in the presentation of the criticism... That is not the most efficient way to make the best survey... Now, lest you object again, that is probably caused by mere misunderstanding of my words, coupled with perfectly normal willingness to be respected (etc.) and, perhaps, insufficient understanding of WP:AGF... No bad intention, but that is something different than pure "Getting It Right"...

I would also ask you about other points (did I persuade you?), but it looks like discussion doesn't matter that much now, given that it looks like you have started the survey already ([8] - or maybe that "survey [...] is currently open" doesn't mean "survey has started"..?)... I have to admit I am rather disappointed... So much for "Getting It Right"... --Martynas Patasius (talk) 20:51, 22 November 2013 (UTC)

The statement on the "Expected" side seems misleading. Your (the WMF, or at least, the Flow Team's) expectations seem to be "A simple comment field with a restricted format". If that's not the user's expectation, the disconnect needs to be explained. If it is the user's expectation, then it should be stated that way. — Arthur Rubin (talk) 11:45, 14 November 2013 (UTC)

All of the entries there should be understood to be user expectations - staffers don't have expectations of a simple comment field with a restricted format, because (I'd hope) staffers have edited pretty frequenty ;p. Okeyes (WMF) (talk) 17:23, 14 November 2013 (UTC)

People who have read the discussions now expect a simple comment field with a restricted format, although if Parsoid is expanded to handle anything which resolves to "legal" HTML, rather than something where each user-entry-element is required to be something which resolves to "legal" HTML, that would be different. — Arthur Rubin (talk) 22:29, 14 November 2013 (UTC)

I'm somewhat confused by that, I'm afraid. Could you clarify? Sorry to be obtuse - I promise it's not intentional :/. Okeyes (WMF) (talk) 23:33, 14 November 2013 (UTC)

Until such time as "Flow" messages are allowed to include (or transclude, or otherwise display) any Wikicode which is legal (and generates valid HTML, even if not accepted by [the present incarnation of] Parsoid) in articles, the format is restricted. The product as conceived by some of the WMF people here seems to disallow use of paired templates which are presently used in some articles, where the first generates an open HTML tag, and the second closes it. That's a restriction. Unless some WMF people deny that is intended, it's a planned restriction. — Arthur Rubin (talk) 18:59, 17 November 2013 (UTC)

That makes a lot more sense, but I'm not sure if paired templates are rejected - unless your argument is they're rejected in parsoid? Okeyes (WMF) (talk) 19:12, 20 November 2013 (UTC)

According to the documentation, Parsoid would reject paired templates if fully implemented. The implementation used by VE apparently isn't as documented. I don't know if I could depend on undocumented (in fact, anti-documented) features being retained as Flow is rolled out. — Arthur Rubin (talk) 01:36, 21 November 2013 (UTC)

Ech; yeah, that's non-ideal, but I'm not sure if it's a problem we can solve for - what Parsoid implements if what Parsoid implements. When the VE team is back from India I'll poke them and get their perspective on this (feel free to ping me if I forget and go silent). Okeyes (WMF) (talk) 17:49, 21 November 2013 (UTC)

Some paired templates can be replaced by single templates, although more complicated multiple templates (succession boxes?) cannot, as far as I can tell. Further discussion as to the details of the MVR of Parsoid would be more appropriate on a Parsoid talk page on en.Wikipedia. — Arthur Rubin (talk) 20:12, 22 November 2013 (UTC)

Agreed, but I don't think there is one - it's usually bundled in with Wikipedia talk:VisualEditor. Okeyes (WMF) (talk) 17:19, 25 November 2013 (UTC)

Just a note that the survey (discussed above) is currently open, aimed at 1 month's worth of new users with >5 edits who aren't blocked. Let's see what happens :). Okeyes (WMF) (talk) 17:49, 22 November 2013 (UTC)

Probably going to close it today and start the analysis. Should have it for people some time next week (Thanksgiving is playing havoc with timing. Bah.) Okeyes (WMF) (talk) 18:16, 25 November 2013 (UTC)

Unhelpful commentary Risker (talk) 22:28, 26 November 2013 (UTC)
The following discussion has been closed. Please do not modify it.
So, we have a survey with such "history": It has been drafted between 2013-10-29 ([9]) and 2013-11-07 ([10]). It has been mentioned here on 2013-11-13 ([11]). The mention has explicitly called User:Liz for comments. It has been commented upon by three users: Liz, who has promised to look into it and commented about terminology ([12]) - 2013-11-13. User:Kudpung, who commented about possible ways to perform the survey ([13]) - 2013-11-14. Me ([14] - 2013-11-16; after response - [15] (2013-11-20), one more comment: [16] - 2013-11-22). The last edit on the page dedicated to survey is dated 2013-11-07 ([17]). The survey has been reported to start on 2013-11-22. I have protested about unfinished discussion ([18] - 2013-11-22). The survey has been reported to end on 2013-11-25. Thus, WMF (the matter was handled here by User:Okeyes (WMF), but I do not know who was responsible for what): has failed to wait for the discussion about the design of the survey to end or get to a "stable state"; has failed to document the survey accordingly (they did have to choose the method of presenting the survey for the respondents, but it cannot be found from the page in "mediawiki.org"); has (apparently) failed to use any suggestions from the community (with exception of my proposal to change "2 weeks" to "1 month" - the change which hasn't been documented properly); has (apparently) made a badly thought-out survey (as it looks like next to no criticism has been taken into account)... So, it looks like WMF couldn't handle making something as simple as a survey, even using some advice from the community... They couldn't take their time for (in "immortal" words of their representative - [19]) "Getting It Right"... And we are supposed to believe that they can create "Flow" (something much harder to make) well..? Will they take their time..? Do they really have the required competence and humility..? I'd say they have praised their own competence a little too often... --Martynas Patasius (talk) 19:26, 25 November 2013 (UTC) On the contrary, we've spent a lot of time walking back previous statements about Flow specifically and the success chances of our processes generally. So, let's be clear here: I posted the survey draft, we sent out notices to newsletter recipients and other interested parties (and posted a note here), and a week later I'd received two sets of comments. That's not really concerns from "the community", that's concerns from "a couple of users" - which is absolutely fine, but let's not use hyperbole. Where I agreed with the criticisms and thought them viable (the time period, for example, or Kudpung's concerns about namespace restrictions) I changed the survey. Where I disagreed with the criticisms (that "talk page" would be any clearer than "discussion page" - really, both of them are subject to the same problem, just from opposite directions) they weren't. Unless something has actual, substantive consensus that it's needed that's going to happen from time to time. I think the biggest problem here is not updating the documentation/posting the survey/generally being transparent about what had been incorporated and how things were being done - I'm going to try and do all of that tomorrow (we have a day-long meeting today. blah.) and do better in the future. Okeyes (WMF) (talk) 20:27, 25 November 2013 (UTC) Sorry not to look in at things sooner, I didn't realize you were on such a tight timetable. Liz Read! Talk! 20:32, 25 November 2013 (UTC) That's okay; I'm going to look into running another survey (this one for more experienced users); I'll try to set out timetable restrictions more clearly there, and your feedback would be most welcome :). It's sort of a circular problem, unfortunately; if we take ages doing our research we have to go into things without having the research complete in advance. If we try rapid iterations on data and producing things as we go, we have to move faster and that limits our ability to be responsive. Okeyes (WMF) (talk) 21:35, 25 November 2013 (UTC) "So, let's be clear here: I posted the survey draft, we sent out notices to newsletter recipients and other interested parties (and posted a note here), and a week later I'd received two sets of comments." - in words of Ostap Bender (from "The Twelve Chairs"), "Only cats multiply quickly.". If you only got two sets of comments after a week, wait a second week. A third. A month. Ask, beg, plead for more comments. Only then give up. There is no deadline - or, at least, there must be no deadline. Wikipedia also wasn't written in a day. "That's not really concerns from "the community", that's concerns from "a couple of users" - which is absolutely fine, but let's not use hyperbole." - well, I might have called you "WMF" as well, yet you do not seem to be complaining. Anyway, well, those comments didn't fall from the sky, they were from the community. Also, speaking of "hyperbole" - try not to claim you are solely motivated by "Getting It Right", when you seem to be more concerned by the schedule rather than the quality... That, by the way, was the one of the main problems with "VisualEditor" as well. I hope WMF has learned something from that... But even if they haven't, honesty is a virtue. Be accurate about your priorities. "Where I agreed with the criticisms and thought them viable (the time period, for example, or Kudpung's concerns about namespace restrictions) I changed the survey." - well, if there is no documentation, you haven't demonstrated that you have accepted anything - as far, as I am concerned. "I think the biggest problem here is not updating the documentation/posting the survey/generally being transparent about what had been incorporated and how things were being done" - well, you say that as if lack of transparency and proper documentation was a minor problem. Documentation is vital for all non-trivial software-engineering projects. Also, WMF claims that "transparency" is their "Core value" ([20] - "We must communicate Wikimedia Foundation information in a transparent, thorough and timely manner, to our communities and more generally, to the public."). I do not sense that you (or anyone else in WMF) take those statements seriously... "I'm going to try and do all of that tomorrow (we have a day-long meeting today. blah.) and do better in the future." - good. Let's hope that you succeed. --Martynas Patasius (talk) 21:49, 25 November 2013 (UTC) Let's assume for the sake of argument that "WMF couldn't handle making something as simple as a survey" (the truth is more likely to be "WMF didn't handle the survey the way Martynas Patasius wants them to"). Does it logically follow that they cannot do a good job on Flow? No. I can turn your argument around; WMF created the software that runs the world's most successful online encyclopedia, so of course they can create Flow. I am getting a bit tired of the constant WMF bashing from a small subset of users. It is boring and unhelpful. Instead, look at the way I handled things when I had a criticism/suggestion; I asked for a document that captures what has been decided about Flow. (Yes, some things have been decided. Auto-signing instead of ~~~~, for example.) After some back-and-forth discussion and refining of the idea, they agreed to create such a document. If my arguments had been full of personal comments (saying that they can't do anything right, saying that they lack competence and humility) we would have never been able to decide as a community what that document should contain. That's right, I said community. Maryana, Guy Macon, Okeyes, Arthur Rubin, Jorm, Tryptofish, etc. are all part of the same community, not the a separate WMF Community and English Wikipedia community. We have essentially the same goals even though our roles differ. Why don't you try making some specific, constructive suggestions instead of being our resident sniper? "It turns out that human communication includes a sideband of non-verbal cues and without those, people's ability to avoid arguing is impaired. Also, online there are no consequences to calling someone a half-shaven chimpanzee with delusions of ability [1], whereas face to face there may be. Do not, for example, use the phrase "you moron" when explaining to a half-naked crazed drug user that the device that he is currently trying to shoot you with is not, in fact, a gun. "There's a classic study from the late '80s, early '90s where roups were given a problem to solve. One set was in the same room, the other on terminals. The first group came up with a solution whereas if I recall correctly the second group not only failed but the disagreements were so acrimonious that some of the members had to be removed from the building through separate doors." "1: The exception is threatening the President of the United States, which can produce real world results in a surprisingly short time." -James Nicoll --Guy Macon (talk) 20:36, 25 November 2013 (UTC) "Let's assume for the sake of argument that "WMF couldn't handle making something as simple as a survey" (the truth is more likely to be "WMF didn't handle the survey the way Martynas Patasius wants them to"). Does it logically follow that they cannot do a good job on Flow? No." - well, let's take one example. What will be easier to document properly: the whole "Flow" or just this one survey..? If the survey hasn't been properly documented, is it reasonable to expect that "Flow" will be..? And I doubt it is possible to finish the project successfully without proper documentation. "I can turn your argument around; WMF created the software that runs the world's most successful online encyclopedia, so of course they can create Flow." - WMF was founded in 2003. Wikipedia was launched on 2001. I don't think it is accurate to say that WMF has "created the software that runs the world's most successful online encyclopedia". They have maintained it after someone else has created it. "Why don't you try making some specific, constructive suggestions instead of being our resident sniper?" - would you count [21] as "specific, constructive suggestions"..? "Instead, look at the way I handled things when I had a criticism/suggestion; I asked for a document that captures what has been decided about Flow. [...] After some back-and-forth discussion and refining of the idea, they agreed to create such a document." - actually, that is a part of the problem. After all, it is the "Flow" team itself that needs all this documentation. Why do they have to be "forced" to write it..? Anyway, one of the reasons why I am disappointed is that in this case that "back-and-forth discussion and refining of the idea" was cut short. And the calmer "protest" ([22]) has failed to get any response. Oh, and, to avoid misunderstanding, about "saying that they lack competence and humility" - my point is that I am not sure "Flow" is actually achievable. In that case we need unbelievable level of competence coupled with humility of canonised saints. Enough to be very very careful. "We will try" instead of "We will do". Refusal to have any deadlines. And readiness to cancel the project if it proves to be really impossible. Finally, since you do not seem to think much of my "protest", I would like to ask you: how would you have worded it in my place..? Or do you think I should have kept my silence..? --Martynas Patasius (talk) 23:04, 25 November 2013 (UTC) If your only two options are silence and doing what you have been doing, pick silence, because both choices lead to the same result. (I am saying that what you have been doing is completely ineffective.) Read your own words above. They are dripping with contempt. How is that working out for you? If you talked to people like that in real life, you would get your ass kicked. --Guy Macon (talk) 02:39, 26 November 2013 (UTC) OK, so, I asked you for ways for rewording and I get "If your only two options are silence and doing what you have been doing, pick silence"... You know, if you do not want to offer more useful criticism, you can just say that... Still, it would be nice of you to try... "Read your own words above. They are dripping with contempt." - well, I think that they are not. Maybe I am wrong. But you didn't explain what exactly could have been said better, thus, unfortunately, I end up with that belief unchanged... "I am saying that what you have been doing is completely ineffective." - well, is it..? You have claimed you were successful, because you got the WMF to give a promise to create some document (in Wikipedia talk:Flow/Archive 4#Down The Rabbit Hole Once Again, I guess). Good. However, if you are going to look at this discussion, I also "got" a promise to update one document ("I think the biggest problem here is not updating the documentation/posting the survey/generally being transparent about what had been incorporated and how things were being done - I'm going to try and do all of that tomorrow") - and a very "generic" promise to "do better in the future" as a "bonus"... Does that count as a good result..? Well, in both cases I would prefer a small change that has already been done to a major change that has only been promised (I haven't seen the document promised to you and the update promised to me didn't happen yet - of course, "tomorrow" isn't over)... But a promise is better than nothing. On a hopefully unrelated note, we did have some statements that were understood as promises outside of WMF and as something non-binding inside WMF. And I would note that in discussing that (for example, on Wikipedia talk:Flow/Archive 4#No edit conflicts? you were not very "soft" either... Still, we do not have a duty to be "soft". We do have a duty to obey WP:AGF (which does mean that, as far as possible, all problems have to be written off to some kind of incompetence rather than bad faith - which explains why it is actually good (in a sense) that WMF have been called incompetent so many times - it is by no means the worst option). We have to try to be polite (for example, no swearing). We should try to encourage every WMF representative who tries to be just a little more friendly, responsive, careful, polite, cooperative. But we do not have to act as if everything was fine. --Martynas Patasius (talk) 19:34, 26 November 2013 (UTC) Re "I asked you for ways for rewording", Nope. Not playing that game. It would not lead to you following my suggestions, but rather to you picking apart each sentence after quoting it in italics. Been there, done that. Your previous comments about WMF are dripping with contempt. Either you have the ability to write something that is not dripping with contempt or you don't. If you don't, WP:COMPETENCE applies. If you do, then I suggest that this is a good time to start. --Guy Macon (talk) 21:44, 26 November 2013 (UTC)

I've closed the above exchange because it is unhelpful and wandered very far off topic. Martynas Patasius, it is very clear that you don't have much use for this proposed feature, or for the WMF staff who are working on it; your commentary on this page has been aggressive bordering on the abusive. I strongly urge you to take an extended break from this page, and remove it from your watchlist, as your monopolization of the discussion and negativity toward this feature and the WMF staff working on it is adversely affecting the ability of others to comment and productively respond. Before you start jumping on me, keep in mind I'm not a big fan of this feature myself. You've made your position clear on this page; now it is time to move on. Risker (talk) 22:28, 26 November 2013 (UTC)

"aggressive bordering on the abusive"? Incredible hyperbole; I find it hard to believe that someone could be so bad at communication that they genuinely believed that, but apparently you do. It's an entirely unwarranted slur on Martynas Patasias' character, and I am repulsed to read it in a closing comment from you, where it will be left on public display until doomsday. For shame. I think you should consider taking an extended break from discussions on Wikipedia, preferably somewhere that people understand the meanings of words like "aggressive" and "abusive" and are able to educate you on where and when to use them correctly. — Scott • talk 20:13, 27 November 2013 (UTC)

Risker nailed it. --Guy Macon (talk) 21:51, 27 November 2013 (UTC)

I agree with Risker and Guy. --Tryptofish (talk) 23:01, 27 November 2013 (UTC)

Hey all,

So, I've now finished analysing the (brief) survey we sent out to new contributors asking them about their talkpage usage. To summarise: a lot of the requested improvements and noted deficiencies in talk pages that respondents provided are in line with Flow, most new users don't know about or haven't used talk pages at all, and around 65-70 percent of those few who have are satisfied with the setup.

Broadly-speaking this is supportive of Flow, but I have some concerns about the survey, namely that a few questions were potentially vague or introducing inaccuracies, and that the small sample size due to the lack of talk page usage limited the quantitative usefulness of the results (it's great to hear, for example, that 20 percent of respondents explicitly call out the UI as needing modernising, but that's not so useful when that's four or five people).

What I'd like us to do is twofold:

1. Interview a few of the more thoughtful survey respondents, to get some detailed qualitative data about their experience editing - ideally with someone from the community sitting in. It'll probably be via Skype or Google Hangout, and while the recording won't be public we'll probably write up a summary of each one;
2. Issue a second survey to more experienced users (1-3 months as editors? 3-6 months? >5 talk page edits? Some combination of the above?), which should solve for the low number of respondents and hopefully help with the quality of the feedback. I'd like help from the community (and my fellow staffers) in defining what a decent group of users to aim at would be, and refining the questionnaire.

Thoughts? Offers to be guinea pi- er, interview volunteers? Okeyes (WMF) (talk) 19:21, 3 December 2013 (UTC)

• I'd suggest a larger sample size, including users up to 3 months. I don't think that personalized interviews are anything more than anecdotes with no real value, and it's incredibly easy to lead interviewees in a specific direction, intentionally or not. Risker (talk) 04:33, 4 December 2013 (UTC)

  That is, the 1-3 month users? (Also: Pinging Guy, Liz and Tryptofish). Okeyes (WMF) (talk) 18:14, 4 December 2013 (UTC)

What is the status of the Flow rollout to select WikiProjects for testing? I noticed discussions at WikiProject Military History, WikiProject Breakfast, and WikiProject Hampshire as well as rumblings at WikiVoyage about participating? Is the testing still scheduled for December and what projects are participating? Would you be interested in the Signpost chronicling the testing process? –Mabeenot (talk) 02:58, 4 December 2013 (UTC)

• I think WP:WPCOL and WP:VG are planned to be participating also? ☺ · Salvidrim! · ✉ 04:41, 4 December 2013 (UTC)

  Video games, definitely; colour, I'm not sure. Quiddity, you'll know better than I :). Okeyes (WMF) (talk) 18:15, 4 December 2013 (UTC)

  Ah, nope, no WPColor, sorry to confuse. I was just trying to leave a helpful example post demonstrating what I would've written. I'm not officially a member in any of the wikiprojects that volunteered. (Though I've now read oodles of talkpage archives for a few of them!) –Quiddity (WMF) (talk) 18:21, 4 December 2013 (UTC)

What's the timeline for being able to beta-test Flow on our user talk pages? 28bytes (talk) 21:23, 4 December 2013 (UTC)

There isn't a firm one at the moment (it's something that'll have to vary, depending on the feedback we get from the Wikiprojects), but we've been discussing that as the release after the wikiproject talk pages - stick Flow in beta features and invite experienced users to enable it on their pages. So, early next year, I think - Maryana? Okeyes (WMF) (talk) 22:35, 4 December 2013 (UTC)

Thanks. Is there a sign-up sheet anyplace? 28bytes (talk) 22:48, 4 December 2013 (UTC)

Why a sign-up sheet? Oliver just said they'd put it in Beta features for users to turn it on if/when they wish. ☺ · Salvidrim! · ✉ 12:13, 5 December 2013 (UTC)

The idea would be the Flow team could send people on that list a message when it's ready for us to beta test. It would also help them gauge interest in the feature among potential testers. 28bytes (talk) 15:06, 5 December 2013 (UTC)

I'm not sure it's necessary to have a separate list, I think the Newsletter sign-up could serve this purpose... ☺ · Salvidrim! · ✉ 16:33, 5 December 2013 (UTC)

Yeah, the newsletter list is the plan :). Okeyes (WMF) (talk) 17:41, 5 December 2013 (UTC)

OK. I see the sign-up list for that; is there an archive someplace of previous newsletters one can read? 28bytes (talk) 23:22, 5 December 2013 (UTC)

Flow has spoiled me on outdenting good question. Quiddity? Okeyes (WMF) (talk) 19:21, 6 December 2013 (UTC)

Good catch. I've added archive copies at Wikipedia talk:Flow/Newsletter. –Quiddity (WMF) (talk) 19:29, 6 December 2013 (UTC)

Thanks! 28bytes (talk) 19:45, 9 December 2013 (UTC)

Judging from the current test talk page, all threads start uncollapsed by default. Is this something intentional, and/or will it be customizable in user preferences? If I had to pick, I'd prefer they all start collapsed, unless I followed a direct section-wikilink to a specific thread or comment... also, I assume this has been discussed before, but damn I miss that table of contents. I understand an infinitely scrolling Flow board is kind of incompatible with a Table of Contents, but I liked loading a talk page and easily being able to "at-a-glance" read the titles of existing threads/sections and click-to the one(s) I'm interested in. ☺ · Salvidrim! · ✉ 22:42, 28 November 2013 (UTC)

Snap - that was just being discussed (the possibility of it being some kind of preference); @Maryana: how did the conversation go? I can't for the life of me remember (and blame turkey for this). Anyone else with thoughts: please provide :). Personally, I really like the idea of a pseudo-TOC through collapsed headers. Okeyes (WMF) (talk) 19:25, 30 November 2013 (UTC)

For a start, the collapsed headers in that view should be much thinner than they are now, about one line high. The current headers are huge and wouldn't serve as rows in a pseudo-TOC - they're not table-like, and wouldn't allow to quickly scan the titles as a TOC does. Diego (talk) 21:54, 1 December 2013 (UTC)

Ask and ye shall receive :) At some point today, you should see a new feature on the ee-flow wiki that will allow you to toggle between 3 different states:

1. All topics fully open
2. All topics collapsed (shows the full topic header area, with title, participants, comment number, etc.)
3. All topics collapsed and condensed (shows a thinner view of the topic header, to allow for a ToC-like experience)

I'll ping you guys when this goes live. Play around with it and see what you think! We can tweak the collapsed + condensed view as necessary to make it more useful. Maryana (WMF) (talk) 19:35, 3 December 2013 (UTC)

Ping! Diego Moya and Salvidrim!, this feature is now live on ee-flow. Play around with the little buttons on the right, below the header area. Just an early stab, and it doesn't remember your prefs... yet :) Maryana (WMF) (talk) 19:35, 6 December 2013 (UTC)

My first reaction to the thread collapsing is two-fold. 1) I would like a more positive reinforcement when I hover over the buttons ie can it depress like a button? 2) It might be nice if the most compact mode were more compact. Chris857 (talk) 20:04, 6 December 2013 (UTC)

What information would you cut out? I'd like some kind of positive reinforcement, too - as a start, what if the pointer displayed as the click-icon, rather than as, well, the pointer? Okeyes (WMF) (talk) 20:25, 6 December 2013 (UTC)

It looks promising! :-) I agree with Chris, the collapsed view and small view don't provide any practical difference; they're almost the same. I was expecting a collapsed view where each topic was at most one line high, and with smaller text - i.e. something cleaner (without the vgrey boxes and repetitive white bars), more table-like and with higher information density, like the Contents index in LiquidThreads. I have more comments about what I like more (the buttons are very well done and understandable) and not so much of the design; I'll try to post them tomorrow. Diego (talk) 23:57, 10 December 2013 (UTC)

There's a newer design iteration of the fully-collapsed option, coming soon, with single-line per topic, and number of comments at the end of the line.

(Sidenote: The process of experimentation and feedback/suggestions seem to be working really well! I hope we can all continue to keep it coming, slowly and steadily, as Flow gets closer and closer to (all) our needs and dreams. :) –Quiddity (WMF) (talk) 16:49, 11 December 2013 (UTC)

Background

Talk pages are completely unstructured data; Flow is structured data. Unlike talk pages, which were created before the existence of smartphones, we have to account for how Flow will look on phones and tablets, which are currently ~20% of our readership traffic and swiftly growing. That means we have to make some choices about how we want discussion threads to look – specifically, how to make it clear who's talking to whom without creating an unreadable mess.

I question the necessity of making talk pages completely conform to smartphones' whims. I doubt many people edit Wikipedia or contribute to talk pages on mobile devices. Maybe 1%.

67.252.103.23 (talk) 01:19, 21 November 2013 (UTC)

Take a look through the list of discussion communities and their nesting levels below (feel free to add more examples to it, too). If you've had discussions on any of these sites (or just browsed through them for a minute as a reader), what are the pros and cons you took away from the experience? (E.g., confusing to follow long conversations? hard to read on a phone? just right?) I'm seeding this with my observations, but you're welcome to add your own. This isn't a vote; I'm just trying to kicking off a conversation :)

(flat conversations, one reply button, replies go to the bottom of the stack)

Comment
Reply
Reply to reply
Reply

Examples of products using this pattern

1. old YouTube
2. Twitter
3. Flickr
4. PhpBB
5. Simple Machines Forum
6. Gawker
7. Discourse
   

Pros/cons?

• works great on mobile!
• hard to have nuanced debate in a flat format
• difficult for users to skip content that irrelevant to them
• can be hard to keep track of who's talking to whom Maryana (WMF) (talk) 22:44, 26 September 2013 (UTC)

(initial comment, all replies to that comment are flat)

Comment

Reply

Reply to reply

Reply

Examples of products using this pattern

1. Facebook
2. new YouTube
3. Gizmodo
   

Pros/cons?

• looks good on mobile
• brings focus to the topic, not tangents/flamewars
• doesn't seem to be intended for robust user-to-user debate Maryana (WMF) (talk) 22:44, 26 September 2013 (UTC)

(initial comment, answers, and replies to comment/answers that are less prominent)

Comment

Reply

Reply to reply

Reply

Examples of products using this pattern

1. StackOverflow
2. Medium
   

• brings focus to question-answer interplay, not off-topic comments
• no confusion about where to respond
• begins to complicate mobile views of content
• by Jeff Atwood's account, intended to actively suppress free-form discussion.. WP:NOTFORUM? Maryana (WMF) (talk) 22:52, 26 September 2013 (UTC)

It's worth noting that on StackOverflow (and the other StackExchange sites) there are also separate "chat rooms" - essentially a zero level of nesting conversation - where free-form discussion is encouraged to take place. While it's important that we adhere to WP:FORUM (and Flow doesn't encourage too much forumy behaviour) it's also important to remember that one of the primary reasons for a talk page is to build consensus, and you can't do that without relatively free discussion.

On the subject of the StackExchange UI though, the ability to vote-up and vote-down questions, answers and comments might be an idea we want to borrow. We do a lot of polling and !voting on Wikipedia talk pages and we need a way for Flow to cope with that, including an easy way to count the !votes. WaggersTALK 13:13, 27 September 2013 (UTC)

@ Waggers, interesting, I didn't know about the StackExchange chat room space... I guess SO's front-page discussion system doesn't quite meet all the needs of its users, if they require an alternate method for backchatting. That's definitely true of Wikipedia, too; some project areas may need more structure in their discussions, and some may need less, so we want to stay open to different configurations. I see you're a member of a couple of WikiProjects – from your experience, do those feel more like StackOverflow-type spaces where people ask questions and want answers, or more like informal chat/forum between members?

On the consensus front: it seems to me that, in a way, StackExchange is also about building consensus (e.g., "what's the best answer for this question?"), and they've created the two-tiered system to encourage people to focus on the topic at hand, instead of spiralling off into back-and-forth 2-person tangents. You can still tangent in the comments, but those are just displayed in a way that makes it clear they're not part of the main discussion.

Polls, !votes, upvote/downvoting, and other methods of gathering the pulse of the crowd are really interesting. I don't think we're going to get to exploring those options in Flow the near future, but it's definitely something to think about. I'm not sure how the wider editing community feels about these methods, though. There may be some users who have used StackExchange and other sites (e.g., Slashdot) and like them, but I've heard people express some misgivings about creating those kinds of filtering mechanisms on Wikipedia. Maryana (WMF) (talk) 19:46, 27 September 2013 (UTC)

About polling, it's helpful to recognize that the consensus at the English Wikipedia is at WP:POLL. --Tryptofish (talk) 23:12, 27 September 2013 (UTC)

...Yep, the notion of "voting" without being able (or perhaps forced) to give an accompanying explanatory comment isn't what we want to encourage. I've put together a quick example of a typical consensus building discussion format - it would be good to see Flow supporting something like this kind of structure. WaggersTALK 07:30, 30 September 2013 (UTC)

@ Waggers, that looks like slide 25 of a deck I put together for Wikimania :)

The current structure of proposals evolved to look like this in part due to the technical constraints of Mediawiki – e.g., there's no concept of in-line annotation, so you can't make minor quibbles/critiques in place and have to put them in a separate section; there's no metadata associated with conversations, so you can't display the number of users participating at a glance. Flow won't be limited by those constraints, so we have a lot more room to experiment :) I'm curious, for example, what the purpose of a !vote section separate from the discussion section really is. Is it just to get a quick headcount? Give the closing admin/uninvolved user a visual cue in cases of WP:SNOW? What if we instead let people provide their detailed support/oppose comments in the "support" and "oppose" sections of a proposal and simply displayed the number of users commenting in each of those sections? Something like the headers in Gawker Media comments? Not saying we should do this; just wondering if there's more to the !votes section than, well, basically just a vote, and if discussion is really where all the important consensus-making happens. Maryana (WMF) (talk) 23:39, 30 September 2013 (UTC)

It depends. An RFA is pretty much a vote. Wiktionary is pretty much voting. In those discussions, a comment is about influencing other people's votes. On other pages, it's really the other way around: the analysis matters more than the !vote. User:Beeblebrox/The perfect policy proposal#Planning the RFC might be interesting reading. User:Beeblebrox could probably provide even more information. WhatamIdoing (talk) 00:42, 1 October 2013 (UTC)

Maryana, people organize RfCs in different ways. Sometimes, particularly with RfCs that you know won't attract much input, there's no need for a separate "survey" section. Where the RfC is likely to attract more attention, people add a separate survey section to make things easier for the closing editor or admin; I've closed a lot of RfCs and it's really difficult to pick out the main comment from each person, and just one from each, if the comments are only in a discussion section (where things get very repetitive). When the RfC is likely to be very large, people sometimes do add separate support/oppose sections and ask that the responses be numbered. That makes it more vote-like and easier to close.

Consensus matters a lot and so numbers do count; analysis counts only in the sense that the closing editor has to make sure that policy has been respected. So, for example, if 100 people vote for an umambiguous BLP violation and one against, the closing editor will (hopefully) close in favour of the latter. But where the policy issue could go either way, the numbers are obviously pivotal, and in those cases (and I think that is probably most cases), it does end up as a vote. SlimVirgin ^(talk) 00:55, 1 October 2013 (UTC)

SlimVirgin, WhatamIdoing, thanks, this is really helpful! As I said somewhere above, the Flow team won't be tackling complex consensus-building discussions like RfA, RfC, AfD, ArbCom, VPR, etc. for some time; one of the many reasons why we're planning to release on a page-by-page basis for now, not to entire namespaces. But when we do get to that bridge, I'll definitely be pestering you two for guidance/help :) Maryana (WMF) (talk) 01:10, 3 October 2013 (UTC)

(initial comment, reply, replies to replies, replies to replies to replies)

Comment

Reply

Reply to reply

Reply to reply to reply

Reply

Examples of products using this pattern

1. Mailman
   

Pros/cons?

• starts to break down on mobile
• following threads gets more difficult – long tangents Maryana (WMF) (talk) 22:52, 26 September 2013 (UTC)

@User talk:Maryana (WMF) About mobile: isn't this just a matter of display that should be resolved via CSS ?

In general, the structure should be present in the HTML code, with CSS depending on the kind of platform, the preferences of each wiki, personal overwrites in personal common.css etc. Do it well for the few most common use cases (e.g. in this case propose 1 or 2 levels of nesting on mobile devices and 3 or 4 on other platforms by default), but expect and allow individual wikis and people to possibly overwrite these. That's an outcome of several discussions around the ArticleFeedbackTool v.5 on WP:fr. Klipe (talk) 15:01, 9 December 2013 (UTC)

(like the above, but even more nested!)

Comment

Reply

Reply to reply

Reply to reply to reply

Reply to reply

Reply to reply to reply

Reply

Reply

Examples of products using this pattern

1. The Verge
2. Reddit
3. Wikipedia (effectively) after which people use {{outdent}}
4. Quora
5. Tumblr (3-5 is common, 11 is rare)
   

Pros/cons?

• on a small screen, pretty much unreadable without a ton of work (clicking, scrolling, zooming, pinching), and all but impossible to add new comments
• where do I respond (to the topic as a whole, to individual comments)? Maryana (WMF) (talk) 22:44, 26 September 2013 (UTC)

Why do we say that it is "all but impossible to add new comments"? New comments are added all the time on Wikipedia discussion pages. --Atethnekos (Discussion, Contributions) 19:07, 1 October 2013 (UTC)

I think that point was just in reference to small screens (particularly mobile), where deep indents (and particularly :*:: mixings) are harder to compose a reply to. Quiddity (WMF) (talk) 19:48, 1 October 2013 (UTC)

Yes, of course. Thanks. --Atethnekos (Discussion, Contributions) 19:52, 1 October 2013 (UTC)

Yep, if you've ever tried to edit a talk page on a phone, it's... well, not pretty. Even on a tablet, it's pretty painful and frustrating, and the number of users we have on tablets is steadily growing. Maryana (WMF) (talk) 00:04, 2 October 2013 (UTC)

Examples of products using this pattern

1. Liquidthreads
2. Thunderbird email subject lines
3. Livejournal
   

Pros/cons?

• yikes... Maryana (WMF) (talk) 22:44, 26 September 2013 (UTC)
• Comment Writing as one who has never taken part in any of the above mentioned sites (and has no intention of joining any of them either...), I find it a bit hard to understand what is being talked about. I've seen the mock-ups of 'Flow', and can't see that it's any improvement over the current system. It only takes a moment to explain indenting to a newbie - and if they can't understand that, they're not going to make any sense of anything. If Flow works anything like as well as VE has, we're going to be in a mess. And not able to talk about it unless there is some sort of opt-out provided. That I can't see happening. It's going to be all or nothing. I get the feeling sometimes that there's a similarity to the highways departments that have to ban parking on a road to speed the traffic flow up, and then put speed humps in to slow the traffic down again. They have to be seen to be doing something in order to justify their existence. Peridon (talk) 07:45, 27 September 2013 (UTC)

  Well, frankly given the backlog of software improvements, if we were merely trying to justify our existence there's a ton of things we could be working on other than this - I would assume that you, like all of the users I speak to (me included!) have a ton of ideas for changes that would improve editing. I think there may be a point of confusion here, though; explaining indenting to new users, as you say, does not take very long - in principle. But then we have "when is it appropriate to outdent?" and "What do I do if I have multiple replies to multiple users?" and a ton of other awkward edge-cases that occur every day and aren't necessarily covered by "count the number of colons in the post you're replying to, then add one". Here, for example, it's asterisk, then asterisk colon, then asterisk colon colon, then.... and the same thing would happen if we had numbered rather than bullet-pointed entries. There are various different formats for discussions.

  For me the greater problem with talkpages and indenting - for new users and for existing users - has always been things like screen width and information density. Explaining indenting to new users - setting aside the edge cases - is easy. Reading the resulting talkpages, with comments offset from each other 8 or 9 times, can be an eye-ache that encourages people to (at best) skim-read discussions or simply not participate. The prime example here is tablets and phones, which don't deal well with horizontal scrolling and will need to horizontally scroll for more than a couple of levels of indenting, but I have the same problem on the laptop I'm using right now. Okeyes (WMF) (talk) 21:02, 28 September 2013 (UTC)

Nice to see a WMF representative admitting that indentation is not nearly hard enough to be a significant barrier. Can we put this point to the main page..? I think you'll have to agree that "Simultaneously, we know that freeform wikitext talk pages present a significant barrier to new users" overstates things and doesn't emphasise what you do.

Also, a discussion that is complex and long enough to have "comments offset from each other 8 or 9 times" is likely to be complex enough to get "people to (at best) skim-read discussions or simply not participate" by its length alone... Speaking of asterisks - I have deliberately used ":::" instead of "*::" in this post... Did you notice a difference until now..?

Anyway, perhaps the most important thing is that the tone you are using here is exactly what all WMF representatives should seek to imitate. There is nothing wrong with exploring different possibilities to improve the talk pages, as long as it is a truly free exploration that doesn't even rule out the answer "We have found nothing better than we had.". It is when we get the unreasonable hype of the product that doesn't even exist ("a great piece of open source software", "a kick-ass discussion system", "No edit conflicts, ever." and the like) that we start to "check for our wallet" (figuratively, of course). And such mistrust is not something you should strive to promote... So, thank you for the change of tone. --Martynas Patasius (talk) 00:12, 29 September 2013 (UTC)

Thanks! I think Maryana, Quiddity and others would agree with me that hype is not something we particularly want. We want to make the positives of this system clear, but there will be some negatives (no system is perfect for every user), and above all this early period is about experimenting, not setting in stone Precisely What Will Definitely Happen. We (the WMF and the community) don't have all the answers yet, be it as to what is technically possible or what is socially possible, and so it would be unfair of us to act as if we could see the future with perfect clarity.

One point of clarity would be that while I don't think teaching new users how to edit with indenting is necessarily the hardest thing in the world (although it does present some barrier, and there are lots of awkward edge-cases that raise that), a necessary skill for being able to reply to a thread is being able to read and understand it. High levels of indenting are sort of a problem there, since they make the page more difficult to comprehend - I had to pass over your post 2-3 times to fully get it, and I've been editing since 2006. So there is a barrier there, just an indirect one.

I think clarifying/expanding on "freeform wikitext" is probably worth doing, to prevent misunderstandings, although I don't see it as being analogous to "indenting" - more "indenting, and markup, and templates, and everything else". Do you have any thoughts on language, there? Quiddity, Maryana, your thoughts? Okeyes (WMF) (talk) 21:03, 29 September 2013 (UTC)

Regarding "freeform wikitext", the initial discoverability of all the systems seem to be the hard part - eg. all the newcomers who start new threads at the page top, or within an existing section (without a new header). All the difficulties with getting paragraph breaks to display properly (currently we mis-use the HTML definition list elements to create indents and paragraphs) with some people adding extra blank lines to create whitespace, and some people objecting per WP:LISTGAP, etc. The habit that some people have, of adding indents no matter who they're replying to, just to make the comment-separation clear.

Trying to explain any of these standards (even in person, with all the added ease that over-the-shoulder-teaching brings), to my friends and acquaintances who are less comfortable with computers (eg. the owner of a local antiquarian bookstore, who reads old books all day, and recently got online) is often frustrating.

I'm not sure how to condense that down into a brief sentence or two. Quiddity (WMF) (talk) 00:36, 1 October 2013 (UTC)

• @Peridon: You say that "it only takes a moment to explain indenting", but yet talkpage discussion are hopelessly indecipherable to anyone who is not an "insider". For example can you tell me who Jimbo Wales is replying to by looking at the indentation? How would you jump into that conversation if you joined in today?

The beauty in Flow is that it keeps the most recently active discussion on top, and hopefully provides permalinks for each comment, so that one could guide others into a particular entry point to a conversation. XOttawahitech (talk) 15:08, 6 December 2013 (UTC)

Perhaps this changed over the weekend, but until last week, it didn't "keep the most recently active discussion on top", it kept the most recently created discussion on top; if you reply to the 8th discussion on the page, it will stay the 8th discussion, not become the first one. Fram (talk) 08:51, 9 December 2013 (UTC)

I'm not sure if it's changed (I haven't checked yet) but that's certainly a planned feature. I'm not sure if we want to make it a feature of all Flow pages, or just a user's feed, or.... personally I'd like some ways to switch between "most recently replied" and "most recently created" to avoid threads sinking like stones. Okeyes (WMF) (talk) 17:40, 9 December 2013 (UTC)

• The question posed here is too broad. There is a plethora of different types of discussion here on just one language Wikipedia, and the level of appropriate indentation differs accordingly. Some discussion structures such as Arbitration Committee cases are highly complex with nested replies allowed in some sections but not in others; some are headed with multiple nested replies permitted, such as AFD or RFC; some are mainly unnested, while some are completely freeform. Perhaps the question could best be answered after having had sight of the taxonomy of discussion structures. Spectral sequence (talk) 15:56, 11 October 2013 (UTC)

All of the alternatives above contain the same unstated assumption that the server must be a web server serving HTML over HTTP and that the client must be a web browser. While that is, most likely, the best solution, we don't necessarily have to do things that way. Take, for example, USENET. This threaded discussion system predates the World Wide Web and is still in use today. In the USENET model, the server simply serves up the post in plain text with some headers which identify who posted it and what it is in reply to, and the user chooses between a wide variety of possible client software.

Besides the standard method of using a newsreader, USENET articles can be served up as HTML over HTTP using a wide variety of formats. The following all present some information I posted to USENET, and start with the exact same plain-text format.[23][24][25][26][27][28][29][30][31][32] Each page gives the user a slightly different nesting pattern. I see no reason why we cannot make the messages that Flow presents available using a standard format, make Flow the default way of presenting the information, and allow those who for whatever reason dislike Flow to write their own client or use one that someone else has written. One of those alternatives could closely resemble the system we have now. with the exception of returning an error message when the user tries to do certain things such as not signing a post, putting a reply in the middle of another reply, etc. --Guy Macon (talk) 21:59, 11 December 2013 (UTC)

Yes, one of the advantages of Flow over Talk pages is that it is structured data, so accessing posts, topic titles, dates, authors/comments, etc. over the API will be much easier. Combine that with the recent addition of OAuth to Wikimedia wikis, and there's no reason you couldn't create whatever kind of client you wanted for posting to Flow boards. Steven Walling (WMF) • talk 22:45, 11 December 2013 (UTC)

Right. Although you (Steven) already know know this, for those following along at home let me expand upon the above a bit. The obvious question is "why not just keep the old system and Flow?" The answer is that the current system really has no structure except what we manually impose with colons and tildes. Humans being by nature inconsistent, there is no way a computer program can reliably tell what is a reply to what, or even where a post begins and ends. By imposing more structure, Flow allows a computer to figure those sorts of things out, which means that we can now customize the user interface rather than being forced into a "one size fits all" situation as we are now. As I touched upon above, we can make one of those customized user interfaces look a lot like the old system by simply not allowing posts that don't fit the data structure. In doing this, pretty much all the capabilities you lose are things that are currently against the rules, like forging another user's signature or putting in a fake date and time. Of course you have to get the structure right, but everything I have seen so far tells me that the Flow developers are on the right path. --Guy Macon (talk)

If Flow will (similar to Echo) present new Messages in watched threads outside of the context of their articles, I wonder how the workflow will be for those of us, who have huge watch lists (admins but not only them). When I came back from a weekend away today, more than 120 pages on my watch list had changes, and I'm not through yet (you know, real life and things). Some of them had only vandalism that already was reset, some hat smalish meaningful changes, that I marked as patrolled, but some needed thoughts, research and further edits from me. If I can go through a watch list, a few items at a time, I can spread this over my short and longer breaks of a work day. If all changes are presented as one heap and there is no simple way to mark those I already looked at, then I don't see how admins or prolific authors with lots of articles and other pages under their wings, can keep their heads over water. grds --h-stt !? 20:48, 16 December 2013 (UTC)

I had precisely the same question four threads above this one. I was told to be constructive and present specific suggestions.--Ymblanter (talk) 20:55, 16 December 2013 (UTC)

What do you mean by 'as one heap'? Okeyes (WMF) (talk) 21:07, 16 December 2013 (UTC)

H-stt, Flow events currently look similar to other events in the watchlist (e.g., one item per change); I'm also not sure what you mean by "heap" (are you thinking of the enhanced recent changes view preference? that's unrelated to this project).

Some users have pointed out that the information is currently too sparse, so we'll work on adding more context to each entry – topic title, an indication of who a reply was addressed to, edit summaries for edited content, perhaps even snippet previews of new comments. Hopefully this addresses some of your concerns, Ymblanter :) Maryana (WMF) (talk) 19:10, 18 December 2013 (UTC)

I believe that this relates to the plans for a Flow feed, whose purpose is (was?) to offer one-stop shopping for all discussions, without needing to visit hundreds of separate pages.

At any rate, the idea with the feed was that it gave you the option of reading all of your discussions in one place; it did not force you to do so. You could choose instead to visit all of the pages separately. Ideally, one could even use both together: I could visit my favorite (they tend to be high-traffic) pages separately, and have the feed notice that I've read those discussions and collapse/remove them, so that when I went back to my feed, I'd see only those discussions that were unread.

But I haven't seen anything about this potentially very useful feature for a long while, so perhaps you've decided not to have one. WhatamIdoing (talk) 23:35, 18 December 2013 (UTC)

What's the current story on finding new/unread comments in long and complex threads? Will previously read comments be collapsed or otherwise marked? WhatamIdoing (talk) 18:03, 9 December 2013 (UTC)

The short answer is: suggestions for "your ideal", and ideas about "problems to avoid", would be good.

It's not part of the MVP, but is on the future release feature list. –Quiddity (WMF) (talk) 01:18, 10 December 2013 (UTC)

I want Flow to automagically hide posts that I've read, to show me everything new automatically whenever I visit a talk page, and to let me manually adjust the status (e.g., to mark a comment as "unread" if I want to make sure that I get back to it later/didn't actually manage to read that far down the page). Depending on your perspective, I either want the Moon or I want what most e-mail systems figured out how to do several years ago.

What I definitely don't want is to drop by WT:MED in the morning and discover that there are nearly 300,000 bytes of stuff on the page and no way to know which ones I've read and which ones I haven't, except to spend two hours reading those 35,000 words all over again, just to see whether someone added a comment to one of the messages since the last time I read it all. WhatamIdoing (talk) 04:41, 11 December 2013 (UTC)

Re: "hide posts that I've read" - do you mean "hide" as in "collapse" (eg like gmail), or as in "grey out" (or similar)? –Quiddity (WMF) (talk) 16:57, 11 December 2013 (UTC)

I'd far rather have it collapsed. One line per comment is the most that I want to see. For discussions that I've read all of, then I'd be happy to see the subject and maybe the first line for the first comment, or perhaps a list of all the people who contributed to the thread.

Something that displays the full text means that I have to scroll through the full text every single time I visit that page. WT:MED is 67 (sixty-seven!) screenfuls for me at the moment. This page is 23 screenfuls. Imagine just scrolling through pages of this size a dozen or more times each day, just to find out whether there was some sort of addition to one of several pages.

If I'm not going to have whole-page diffs to show the new content, then I want something that makes it quick and easy to identify (a) whether there is any new content and (b) what that new content is. WhatamIdoing (talk) 23:20, 18 December 2013 (UTC)

Please click here to see what happens if you gray out the old messages. Can you find all the new messages easily? Is that really what you want to deal with all day, every day? WhatamIdoing (talk) 23:53, 18 December 2013 (UTC)

I don't see anything mentioning those. What about all the templates that are used to describe things in the main articles? They aren't comments, don't need to be signed, and have to be editable by anyone.

Also, what happens to old comments under this system? And how do the two different systems interact during partial rollout? — trlkly 11:07, 8 December 2013 (UTC)

Do we not have a FAQ with this? The "banner area" will still be there. Old talk pages will be kept unconverted. Keφr 17:26, 8 December 2013 (UTC)

Have you seen this test talk page? It has a space for WikiProject banners and the like. Chris857 (talk) 20:13, 8 December 2013 (UTC)

I've added an FAQ item at Wikipedia:Flow/FAQ#What will happen to all the banners? - Thanks :)

Re: old comments, yes, what Kephir wrote. See also Wikipedia:Flow/FAQ#What will happen to current talkpage discussions? Quiddity (WMF) (talk) 00:06, 19 December 2013 (UTC)