Wikipedia talk:Flow

Request for your feedback: Let's talk about nesting!

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.

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, zero levels of nesting

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

One level of nesting

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

Two levels of nesting

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

Three levels of nesting

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

8-12 levels of nesting

(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

(outdent)

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)

30+ or more levels of nesting

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)

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

Editing the comments of others

Hey all

So, one of the ideas for Flow we're experimenting around with is limiting or removing the ability for users to edit the posts of others. The user experience argument is pretty clear; discussion medium does not work without the certainty that the comment you are replying to is genuine, and that your comment will not itself be tweaked or corrupted by others. The argument from existing users is also pretty clear: we have a lot of workflows that centre around being able to edit or interleave comments by others. I've tried to list the use-cases I can think of (and the ones at WP:TPO) at mw:Flow Portal/Editing comments. If you can think of any others, please list them if you're comfortable on MW.org or provide them here if not; I'm fully aware we don't know everything, and there are a ton of different workflows in this area. Thanks! Okeyes (WMF) (talk) 19:01, 1 October 2013 (UTC)

Please have a closer look at peer reviews (e.g. en.wp, de.wp) which occur on article talk pages (or sometimes even user talk pages) as well. --HHill (talk) 21:10, 1 October 2013 (UTC)

Those are a good point; they're included under "GAN/FAC" in practise, I think. When do they happen on user talkpages? Okeyes (WMF) (talk) 21:31, 1 October 2013 (UTC)

If author A specifically asks author B to review article X, this review is sometimes given as a reply on B's talkpage. If this happens (it does occur only rarely, but I have seen such cases on de.wikipedia), the review is usually rather on the short side and thus unlikely to be edited by A (but might be moved to talkpage X). Not all collaboration is done in formal and regulated places ;-) --HHill (talk) 22:07, 1 October 2013 (UTC)

That's a really good point; I'll include it in my example of "why our existing solution for GANs is not necessarily workable". Okeyes (WMF) (talk) 16:57, 2 October 2013 (UTC)

Just out of curiosity, is there a place where I can take a look at this ″existing solution″? --HHill (talk) 17:42, 2 October 2013 (UTC)

Not at the moment - sorry, I'm totally fried this morning :). We're talking about the idea of a scratchpad (think an etherpad, or heck, a wiki page!) that people can use to write freeform notes for [blank], where blank is "peer review" or "notes about an article" or reminders-to-self, or...so on and so forth. It'll be collaborative and nifty, but it also won't be out for a while, and I don't think it's feasible for us to widely release until we have a solution for this problem. Okeyes (WMF) (talk) 18:15, 2 October 2013 (UTC)

Having different ([maybe somewhat transparent] background) colours for different editors (like in etherpad) on the same page or in the same comment might be a nice feature for reviews. And implementing this possibility in all flow posts might even solve some of the problems discussed below as well. --HHill (talk) 18:37, 2 October 2013 (UTC)

Okeyes (WMF), I think you should change the language you use for this. Subsuming it under GAN/FAC could imply refering just to a playground for vain powerusers. Actually a peer review is also something that might be done to help a newbie with her/his first bigger article. And in this case it will possibly or even likely be done in a rather informal setting (and I think this should rather be encouraged than made technically impossible). By the way, why is this point missing from the comparative analysis table? Just because the "existing solution for GANs" treats this as completely apart? I think we should at least for now keep the option open, that at some point it might be necessary to have the capability to do reviews and interleave comments in/with some (special), most or even all Flow posts. --HHill (talk) 00:55, 4 October 2013 (UTC)

I'd ask us to avoid statements like "playground for vain powerusers" - while I'm biased (as someone with a lot of GA work), it doesn't serve us to denigrate any group of Wikimedians. GAN is as useful for copyedits as anything else, and while I know of a couple of users whose motivation is certainly vanity, I know many more who want to improve the article through peer review and collaboration.

I've amended the doc to take into account things like user reviews; hopefully that helps :). Okeyes (WMF) (talk) 18:38, 4 October 2013 (UTC)

You are absolutely right about GAN/FAC, I exaggerated here perhaps a bit too much in trying to point to the negative connotations that sometimes show up in debates about these. I think they are very important, which is part of why I am here. And yes, I believe your amendment will certainly give people, who aren't as involved in this kind of work (and who might have to look up those acronyms), a hint as to what belongs to this category.

As an aside, I noticed this morning, that I quite regularly edit other peoples posts in the ressource exchange adding bibliographical information and changing formatting, yet another extremely rare edgecase on a single page with a small handful of regular contributors doing stuff like this just for their own convenience. --HHill (talk) 19:31, 4 October 2013 (UTC)

A useful edge case, though! I'm helping write up the document now and can see a lot of areas where I have worries/questions/whatever about Flow's ability to handle the same things; I suspect we may end up with configurable/wider comment editing. It's good to be doing so based on use cases rather than familiarity, however! Okeyes (WMF) (talk) 20:11, 4 October 2013 (UTC)

Oliver, as that page you linked to shows, there are lots of occasions where other editors' talk-page posts need to be changed or removed – libel, BLP violations, outing, personal attacks being the most common. But at the same time there is strong consensus that it should only be done where necessary, and usually by striking certain words, or removing comments entirely, rather than altering posts in ways that can't be detected. As a matter of interest why would the WMF consider removing or limiting that ability? In other words, is there evidence that being able to edit other people's posts causes problems? SlimVirgin ^(talk) 02:20, 2 October 2013 (UTC)

"Being able to edit posts of others isn't a problem for the editor, but is unexpected behaviour for the editee if the editee is new" goes the argument; while the idea of being able to remove posts entirely is common (moderation is a net-wide thing), being able to tweak comments in such a granular way isn't - as much as I love John Scalzi's work on the subject ;p.

I agree - the examples you give are important (and frankly I don't think any of us would be willing to work on software that didn't provide for them). But, as you say, it tends to be a 'whole hog' kind of thing; if someone posts personal information in a comment, you roll back the comment and oversight rather than just excising that chunk of the post. Things like suppression and revision-deletion will be built into Flow before we consider even a limited release, so at the moment I'm looking for things that require granular editing that we've missed - there are undoubtedly some :). Okeyes (WMF) (talk) 02:56, 2 October 2013 (UTC)

If by granular editing, you mean removing parts of posts, the most common reason would be a personal attack, or inadvertent BLP violation or outing. So if someone were to write: "X is a moron and completely wrong about this," someone else might remove "a moron and," then will usually leave a note below the post saying it was edited per WP:RPA. But if it's a wikifriend of the original poster who's doing the removing, they might remove the attack without leaving a note, in the interests of drama reduction. Or someone might write: "Susan, I disagree," having forgotten that Susan prefers not to be known by her real name, in which case another editor will quickly remove the name, without leaving a note because that would defeat the purpose. SlimVirgin ^(talk) 03:15, 2 October 2013 (UTC)

Yeah, these are all plausible use-cases, and I've seen them happening (I saw one yesterday, actually). Another good example is when users strike-through chunks of the post rather than redacting it entirely, which Flow can sorta handle; "hide" is equivalent to rollback in function and intent except it merely collapses the post - any [autoconfirmed/whatnot/still to be decided] user can still see it, so it's a rough strike-through equivalent. My question would be how often the partial redaction situations happen, and how often they happen in circumstances where the original author wouldn't be willing (or pressured) to handle it themselves? Okeyes (WMF) (talk) 16:28, 2 October 2013 (UTC)

It happens a lot that other editors strike through and there are lots of subtexts associated with it. It's a way of saying "this was said, but all agree that it ought not to have been said." That is, it's a way of reaffirming community values. This is important, because it shows other editors where the limits lie. Obviously, you would not strike through something very serious; you'd remove it. But for borderline rudeness: "John, your low IQ is on display again, and I must object to your argument," the strikethrough sends a visible signal to onlookers that a boundary was crossed. It also says to the original editor: "You crossed a line, but we like you so we're not removing this entirely, and we're keeping you out of trouble by striking instead." SlimVirgin ^(talk) 23:53, 3 October 2013 (UTC)

SlimVirgin, while removing personal attacks from otherwise constructive comments might happen in some high-drama corners of the wiki, I doubt it's something that occurs even close to frequently on most WikiProject talk spaces, which is where we're planning our first onwiki release :) If it's really a huge problem for the WikiProject members who choose to trial Flow, we can always change the comment editing permissions – but I want people to give this system (which, as Oliver said, has other easy ways of dealing with vandalism, spam, and personal attacks) a real shot before they dismiss it as untenable, and the WikiProject space is pretty safe-to-fail in that regard.

I'd also like to play devil's advocate for a moment here and ask whether this is really the kind of communication you'd like to encourage people to have. I'd argue that the ability to edit others' posts has created a culture that excuses (and thus tacitly encourages) personal attacks, since the attacker knows the body of his/her comment will be unaltered even when it's prefaced with flagrant ad hominems. Someone will have to clean up the mess, but the point will get through. This is a choice that the existing talkpage software has made for us, but we can choose to try another way. Perhaps users who are prone to issuing personal attacks will think twice about doing so if it's highly likely that their entire comment will simply be hidden? I don't know for sure whether this is true or not, but I think it's worth giving it a shot on a couple of discussion pages for a limited time and seeing what happens. Maryana (WMF) (talk) 17:25, 2 October 2013 (UTC)

Hi Maryana, the thing is, if you release it on WikiProjects where changing others' comments isn't needed much, they're not going to know whether it would be a problem elsewhere. Instead I hope you'll take editors' word for it that it would be a problem. In particular, making it a user right that people have to apply for would create another fissure within the community. It's really quite unusual for vandals to change people's comments, and it's caught the way any other vandalism is, so it would be regular editors who are most affected here.

I'll have to give your second point some more thought: that people might think twice before making personal attacks if it means the whole comment will disappear. First, I would say that doesn't address the inadvertent mistake, such as naming someone who doesn't want to be named (per the example above: "Susan, I disagree," where Susan doesn't want people to know that's her name). It's helpful that all editors can remove the name quickly, but leave the rest of the post intact. There are also overly emotional people who will post a personal attack, and minutes later a wikifriend will arrive to massage it to keep the original poster out of trouble. That's an important social function. I've seen a fair bit of trouble averted over the years by people swooping in to do that. SlimVirgin ^(talk) 00:06, 4 October 2013 (UTC)

Collapse discussion about whether comment editing will be configurable - it will be, but the default (for the small-scale, experimental releases) will be "no editing other people's comments". If there are legitimate examples of where editing others' comments is necessary, we'll happily change it back: the idea is just to try exploring all the options before narrowing down to the existing one. If you have such examples, you should post them in this thread :). Okeyes (WMF) (talk) 23:26, 8 October 2013 (UTC)

