Wikipedia talk:Flow/Archive 5

Archive 1

←

Archive 3

Archive 4

Archive 5

Archive 6

Archive 7

→

Archive 10

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)

Yep; 'hide' is going to be the Flow equivalent of reverting, with some obvious restrictions/openness (so, something like: autoconfirmed and above only. Obviously it'll be configurable). Okeyes (WMF) (talk) 18:45, 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)

Talk page templates (headers, banners, archives, NavBoxes)

It took me a while to decide whether this was a Design issue or not... I'm defaulting to post it here anyhow.

How will Flow work with current talk page templates? Things like WikiProject banners, To-Do Lists, shortcuts, archive lists, NavBoxes, or, say, the three templates heading this very page? Will there be a way to have them displayed above/around the "Flow" area?, as they currently are above/around the "Talk" area? Note that I say template but technically, whether these boxes are transcluded, subst'ed or hardcoded, the argument is the same. For example, both WT:VG and WT:MILHIST make extensive use of these talk page templates. ☺ · Salvidrim! · ✉ 03:56, 22 October 2013 (UTC)

In the current proposal, there is a "space" at the top of the talk page for all such things. How it will be prevented that people use this for new discussion topics is unclear though. I'm more worried about how all the things that are currently used to "tag" discussions will be implemented. Things like the "resolved" template, hat/hab comments, and so on. Or indeed, as has been asked above, how discussions will be moved if they are on the wrong page. Or how they will be subdivided if necessary (subsections?) Or... It's all still very, very unclear for something that will go live in the next few months. Fram (talk) 09:55, 22 October 2013 (UTC)

Salvidrim!, yes, all those things can be placed in the header area of a Flow discussion :)

Fram, {{resolved}} and all others like it will work just fine in Flow posts, and you'll be able to close and summarize discussions from day one. Splitting, merging, and moving topics is something we're probably not going to get to in the very first release, but those are definite must-have features for subsequent releases. Also, while we're planning on demoing our MVP on a test wiki sometime in the next few weeks, Flow won't "go live" anywhere on Wikipedia until WikiProject members decide it's ready for them to trial. Have I un-confused you? Maryana (WMF) (talk) 18:13, 22 October 2013 (UTC)

Thanks. Not completely unconfused, but on the way :-) The roadmap states

"Short-term (up to December 2013)
   Not done Community testing and feedback
   Not done Limited, opt-in release on select WikiProject discussion spaces"

I had seen no indication that this timeline was only tentative, and with VE I had gotten the distinct impression that meeting deadlines was sometimes more important than only implementing something when it was good enough. If this won't happen here, and the roadmap may be left if it turns out to be too ambitious, then I'm happy with it. Fram (talk) 19:10, 22 October 2013 (UTC)

I think the opt-in element requires it to, well, not suck, as it were; it'd be hard to find wikiprojects willing to test something unusable (at least, I hope it would be). Might be worth making it explicit, though? Okeyes (WMF) (talk) 19:18, 22 October 2013 (UTC)

I'll test the Header thing out; merging new posts into being comments of other posts is a must, new users are likely to make "new" posts in order to reply to an existing post, which only brings more and more confusion. I'm also interested in seeing how hatting/closing discussions with a summary will work; formal-ish RfCs have happened before on WikiProject pages; this meshes with the idea (which I am in favor of) that !votes should be coded in separately from the comment itself, but am reluctant to offer a dropdown of choices instead of completely custom !votes because a lot of RfCs, especially WikiProject ones, don't follow any "set" list of !voting options. ☺ · Salvidrim! · ✉ 19:31, 22 October 2013 (UTC)

Re: merging new posts into being comments of other posts is a must, new users are likely to make "new" posts in order to reply to an existing post – I strongly doubt that will happen, given the way we've implemented replying. Starting a whole new topic is pretty isolated from any existing topic in the UI. But I'll run some remote user tests with total newbies to make sure this interaction works (and share the results with you) :) Maryana (WMF) (talk) 22:24, 23 October 2013 (UTC)