Why is this coming up again? Allow the privilege required to edit comments to be configurable on a per-wiki basis. Let each wiki choose what privilege is required and determine local procedures for gaining that privilege. Why should WMF try to dictate a one-size-fits-all solution when it's so easy to make it configurable?—Kww(talk) 16:38, 2 October 2013 (UTC) We're not; again, this is something we're trying to discuss and work out whether it's needed or not. I'll try to avoid ambiguity here: I am trying to ascertain whether there are probable use cases for building this feature in by default, so that we can make an informed decision as to whether it's necessary (and so something we have to have) or a nice-to-have. I'm not trying to "dictate" any solution - if I was, we'd just provide that solution and wouldn't be discussing it with you. In the future I'd ask you to read the thread before commenting and avoid assuming we're taking the stupid action here (which would be, as you say, dictating without consultation or community participation). I appreciate other development processes have not been particularly smooth, but the WMF is not one monolith. Okeyes (WMF) (talk) 16:57, 2 October 2013 (UTC) You heard tones in my question that weren't there, but I do think your basic approach is problematic. We're able to do it today. It's done today. That should be sufficient use case to provide it. You have concerns that it could be abused, and have concerns that it may be a feature that's a relic of our use of talk pages and isn't generally suitable for all environments. That's a sufficient argument for making it configurable. We all know from experience that different wikis have different policies for such things: that's sufficient argument for making the combination of privileges itself be configurable. What I object to is the notion that removing an existing capability is being discussed, and I don't understand why we keep having to have these discussions. Please don't release anything until it's able to do what we already can do.—Kww(talk) 17:16, 2 October 2013 (UTC) Well, it was the "dictate" statement; as you can see, we're not dictating (again, if we were, it'd be done). I'm not sure where the configuration thing is coming from - who made the statement that it would be done like that? Let me be clear, I'm not saying it won't be done like that, merely that at the moment we're not committing to any one solution - we want to discuss it and work out whether people are comfortable with the reduced functionality or whether it provides genuine problems. I think it would be irresponsible for us to say "this is the easiest solution, let's do that" or really do any solution before we've had the chance to see what the options are and use them. I understand your perspective here and it's a valid one to bring - it can and should be configurable - but I don't see "the existing system can do it" as necessarily a valid argument. So, for example: the existing system can also use talkback templates. If (and we're not planning to do this, note) we released a system without talkback template support, because we've included a way for the software itself to unify threads on multiple pages or send notifications or watchlist entries for just that thread or [blank]. We've deprecated the need for talkback templates. Would you argue in that situation that we need to provide talkpage support solely because that's the way things have always been done? What we need to be discussing and fighting for is not the form but the underlying function - not "we can already do that" but "we need that, for X situation, and your proposal does not provide for X situation, and it's a plausible one". We need to be preserving used functionality. That's what this thread is about; highlighting the places where we (a) use comment editing at the moment and (b) don't have a valid replacement for the functionality there in Flow. I'd encourage people to focus their energies on providing those use cases - arguing not that we have comment editing, but that we need it. Okeyes (WMF) (talk) 18:27, 2 October 2013 (UTC)

I thought I would respond here partially to the comments at [1], since the same issues are being taken up here, where there are more people.

So there and here, in order to defend the disparity between "own editing" and "others' editing", there has been the claim that people expect to be able to edit their own comments indefinitely, and do not expect other people to be able to do so. Also now there is the claim that "own editing" promotes disruptive behaviour, because the disruptive editor knows that her comments will otherwise remain after someone has edited out the disruptive material.

First I would note these claims are not in conciliation: On the first argument, it is premised that people do not expect their own comments to be edited by others, while on the second it is premised that people do expect their own comments to be edited by others.

Let's look at the second claim, which really is a non-starter. This applies only to intentionally disruptive editors. If the goal of such an editor is to post something disruptive and also post a comment which is otherwise non-disruptive which won't be remove, there is no stopping such a person: They will just post two comments. This could only be trivially harder than combining the disruptive with the non-disruptive. Indeed, if it were a legitimate punishment and deterrent to remove more than just the offending material, then that would be the practice now.

For the older claim, about expectations: Is this even true? For any random site with which I am not previously familiar, I don't think I would have a positive expectation that I would be able to modify my own comment after posting. And I definitely do not have a positive expectation that I would be able to modify it after someone else has read the comment. And, finally, I would have a negative expectation that I would be able to modify it after someone has already replied to it. So the supposed "own editing" expectation is not met. What about the supposed "others' editing" expectation?

If I write a comment on most blogs, news stories, etc. with some expletives, I don't have a positive expectation that the expletives won't be starred-out. It may be responded that it would be an administrator that would do such an action, not just any other commenter, which would still be the case here. But this would be an equivocation. "Administrators" or "moderators" for any random blog or news story comment section are almost never bound by any scrutable policies such as we have here, and there is no way to review their decisions and appeal them. Administrators for such sites are nothing like the administrators here. The common editor here is more accountable for their editing of others' comments than the administrators of most sites are. There just is not a comparison to make.

There are others reasons why such is not comparable. Even if it were granted that the expectations concerning "own editing" and "others' editing" are exactly as supposed by the argument, the expectations are nonetheless otherwise completely different. If I don't expect other commenters to be able to edit my comments, also neither do I expect to be able to post an image that is 3000 pixels wide. I do not expect to be able to make a Wikipedia-style reference, but then be able to post while forgetting to put a closing ref tag. So many of these formatting errors are simply not possible in other commenting systems. To compare expectations on only one issue will be misleading, because the features differ, and these features interact.

An example of interaction. Say a user writes a comment and includes a [[File:Map of Italy-sr.svg|tumb|]], where he accidentally misses the "h" in "thumb". The result is a monstrously misformatted page. If a peer editor can edit the comment, she can correct this error. To say that VE will lessen instances of misformatting is wishful thinking: An essential reason VE was changed to opt-in was because the community felt the formatting issues were exacerbated by it.

Such disruption is what the ability to modify others' comments helps ameliorate. Take some other cases. An editor makes a cogent, thoughtful, calm comment. A number of thoughtful responses from others follow. Then a day later the original commenter comes back and edits his original comment by appending "oh mann, im so drunk, i dont now what you people are saying; i love you guys, your crazy." etc. This is disruptive because prima facie it makes the following comments seem ignorant of drunken ranting above them. The proper response for someone else who sees this happen is to outright remove this addendum, or strike it and note that it came later, and this is probably what would happen. This is a case where editing of one's own comment is disruptive, but where editing another's comment is corrective.

Similarly, an editor asks whether something is formatted correctly, and then follows which some example code. Then a bunch of responses ensue saying how it is not formatted correctly and how it could be changed. Then the original editor comes back and changes the code to correct it. This is also disruptive, because prima facie is makes the following commenters seem ignorant of what is and is not proper code. Another editing seeing this does right to edit the original comment again to make it clear what happened.

Or a classic bait and switch troll: An editor makes an image he uploaded of a cake, and asks "Hi guys, I made this image for the cake article, what do you think?" And then you get a bunch of responses: "The image is great, also I just want to say that looks delicious!" "Yeah, good job. I wish it wasn't just an image, I want a taste!" Then the original editor changes the image to one of a penis. Of course, the response for a third-party is to change it back.

The point is, one can be just as disruptive by editing one's own comments as one can be by editing another's comments. One can easily make the case that modifying comments should be limited to groups privileged based on editing history (admins for example). But this means "own editing" as well. There's simply no reason to think that, prior to any review of her editing history, that an editor should not be trusted to edit others' comments, yet still be trusted to edit her own comments. It's a fallacy that disruptive people cannot be as disruptive with their own comments as they can with other people's comments. --Atethnekos (Discussion, Contributions) 20:35, 2 October 2013 (UTC)

Atethnekos, I understand your concerns about all the possible edge-cases. My view remains that when we deploy the first release of Flow (please keep in mind this won't mean Flow will be enabled on all talk pages, or even most talk pages – just on a few WikiProject talk spaces, with user consent), we should initially give users the ability to edit their own comments but not someone else's. If the WikiProject users who are testing out Flow in their discussion space encounter serious issues with this, we can change the permissions. It's not as cataclysmic and unmovable a change as some users seem to think it is.

We can speculate all day about abuse and create elaborate trolling scenarios (a bit WP:BEANSy, if you ask me...). I'd rather we just try it for a week and see what happens. Maryana (WMF) (talk) 01:01, 3 October 2013 (UTC)

It's not about edge cases or speculation or potential and actual forthcoming evidence of serious issues. The examples are just for illustration. I agree that disruption caused by editing one's own comments are rare. But so is disruption caused by editing others' comments. The point is that the stated reasons for not allowing one to modify others' comments after the fact are as equally applicable to not allowing one to modify one's own comments after the fact. There just has been no good reason for creating such a disparity. If I had to frankly guess, I believe there is an unexamined premise that the common editor can be trusted to appropriately edit her own comments, but cannot be trusted to edit someone else's, and that that is why the disparity is accepted. But such a premise does not stand up to examination. --Atethnekos (Discussion, Contributions) 01:59, 3 October 2013 (UTC)

You can't tell me that you've never encountered the situation where you type out a talk page comment, hit save, and then realize you left out a word, or misspelled something, or needed to clarify something, or needed to come back 5 minutes later and add something :)

I don't have hard data on this, but I'm pretty sure that's a much, much more common scenario than having to edit out a personal attack from someone else's talk page comments. Maryana (WMF) (talk) 22:26, 3 October 2013 (UTC)

• If I understand the current plan, comments will not be editable, and if you post anything that needs to be removed, it will require hiding/revdel/oversight of your entire comment? What happens to replies? Suppose I propose an indef block of a disruptive user, and quote some evidence. There are several support !votes. It is then determined something in my original post needs to be removed, how will anyone know what was being supported? Monty₈₄₅ 00:00, 4 October 2013 (UTC)

  This is a really good point, and something I will include in the use-cases doc I'm building. If you think of any more, bring them up here or throw them into the doc directly :). I personally worry about that - or the alternative. That is, if we allow for say, sysop or OS editing of the post, will we have to build in a suppression tool for revisions to each post? That could get thorny and awkward for the end user. I've factored it in. The first release will be without comment-editing, and we're going to play around with it and see whether it raises problems practically :). Okeyes (WMF) (talk) 00:12, 4 October 2013 (UTC)

  Now here - if I got bits wrong, be bold :). Okeyes (WMF) (talk) 00:14, 4 October 2013 (UTC)

  Not necessarily just evidence either, what about a long, mostly acceptable comment/complaint/defense, that also includes a personal attack or blp violation? Or say a new editor at the help desk, who includes contact information in their otherwise totally acceptable request for help. (This was an issue with article feedback too, don't know if it was raised or got much attention) Monty₈₄₅ 05:01, 4 October 2013 (UTC)

  Good point; amended as such :). Okeyes (WMF) (talk) 18:02, 4 October 2013 (UTC)

Break

Sorry if this has already been explained, but could someone say why removing this ability is even being considered? I've been editing a long time, and I've never noticed problems with people editing others' comments. It happens occasionally when it ought not to, but it's always done with something helpful in mind. In those cases you leave a polite note on the person's talk page about talk-page etiquette. But I could probably count on two hands, and maybe on one, the number of times I've seen it be an issue.

What are the actual benefits of not allowing posts to be edited (or moved?) by others? Jorm said somewhere (I'm writing from memory) that lots of people in the Foundation want to remove this ability for lots of reasons, so could those reasons be listed here? SlimVirgin ^(talk) 00:29, 4 October 2013 (UTC)

I don't know what the official reasons are, but the obvious advantage is that if a post cannot change, there is no need to have a system to track edits to it, or revdel/oversight specific revisions of them. With the ability, you will also need a way to access that history. Monty₈₄₅ 05:04, 4 October 2013 (UTC)

Pinging Jorm (WMF) in case he hasn't noticed this. Sorry, Monty, I don't follow that (technical dinosaur speaking here). SlimVirgin ^(talk) 23:14, 4 October 2013 (UTC)

Pretty simple, SlimVirgin. If something can't be changed, it doesn't have a history. Since it doesn't have a history, you don't have to write software to display its history or revert changes.—Kww(talk) 01:50, 8 October 2013 (UTC)

Just to clarify, the prototypes have displayed history since the very beginning, and the current ones continue to do so. Quiddity (WMF) (talk) 02:58, 8 October 2013 (UTC)

When I said I was a technical dinosaur I really meant it, so I'm always at a huge disadvantage in discussions like this. I'm not sure what displaying the history of a talk-page comment would be (as opposed to the history of a talk page). Kww, if the Foundation is going to write the software to make it configurable so that we can edit posts (as we can now), it raises the question of why they would ever want us not to have that ability. That's what I'm struggling with. Yes, it is irritating when people change talk-page posts when they shouldn't (just as it's irritating when they change articles!). But that doesn't mean we remove the ability, especially as it doesn't happen that often.

So why is it even being suggested? In fact, why would the Foundation even have an opinion on it? I'm very sorry if there's an obvious technical point here that I'm missing. SlimVirgin II (talk) 03:28, 8 October 2013 (UTC)

There's no technical objection that I'm aware of, and I agree, the Foundation should not enforce an opinion on the topic. They are certainly entitled to have an opinion, but they should not use their control over the software implementation to enforce it. —Kww(talk) 04:00, 8 October 2013 (UTC)

If we were to line up a few thousand editors and ask for their top-ten wishlist of software changes, I'd be surprised if a single one of them said, "we don't want to be able to edit other people's talk-page posts." And yet Jorm says there's consensus about this within the Foundation and that there are many, many reasons for it. So this is an interesting divergence of opinion, and I'd really like to know what the roots of it are. I apologize if I'm banging on about it too much, but I think lots of other editors are likely to be just as surprised. SlimVirgin II (talk) 04:08, 8 October 2013 (UTC)

The community is used to collaborate using talk pages that are built on a wiki, a flexible whiteboard where many workflows are possible but that requires all editors to participate in its maintenance (like the possibility to edit any comment by others). What the WMF is envisioning with Flow is a quite different system, very similar to Liquidthreads in essence (though more refined), and nothing at all like a wiki. My belief is that the development team is up for a surprise when the community finds about the new software and rejects its very different nature, disregarding its potential; fortunately, the drafts for new design have suggestions for some features (the freeform header area, the customizable worflows editor) that could redeem it and make it acceptable as a wiki substitute. Such features have yet received little thought and are currently underdeveloped, so they'll likely need to be the ones that receive the most attention right after the basic system is put in place. Diego (talk) 16:01, 8 October 2013 (UTC)

I think that's fair (although I would argue it's different from LQT in a number of ways), and personally I hope workflows and scratchpads - things enabling that kind of free-form editing and the processes dependent on them - are things we indeed put a lot of work into. The technical side of workflows is being investigated as we speak, but I expect that fleshing things out will probably be after the first on-wiki release (which is to two wikiproject talkpages). To me this actually makes a lot of sense - we could build a workflow engine that can do literally anything, but that risks turning it into templates: a big, kludgy onerous thing. Instead I'd like to see what workflows people actively need, and what they are dependent on, and build those :). Okeyes (WMF) (talk) 17:06, 8 October 2013 (UTC)

If you have never noticed problems like these: [2] [3] [4] [5] [6] [7] [8] then we obviously do not have the same watchlist. WhatamIdoing (talk) 23:32, 5 October 2013 (UTC)

What you've linked to is IP vandalism or people editing in the wrong place, which really isn't that common. We're obviously not suggesting that editors not be allowed to change each other's article edits because there's so much vandalism and error. My question was what are the many, many reasons Jorm referred to here for removing the ability. It seems odd to potentially cause ill feeling over such a non-issue, so I'm genuinely interested to know how it managed to become an issue, and what the many reasons for that are. SlimVirgin II (talk) 01:34, 8 October 2013 (UTC)

@SlimVirgin: There's Maryana's earlier comment in case you missed that. I'll prod them for another response tomorrow. Quiddity (WMF) (talk) 02:58, 8 October 2013 (UTC)

Comment: Here's the reasoning from my perspective. Other folks working on the design side of Flow should feel free to chime in :) I'm cribbing from some of the things we've talked about, but I'm not a UI/UX designer, so I don't have the citations handy.

1. It's extremely rare for any modern discussion system present on the web today to allow for third-party comment editing, except in cases of content moderation. StackOverflow and Quora are the only examples I can think of (please let me know if there are more), and they actually have a Pending changes-like system, rather than a full-on edit. As such, Internet users today have clear expectations that their comments are their own, and Wikipedia talk pages violate those expectations. This isn't just about inconsistency; it's a barrier to participation. When people perceive uncertainty and a lack of control in an interface, it makes it much less likely for them to participate, even if they have something valuable to add to the conversation.
2. A large portion of the use-cases for editing others' talk page comments, currently, have to do with fixing broken formatting/layout/signatures or creating de-facto features out of markup (closing off-topic threads, splitting or merging discussions). In other words, you're editing comments today because you're dealing with the bugs of broken commenting software :) We're building features in Flow that deal with the majority of these things much more simply and elegantly (e.g., auto-signing posts, one-click close and summarize a thread, etc.) than having to edit raw markup.
3. The rest of the use-cases for editing others' comments deal with abuse. Wikipedians currently deal with this abuse by having to spend a certain portion of their mental energy and onwiki time policing talk pages and cleaning them up when necessary. It's still not clear to me that the benefits of having this be a free-form editing process outweigh the costs. I'm confident that the three moderation features we've built into Flow – hiding, deleting, and suppressing – can handle things like spam, vandalism, outing, and personal attacks just as well as talk page comment editing. They also require less work and time on the part of the user who's cleaning up the mess (you don't have to open up the comment, find the offensive portion, edit it out, and hit save – you can just click a button and hide the whole thing).
4. When you make something like editing comments into a social convention and not something limited by software, it becomes really easy for new/less experienced people to mess up – especially the kind of people who have the curious, bold disposition that makes them likely to be great Wikipedians someday (e.g., the kind of people who'll hit a button that says "edit" and mash some keys just to see what happens). And if those people are considerate and sensitive, they'll immediately feel horrible for messing up (doubly so if they then get yelled at for doing it) and will be less likely to try to participate again.
5. The fact is, participating in a discussion on Wikipedia is not like editing articles on Wikipedia. It never has been. There's no need to come to consensus or have NPOV on each and every discussion element; there is, practically speaking, ownership of individual comments (which is why editing others' comments, while technically allowed in some special cases, is generally strongly frowned upon in Wikipedia policy). I think that's perfectly okay, and has been working quite well for the 11+ years of Wikipedia's existence.

That's basically it. I'm not saying it's crazy or impossible to have a structured discussion system where users edit each others' comments (again, see StackOverflow and Quora). I'm just saying that due to the technical limitations of talk pages, the Wikipedia community has never been able to explore any alternative, so we've kind of just been trudging down this path with no evidence that it's necessarily the best one to follow. All I'm asking for is a safe-to-fail experiment with the alternative, to see if it's really as unfeasible as some users here seem convinced it is. Maryana (WMF) (talk) 21:38, 8 October 2013 (UTC)

And all we've asked in turn, Maryana, is that you not hardcode the result to match your conclusion. I tend to agree that willy-nilly comment editing by everyone is a bad idea. I'm fairly certain that allowing bureacrats to edit comments would be pretty safe. If you make the user right configurable, we can experiment with restricting it to autoconfimed editors, restricting it to admins, restricting it to bureaucrats, establishing a separate user right (similar to our current "reviewer" user right for Pending Changes), or things that I haven't even thought about. Any of those systems may prove to be best for English Wikipedia, and it may be that a different system is best for German Wikipedia, and yet another best for Spanish Wikipedia. I really don't understand your resistance to that.—Kww(talk) 21:51, 8 October 2013 (UTC)

It will be configurable. It's impossible to implement "only authors and admins" without configurability. That is a configuration. It might not have an onwiki toggle that you personally can change, in the very first release (just as many thousands of mediawiki settings do not), but some system of changing it will inherently be possible. "Admins" is just a User group, and if one is assignable, any or many are assignable - nobody has ever suggested that it would be hardcoded! (The amount of confusion over this issue is too damn high!) Quiddity (WMF) (talk) 22:10, 8 October 2013 (UTC)

Thiiiiis ^ is 100% correct, approved by all official organs, signed and counter-signed. (Thanks, Quiddity (WMF), that sums it up perfectly.) Maryana (WMF) (talk) 22:39, 8 October 2013 (UTC)

So why did it take so long to get you to say it, Maryana? Or is it the commitment to honouring community consensus about the appropriate setting that gives you pause?—Kww(talk) 22:42, 8 October 2013 (UTC)

You are the only one saying that will be possible, Quiddity, but you are correct: that's all I'm asking for a commitment to support from the software, so long as WMF commits to respond to each community's consensus as to how it should be set. Just get Maryana and Okeyes to confirm, and this whole discussion goes away.—Kww(talk) 22:15, 8 October 2013 (UTC)

Maryana just agreed with it, and I've been saying that (in different words) from the beginning; that what we are debating is whether the configuration will be commonly altered or not. Okeyes (WMF) (talk) 22:50, 8 October 2013 (UTC)

Oliver, I'll accept that you believe you've been saying that in different words. For the sake of project communication, I ask you to go over what you have said and try to understand why none of us read the words you wrote that way. In fact, you specifically said that you would only implement comment editing if trials without comment editing failed, and made no commitment to have any configuration control over it at all.—Kww(talk) 22:57, 8 October 2013 (UTC)

Suggestion

Yesterday I changed -- in fact reverted -- another user's comment on this very page: it was a trivial piece of vandalism which had in turn changed a previous user's comment. It made me think about how to deal with obvious vandalism in structured discussions. Here's one possibility. Allow anyone in one group of users, such as everyone, to "hide" a contribution so that it can only been seen and restored by some in some smaller group, such as admins, while flagging up that there is a hidden comment. It seems that it would be feasible to implement this and it might be useful in certain situations. Spectral sequence (talk) 06:37, 21 October 2013 (UTC)

Community engagement strategy

... is up onwiki. We want to be transparent about:

• our plans for the development and deployment process of Flow, and how the community can take part in it
• how we're planning on incorporating community feedback
• specific milestones and goals for the next 3 months

Have a look and see what you think! Maryana (WMF) (talk) 22:17, 3 October 2013 (UTC)

Your first problem is that you commit to treating user comments "with the same weight" as feedback from team members. In general, comments from a user community are considered to be more important than comments from developers.

I'd also like to see you say something that addresses the little problem we have above, where a WMF member committed to a feature, WMF forgot the commitment, and then, upon being reminded, we have WMF staff members commenting that it would be a good idea to experiment with reneging on the commitment. It really should not be surprising to you that people have difficulty taking WMF at their word.—Kww(talk) 22:27, 3 October 2013 (UTC)

In general, comments from a user community are considered to be more important than comments from developers. If all we want is a wishlist of community features, let's just enable Liquidthreads :) But seriously, most community members are not software developers or designers. If you asked a random Wikipedian, I don't think he or she would feel comfortable being responsible for developing a discussion system that will be used by hundreds of thousands of people all over the world – not just the people using Wikipedia today, but current and potential new users for the next 5-to-x years. As the doc mentions, we have different skills distributed among us, and we will need to balance community knowledge with visual and interaction design best-practices, technical feasibility, patterns from other products, research and data analysis, and many other things that the WMF has the staff and resources to do. I'll add a note about that.

As to your second point, clearly somebody needs to make the {{draft}} template much more flashy... perhaps blink/marquee? :) Maryana (WMF) (talk) 23:05, 3 October 2013 (UTC)

I don't think it's practical to say that user feedback should be prioritised above all other concerns, for a couple of reasons.

First: in a lot of situations, we need comments from developers to take priority - comments about what is possible, what is feasible, what is scalable, for example. Second: comments from inside the power user community taking precedent over all other thoughts only makes sense if you posit that features for existing users are the only things we should be building. Now, if you genuinely believe that, I would genuinely advise that you disengage from Flow entirely, because Flow - indeed, most of our features - are not exclusively about making life better for existing users. They're also about making things better for all users, including new ones who don't currently get a voice on conversations like this, and potential users who don't get to participate in any of our things full stop. And existing users (including me!) are not necessarily the best people to decide what "all users" need - we have a vested interest and a vested perspective.

That's why we have people tasked with looking at what is needed overall - not developers, but Product people like Maryana, designers like Brandon or May. Because we need to synthesise all perspectives in this conversation, be they from people who represent the experienced user (us) or people who represent those who don't have a seat at the table yet. If you genuinely believe the WMF's task with software development is to build things exclusively for and dictated by the existing users, like you or me, then we have a fundamental conflict here, because that's not something we're ever going to do. We should have a cooperative relationship, not a master/servant one (in either direction). Okeyes (WMF) (talk) 23:07, 3 October 2013 (UTC)

It was a direct commitment from a staff member. Fixing the draft template has nothing to do with the basic concept of honest communication and viewing commitments as commitments. The only reason given so far for reneging on the commitment has been that Maryana, personally, dislikes the way we are able to edit comments. Why do you think her personal dislike for something should be imposed on each and every version of Wikipedia, as opposed to making it configurable so that each Wikipedia version can set its own policies independent of the WMF?—Kww(talk) 23:15, 3 October 2013 (UTC)

We're not talking about policy, here, we're talking about software; let's be clear. And, no, that's not the reason that's been given - the reason that has been given is that our designers believe it is inconsistent with user expectations and web standards. I want to again underscore that we are not talking about "oh, that thing we said, ignore that thing, here's no-comment-editing ever". What we're saying is that it's trivial to build a system that does, say, no-comment-editing and then switch it over so that it's configurable on a per-wiki basis. Because of that, it costs us almost nothing to experiment - and when we say experiment, we mean "deploy one version to the talkpages of two wikiprojects, in a couple of months, and see what they think, and switch if they really don't like it and can point to tasks it inhibits".

Yes, it was a direct commitment from a staff-member; that staff member was wrong. What you're asking for here is for us to always back up any statement made by any individual staffer, and that's not going to happen (I could say, right here, "I promise wholeheartedly we will experiment", and then his commitment conflicts mine. You see the problem). What I'd rather is that we maintain a consistency of communication from hereonin, and in future projects, and experiment with different variants on comment editing to see if there are useful use cases for allowing different user classes to edit the comments of others. If you want to help convince us that we should allow for comment editing by other users, you should contribute to the list of use cases linked above. Insisting that we as an org commit to anything any one staffer promises is not going to help (and, given the things individual staffers have said you undoubtedly disagree with, probably wouldn't make you happy any more than it would us). Okeyes (WMF) (talk) 23:24, 3 October 2013 (UTC)

I think you'll find that it is not only Maryana who does not want comment editing. I think you'll find that's pretty much a unanimous consensus among Foundation staff, for many, many reasons. So please don't single her out for your frustrations.--Jorm (WMF) (talk) 23:26, 3 October 2013 (UTC)

I agree with you that we should not single people out. But I think at least part of the point was about where WMF staff may be imposing their views on the community, so having other WMF staff agreeing does not address editors disagreeing. I like the way the most recent descriptions of the planned rollout include lots of respectful community consultation. I simply ask that WMF people not go into that consultation having already made up their minds. --Tryptofish (talk) 23:44, 3 October 2013 (UTC)

That's reasonable, and I don't think we have. I can't speak for everyone, mind, just myself, but: I get the impression that while people have preferences (just like volunteer members of the development process have preferences), they're not committed to doing something if the evidence says "this is a terrible idea". That's why we're trying to keep things rather loose and experimental and hunt for that evidence. On my part, at least, I'm kinda..wavery. I don't use comment editing that much myself as a volunteer, and I get the UI argument, but I'm looking at workflows like GAN and talkpage reviews, and the problem of people using incorrect wikimarkup and damaging their comment, and inwardly flinching. Okeyes (WMF) (talk) 23:52, 3 October 2013 (UTC)

The question as to who should be allowed to edit comments under what circumstances is a policy decision, not a technical one. It is something that each community of users could reasonably be expected to come to a different conclusion about. Simply taking it away takes it away from everyone, giving it out carte blanche keeps each community from regulating it. Your point above is well taken: it's trivial to make it configurable. It's your conclusion that's dead wrong: it's not each community's obligation to convince you what you should hardcode the setting to, it's your obligation to provide control of that setting to each community.—Kww(talk) 23:34, 3 October 2013 (UTC)

And again, that principle makes perfect sense if you think the community of long-term editors, such as you or I, can bring every necessary perspective on something with UI and user experience implications to the conversation. If you genuinely believe that, again, I'd advise you to walk away from Flow, because we do not. We believe that we can't succeed with this without experienced users' perspective - otherwise we wouldn't be asking for and including feedback - but we can't succeed exclusively with experienced users' perspective, either. I've already explained we're not taking it away as an option, just noting it as an option rather than a dead certainty. If you want to convince us it should be a dead certainty, add use cases to the document mentioned above. The discussion as it stands now is circular and not a useful way to spend your energy or mine, because we are not shifting from the position that small-scale experimentation is superior to picking the first option that comes along and ignoring others. I'm going to go back to adding the use cases; you're welcome to join me :). Okeyes (WMF) (talk) 23:42, 3 October 2013 (UTC)

I'm flabbergasted. I'm trying to tell you not to decide at all and that it isn't your decision to make, and your response is that you won't "pick the first option" that comes along. Please, don't pick an option. Please, don't make a decision. I'm begging you not to decide this issue. Simply implement the tools that allow people to decide for themselves, and potentially change their minds for themselves. The mindset that you have that I'm objecting to is way above this particular issue of comment editing. It's the mindset that WMF should make decisions about things when decisions don't need to be made. WMF never needs to decide when comments should be editable and by who. If your mindset is that you should make rigid decisions about features when they are easily made configurable, then I beg of you to walk away from Flow. Make decisions only when you absolutely have to: don't hard-code things when you know that there's disagreement.—Kww(talk) 23:54, 3 October 2013 (UTC)

Let's see if I can draw a conclusion from the raw data.

Data point 1: A while back we had a discussion about naming pages "Talk Page", "Discussion", "Comments". "feedback" etc.

Data point 2: It was determined that this would be a configuration option, (which it pretty much has to be for the different language wikis) and thus the WMF doesn't know, doesn't care, and doesn't have to decide what to call it.

Data point 3: This ended the discussion. Go ahead and try to bring it up again and see what happens.

Data point 4: We also had a discussion a discussion about who can edit talk pages.

Data point 5: Some of us were under the impression that this would also be a configuration option, and thus the WMF wouldn't know, wouldn't care, and wouldn't have to decide who can edit comments.

Data point 6: Unlike the case with the names, various people on the WMF side are still talking about it as if they have something to do with making the decision.

Conclusion: The WMF still doesn't "get it". Kww tried to explain it above, but doesn't seem to be getting through despite his explanation being quite understandable.

My opinion: This has the potential of devolving into open warfare with many hard feelings and misunderstandings. I really don't want to see that. --Guy Macon (talk)

Well, no. If you look at the conversation that was part of data points 1-3 (or at least, the bits I remember) you'll see we said that it was per-wiki configurable and so we could discuss it later without having any problems, and that we probably wouldn't care but obviously reserve the right to step in if (somehow) a ludicrous conclusion is reached. So it's somewhat different. More importantly, the fact that it was settled back then is...somewhat secondary, in the sense that it's not a factor; I agree (I can't speak for the team overall) that per-wiki configurations are appropriate. The fact that there was a discussion, pre-proper-discussions-about-Flow, that agrees with me, isn't really a factor.

I agree it has the potential to devolve - this is why I've tried to shift users' attentions to (1) actively contributing to the discussions about comment editing using arguments on the pros and cons of comment editing, rather than what was said by one staffer before the rest of the team was involved, and (2) keeping us honest in future discussions. I can't promise that anything agreed to by any one staffer in the past will be honoured, no. I can promise that, unless there are pretty substantive exigent circumstances (which we would explain and discuss), our statements can be relied on hereonin - and that our statement in this case is not "no comment editing" but instead "let's experiment with different solutions and see what works". Okeyes (WMF) (talk) 04:45, 4 October 2013 (UTC)

But why is WMF doing the experimentation and reserving the right to make the decision for all projects forever? What would be the reasoning for ever making this hardcoded? The issues of voiding previous agreements and expecting us to believe that you won't void agreements again aside, why aren't you simply defaulting to make things like this configurable? The various communities are quite capable of experimenting for themselves.—Kww(talk) 06:04, 4 October 2013 (UTC)

I keep trying to parse these issues, and I keep running into the fact that different WMF people, if not exactly saying different things, certainly have different styles of saying them. I accept that WMF is very interested in "data" about what potential new users – who, by definition, are not commenting here – are going to benefit from. At the same time, experienced users have opinions based upon experience and not upon personal whim, that I hope and expect will be taken seriously during the forthcoming rollout and consultations. I think that the dividing line resides where the "data" might conflict with community consensus. Editors here, not unreasonably, are worried that there will be "data" that appears flawed to us, but WMF will insist that they have evaluated the "data" correctly and are drawing the correct conclusions. WMF reserves the right to draw their own conclusions. The community worries that WMF will draw conclusions that ring false to the community. --Tryptofish (talk) 15:29, 4 October 2013 (UTC)

Kww; because, again, the existing communities do not necessarily have a wide group of voices in the conversation.

Tryptofish; I think that's fair - we all have different comms styles as different people (my last post, sent late at night, has potentially contributed to this problem; I was rather tired. Let me know if you want clarification on any point.)

I think your assessment of the data question and the worries people might have about data from our end is fair - I know Maryana has some thoughts about what we mean about data that she'll hopefully post soon, that heavily biases what we're initially interested in towards the type of qualitative data that existing users are great at providing, so hopefully a lack-of-factoring-in will not be a problem. I obviously can't speak to potential flaws in an unknown pool of future data, except to say that nobody questions data more than I do ;p. Okeyes (WMF) (talk) 17:24, 4 October 2013 (UTC)

To your first question, no, not at all. I feel like your communications on this talk page have been amongst the most helpful, and I thank you for it.

To the second point, let me put it this way. Sometimes, we have RfAs that fall in the discretionary zone, where bureaucrats have discretion to either pass or fail the candidacy, and where editor opinions are strongly divided. One or more crats will close the RfA, and explain how they arrived at their decision. Often, they will state that they gave less weight to some comments, and more weight to others, basing their explanation on policy and community norms. That has the effect of a few arguably privileged individuals, the crats, deciding to agree with some editors and disagree with others, even though those editors on the losing side may have felt very strongly. Similar outcomes happen with closures, typically by administrators, of very contentious RfCs. The community accepts this, even though some community members are disappointed by the outcome. The reason that the community accepts it is that we can see how the decisions are based on agreed-to principles, and we can see that the closers are not simply using their positions of privilege to impose their personal preferences on the community.

That is what you folks at WMF need to strive for. If there are reasons to say that you are discounting the advice of experienced editors because of what you know about the needs of inexperienced editors, you need to convince us that you have good reasons, consistent with community norms, and that you are not just imposing your personal whims upon the rest of us. In discussion with a larger section of the community than what you have on this talk page, you will get acceptance if you succeed at that, and very strong pushback if you fail. --Tryptofish (talk) 17:41, 4 October 2013 (UTC)

That seems both reasonable and rational. I'm not sure if community norms are necessarily what we need to be striving for, insofar as there are going to be differences between "an optimal relationship between editors" and "an optional relationship between developers, designers, researchers, product people and editors", but I agree we need to aim for some kind of normalised set of principles - based, presumably, on movement-wide rather than community-specific values (since the WMF and community both fall under movement, but don't both fall under community). I think that's what Maryana is aiming at with the statement of principles on the Flow page, and with the community engagement principles that follow from it - including the one that states that staffers, too, are required to follow the movement norms. If there are specific things you think could help (eg, "explain why you are discounting things" being called out explicitly rather than implicitly), we can discuss them and factor them in if nobody has a problem, although I'd like to avoid seeing it turn into something the size of Raul's Laws. Okeyes (WMF) (talk) 18:19, 4 October 2013 (UTC)

I certainly hope that this isn't becoming a retread of that tired "power users are taking away things that newbies need because they are just great big meanies and the WMF has to come to the rescue" argument. Options should default to being under community control, and the WMF should eliminate local configurability only in extreme cases.—Kww(talk) 18:01, 4 October 2013 (UTC)

I observed earlier that some WMF staffers have different communication styles than others, and it occurs to me that the same is true of editors. Kww and I just said those things in different ways, but my opinions are fundamentally the same as Kww's. --Tryptofish (talk) 18:07, 4 October 2013 (UTC)

@KWW: I thought we (power users) were generally accused of adding too many options, and thereby overwhelming newbies! (I want more preferences. I love firefox's about:config page, and am frustrated by linux-gnome's current move towards oversimplification.) - Anyway, my take on the issue, is that it will be configurable, by the communities, but the staff are planning a short experiment with a different configuration than the one we asked for, because it might lead to interesting insights. Ie. They want to test some of our assumptions. The same goes for some of the design-choices in the initial versions (with which I disagree personally, but I'm willing to test out different options). When Okeyes says "qualitative data" above, he means direct feedback from us (the community). In the long-run they're definitely not going to force settings on us that don't work.

@Tryptofish: "All people are the same, only their habits differ." (attributed to Confucius) :) Quiddity (WMF) (talk) 18:41, 4 October 2013 (UTC)

--Tryptofish (talk) 21:04, 4 October 2013 (UTC)

Quiddity: bear in mind that I've been publicly accused of selfishly disabling critical software and endangering the stability of Wikimedia servers because I was insensitive to the needs of newbies. The meme that I did so because as a "power user" I'm unable to understand the needs of inexperienced users and that RFCs should be ignored because they don't truly represent the community is one that I'm growing exhausted by, but it has been popular recently.—Kww(talk) 19:06, 4 October 2013 (UTC)

Re: power users adding too many options and thus confusing newbies, we don't allow newbies to see the configuration options that set what each user group can do. (BTW, who does have permission to change those settings? I have never seen that defined.) --Guy Macon (talk) 23:16, 4 October 2013 (UTC)

Kww, I would be a lot happier if you stopped saying "configurable per wiki" when you actually mean "configurable by any local admin" (e.g., by you or any other admin here who believes himself to have local consensus for the change).

"Configurable per wiki" includes "the English Wikipedia and the German Wikipedia can have different settings, but to get any change made, you have to file a bug report and get a dev to implement it". Flagged Revisions—which is turned on there and turned off here—is "configurable per wiki". Although you ignored my direct question about this above, you seem to want "any admin can change the setting any time he feels like it" (I assume that no admin would do so without community support; our admin corps is overall quite good that way).

I've got no objection to that kind of system, but it is far more specific than just "configurable per wiki". You want "configurable by local admins", not merely the possibility of different wikis having different settings. It would reduce confusion if you'd start using the clearer language. WhatamIdoing (talk) 23:21, 5 October 2013 (UTC)

Actually, WhatamIdoing, I'm quite willing to deal with "configurable by bureaucrats" or even "configurable per wiki by devs" so long as WMF commits to honouring RFCs (or similar community processes in other versions of Wikipedia) over how the individual flags should be set. That's generally been how things like this have worked in the past, and, despite the recent conflict, a reasonable model for how things should work in the future. The administrative structure of a Wikipedia version going into open revolt should be a rare occurrence, and the WMF saying "we don't care what the result of your consensus seeking process is: we will inflict this upon you anyway" should be equally rare. What's being said here is that no one will commit to making any mechanism to adjust the behaviour of a setting despite it being fairly obvious that there is no single agreed-upon value for the setting and it being extremely likely that different versions of Wikipedia would, given the choice, select different configurations. I don't understand the rationale behind the present argument that the conditions for "who can edit another editor's comments?" should be fixed, as opposed to configurable, unless the plan is to disable the feature completely.—Kww(talk) 23:41, 5 October 2013 (UTC)

Then perhaps you'd like to try "controlled by each community" as a phrase that might make your concerns clearer. So far as I can tell, it will be configurable per wiki (for essentially technical reasons). This has been expressed as the designed intention, and it has never been contradicted by anyone. The only open question that I can see is who gets to decide what the configuration will be. WhatamIdoing (talk) 23:48, 5 October 2013 (UTC)

WhatamIdoing:They've explicitly repudiated honouring Jorm's commitment to make it configurable on a per-wiki basis. Okeyes's statement it "What we're saying is that it's trivial to build a system that does, say, no-comment-editing and then switch it over so that it's configurable on a per-wiki basis. Because of that, it costs us almost nothing to experiment - and when we say experiment, we mean 'deploy one version to the talkpages of two wikiprojects, in a couple of months, and see what they think, and switch if they really don't like it and can point to tasks it inhibits". That's a pretty explicit statement that they will build a version where the ability to edit comments is not configurable in any fashion and only change it if those particular wikiprojects can persuade Maryana's group that it's a problem. If that's not what Okeyes intended to say, it's not me that requires education in how to communicate more clearly. I do my best to read everything the WMF says carefully and respond only to things that have actually been said. As a corollary, I do sometimes get insistent that people actually say something and make some commitments because of how badly trusting people to make reasonable decisions about VE turned out.—Kww(talk) 00:21, 6 October 2013 (UTC)

You seem to have missed Maryana explicitly saying that wikiprojects refusing to use it would constitute it not being viable. Anyway; at this point we're clearly not having a productive conversation - I would suggest we all split off to more productive things (like; providing pros and cons and use-cases for different levels of indenting, above). Okeyes (WMF) (talk) 16:57, 7 October 2013 (UTC)

I certainly hope that it doesn't have to get to the point of communities refusing to use Flow at all before Maryana will consent to implement obvious and trivial options that allow the tool to be tailored to each community's preferences. That's establishing a "we won't cooperate unless the community goes on strike" model from the beginning, and I think that's what we are all trying to avoid. If the conversation is unproductive, I think it's pretty clear as to why. We are in a situation where everyone agrees the option is trivial to implement, but WMF staff are refusing to commit to implementation without providing any substantive justification for their refusal. And no, "other discussion formats don't permit it" isn't a substantive justification for removing an existing capability.

The capability exists. We've requested it be retained. Everyone has been willing to compromise by putting constraints on it, such as requiring specific user rights. Why does the WMF have to get so confrontational by refusing to commit to implementing it?—Kww(talk) 17:24, 7 October 2013 (UTC)

I read the same comments that Kww read, and came to the same conclusion. Yes, I am hearing some voices say that it will definitely be configurable with the configuration decisions in the hands of the local Wikipedia, but I am also hearing other voices that are implying that they just might make it so that the the only way to get control of the configuration option -- or even to insure that it will exist -- is to completely reject Flow unless it has the option. The problem with that is that if (as seems likely) Flow turns out to be far better than the present system in a hundred ways, it might be very difficult to get consensus for rejecting it over this one issue. Picture someone trying to control a room foll of preschoolers when the only tool they have is a 12 gauge shotgun. What if I really want Tommy to stop stealing Suzie's pencils, but I am not willing to blow his head off over it?

Please note that additional assurances from those at WMF who have already assured us that it will be configurable are of little value. We need assurances from those at WMF who have stated or implied that it might not be. --Guy Macon (talk) 23:16, 7 October 2013 (UTC)

Okay, there seems to be a misunderstanding here; we're not talking about rejecting on a wide scale here. The workflow goes something like this:

1. We produce the prototype version
2. We ask a wikiproject to try Flow, having them play around with the prototype to see what it's like
3. The wikiproject says "are you kidding? Without comment editing? That's not workable for X, Y and Z reasons"
4. We go "okay!" and introduce configurable comment editing.

We're not talking about project-wide consensus on every point, here; we just want to make sure that users have the opportunity, with experimental features or decisions where there are a lot of pros and cons in both directions, to try alternatives before returning to the default. If the alternatives work, great! We've made an improvement. If the alternatives don't, the cost of experimenting (in editor time, in staffer time) is tiny. Okeyes (WMF) (talk) 23:43, 7 October 2013 (UTC)

Gosh, Okeyes, if you want us to try alternatives, why don't you make it configurable so we can try alternatives? It would be interesting to experiment with only allowing admins to edit comments, or allowing only autoconfirmed accounts to edit comments, or only bureaucrats to edit comments, or making it an independent user right granted by community consensus and bestowed by admins. There are numerous configurations we could try. But we can't if you refuse to make it configurable.—Kww(talk) 00:01, 8 October 2013 (UTC)

Why do we need to fix something that works fine already with this? Bwmoll3 (talk) 23:50, 5 October 2013 (UTC)

I think Flow might be a good thing as long as certain critical aspects are met.

1. First, it must be able to use templates. Consider that a requirement in the design phase. If Flow cannot handle templates, then you may as well not even deploy it here and keep it for other Wiki's who don't rely on templates.
2. Next, it really needs to be used on all talk namespaces not just one or two. Its fine to start out testing on one or two, but we absolutely should not maintain multiple talk page platforms on one wiki. Its confusing and pointless. If its not going to work for all talk pages, then don't do it.
3. TEST, TEST, TEST....BEFORE you release. Don't rush it and do the job half-ass like Visual editor. Test it on Wikiproject banners and a variety of templates. Does it work with Twinkle and AWB (I admit theh WMF isn't on the hook to fix these but they should be aware of problems and get the appropriate devs engaged). No more of this gunslinger mentality, we know better than you attitude like we saw in Visual Editor.
4. Absolutely no red or green text boxes.
5. Take community input seriously. We are not as stupid as we seem and can help if you allow us and listen to our input.
6. Be original, we do not need too and should not be copying facebook or some other site. 71.126.152.253 (talk) 23:54, 5 October 2013 (UTC)

Red and green text boxes? And: yeah, we're going to test extensively. If you look at the deployment plan and such you'll see that we're deliberately rolling out on an incredibly small scale to start with (read: two wikiprojects) and incrementally after that. This should allow substantive bugs to be surfaced. Okeyes (WMF) (talk) 16:57, 7 October 2013 (UTC)

I take it you've never done UI design for the color-blind, Okeyes? When I used to design alarm displays, one of the key steps was to ensure that the system state was instantly recognizable for people that could not distinguish green from red. It holds for computer interfaces as well: green or red backgrounds or text tend to make systems difficult to use for a large percentage of males.—Kww(talk) 23:26, 7 October 2013 (UTC)

No, I've never done UI design for the colour-blind - this is because I'm not a UI designer. Instead I listen to the ones we have. I was not asking "what's wrong with colour?" I was asking "what red and green boxes do we have?" Okeyes (WMF) (talk) 23:39, 7 October 2013 (UTC)

I read the IP's comment as providing guidance, Okeyes, so I was explaining it. There were some red/green issues with the Notifications feature, which is probably why he chose to bring it up.—Kww(talk) 23:47, 7 October 2013 (UTC)

That makes sense; thanks. Okeyes (WMF) (talk) 17:20, 8 October 2013 (UTC)

Yes, that is correct and the reason I say test Okeyes is because the WMF has a history of not doing proper testing. The community are not guinea pigs, there should be significant testing before it is thrust upon the community. A lot of the problems with Visual Editor were so blatant and obvious it was easy to tell that testing was an afterthought. I would also be interested in knowing how Flow differs from Liquidthreads. Maybe that has been explained somewhere you could point me too. 71.126.152.253 (talk) 01:55, 8 October 2013 (UTC)

It hasn't to my knowledge, but that sounds like a good thing to go in the FAQ - Quiddity, what do you think? Okeyes (WMF) (talk) 17:20, 8 October 2013 (UTC)

There's a brief mention in the meta FAQ (which is out of date in other places), but I'll work on getting more details added. Quiddity (WMF) (talk) 18:09, 8 October 2013 (UTC)

In case it's been forgotten, other minimal features required for Flow to be usable are:

1. Copy/paste between Wikitext and Flow messages, or between Flow messages. (Adding copy/paste with VE would be helpful, as VE should not be considered acceptable without it, but, that's a matter for another talk page, as copy/paste between VE windows is not yet implemented.)
2. Including arbitrary Wikitext (not restricted to mw:Parsoid) in any Flow message. (Some projects might be able to get by without this, but if it is not intended to put it in eventually, Flow will not be usable on article talk pages or user talk pages.)

Note that it doesn't have to be "native" Flow text, but it has to look the same as if it were on a talk page.

Have you any criteria for selecting WikiProjects which might be interested in Flow? — Arthur Rubin (talk) 02:33, 8 October 2013 (UTC)

Any WikiProject that puts itself forward as a volunteer, will be welcomed! We're just planning on a very limited number at first (see the updated WP:Flow#Roadmap), but aim to add more locations as the bugs and issues are resolved over the following months. We're slowly getting a list of locations that have discussed it and are interested. Quiddity (WMF) (talk) 03:31, 8 October 2013 (UTC)

Copy-paste between wikitext and Flow could be complex; since we're planning on having a wikitext editor for Flow it may not be necessary. I agree that VE copypaste and copypaste within the Flow instance of VE will be required for it to be perfect, but those things are out of our hands to some degree - the VE team has to work on them. Okeyes (WMF) (talk) 17:20, 8 October 2013 (UTC)

If there is a wikitext editor for Flow, which doesn't block normal copy-paste functions of the user's OS, then copy-paste between wikitext and Flow will be available. I didn't necessarily mean that you (WMF) have to provide it. — Arthur Rubin (talk) 10:06, 9 October 2013 (UTC)

Aha, gotcha. That seems totally reasonable - I can't see us blocking the functionality (at least, I hope we don't. I use copy-text-fragment-and-find to match things between read and edit mode.) Okeyes (WMF) (talk) 16:43, 9 October 2013 (UTC)

The use case here is for the convenient incorporation of fragments of text, including advanced markup such as mathematics, from articles into Flow discussions, then from one Flow comment into another, possibly modified, then when agreement is reached, back into articles. This would appear to me such an important aspect of building the encyclopaedia that I find a mere "hope" somewhat lukewarm. Indeed, I had thought that we already had agreement on that case. Perhaps I was misinformed. Spectral sequence (talk) 15:57, 10 October 2013 (UTC)

Yes. Article text must be copyable to discussion posts. That is agreed. (The engineers are currently working on importing many of the templates and extensions that are necessary for things like <math> to work properly in the prototype. Not today, but it will work soon. But {{citation needed}} alone has 88 dependencies, and the import tool didn't appreciate being given the top 500 templates last night, so it's not simple and easy.) Quiddity (WMF) (talk) 19:09, 10 October 2013 (UTC)

I noted that there were three relevant directions for copying text including advanced markup in the use case: article -> Flow; Flow -> Flow; Flow -> article (the logical fourth, article -> article, not being relevant here as not involving Flow). You mentioned just one, article -> Flow, as being agreed. Could you let us know what the decision, if any, is on the other two directions, please? Spectral sequence (talk) 08:41, 11 October 2013 (UTC)

I have provided feedback after my first encounter with Flow here. Please don't plan on releasing this in the the next few months, this is so far removed from a community testable stage that I don't know whether to laugh or cry. If I didn't know better, I would guess that development on this had started one, at most two months ago. If you need to release this, do it on MediaWiki only, where the "ommunity testing" will mostly hinder devs and WMF people and not so much regular editors. But it would be better if you would not bother us with this... thing for the next six months or so, make sure that both Flow and the implementation on Labs are working correctly and as expected (by the devs and WMF), and then ask us to test it (preferably not on Labs with its dreadful privacy strategy, but that's a different discussion). As it stands, the "interactive prototype" simply doesn't work at all. Fram (talk) 14:24, 8 October 2013 (UTC)

Can you provide substantive criticisms please? (of the design, of the functionality...). Note that this is by no means the actual design - it's a placeholder.

If you've read the engagement plan you'll know that the first deployment is planned for a sandboxed Labs instance where it can't impact on anyone, and where users will be invited to test - the second is for two wikiproject talkpages, with both of them opting in to having it enabled and with substantial testing and consultation there in advance. If you haven't read the engagement plan, you might like to :). Okeyes (WMF) (talk) 17:20, 8 October 2013 (UTC)

@Okeyes (WMF): He did give substantive criticism, over at the linked diff! (which I'll reply to momentarily). Have some more coffee ;) Quiddity (WMF) (talk) 21:08, 8 October 2013 (UTC)

Thanks, Quiddity. Okeyes, these two Wikiproject talk pages, I suppose they will be on en-wiki? Any reason why you don't test first on MediaWiki? The roadmap seems to lack an internal testing phase, before the community testing phase, to get at least the technicla bugs removed first. And any reason why yuo are directing people to a poor placeholder instead of posting a "please don't test yet, a first testablke version will be available on date X" text instead? My visit to the Labs was basically a waste of my time. Fram (talk) 07:28, 9 October 2013 (UTC)

Bah, sorry; didn't see that. Consider my comment struck :/.

So, in order; yes, they'll be on enwiki. I think we'll deploy to mediawiki too (I'll find out), and we're going to be doing internal testing along the way (it's part of S Page's duties). These aren't in the engagement plan or release timetable, as you noted - as the author of the former I felt they'd probably not be of interest to most people, and I can't speak to Maryana's thoughts on the latter. But I'll ping her so she can address the questions :). Okeyes (WMF) (talk) 16:59, 9 October 2013 (UTC)

The 0.5 release will be to Labs, which is a Mediawiki environment – hence, a lot of bugs can be caught there. We probably will release to Mediawiki.org as part of this or subsequent releases, but that's not really all that much better than Labs; it's not going to provide us with the kinds of feedback we need to actually make this work on Wikipedia. To answer your second question, we're not actively directing anyone to Labs. The link is there, and anyone who's really interested can check it out. Transparency :) Maryana (WMF) (talk) 17:15, 9 October 2013 (UTC)

Ugh, Labs. Why direct people to a place with such a terrible privacy policy? I have visited a few times now, but am not inclined to test anything there.Why not the TestWiki? And I don't see why using two Wikiproject talk pages here would give so much more feedback than testing it on MediaWiki. Plus, it simply gives a better impression if you show that you have tested it in your own home environment first, MediaWiki of (perhaps even better) Wikimedia Foundation. Any reason why en-wiki is used again instead? Fram (talk) 10:10, 10 October 2013 (UTC)

I would've thought the advantages of trialling it here would be obvious; people use wikiproject talkpages. When we say testing we don't just mean "making sure it's not broken" (that's obviously of primary importance, but I'd hope a lot of those bugs would be found before any on-wiki deployment) we mean "making sure it does what people need it to". If we throw it out on mediawiki.org and invite people to test there then, ignoring the problems with an increased barrier to participating there, people will be testing for bugs. People won't be testing for "does it support X workflow based around Y template" (or if they are, won't have any luck) because mediawiki.org doesn't have, in this case, templates. It also doesn't have newcomers or message delivery or all of the other things we'll encounter if we deploy the software on a wiki people actually use. If your interest here is finding things that are bugs under the strictest sense of the word, that's great and I hope we can do it through the Labs instance and mw.org, but when it comes to on-wiki releases we're looking to find gaps in used functionality as much as actively broken things. Okeyes (WMF) (talk) 16:15, 10 October 2013 (UTC)

I agree with Fram here. If your going to start developing this use the lessons learned and base code from Liquid threads version 3. In fact what is the difference between Flow and Liquid Threads besides Flow being led by Jorm and Flow being a massive step in the wrong direction? 71.126.152.253 (talk) 16:37, 8 October 2013 (UTC)

I don't respond to questions phrased in bad faith; please refer to our engagement guidelines. Okeyes (WMF) (talk) 17:20, 8 October 2013 (UTC)

Dodging the questions isn't a good way to get off to a good start with the community. That was one of the problems with the Visual Editor implementation. 71.126.152.253 (talk) 20:38, 8 October 2013 (UTC)

I wouldn't have answered you either. You are clearly looking for a fight and Okeyes (WMF) was entirely correct to refuse to knock the chip off your shoulder. Try rephrasing your question to reflect the blindingly obvious truth that we are all in this together and we all want to do what is best but have some disagreements to work out concerning what exactly is best. Putting "(WMF)" after your name does not mean that you have to be a doormat or a punching bag. --Guy Macon (talk) 21:14, 8 October 2013 (UTC)

For what its worth you all are reading more into the comment than what it was intended. Its a simple question that IMO deserves an answer. The WMF stopped development on Liquid threadss because no one liked it. Now they are doing the exact same thing but calling it Flow. I have asked the question three times what the difference is besides who is leading it and have yet to get a response. So at this point I am going to infer that there is no difference, its just a name change for the same project. As it stands now the Flow implementation is going to be another Visual Editor bomb. 71.126.152.253 (talk) 22:08, 8 October 2013 (UTC)

No. In your opinion they are "doing the exact same thing but calling it Flow". In your opinion Flow is "a massive step in the wrong direction". You are entitled to your own opinion, but you are not entitled to your own facts. And you are not entitled to a response to your loaded questions. I have an opinion as well, based upon what I have seen and read so far and on many years of managing large and small software projects, several of which used Agile. My opinion is that WMF is basically on the right track. Yes, I disagree with some things -- but that doesn't mean that I am right. Yes, we do need better communication, but you are not helping. If you continue trying to start a fight, I am simply going to ignore you and advise others to do likewise. --Guy Macon (talk) 00:43, 9 October 2013 (UTC)

First, I have already stated on a couple other forums that Flow might be a good thing..if its done right. I didn't even have a problem with Liquidthreads other than a couple of things that could have been easily worked out. What I am saying, is that if these 2 software platforms aren't that different, which it appears is the case, then they shouldn't reinvent the wheel. They should look at the comments made by the community on it and build out from there. You keep inferring conflict where there is none. I a simply trying to get the WMF to answer one simple question and they aren't willing to do that. Stop making me into the bad guy for asking a simple question. The WMF has a long and clear track record of telling the community they want our input and they are going to do better next time and then when next time comes along they just ignore it. Indications are they will do the same thing here and you are not helping Guy Macon. 71.126.152.253 (talk) 01:13, 9 October 2013 (UTC)

Anon: Two of the developers who worked on Liquidthreads, werdna and jorm, are working on Flow, so yup, they're well aware of the problems that LQT ran into, and will be able to avoid many known problems. I won't speculate on whether they're reusing code. (Afaik developers reuse code constantly, and reinvent the wheel constantly. That's how they work from school till death!)

I hope we can all agree that Flow might be a good thing if it's done right! And work together (slowly, patiently, calmly, with a dusting of friendliness because we're all err-full humans) to make that happen, over the next 6-24 months. I do appreciate Guy's attempt to communicate, that the way some editors have been phrasing things occasionally comes across as quite combative - I keep looking at this talkpage and thinking of the Monty Python sketch about the man looking for an argument! Also, note that we're a separate group of people from every other team at the WMF, and will probably make completely different mistakes than those other people did... By which I mean: writing things like "the WMF has a long and clear track record" is inherently problematic, because the WMF is made of people - people can make decisions/mistakes, and teams of people can make decisions/mistakes, but beyond that the generalization is flawed.

This place has been my dysfunctional family of choice, for almost 8 years. I want to help improve it, and to get more of my intelligent acquaintances involved with Wikimedia projects. I love (because I'm used to?) the way the interface all works currently (with all the scripts and gadgets I use), but I'm hoping we can collectively (continue to) improve hundreds of aspects. </ramble> I hope that answers the questions, and resolves this tangent/thread. Quiddity (WMF) (talk) 23:09, 9 October 2013 (UTC)

Speaking as someone who has actually used LiquidThreads, it would be interesting to know what were the lessons learnt from that project and how they have been incorporated into the design of Flow. Spectral sequence (talk) 15:52, 10 October 2013 (UTC)

That's a very interesting question. From the conversations we've had internally I think there are substantive differences, both architecturally and in a user-facing way, but I'll let Jorm (ping!) chip in with his thoughts, as someone involved in both to some degree. Okeyes (WMF) (talk) 16:17, 10 October 2013 (UTC)

The subsection at Wikipedia:Flow/FAQ#Why not use LiquidThreads? (written by Jorm) has just been added. (Note that the rest of the FAQ is still outdated, per the note at the top). Quiddity (WMF) (talk) 07:21, 12 October 2013 (UTC)

A comment on engagement

Please when engaging with the user community could we all engage with the comments that have actually been made rather than replying to some exaggerated version. For example:

• Comment: "In general, comments from a user community are considered to be more important than comments from developers."
  • Response 1: most community members are not software developers or designers
  • Response 2: I don't think it's practical to say that user feedback should be prioritised above all other concerns
  • Response 3: comments from inside the power user community taking precedent over all other thoughts only makes sense if ...

None of these seem to address the comment as actually made. Could we agree not to do this in future? Spectral sequence (talk) 16:25, 10 October 2013 (UTC)

Speaking for myself: I try to answer everything as clearly and thoroughly as I can, without making TL;DR posts, and without spending excessive amounts of time phrasing things absolutely perfectly. I do struggle with phrasing, as there are so many word choices and combinations, and especially in a written context the tone or desired-intonation/emphasis is very hard to get across in an guaranteed way. I try not to misinterpret a statement/question, but often do. I try not write statements/questions/answers that over-generalize or over-simplify or could be understood in a different way than I intended, but often do. If someone asks a question and demands a black/white answer, but the reality is a spectrum of greys, then I'll try to explain that. If it were possible to have communication that was error-free, the human part of the planet might be a lot more peaceful.

In regards to the comment in question: Yes, the people who use the software are clearly the most important voices, in many many aspects. But an individual community member doesn't get a blunt veto card - for every aspect of the product, from database design to color choice, no matter what the developers or designers suggest - simply by being a community member - that's what the "Comment" seems to potentially imply (to me, depending on how I interpret the very short sentence), and what I guess the "Responses" were trying to address. TL;DR: The more provokingly/argumentatively a question is phrased, the more defensively-phrased the answer is likely to be! So yes, we can agree to all be as clear as we can, and to understand that misunderstandings can/do/will occur given the limitations of humans communicating via snippets of text. Quiddity (WMF) (talk) 19:08, 10 October 2013 (UTC)

Another ground-rule for discussion I would propose is, please don't answer a question with a question. For example, the following exchange is not helpful.

Is there pre-existing research and development to build on?

Into things like what the workflows are, or what capabilities the workflow system will need?

Spectral sequence (talk) 18:40, 14 October 2013 (UTC)

I'd say here you are being too hard on them. If they do not understand the question, there is nothing wrong with asking for clarification.

Anyway, perhaps the worst thing about communication from WMF side is much harder to define. It is the slight - but almost constant - belittling of the opposing side, coupled with self-righteous outbursts when opponents do not show them the respect they seem to expect. I am sure they do not even notice that (unfortunately, such level of social competence is rare). That is not going to be changed by any "ground rules"... It's the question of attitude: WMF representatives seem to be acting as if they were masters of Community members or (when they feel generous) their equals, while in fact they are supposed to be their servants... --Martynas Patasius (talk) 19:29, 14 October 2013 (UTC)

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

I would have supported this response by Jorm (WMF) if he had confined himself to answering the point about "servants". However, the gratuitous "why you seem to have difficulty communicating" is a good example of what Martynas Patasius describes as "belittling": it is a personal comment which does not help to take the discussion forward, and I for one have no difficulty in understanding MP's comments, even though I do not necessarily agree with them. And in this case I believe there is some validity to MP's point about attitude: I have already stated elsewhere that on occasions I have found WMF staff too ready to argue down points made by users rather than discuss them. Spectral sequence (talk) 06:43, 15 October 2013 (UTC)

I disagree. This part is true: nobody at WMF is my master or servant, but rather is a respected partner in a cooperative relationship. What I disagree with is taking Jorm to task over a rather mild expression of opinion while completely ignoring far worse from our side. Joining WMF does not imply that you are a doormat or a punching bag. Also, as a working engineer I know that there is one truth that will never change; you can have diplomatic and inoffensive communications or you can have developers be part of the conversation, but you cannot have both. Please try to cut those of us with technical skills a bit of slack; we try, but sometimes we are a bit blunt. --Guy Macon (talk) 07:00, 15 October 2013 (UTC)

I hope we all agree that all the conversations between WMF staffers and editors should be on the basis of a common standard of collegiality and collaboration. I am surprised by the "truth" enunciated here: it is simply not the case that developers and working engineers are incapable of collegial and constructive discussions, and as I say I think we all agree that everyone should be held to the same standards. Being blunt is not the same as being personally offensive, and the former is not an excuse for the latter. Spectral sequence (talk) 16:36, 15 October 2013 (UTC)

Well, there is a sense in which WMF is supposed to serve Community and not vice versa (just in case, I will clarify that I did not mean any kind of "personal" masters and servants). As the mission statement of WMF (m:Mission, [9]) states: "The mission of the Wikimedia Foundation is to empower and engage people around the world to collect and develop educational content under a free license or in the public domain, and to disseminate it effectively and globally. In collaboration with a network of chapters, the Foundation provides the essential infrastructure and an organizational framework for the support and development of multilingual wiki projects and other endeavors which serve this mission. The Foundation will make and keep useful information from its projects available on the Internet free of charge, in perpetuity.". In "scholastic-speak", the final cause of WMF would be to make it possible for the community of Wikipedia (and not just Wikipedia) to function. But that is not symmetric: the final cause of the Community is to build the encyclopedia, not to help WMF do something.

So, WMF is providing services to the Community. And in that sense they do serve it (there is nothing demeaning in being a servant; a title of Pope is Servus servorum Dei - "servant of servants of God"). For example, WMF is developing software for the Community, not vice versa. And thus we have another non-symmetric relationship: programmer - customer. And while The customer is always right might be a hyperbole, WMF seems to act according to "The service provider is always right" a little too often...

Thus, sure, there is a sense in which we all can be (and should be) equal partners. But that is not the complete story, and WMF would do well to pay a little more attention to the other part...

Also, I concur that "blunt" is not supposed to be synonymous with "unnecessarily insulting"...

P.S. Did you notice that I am using the same post to answer more than one post..? Will it be possible in "Flow" without workarounds..? --Martynas Patasius (talk) 21:39, 15 October 2013 (UTC)

I'm just going to leave this here... :) --Guy Macon (talk) 08:17, 16 October 2013 (UTC)

back to the original topic; I'm sorry if answering questions with questions is unwanted; I was trying to ascertain what precisely you wanted me to answer :). I'm happy to do a sort of...brain dump, of everything I know about a specific topic, in reply to a question about it that I find ambiguous, but that seems like it would be less productive than trying to get the language we're all using to line up so we can answer the questions as asked. For what it's worth, the engineers on the Flow team are sort of...disturbingly chill and calm about everything, but I think Guy is right that there are different standards of communication and interaction in engineering and non-engineering environments (that's probably a different conversation, however, and one only tangentially related to Flow). Okeyes (WMF) (talk) 17:51, 15 October 2013 (UTC)

Planning the communications

The Community engagement plan seems heavier on what you're going to do than what you're going to say (the comms part is really about groundrules). Do you have a plan for the messages you're going to put out, and when and how you propose to put them out to the various communities? For example, it was only by some fairly heavy engagement on this page that I realised just how ambitious the plan was in terms of capturing and codifying the workflows and discussion structures. I haven't really seen anything about that in the wider communications so far. It seems to me that that is a message you need to be getting out now to prepare the various communities for all the work you're going to ask them to do. And you must not underestimate just how much uphill work you have on the comms front right now. Spectral sequence (talk) 20:52, 15 October 2013 (UTC)

Re: Messaging: Slow and steady to begin. We need more basic functionality in place before we can start inviting hundreds of people to comment. We also need to work out how to structure and/or summarize the information that is needed to understand the "whole picture", in a way that appeals (as in, is not an offputting TLDR wall of details) to the most number of editors (so many different archetypes and demographics to communicate with!). (When I first learned about Flow, I skimmed through all the links in/from the navigation box. Hence mw:Flow Portal/Use cases was one of the first things I encountered, which gave me a good understanding of the scope. But not everyone works like that...). So yes, wider and wider notices and requests will be sent forth, but in a gradual buildup. Quiddity (WMF) (talk) 22:12, 15 October 2013 (UTC)

Too much chrome

I have problems with the default theme, it's too noisy and heavy (assuming this is the look you're planning to release), despite the steps taken to make it subtle. Can you assign your visual designer to iterate the design and make a lighter theme that removes all the distractions? Making a control light grey isn't enough to give it less visual weight (specially when it's a bold solid box covering the screen from side to side), it only makes it harder to read. The stripped bars effect is distracting, as it produces too much vertical rhythm and movement.

Please, take advice from Edward Tufte and remove every pixel that doesn't convey useful information. The bar to match is the current mediawiki Talk page - with its Vector default theme, which is extremely minimalist (and also what editors are accustomed to look at, for years). The Article Feedback Tool is better in that regard, as its uses a small grey line to identify each editor and separate one post from the next. For Flow, maybe a small grey line to the left of each post would be enough to signal indentation.

I think aligning comments text to the left and action controls to the right (including the balloon and the huge and too much repeated "click to reply") would also help to make the conversation easier to read. The focus of the design should be the content (even if you are proud of the dynamic controls and interaction, they should be receded - interaction is secondary to the main task, which is just reading). Diego (talk) 17:21, 8 October 2013 (UTC)

Uh? Have you recently changed the style? The Sandbox has now a different look than the one it had in my browser a few minutes ago. The new one still has too big Reply and Thanks buttons and the text has been made light grey and harder to read, but at least it doesn't have the huge distracting bars for each comment (only for each topic). Diego (talk) 17:38, 8 October 2013 (UTC)

The code (including the design) on that site is changing constantly (sometimes daily, sometimes more), as code changes are made. It will not be stable for a while yet (and will continue to change as we give feedback). I've given some FAQ type questions to the design team, and will put those up when they've answered them. I'll also pass along / point at your comments. Quiddity (WMF) (talk) 17:47, 8 October 2013 (UTC)

Thanks Quiddity :). I think the dynamic controls are likely to be mouseover or click-activated for the desktop view, which should help. Okeyes (WMF) (talk) 19:02, 8 October 2013 (UTC)

Ok! The Wikipedia:Flow/Design FAQ (initial questions that I threw at the design team) has been answered.

I'm hoping we can split the feedback into 2 parts, with Design comments/collaborations at Wikipedia talk:Flow/Design FAQ, and discussion about How Flow Works (functionality/features) on this page. There will inevitably be some overlap, and some people will continue to mix the two topics in a large post of feedback, but it's a start.

[Mixing the discussion of form and function, are what made many of past "redesigns" I've been involved with (eg the Main Page in 2005, and attempts in 2008/2011), drastically more complicated than they should've been.]

Emphatic reminder: The current prototype is not even close to complete! There is a cohesive design growing in there, but it's not visible yet. Feedback on anything is welcome anytime, but we know there are oodles of things that are missing/broken at the moment. Once a more complete design is available (and can be tested out properly), will be a better time to start giving detailed feedback. (I have no guesstimate when that will be, but will enthusiastically let everyone know!) Quiddity (WMF) (talk) 23:49, 10 October 2013 (UTC)

Who speaks for the WMF?

The WMF has decided to implement Flow but has stated that it needs the help of the community to do so. Some weeks ago I pointed out that this put members of the community under the necessity of assessing their position in terms of the amount of effort they were prepared to continue to invest in helping to develop and implement VE and Flow effectively and continuing to contribute content during the transition. At that time I was quite clear that members of the community could and should be involved in design decisions early, and that there were members of the community willing to involve themselves. The response I got from various members of WMF staff was such that I for one found no difficulty in deciding what the level of my own personal contributions should be for the next few months.

I now see that there is a "legacy of previous comms issues", that "statements made back then about what Flow will or will not have as a feature should not be relied on", that a statement "was a direct commitment from a staff-member; that staff member was wrong". This situation is frankly inadequate for the task of designing and testing a complex and inter-related set of software systems. I would earnestly suggest the following:

• WMF state exactly who is authorised to make decide, and report decisions, about design and implementation;
• WMF state exactly who is authorised to make statements about the technical aspects such as feasibility;
• WMF staff not on those list do not make statements that could reasonably be interpreted as being made on behalf of WMF;
• WMF staff expressing non-official or personal opinions do so from person accounts;
• Users do not take unauthorised statements as anything other than personal and do not attempt to hold WMF to them or complain if they are not acted on.

Spectral sequence (talk) 15:33, 10 October 2013 (UTC)

It sounds like you might benefit from checking out our team roles and responsibilities :) Here's the breakdown:

The Flow team operates on consensus. We are a large, cross-functional team of engineers, designers, product analysts, and community liaisons – and everyone has a say in decision-making. I'm the product owner on the team, which makes me sort of like the closing admin/uninvolved user. Everybody (and that includes anybody from the community) is encouraged to take part in discussions on Flow development and design, even if they disagree with me or others on the team (and I don't want to discourage that at all, not even onwiki), but no official decision has been made until I close the discussion. Maryana (WMF) (talk) 17:22, 10 October 2013 (UTC)

It is not about how WMF makes its decisions internally, it is about how it conveys them to the community, and how it deals with the areas in which no decision has yet been made. Do you regard it as acceptable that a member of WMF staff can make a statement to the community here which appears to be a commitment but which is then revoked with the comment "that staff member was wrong"? I do not. Spectral sequence (talk) 21:25, 10 October 2013 (UTC)

Changing a !vote

A common style of discussion which we see, for example in !votes such as RFC, RFA, AFD, runs like this (a typical RFA exchange)

• Delete as not notable. A.B

followed by an indented response

I have added three independent sources. M.N.

followed by a response

OK, I'm convinced, changing to Keep. A.B.

followed by striking the original comment to

• Delete Keep changed my mind A.B.

The resulting discussion looks like this

• Delete Keep changed my mind A.B.

I have added three independent sources. M.N.

OK, I'm convinced, changing to Keep. A.B.

It's well understood how to read such an exchange. Will Flow be able to cope with this particular case? Spectral sequence (talk) 16:35, 10 October 2013 (UTC)

This doesn't exactly fall under the scope of the first release (WikiProject talk), since that's not a place where AfD or RfA discussions are held (there may be cases of RfCs held on WikiProject discussion spaces, but I've never actually seen one). When we get to building for those discussion spaces, we'll definitely think specifically about how to support !votes, straw polls, and other decision-making processes with Flow. Right now, we're focused only on the peer-to-peer content discussion side of things.

But if you're just asking whether Flow will support things like editing your own posts, bolding, and strikethrough, the answer is yes :) Maryana (WMF) (talk) 17:31, 10 October 2013 (UTC)

I think it rather likely that decision-making processes are taking place at WikiProject pages and Flow will need to support them from the outset. It would be useful to start the process of collecting those requirements as soon as possible. The usecase I describe, one of many, at the workflow level is to be able to change one's !vote in a structured discussion in some way which makes it obvious to the reader what has happened and easy to read the current state of the discussion: a convenient way of instantiating that sort of process is to edit one's own comments, as is the current convention, but this need not be the only way, and I am trying to articulate requirements not solutions. Thank you for the assurance that the usual formatting will continue to be possible: that was not my concern. Spectral sequence (talk) 21:43, 10 October 2013 (UTC)

In a structured system, there isn't a need to edit your own comment to change your !vote. A structured system would store the value separate from the comment (if any) and you'd only need to modify the value of a pull down. No editing of wikitext necessary. Indeed, I think the idea of running !votes through wikitext is archaic.--Jorm (WMF) (talk) 21:47, 10 October 2013 (UTC)

Maybe so, but there is a need to make the history of the discussion clear. To take a more generalised example, it happens quite commonly in free-form discussions that a contributor makes a trivial mistake, for example, gets a URL wrong, and wants to correct it. Simply changing it silently, or with a <small> comment at the end, is quite unexceptionable. However, difficulties start to multiply when the error is meaning-changing. If I wrote that your comment was "good" and then realised that I should have written "goo", or the other way round, it would be courteous to people who might have read it to explicitly acknowledge the change. The current idiom for this is the strikethrough. An even harder case arises when another contributor has replied to the first version of the comment. If I write that your idea is "goo", and someone else writes "I agree with that" and then I go back and change "goo" to "good", I have materially altered the meaning of the other user's comment without actually touching it. In this case it is imperative that the system either prevent my doing that, or make it clear by an visible warning. For example, one might suggest that it a comment has been specifically replied to, it cannot be changed, or, better, that every dependent reply has a line added saying "This is a reply to an earlier version of the the previous comment dated foo and which may be seen at permlink bar" Spectral sequence (talk) 06:47, 11 October 2013 (UTC)

Minimum requirements for Flow

Will there be minimum requirements for browsers, operating systems or machine specifications needed to run Flow? This is clearly related to, but seems a different question to, the corresponding question about VE. Spectral sequence (talk) 16:40, 10 October 2013 (UTC)

We've discussed them briefly internally, and the need to cope with things like a lack of javascript: obviously since we'll support both VE and wikitext we'll have the option to support non-JS browsers for the main functions of a discussion system (although it may be pretty ugly). In terms of specific browsers, we haven't set those down in stone yet, although it's a conversation I've been encouraging us to have. MW as a whole doesn't have a coherent browser matrix anyway - also a conversation we need to have. I appreciate it's not the ideal answer, but it's the one I've got :/. Okeyes (WMF) (talk) 17:00, 10 October 2013 (UTC)

You'll need to support all browsers and OS and whatever though, if you want to follow your Wikipedia:Flow/FAQ: "New users will be automatically be given Flow"[sic]. It is not clear, after reading this and the above discussions, whether Flow will be implemented on a page by page base, or on a user by user base. The FAQ suggests the latter, but everything else (and logoc) suggests the former. According to the FAQ, "existing users will have to choose to upgrade.", but how one will be able to participate at e.g. WT:MILHIST without "upgrading" is unclear, and whether once someone has "upgraded" he will still be able to participate in "downgraded" old school discussions is equally unclear if one believes the FAQ. In reality, it seems to me that no one will have the possibility to opt-in or opt-out wrt using Flow, people will (at most) have the possibility to decide whether page X or Y uses Flow. Perhaps this is what the FAQ tries to convey, but it fails rather badly... Fram (talk) 19:57, 10 October 2013 (UTC)

Fram, I just updated the FAQ with a huge "this is out of date! please stand by" header, because it hasn't changed substantially since it was created 6 months ago, and our thinking about the first release has shifted pretty drastically in the last few months. Please consider WP:Flow/MVP and the roadmap on the Flow main page the definitive documentation for now; we'll be working to gut and update the FAQ in the next few weeks. Maryana (WMF) (talk) 20:10, 10 October 2013 (UTC)

Thanks. I had also started a thread about the FAQ at MediaWiki, perhaps you can make the same comment there (if you already did, please ignore this of course). Fram (talk) 20:13, 10 October 2013 (UTC)

Accessibility is not an option, so it would be a good idea to start off with a minimal list of browsers that must be supported if only to include those that are required for users with various accessibility needs. Spectral sequence (talk) 07:10, 11 October 2013 (UTC)

Thinking about this, never mind what the FAQ says; if you change a few Wikiproject talk pages to Flow, then Flow has to support every slightly popular browser version / OS version / device / ... combination, or your attempt to reach more people will backfire when people who are now technically able to use talk pages will be excluded from discussing things for purely technical reasons. With VE, people could choose at every page whether they wanted to use VE or wikitext; but "once you go Flow, it's the end of the show" for them... This is one of the reasons why "testing" this on "live" pages on short notice is a bad idea IMO. You need to know quite well that these things are supported before thinking of bringing it here. Fram (talk) 12:01, 11 October 2013 (UTC)

I think that might be mixing up a different aspect. There's the question of browser-support for the fully-featured javascript Flow, and then there's the separate (and not much discussed yet) question of browser-support for the "other version" which ought to be as all-encompassing as the current system is. I'm not sure what the timeline is for the other version, but I assume it's what folks like Graham87 will use - he's one of my favourite characters around here, so I'll be constantly checking and prodding at all that. I've also got a (very) short list of editors who don't use javascript, who I'll be asking for specific feedback when it's ready for that. (If you, or anyone, knows of other editors with special setups, or needs, let me know. I started a thread for folks with vision impairment, and would appreciate assistance finding other specific editors/groups that need to be kept in mind.) Quiddity (WMF) (talk) 07:06, 12 October 2013 (UTC)

<Sigh>

This edit is problematic. The edit summary essentially accuses anyone who does not believe that the current talk page is a barrier as being directly opposed to the principles of the movement. It is an unnecessarily confrontational, and inappropriately conflates agreement with WMF principles and the development of this specific software. I am very disappointed, and I hope that there will be a refocusing of the message that the WMF wants to send out; it would be a shame to see a repeat of the messaging faux pas that have led to the widescale deprecation of VisualEditor across major WMF projects to happen with another new idea. Please reconsider the manner and the words which are used to communicate things. Bottom line, not immediately jumping up in support of Flow has absolutely nothing to do with whether or not one subscribes to the WMF principles. Risker (talk) 18:07, 10 October 2013 (UTC)

Ah; no, it doesn't; the preceding edit removed a quotation from the movement principles. That's what that was a reference to. Okeyes (WMF) (talk) 18:17, 10 October 2013 (UTC)

See now. This is what I mean. That is not all you reverted, as you are well aware. Now, stand back and pretend that you're reading that same sentence on the website of some other organization. Is that really, truly, the message that the WMF wants to convey? That people who question the assertions made (i.e., that Flow is the solution to a crippling communication problem) are actually opposed to WMF principles? That's what your summary reflects. It doesn't much matter what the heck you're reverting. Perhaps some thinking about the way the actual text is written would be useful, as it too suggests "if you don't agree with us, we're not interested in talking to you", but that is secondary to your own edit summary. Now, perhaps your edit summary is entirely on message, and it really is the philosophy of this particular product team that anyone who disagrees with their vision should be isolated, ostracized and ignored. I don't think that's the case; I think it's just a case of borderline product marketing that gives the impression of being written for a target market that isn't paying attention, but is being read by a market that assumes it's not the target. Risker (talk) 18:40, 10 October 2013 (UTC)

Here's the jist of what I want to get across in the community engagement doc and the Flow main page blurb:

1. We're building a structured discussion system for Wikipedia.
2. If you think Wikipedia doesn't need a structured discussion system and the current implementation of talk pages is just fine, you're still welcome to give us feedback/criticism. But if your only feedback/criticism is that Flow is terrible, talk pages are great, and we should stop this project and go home, that's not advice we're going to take – we want to make that clear once, so we don't have to respond to it with a justification for why we're doing what we're doing every subsequent time.
3. If you do think Wikipedia needs a structured discussion system, whether or not you believe the direction we're taking with Flow is a good one, you're on the team. Welcome :) We're listening – please help us understand how we can do a better job of making Flow into a discussion system that's ideal for you and every other Wikipedia user, current and future.

I appreciate that there are levels of nuance that these bullet points don't cover and still a lot of outstanding ambiguity – the point of that doc was to try to work those out, so I suppose this discussion indicates that we've hit one wall right here :) Risker, I have absolutely no intention of giving off the impression that "anyone who disagrees with their vision should be isolated, ostracized and ignored." Where are you getting that impression from, and how can the messaging be changed to make sure nobody could possibly interpret it that way? Maryana (WMF) (talk) 19:21, 10 October 2013 (UTC)

Not wanting to speak for Risker, but I am getting that impression from things like "if your position is that the movement principles aren't something you want to follow, and that improved software won't help discussions, you're not going to be able to participate effectively" as a reply to an edit that made a text shorter, easier to understand, without losing any actual value for the reader. And the section is labeled "How can I help?", but the text is "Why do we do this?". The sentence I removed had "zero" value on "How can I help?"Fram (talk) 19:43, 10 October 2013 (UTC)

Okeyes, If you're not with us, you're against us? The sentence I removed was completely superfluous. Nothing of value was lost by removing that sentence. The whole section should be rewritten actually, "How can I help?" should contain something concrete, not a rehash of the WMF principles, as if the current situation doesn't follow these principles or that Flow is the only solution, and more importantly that reading those two things are in any helpful for someone looking for "How can I help"? These two quotes belong in "Why do we do this", not "How can I help".

You claim "if your position is that the movement principles aren't something you want to follow, and that improved software won't help discussions, you're not going to be able to participate effectively". Please don't use confrontational, divisive and incorrect edit summaries. My position is that so far, Flow isn't improved software. I can believe that improved software will help discussions and at the same time not support Flow, or aspects of Flow, or the current proposed version of Flow. I can perfectly follow and support the movement's principles and oppose Flow. I can also be completely neutral about Flow and just wanting to help with testing, and make up my mind after I have actually tested it. Apparently this isn't allowed in your world. Please, next time, use some less aggressive and more helpful edit summaries if you feel the need to reverse an edit, or better yet, don't reverse without thinking about it. Fram (talk) 19:43, 10 October 2013 (UTC)

@Fram and Risker: I'm not going to single out an editor or diff, but there have been a few comments here and elsewhere along the lines of "I hate this entire idea, the talkpages are fine the way they and should not be changed a single bit, you should stop working on this software immediately". There have been some assumptions of bad faith, and personalized attacks. There have also been comments along the lines of "I don't want more of the seething masses to join Wikimedia, if they're not smart enough to learn wikimarkup and current talkpage conventions, then they don't belong here". That is what the Wikipedia:Flow/Community engagement document is about, and is (I assume) what Okeyes meant by not following the "movement principles". (See also Maryana's reply above, for additional perspective on that).

We (staff and community) want active discussion/suggestions/criticisms/comments (but slowly/calmly/patiently and with AGF in all directions). We (staff and community) don't want needless hostility, or unresolvable arguments. I think everyone active on this page right now agrees with all that, so we're just arguing with phrasing. Phrasing will never be perfect (See my reply to Spectral Sequence above, for a ramble on that point), but if you can retain that broad intent, with some tweaks to the word-order/word-choice, then go for it. Quiddity (WMF) (talk) 20:10, 10 October 2013 (UTC)

"There have been some assumptions of bad faith, and personalized attacks." That's basically the problem I (and it seems Risker) have with Okeyes revert (and especially the edit summary, the revert in itself is not the problem). The section is "How can I help?" Please put yourself in the position of an editor (newbie or not), not too well versed in WMF matters, who has heard about this new discussion system and truly wants to help. From that perspective, read the section. Only the very last line, "See our community engagement strategy to learn more.", has actually anything to do with the section; the rest is, well, promo talk. It may be included in its own section if you (WMF) think it is necessary ("Why do we do this?"), but it is completely misplaced as it stands now. I tried, with a minimal action to make it a little bit less top-heavy and a bit more truly open and without requirements. "You have the power to shape the development process of Flow." is short, simple, and true, without the "ifs" that were included before. There should be no "ifs" in an invitation for people to help discuss, test, shape this. If you are welcome to edit here, then you are welcome to join the discussion. That was what my edit tried to promote. Fram (talk) 20:21, 10 October 2013 (UTC)

@Fram: most of that is fair; as Maryana says above, some nuance gets lost. However, I would suggest that writing that off as 'promotalk' is similarly confrontational as an edit summary. I'm going to do better with mine (or, as better as 255 characters will allow!) but it's a two-way street. Okeyes (WMF) (talk) 20:16, 10 October 2013 (UTC)

So basically what I am getting from Maryana and Okeyes comments are that Flow is coming and we can either choose to get on board or get out of the way. Not a great way to garner the support of the community IMO. So basically we have another Visual Editor fiasco in the making. The WMF builds something half ass, releases it early, we complain, they ignore us and the cycle continues. There is absolutetely nothing in this that is anything new. And I am saying that from the point of view of someone who actually kinda liked Liquid threads and thinks that something like Flow might be a good thing. But if the WMF isn't going to take input from the community seriously and just ignore what they don't like, then there is no use in even wasting the communities time in asking for it. 138.162.8.59 (talk) 20:17, 10 October 2013 (UTC)

I'm not sure where you're getting that from, Kumioko. What we're saying is "A replacement for talkpages is coming, and if you don't think a replacement for talkpages is needed then you're welcome to give us feedback about how to make Flow better, but 'nothing needs to be replaced' isn't constructive". If your feedback is "I disagree with fixed width", that's fine. If it's "I disagree that any changes are even needed", well, that's not going to be massively helpful. I'd again ask you to stop making assumptions about the quality of the software, having not actually seen it, and refer to our deployment plan before making pronouncements about that. Okeyes (WMF) (talk) 20:24, 10 October 2013 (UTC)

Well I guess we'll have to see how it works out. 138.162.8.59 (talk) 20:35, 10 October 2013 (UTC)

(ec)Okeyes, I don't agree. Like I said above, read the section "How can I help" from the position of someone interested in, well, how they can help. Only the last sentence actually has any useful information, and the sentence above qualifies it with some "ifs" and "thens", with totally irrelevant promotalk ("improved", "better", "help eliminate"). The question was "How can I help". The reply is "You have the power to shape the development process of Flow. See our community engagement strategy to learn more." Not "if this and that, then you have the power". No. You have the power. Nothing of the divisive promotalk that was there contributed anything to that section. Fram (talk) 20:26, 10 October 2013 (UTC)

Better? More improvement suggestions welcome; it's a wiki! :) Maryana (WMF) (talk) 20:52, 10 October 2013 (UTC)

Thanks. I'm off to bed, will take a look tomorrow! Fram (talk) 20:55, 10 October 2013 (UTC)

There's a nuance to if your only feedback/criticism is that Flow is terrible, talk pages are great, and we should stop this project and go home. If that is literally the only feedback, with no justification or reasoning, then of course it is not particularly useful, given that there is an imperative to make Flow happen. However, I would prefer always to see a positive angle. The attitude should be "if you think that Flow is terrible, talk pages are great, and we should stop this project and go home, then tell us why, what you think is bad about Flow and we will try to make it better, what you think is good about talk pages and we will incorporate it: Flow is going to happen and we are all going to make it work". Same position but putting the naysayer on the spot to explain and give something useful, and trying to be inclusive not divisive. Spectral sequence (talk) 06:53, 11 October 2013 (UTC)

Having read the new "how to help" section, it is a lot better. I would personally not include the second bullet point (no need to diss the current discussion system to invite people to help with a better one), and would provide some more info on concrete possibilities to help (testing? Brainstorming?), but basically it is a lot closer to what I had in mind. Getting more editors involved and removing barriers is easier if you don't have too many barriers in the invitation :-) Fram (talk) 08:51, 11 October 2013 (UTC)

"How you can help" to me has two possible sorts of content. One is along the lines of "Turn up at this place, between these times, wearing old clothes. Oh, and don't forget to bring your aardvark". The other is "We need help with the bricklaying, with algebraic topology and another saggar-maker's bottom-knocker with double-jointed thumbs". The current answer seems to have the first, the logistics and process, nailed down. What about the second, the content and the work? What do you want people to actually do to help? Not a complete list, perhaps, but some examples to give the flavour. Spectral sequence (talk) 09:07, 11 October 2013 (UTC)

That's a really good point, Spectral sequence. There's a ton of work we need help on; it's just a matter of structuring it so people who are interested can stay updated and participate if they want to. I'm chatting with Okeyes (WMF) and Quiddity (WMF) about some ideas for taking our huge to-do list and divvying it up into more satisfying chunks. Stay tuned... Maryana (WMF) (talk) 20:13, 11 October 2013 (UTC)

There's admittedly a huge amount of work to do to document and codify (in all senses) the various discussion structures in use or likely to be needed in the future. Two thoughts arise. Firstly, why is that work not under way right now? Instead of letting the various communities focus on the minutiae of what Flow software might or might not do, challenge the communities to start documenting their own processes. (In passing, to do this you will need a lot of work from "power users", so it's probably a good idea not to be quite as scornful of their comments as has been seen at times on this page: WMF badly needs to repair quite a lot of its relationships). Secondly, the design of the software cannot proceed entirely in a vacuum. There are already a few random discussions here about what sort of capabilities are inevitably going to be required in some structures and workflows, even if not the earliest ones to be codified. That discussion should probably be formalised. Spectral sequence (talk) 09:06, 13 October 2013 (UTC)

I agree; this is work that needs to be done. In terms of "why isn't it being done now?" - because, well, we've got a heck of a lot of work to do all at once :/. I'm a big fan of setting up a framework so that we can get users involved to document these workflows, but it's taking a bit of time to get everything up to speed. There's also an argument (and it's one I agree with, but I'm prepared to be disabused) that supporting every use case anyone can think of is not necessarily what we want to do - we want to support every use case that is actively used. So we might take the "have people document all the processes" process and pair it with the small-scale release onwiki so we can see what processes are used, as well as what processes are available. Okeyes (WMF) (talk) 18:09, 15 October 2013 (UTC)

There's an argument that when I said "in use or likely to be needed in the future", I said, and meant, something different from "every use case anyone can think of". Spectral sequence (talk) 20:58, 15 October 2013 (UTC)

It wasn't intended to be - more that demonstrated uses > potential uses. Again, this is something we should set up a framework for, but we're very early on in development (workflow development hasn't even started); we have time. Meanwhile we've got office hours on thursday and a deployment in december-ish - those we can't wait on so easily :). Okeyes (WMF) (talk) 21:21, 15 October 2013 (UTC)

There is obviously a way in which it is not wrong to keep the ones who do not share the goals of the project away from it. I have even written an essay about it (Wikipedia:Wikiheresy). There is nothing wrong with, for example, not wanting me as a programmer on the "Flow" team - instead, it would probably be wrong for me to try to get into that team (not that I want to). There is nothing wrong with demands to stay away from the project, somewhere where it would have little impact. But in this case we have "What we're saying is "A replacement for talkpages is coming, and if you don't think a replacement for talkpages is needed then you're welcome to give us feedback about how to make Flow better, but 'nothing needs to be replaced' isn't constructive"." ([10] - by Okeyes (WMF) 20:24, 10 October 2013 (UTC)). Thus, unless that gets called off, the only place that does not get affected by "Flow" is outside of Wikipedia. So, are representatives of WMF ready to say that the ones of us who are sceptical about their project should leave Wikipedia (and other Wikimedia projects), as consistency would require..? By the way, that would be OK with me (consistency and clarity are good). Honest "Go away. We do not value your opinion." is much better than all kinds of "Sure, we do value your opinion. Just not really.".

Oh, and speaking of "constructive criticism", I have written an analysis of research methodology that, apparently, was used to conclude that "Flow" is necessary. I intend to write analysis of the test results as well. Do you (WMF) count that as "constructive criticism"..? Or is it "destructive", because it could lead to conclusion that "Flow" (as intended) is not necessary..?

And one more thing, since it looks like I was asked ([11]) about rewording of what now is "freeform wiki talk pages are a barrier to participation for new users and provide a bad user experience for many existing users." ([12]) - if the goal is to find a formulation everyone can agree with, then a simple "current wiki talk pages have some flaws and could be improved upon." would do. Of course, if the goal is to say "If you do not hate the current talk pages with all your heart, go away.", that would be a worse formulation. --Martynas Patasius (talk) 19:33, 13 October 2013 (UTC)

Discussion structures

The previous section on modifying one's own comments yielded an interesting insight. It seems that Flow is moving towards a set of structures for discussions which will codify (in all senses) practices. This is an ambitious undertaking. Is there already a taxonomy in place of the sorts of discussions which Flow will permit? How many are there? Is there significant difference across the 287 language communities? Are there any structures which it has been decided to deprecate, to change and are there any new structures proposed? It is certainly laudable to want to replace the arcane undocumented social structures with intuitive and well-documented technical structures: is there any of that documentation in place yet? Spectral sequence (talk) 07:21, 11 October 2013 (UTC)

Well, so the precise plan isn't to replace all of the informal structures with formal structures at our end; while that's a desired goal it would be incredibly difficult to provide every necessary structure here. We're not going to pretend it's possible for, well, 4 or 5 engineers to build every possible thing that every community could want, and then indefinitely maintain them. We're not approaching this with hubris.

Instead, we're approaching this with the idea that Wikipedia exists due to the fact that many people making small contributions is greater than a small number of people making many. We may as well extend this to the software. So, what we're hoping to build is some kind of structured workflow language that can be used to define non-standard formal methods of interaction on talkpages; individual wikis can build the ones they need as the use cases arise, and modify them as the use cases change. In the long term, we hope this will also allow for things like Page Curation to be more easily adaptable to other projects and to changes on this one. I hope that makes sense.

In terms of documenting that, Adam Wight (one of the fundraising engineers) took a stab at drafting out what it could look like here. None of that has been built yet (it's a pretty long-term project) but, thankfully, rolling Flow out to a lot of pages is also a long-term project. So we have time to discuss the problem and work out what workflows look like - once we've built the Flow structure, of course, which is the current priority. Hope that's helpful :). Okeyes (WMF) (talk) 20:17, 11 October 2013 (UTC)

I see. That's ... ambitious. Is there pre-existing research and development to build on? Spectral sequence (talk) 21:14, 11 October 2013 (UTC)

Into things like what the workflows are, or what capabilities the workflow system will need? Okeyes (WMF) (talk) 21:37, 11 October 2013 (UTC)

Either or both. Or indeed, in developing any generalised workflow description language of the scope and complexity required to capture the Wikipedia decision processes and simplicity and ease of use required to make it useable by the communities of editors. This is a very challenging task you have undertaken (nd asked us to undertake with you) and it would be useful to all of us to know what if anything like this has been thought about before. Spectral sequence (talk) 06:42, 12 October 2013 (UTC)

Actually, the larger software development community solved this years ago. The solution goes back to the introduction of the FORTH programming language. Letting the user do anything she wants by providing a markup language works, but not well. Making and enforcing rules is a poor substitute for the software not letting you do disruptive things. Trying to force everyone into one way of doing things also works poorly; you end up playing Whac-A-Mole because you cannot anticipate everything. The solution is to create a mini-language that defines what a user can and cannot do, and make the language flexible enough so that "what a user can and cannot do" can be pretty much anything. Then you let someone local deal with the question of what a user can and cannot do. It's more work up front, but it makes the system self-maintaining. --Guy Macon (talk) 19:29, 13 October 2013 (UTC)

Just to expand upon the above, let's consider signatures.

Under the markup paradigm, you ask the user to remember to sign his posts. Then you tack on a script that looks for "~~~~" and replaces it with a signature, hoping that nobody will need to use "~~~~" for some other purpose.

Under the structure paradigm, you hard-code a signature in a fixed format at at the end of each post. If you later decide to, say, put the date before the name, you go back to the developers and ask them to change the code.

Under the minilanguage paradigm, there is a file that contains a string of commands like "insert user name", "insert nickname", "insert year", etc. with a select group of users allowed to change that file. Now if you later decide to put the date before the name you simple put the date command before the name command. Or you can put the date at the top of the post and the name at the bottom or pretty much do anything else, all without bothering the developers. --Guy Macon (talk) 23:17, 13 October 2013 (UTC)

@Spectral sequence: I rounded up some of the prior discussions about workflows, and I've now added all the technical notes (preliminary research, drafts, etc) at the top there. The mw:Flow Portal/Use cases page in particular, might be what you're looking for. Although as you saw and noted at Maryana's talkpage, it's definitely a fantastically complex idea, full of potential ramifications. Discovering the correct balance between too-complex and too-simple, will take time - hence we're not rushing anything! Quiddity (WMF) (talk) 19:56, 14 October 2013 (UTC)

Actually, what I was looking for was a simple statement along the lines of "yes there is" or "no there isn't", in the former case possibly amplified by "and here's a reference to it / the name of it and we are / are not going to make use of it". Possibly split along the lines of "yes in the case of what the workflows are but no in the case of what capabilities the workflow system will need" (or whatever). Presumably the people working on the project know perfectly well whether they are building on something already in existence or starting from a completely clean sheet, and are capable of articulating that in a few words? Pointing readers of this discussion to a mass of documentation is not the most helpful way of answering the question. Please bear in mind that WMF is trying to persuade readers to take part in a demanding project and can reasonably be expected to demonstrate that they are making best use of their collaborators valuable time and energy. Spectral sequence (talk) 20:31, 14 October 2013 (UTC)

Sorry I wasn't clear. What I was trying to say is: Yes there is pre-existing research (as linked). No there aren't any rigorous specifications or code-written yet, because that aspect is still in the discussion/brainstorming/research phase. (afaik). Quiddity (WMF) (talk) 20:59, 14 October 2013 (UTC)

Thank you for clarifying that. Spectral sequence (talk) 21:14, 14 October 2013 (UTC)

Er, so, when Community demands something as users of the software, their wishes can be ignored, because, "But seriously, most community members are not software developers or designers." ([13] - by "Maryana (WMF)", 23:05, 3 October 2013 (UTC))..? And now those same "community members" are actually expected to develop the software..? Really..?

And "wikitext" elements like colons supposedly "are a barrier to participation for new users and provide a bad user experience for many existing users" ([14]), but making "statecharts" for "workflows" in unclear language is supposed to be a great experience for everyone..?

Now seriously, can't you (WMF representatives) hold a couple of team meetings and reach an "official" position that is at least consistent (if "reasonable" is too much to ask)..? --Martynas Patasius (talk) 18:20, 13 October 2013 (UTC)

I don't think that's quite fair. It seems clear that the work of documenting the workflows and discussion structures is going to be done, if at all, by experienced users and admins. It may not be precisely one-off, but presumably isn't going to need to be done very often after the initial investment of time and effort, and needn't be done by novices. Spectral sequence (talk) 19:02, 14 October 2013 (UTC)

They were not using those excuses to ignore opinions of newbies either (most newbies do not know about "Flow" and thus do not oppose it).

As for reprogramming - it is hard to say how often that will have to happen. We would have to know how it will work in order to know that. What can be said before that is this: it is not going to be a pleasant task. It will be far less pleasant than counting colons for indentation.

P.S. Isn't if funny that we both tried to "defend" WMF from each other in parallel ([15])..? --Martynas Patasius (talk) 19:42, 14 October 2013 (UTC)

So, a couple of points. The first is that part of this work is not new. Let's take the workflow of...closing a discussion, say. For me to close a discussion, I add templates to it - templates that can incorporate (extended) parser functions, which technically constitute a Turing-complete language we had to turn off, iirc, looping, because massive drain. So our implementation isn't Turing-complete, but the language is and are maintained and structured by the editor community. What we're talking about here is ambitious, in the sense that we've never had a language users can write in that actively interacts with the software before - that creates workflows which integrate with MediaWiki properly. But part of the work (users being willing to write and then maintain these workflows) is not new; it's something that happens all around us, right now. It just isn't something MediaWiki really knows about.

In terms of pleasantness, these are not things most users will have to interact with, much like the process of writing templates (as opposed to the process of using them); as Spectral sequence writes, the initial implementation process is likely to be handled by experienced users used to dealing with this sort of thing, as is the maintenance. Okeyes (WMF) (talk) 18:22, 15 October 2013 (UTC)

Indeed. And since this is work that has already been done, you'll be asking users to do it all over again, so you'll have to explain pretty convincingly why it's so important. The first step seems to be getting the workflows documented since that's of value in itself and a good halfway-house towards the codification. Spectral sequence (talk) 20:44, 15 October 2013 (UTC)

To some degree. I mean, I think there's a difference in the work that needs to be done - just not a difference in the mentality needed to do it. Getting workflows documented is indeed crucial, if only to see what capabilities the system will need - I'm going to throw it up on our Mingle instance now as something that needs to be done, but don't expect movement immediately: as said above, there are more imminent tasks that need to be done :). Okeyes (WMF) (talk) 23:34, 15 October 2013 (UTC)

Well, I think that's a mistake for several reasons. Firstly this is largely work being done by other people, so can be carried on in parallel with design and development; secondly, it gets the community on board and thinking about what it wants to achieve with the software when it arrives, so it doesn't all come together as one huge change; thirdly, it may tease out requirements that it would be important to know about at the design stage but which you don't happen to have thought about; fourthly, it's work worth doing in itself and of high value independent of the ultimate fate of the project. But it's only my opinion of course. Spectral sequence (talk) 06:48, 16 October 2013 (UTC)

That is, not doing it immediately is a problem? We have very limited bandwidth at this end - the team is maybe 8 full-time staff (including the part-timers) and that includes all the engineers and designers. I'm going to work on it, but it's not something of imminent importance and it does require setting up (working out precisely what we're asking people to document, and why). Yes, it can happen concurrently with design and development, but the people who need to be working on it at this end aren't the designers or developers, so that was never going to be a factor. Yes, it can get the community on board, but we need to be reaching out to people about Flow in the first-place for that to be viable - and that sort of task is what I mean when I mention things we have to get done soon :). Okeyes (WMF) (talk) 16:41, 16 October 2013 (UTC)

No, what I said and meant was, the earlier you start the better. You introduced the words "immediately" and "problem": I do wish that we could agree not to exaggerate other users' comments like this. Spectral sequence (talk) 17:32, 16 October 2013 (UTC)

I agree that we should be thinking about workflows regardless of Flow, as it is a very intriguing and potentially useful line of enquiry. Getting the list of "This is what has already been researched, over the last 12 years" items into one place (and dated and annotated), is the first order of business. I agree with Oliver that we shouldn't leap into it full-force, because we (both community, and Flow-team) already have a lot of new plates in the air, and adding another major effort/task would fragment attention. However, I agree with Spectral sequence that we (few curious individuals) could start collating links, for later/slow discussion, anytime. I've started a centralized scratchlist at m:Workflows. There is a LOT to read and see, so don't expect other folks to catch-up, anytime soon.

Regarding language: I think the way Oliver phrased it was in a "is this what you mean?" sense (as implied by the question mark). We all understand things in different ways, with different implications/intonations/insinuations/cultural-baggage/personal-history/etc. That's part of the reason that WP:AGF exists! Some of us (eg. me) doubt our assumptions/understandings a lot, and so tend to ask a lot of clarifying questions. Others of us (no names!) are more confident in interpretations (sometimes), which can lead to other sorts of problems... Quiddity (WMF) (talk) 20:14, 16 October 2013 (UTC)

Please provide indexing "table-of-contents"-like functionality

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)

Experiences with the Labs Sandbox

Only replying to the original post, and no possibility to have subsections?

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)

Mathematics markup

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: $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: ⁠$\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 $\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)

Template expansion

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)

A comment on language

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)

Flow software questions

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)

Flow updates - Oct 15

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)

MVP questions

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)

Help prepare the Flow sandbox

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)

[16]: "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[17], 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 [18] 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)

English Wikivoyage as a test for Flow?

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)

Wikitext

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)

User "expectations"

I was wondering how you derived your "user expectations". Your usability testing was limited to a half dozen users (and there is no indication when it occurred). Much of the other research you draw on is 5 or more years old.

It's easy to get a list of new users, every Editor who posts welcome notices can see who just registered an account. Did you think to send out a survey to all new users within, say, a two week period to ask them about their experiences getting used to Wikipedia? A survey would have been simple to set up and would draw on a much wider diversity of users (different language abilities, different levels of education, different technology, different levels of familiarity with online communication, etc.) than the 6 or 7 Editors you spoke with. It's not even clear what your basis of their selection was...was it random? Or people you knew that you asked about their experience?

I don't mean to just criticize. But if you are designing a new system based on user expectations and difficulties and you are basing this on a very, very small sample, you are going to face many problems down the road. Liz 23:28, 19 October 2013 (UTC)

For what it's worth, user expectations for discussion systems generally are pretty widely known - not necessarily here but in the HCI and design worlds generally. I'm going to ask people if they can point to any documentation of general research (ping, Maryana). But it's true that Wikipedia and Wikipedians are going to be distinct in what they expect and in what they need. I'm not going to promise a survey (I can't promise things generally) but I think it's an interesting idea and something that would be worth doing if we could set it up easily. Okeyes (WMF) (talk) 17:51, 21 October 2013 (UTC)

I seem to recall asking that question at 21:14, 11 October 2013 (UTC). It seems rather late in the day to be collecting the documentation of the general research; and surprisingly laid-back to suggest that it might be worth collecting user expectation if it could be done easily. Can it really be that you currently do not have a clear overview of what users are going to need? (And if you do, perhaps you could point to it, please) Spectral sequence (talk) 18:13, 21 October 2013 (UTC)