Jump to content

Wikipedia talk:Flow

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Spectral sequence (talk | contribs) at 20:58, 15 October 2013 (: 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"). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.


Smaller and offsite announcements/mentions

Continued from Wikipedia:Flow#Announcements

Sugar and spice and everything WP:CIVIL

I was looking at some of the screenshots higher on this talk page, and I noticed that the "click to reply" links conclude with the exhortation to "Be nice!". Before I go any further, please let me be clear: I am in favor of being nice, and I do not oppose niceness, OK? I know that things are still in the development stages, and that a lot of the wording can be configured specifically for each project. I'd like, therefore, to make a suggestion.

A lot of male users in their teens or twenties are, I think, likely to see "nice" as patronizing, and it could boomerang by tempting them to do the opposite. Also, the English Wikipedia does not really assign a role to the word "nice" in policies or guidelines, instead using the word "civil", as in WP:CIVIL. I also recognize that the developers want to make the interface friendly to new users, so I'm not advocating sending users right to wiki-jargon, either.

I suggest changing "Be nice!" to "Please be polite.", with the word "polite" linked to WP:CIVIL, and the exclamation point changed to a simple period. --Tryptofish (talk) 00:09, 22 August 2013 (UTC)[reply]

It won't be possible to include links within that text, btw. It's an HTML attribute called "placeholder"; once you interact with the element (click into it), the text disappears.
My first thought is that if someone decides to be uncivil because they hate the word "nice" that they're probably going to quickly be blocked for being uncivil. But that's me.--Jorm (WMF) (talk) 00:13, 22 August 2013 (UTC)[reply]
OK, please disregard what I said about the blue link. I actually agree with you about the behavioral part, but I really do think that we do no one any good by tempting them. The word "nice" can come across as kind of prissy to some eyes, and the word "polite" is more adult-sounding. There's so much youthful testosterone on the Internet that I believe it's worthwhile to pay attention to this. I can easily envision users that I come across every day looking at "Be nice!", and thinking, "Who are you, my mother?". --Tryptofish (talk) 00:25, 22 August 2013 (UTC)[reply]
Dear Tryptofish; be nice. :) --Mom 04:50, 22 August 2013
I don't really feel all that strongly about which word(s), if any, we should use to encourage civility, but I would like to point out that it's very interesting that you assume we should be catering our copy to "male users in their teens or twenties," or that the worst possible thing is to sound "prissy," Tryptofish. There are some deeply-held assumptions and stereotypes packed into those ideas that I think might be good to challenge, even if just hypothetically, as a thought experiment. Because it's absolutely true that much of the text on Wikipedia was written by men for men, and I wonder how much this one simple fact contributes to the ever-present gender gap... Maryana (WMF) (talk) 03:30, 22 August 2013 (UTC)[reply]
Wait a second here. It can be fairly said that Wikipedia is written by more men than women—that research has been done. But "by men for men"? Male I may be, but when I write here, I'm writing for whoever may read it. I haven't seen a "No girls allowed" template at the top of any articles recently. What do you mean by that, when anyone who writes here has no idea who may read it, nor can control that? Seraphimblade Talk to me 21:47, 22 August 2013 (UTC)[reply]
I was just reacting to this from Tryptofish's original comment: A lot of male users in their teens or twenties are, I think, likely to see "nice" as patronizing, and it could boomerang by tempting them to do the opposite. The assumption here appears to be that since most Wikipedia editors are currently male (which we do know from extensive research), we should be writing all our instructional copy (not content; specifically interface and system messages) in a way that makes men think/feel/behave a certain way. What I'm saying is that just because it's factually true that more men edit Wikipedia, we shouldn't necessarily continue to tailor our instructional copy only to them. Perhaps if we broke away from these assumptions about who our users are or could be (like the idea that the word "nice" is too "prissy" for Wikipedia editors and will cause them to intentionally be jerks), we could actually begin to attract a more diverse set of contributors. Maryana (WMF) (talk) 22:56, 22 August 2013 (UTC)[reply]
Or we could lose the contributors we actually have without gaining any new ones... It is hard to tell what would happen.
Anyway, that is beside the point. The actual string of characters is certainly configurable - at the very least because it would have to be translated for other Wikipedias. It is simply unthinkable that things could be done otherwise. Technically, the string itself would have to be a matter of policy - and policy is still decided by the community. And even if WMF would try to overrule the community, such decision is highly unlikely to be done by someone with job title "Product Manager".
I do think that "Flow", the process of its development and WMF have many significant flaws, but this string is not one of them. --Martynas Patasius (talk) 00:14, 23 August 2013 (UTC)[reply]
Oh, dear, maybe I should repeat what I said to begin with: I am in favor of being nice, and I do not oppose niceness, OK? (And thanks, IP-mom!) Starting a debate about gender was the farthest thing from my mind. (Indeed, anyone who cares might want to look carefully at the user boxes on my user page.) I never said that typical Wikipedians would react the way that I described, but rather that there are a goodly number who would, and that I see some of them every day that I edit. It's not about catering to them, but about being practical in dealing with the way that things are.
Actually, I'm very much in favor of making Wikipedia more inclusive. But I rather doubt that this particular wording will accomplish that. In fact, another aspect quite distinct from what I said above is that the wording just tends to make it sound like social media, instead of a serious website where an encyclopedia is created.
It occurs to me that, instead of discussing which word to use, we ought to discuss whether we need to say it at all. Was there any research that led the developers to add the "Be nice!" part to begin with? There is nothing on the current user interface that says that, so is there a reason for introducing it with Flow? --Tryptofish (talk) 00:30, 23 August 2013 (UTC)[reply]
Hey, no worries, Tryptofish – this is just something I'm particularly sensitive to, so I'm a bit of a gadfly about it :) To answer your last question, the copy in the prototype is all super preliminary, not the real deal just yet. You're right that it may not make sense to include any message there at all in the final product; having the same phrase repeated in every single comment box risks an element of banner blindness. We'll play around with it. Maryana (WMF) (talk) 17:06, 23 August 2013 (UTC)[reply]
That's a good kind of gadfly-ery, thanks. My advice would be to seriously consider leaving it out. If you've got to tell someone to be nice, they probably can't be told. --Tryptofish (talk) 00:44, 24 August 2013 (UTC)[reply]
I cannot help thinking of an old maxim about the difference between good girls and nice girls - that it was the good girls you took home to mother, and the nice girls you took to the back alley. So, no, I'd really rather not be told to be nice. Risker (talk) 22:09, 21 September 2013 (UTC)[reply]

What is Flow?

Having encountered the linked term "Flow" in a Portal article (with no explanation), I came here to find out what Flow is. The lede is of no help, saying it is a proposed change and it is not something else. Only after getting well into the article did I get an idea of what Flow is -- sort of. Can some-one please say what it is in the lede, and not just what it is about. For example, "Flow is a proposed change to the talk pages of Wikipedia that would (attempt to) make them easier for novices to use by ...[include the salient characteristic of the changes or deficits to be corrected]." — Preceding unsigned comment added by Kdammers (talk • contribs) 07:18, September 19, 2013 (UTC)

@ Kdammers check out the main page now and lemme know if that makes a little more sense :) Maryana (WMF) (talk) 17:40, 20 September 2013 (UTC)[reply]
Um, could we have less pro-WMF propaganda and more description there..? For example, "Talk pages—as a discussion technology—are antiquated and user-hostile." ([1]) is simply wrong: isn't WMF far more "user-hostile"..? The same statement is also shown to be false by many users who do manage to express their views even without full understanding of "wikitext".
So, please, try to write as if it was an article: obey WP:NPOV and WP:V. Fairly describe all significant views, both "pro-WMF" and "anti-WMF". The difference form real article writing is that (perhaps) in this case you can cite yourself as a source of views of WMF.
There is another advantage in that: if you will force yourself to state the arguments of your opponents fairly and in the way that they will accept themselves, you will be able to understand their position better and even to argue with it more competently (if, of course, you won't get persuaded). --Martynas Patasius (talk) 19:37, 21 September 2013 (UTC)[reply]
  • I have removed the phrase "user-hostile", and replaced it with "not user-intuitive". Any technology, including Flow, can be used in a user-hostile manner. In fact, I think it's actually going to be far, far easier with flow to be user-hostile, especially given its core philosophies. Frankly, at this stage it looks like facebook - which is already severely outdated technology itself, and is losing users in droves. Risker (talk) 22:04, 21 September 2013 (UTC)[reply]
    I'd say it would still be better to write "Wikimedia Foundation [or "Maryana (WMF)"] thinks that talk pages—as a discussion technology—are antiquated and user-hostile, because they use elements of syntax not used elsewhere [or for some other reasons].". And then - "Opponents of this project argue that it is not true, as evidenced by the users who do communicate successfully in the talk pages without mastering the 'wikitext'." (or some different points).
    Although perhaps actually writing this "article" might be better left to Maryana (WMF) (provided that she tries to follow WP:NPOV etc.)..? After all, if her job has anything to do with gathering requirements and persuading us that the project are not worthless and WMF is not our enemy, she needs to demonstrate that she understands the arguments of "anti-WMF" side anyway... --Martynas Patasius (talk) 13:08, 22 September 2013 (UTC)[reply]
This isn't an "article". It isn't subject to NPOV. We are very well aware of the "anti-WMF" arguments (and I have to say that using that name - "anti-WMF" - is not likely to carry any weight with anyone except people who hate the Foundation). Our job is to follow the mission and vision statement of the Wikimedia Foundation. Part of that is to make knowledge sharing available to everyone - not just people who are able to figure out the arcane rules and syntax of talk pages. Talk pages are anti-mission in that regard - they actively work against what we are trying to do.
If you are not able to see that, I'm not sure if there's a chance of having a productive conversation. If you start your entire premise with "I am anti-WMF", I am not sure there's a chance of having a productive conversation. And if you base everything around "the WMF staff are idiots and don't understand what we're saying and don't get the community", I'm not sure there's a chance of having a productive conversation.--Jorm (WMF) (talk) 18:13, 22 September 2013 (UTC)[reply]
It's starting to appear that we may be having a change of modus operandi that we are not asking for. The present one seems to be more than fit for purpose.
— | Gareth Griffith-Jones | The Welsh Buzzard | — 18:41, 22 September 2013 (UTC)[reply]
Gareth, you might want to go look at the very earliest edits by this user on his talk page. If it's "fit for purpose"—and if that purpose is to make things "available to everyone - not just people who are able to figure out the arcane rules and syntax of talk pages", as Jorm put it, then why did this guy have no idea how to post a message (his first-ever talk page words: "Im a new user. Not at all sure how to talk on talk page?? Have been blocked due to not talking...how is this done then please."), and why did he have so much trouble figuring out how to post that message when he needed to? If you hang out at the help desk or the teahouse, this is not actually an unusual level of difficulty. Unless the purpose is to keep new or less technically savvy people away, I can't see how this is fit for the purpose of having discussions with people who aren't already as experienced as you and I are. WhatamIdoing (talk) 23:50, 22 September 2013 (UTC)[reply]
Sorry, but I am not impressed by your "counterexample"... The same user has been able to find a way to revert an edit ([2]) very soon - on his 10th edit. And using HotCat ([3]) just after the unblock request ([4])... Now it is good to assume that the user is telling the truth, but maybe we could get an example where it would take a little less effort..? And if it has to be an unblock request, maybe it could be without unfair accusations and demands to block directed at one's opponent who has communicated with the blocked user very nicely..? For I don't see why we should go out of our way to keep such newbies... There are enough newbies who are acting much better.
Also, if the user doesn't notice the posts addressed to him, isn't it a problem with WP:NOTIFICATIONS (that, may I add, is another novelty of WMF)..? How is "Flow" supposed to affect anything about that..? --Martynas Patasius (talk) 01:57, 23 September 2013 (UTC)[reply]
The value in this counterexample is that anyone familiar with this area knows just how typical it is. About 10% of unblock requests are malformed. There's one sitting in CAT:UNBLOCK right now whose editor forgot the closing }}. WhatamIdoing (talk) 02:07, 23 September 2013 (UTC)[reply]
"The value in this counterexample is that anyone familiar with this area knows just how typical it is." - so, it is not addressed to anyone who is not "familiar with this area"..?
"About 10% of unblock requests are malformed." - and what sample is this "10%" based on..? Anyway, your counterexample shows that "malformed" unblock requests are not necessarily a problem. The unblock request in [5] is malformed, if we'll look formally, but I am sure that the request was not denied ([6]) because it was "malformed", but because it was, well, a bit impolite and had little indication of contrition. And your new "counterexample" is likely to fail for the same reason: if one can find the request and read the valid reason for unblock, no problems with formatting will matter. Contrary to your claims, there are no "arcane rules". It is just that competence (in the sense of being able to communicate in English reasonably and politely) together with humility and obedience are required for all Wikipedians - and they are much harder to learn than "wikitext"... --Martynas Patasius (talk) 02:31, 23 September 2013 (UTC)[reply]
The point you just raised is one that has come up repeatedly on this talk page. In part, I think the WMF folks do themselves no favor when they take the bait from the distinct minority of editors who feel as Martynas Patasius does. Many of us have concerns about effects on consensus-building and so forth, but do not see any of this as us-verus-them. I've become quite won-over to such improvements as automatic signing of comments, automatic fixing of what we now do with indentation, the ability to watchlist just one part of a talk page, and so on. I think that we have to be careful about ways in which the user interface might end up getting altered in ways that mislead new users about how Wikipedians come to decisions, and I am cautiously optimistic that the developers do not want to work at cross purposes with us in that regard. I hope that we are all in this together. --Tryptofish (talk) 19:20, 22 September 2013 (UTC)[reply]
Please do not accuse editors making good-faith inquiries of baiting. That is rude. Thanks. — Scott • talk 11:27, 23 September 2013 (UTC)[reply]
That's what you took away from what I said? It most certainly was not my intention! --Tryptofish (talk) 19:23, 23 September 2013 (UTC)[reply]
"This isn't an "article". It isn't subject to NPOV." - yes, I know. I am saying that it might still be a good idea to write as if it was.
"Talk pages are anti-mission in that regard - they actively work against what we are trying to do." - well, do you have a proof, or are you just begging the question (assuming what still has to be proved)..?
"If you are not able to see that, I'm not sure if there's a chance of having a productive conversation." - well, it depends on what counts as "productive". If you only count as productive something that assumes that we do need the "product" ("Flow") then no, it will not be "productive". But I don't see why that is a bad thing. And I also do not see why such a conversation could not be productive in any other way. Well, in principle - I see that you are not really interested in it and it takes at least two sides to have a conversation...
"We are very well aware of the "anti-WMF" arguments" - good. You might wish to start answering them. "([A]nd I have to say that using that name - "anti-WMF" - is not likely to carry any weight with anyone except people who hate the Foundation)." - it can be "anti-Flow", if you wish.
"If you start your entire premise with "I am anti-WMF", I am not sure there's a chance of having a productive conversation." - are you sure it is not a conclusion..? Also, how did you understand "anti-WMF"..? I even added quotation marks to emphasise that it was meant to denote a position contrary to position of WMF on the matter of "Flow" (and, perhaps, related projects, like "VisualEditor"). I get the impression that you took it to mean something different... Finally, even real enemies are not unknown to have productive conversations. That is how peace treaties come into being.
"And if you base everything around "the WMF staff are idiots and don't understand what we're saying and don't get the community", I'm not sure there's a chance of having a productive conversation." - sorry, but that is just a caricature of your opponents' position. Who has called you (or anyone else) an "idiot"..? Who has even implied that..? If someone has, I must have missed it. There is an opinion that you (WMF) might not be doing a very good job, but that is a different thing.
Or "don't understand what we're saying" - you know that I don't like "Flow" and I know that you know that. To that extent you certainly do understand what I am saying (and that is one of the reasons why I think your description is a caricature of a real position). But statements like "Part of that is to make knowledge sharing available to everyone - not just people who are able to figure out the arcane rules and syntax of talk pages. Talk pages are anti-mission in that regard - they actively work against what we are trying to do." asserted without any evidence do give a reason to suspect that you might not understand the position contrary to yours in full detail... And that is what writing a page as if it had to follow WP:NPOV might help with.
Now just to show why the assertion about "the arcane rules and syntax of talk pages" is not "self evident", try to think how one can write something on a talk page. Yes: in simple plain text (for example, [7]). One does not need a signature. One does not need to answer with correct indentation. If necessary, someone else can do some refactoring (for example, [8]). Or it can be left as-is. What is "arcane" about that? How are you going to create anything less "arcane"? It would probably require speech recognition... And, unless I am mistaken, "Flow" is not going to have that.
So, is my position clearer now..? --Martynas Patasius (talk) 23:47, 22 September 2013 (UTC)[reply]
I think your position is crystal clear, and that there's no productive conversation to be had with you about this.--Jorm (WMF) (talk) 00:12, 23 September 2013 (UTC)[reply]
Well, you sure do not seem to be close to persuading or befriending anyone who does not agree with you yet... Then again - I guess that is not your goal... --Martynas Patasius (talk) 01:30, 23 September 2013 (UTC)[reply]
Given the shotgun spray of mischaracterizations and argumentative fallacies that have peppered your replies thus far, Jorm, which Martynas has been able to sidestep with the easy grace of a ballet dancer, no, it does not appear that there is. — Scott • talk 11:27, 23 September 2013 (UTC)[reply]
  • Comment: I added some info on the guiding principles of the Flow project and Core features development in general. I'm also going to work a bit on fixing up the Rationale section and synthesizing some of the background research. What I'm hearing here is that some people are not convinced that talk pages are one of the "barriers that could preclude people from accessing or contributing to our projects." I'm guessing that's partly due to the fact that the citations to back this statement up are scattered over a number of pages and wikis. If you're still unconvinced even with these citations and feel we should not work on this project, you're welcome to continue leaving us feedback; however, it's unlikely that anyone from the development team will respond, since there's not much to say at that point.
What we will gladly respond to – and not just with words, but with actual design and development of features – is feedback from anyone who believes that discussion and collaboration can be improved on Wikipedia and offers us ideas, suggestions, even scathing critiques that help keep us working toward our guiding principles. You may not realize this, but if you actually care about improving the discussion system on Wikipedia, you have tremendous power and resources at your fingertips right now – use them :) Maryana (WMF) (talk) 21:02, 23 September 2013 (UTC)[reply]
Yes, I am pretty sure you do not want the discussion to end in the cancellation of your project or in the severe decrease of its priority. That is understandable, human. No one likes to do work that is seen as useless. Though, of course, I would like to remind you that if you do not try to persuade your opponents, they are not likely to change their positions... But anyway, this response is at least politely worded - and thank you for that.
Still, after saying that, the statements you have added to the page ([9]) - "The Wikimedia Foundation works in partnership with a global community of volunteers made up of article writers, [...] and many others. These are the people who build the projects, and they are the Wikimedia Foundation's partners in developing the platform." - do look rather insulting... I do not really feel like your "partner in developing the platform" if you won't even take the trouble to try to persuade me that the platform actually does need the development you have in mind and that you are not just exaggerating the problems with it.
"I'm guessing that's partly due to the fact that the citations to back this statement up are scattered over a number of pages and wikis." - what citations? I look at the page after you have edited it and I can see no "ref" tags at all. Nor do I see anything like malformed "ref" tags - neither internal links, nor simple plain text external links. That is my point: if you think that the problem with persuasiveness is that the evidence is not given in one place - add links here, as if you had to follow Wikipedia:Verifiability. Act as if that was an article! --Martynas Patasius (talk) 23:09, 23 September 2013 (UTC)[reply]
I consider that it would be a formidable task to argue dissent with Martynas Patasius' post immediately above.
— | Gareth Griffith-Jones | The Welsh Buzzard | — 17:24, 24 September 2013 (UTC)[reply]
See..? Don't "ref" tags make everything better ([10])..?
Finally, now we can "officially" discuss what does the cited evidence actually show - and, by its nature, such discussion might "accidentally" result in some requirements you are calling for.
So thank you, Maryana (WMF), that was a good change. --Martynas Patasius (talk) 01:26, 24 September 2013 (UTC)[reply]
Just so we get this straight, is there a serious argument being made here that we don't need to replace the present system at all, as opposed to questions about what the replacement should look like? I can't wrap my mind around the concept of anyone thinking that our current system is acceptable. --Guy Macon (talk) 20:01, 24 September 2013 (UTC)[reply]
You would be surprised. Or maybe not. We actually hear that a lot - that talk pages are perfectly normal, and that people who can't figure them out don't deserve to be working on the projects.--Jorm (WMF) (talk) 20:22, 24 September 2013 (UTC)[reply]
It depends on what do you mean by "need". If "need" means literally "need", in the sense close to "Wikipedia will not survive to next Sunday unless we replace the talk page system with just anything else!", then yes, there is a very serious argument that we do not "need" to replace the current system. Wikipedia has used this system for years and survived - there is no reason to think that it would not survive for another week (or month or year or two or perhaps even ten), just because we do not change the talk pages.
If, on the other hand, by "need" you merely mean that the current system of talk pages is not perfect and could be improved, then yes, I am not going to argue that it is perfect - and I do not think that anyone else is.
I would say that the flaws of the current system have been exaggerated and the advantages of the current system (for example, flexibility or the unity of interface between articles and talk pages) have not been sufficiently appreciated by the representatives of WMF. Thus I see a danger that they will create something worse than the current system and push it against all disagreement (by then it might become dear to them just because it it "their" - that is understandable and human, but not very desirable). That is why I think that at this moment it is important to emphasise the advantages of the current system and flaws of "Flow". --Martynas Patasius (talk) 21:59, 24 September 2013 (UTC)[reply]
In response to Guy, I should put myself forward as one who does "... think[ing] that our current system is acceptable."
Just two years ago, I began my first of any Talk page correspondance here on Wikipedia, having started editing experimentally only a few weeks earlier. I had no previous computer experience and I taught myself entirely by watching and examining other editors' posts in the edit mode. I was then 69 and delighted to have the opportunity of being a tiny cog in this wonderful project — I still am. I continue to learn new tricks every day. I am grateful for the stimulus/provocation that the editing and subsequent Talk page posting presents. Yes, I believe it is acceptable and, as with everything else, it may be modified in parts because without change it would stagnate.
— | Gareth Griffith-Jones | The Welsh Buzzard | — 08:20, 25 September 2013 (UTC)[reply]
Just posted on the Project page:
Flow will be released incrementally, as a limited opt-in beta. We want this product to change and grow over time, based on the feedback of the people who use it.
@ Maryana Does this indicate that even if Flow is operative, one may still continue with the existing Talk page method instead?
— | Gareth Griffith-Jones | The Welsh Buzzard | — 21:00, 26 September 2013 (UTC)[reply]
"Release" in the above sentence simply means release to a couple of pages where people have agreed to try Flow out for a set period of time and give us feedback on what needs to be changed/improved. We're aiming for around December for that phase, then some time to fix issues based on that feedback, then figuring out whether we need to go back to the drawing board or release more widely... So, basically, most talk pages will still be talk pages in the next 6 months. At some point in the grand, utopian future, Flow is intended to replace talk pages, but that's pretty far out, and it won't come a surprise to anyone :) Maryana (WMF) (talk) 21:28, 26 September 2013 (UTC)[reply]
And to further make sure that there is absolutely no confusion regarding this: it will not be possible to edit Flow-enabled talk pages like current talk pages. They are either-or, not both. When a page becomes Flow-enabled, the existing talk page is subsumed.--Jorm (WMF) (talk) 21:32, 26 September 2013 (UTC)[reply]
Thank you both for your prompt replies.
— | Gareth Griffith-Jones | The Welsh Buzzard | — 21:49, 26 September 2013 (UTC)[reply]
I was actually quite pleased to see the description of the plans for the incremental roll out. I think that's the right way to go, because it will seek community feedback over time, before implementing it everywhere. --Tryptofish (talk) 22:36, 26 September 2013 (UTC)[reply]
@ Tryptofish, speaking of feedback, a new section arises :) Chime in! Maryana (WMF) (talk) 22:48, 26 September 2013 (UTC)[reply]
Thanks for asking me. I read that section, and my reaction to it is to agree with where you said "yikes!". Old fogie that I am, I've pretty much steered clear of pretty much all of those systems listed, other than Wikipedia of course. So I don't have anything helpful to offer, about structure. What is on my mind is a more cultural issue. It's not about how Flow would be put together, but more about the choice of words at the user interface, and about how to convey to new users the right, well, signals about how to work successfully on Wikipedia. It's not what you asked, in this case. One example would be where you and I previously discussed "nice". A more important instance would be choosing language that helps new users understand how WP:Consensus does and does not work, something I've raised in earlier talk threads about "talk" versus "discussion" versus "boards". I want to be careful not to mislead new users into thinking that Wikipedia is just like (fill in the blank, with whatever other website you wish), only to find subsequently that the community has certain cultural expectations that differentiate constructive editing from disruptive editing. TL;DR: Wikipedia ain't Facebook. --Tryptofish (talk) 23:10, 26 September 2013 (UTC)[reply]
@ Tryptofish, this thread is getting pretty unwieldy. Hope you don't mind me splitting this off into a new section and replying to you below... Maryana (WMF) (talk) 23:24, 26 September 2013 (UTC)[reply]
All good. --Tryptofish (talk) 00:27, 27 September 2013 (UTC)[reply]
I might be coming late to this thread but please let me answer the question in the title:
First of all, what Flow is not: Flow will not be a wiki text, meaning that discussions at Wikipedia either regarding articles or users won't be wiki style anymore. We won't be able to edit each and any letter, no matter who wrote it an when. We won't be able to collaborate!
Flow will be individual snippets, written and owned by the one author, and connected to threads or other compilations by software. There won't be any user or article talk pages, but only snippets that somehow are linked to the article or user in question.
Proponents argue that we will be able to watch only "relevant" parts of talk pages. But that way we will stay inside a bubble of "My Wikipedia". My Wikipedia will not be your Wikipedia, we won't see and know the same things behind the scenes. We won't have much in common and seeing things that surprise us, just by watching certain user or article talk pages, will become rare. Being a Wikipedian is first and foremost caused by my curiosity. I am curious about the world, life, others and myself. I don't want a filtered "bubble" Wikipedia. And I don't want to encounter Wikipedians who live in their bubble. rgds --h-stt !? 17:49, 30 September 2013 (UTC)[reply]
As I've said elsewhere on this talk page, my principal interest here is in avoiding any adverse effects on consensus-building on Wikipedia, and in that regard what you said is very interesting to me. Although I'm pretty sure that we won't be required to watch only one part of what are now talk pages, and therefore one can certainly continue to pay attention to however much one chooses, the concept of people winding up in isolated "bubbles" is a provocative one. I think it's very important that we not go down a path of making the discussion process seem too much like social media, where people post about what they ate for breakfast, but don't necessarily remain focused on building encyclopedic content. --Tryptofish (talk) 18:24, 30 September 2013 (UTC)[reply]
"My Wikipedia" is already not "your" Wikipedia. We can see that easily by looking at comments from editors here: "I" use math, and even though 99% of pages don't, what I use is critically important. Or "I" edit other users' comments (e.g., to remove vandalism), and even though 99% of comments don't need this, what I do is critically important. Or "I" post welcome templates, and even though 99% of comments aren't welcome templates, what I post is critically important.
IMO all of these things are actually important and desirable, but there's almost no overlap between these groups. The anti-vandal editor doesn't post math equations or welcome newbies. The English Wikipedia is already too big, and editors too specialized, for everyone to have a shared vision of what happens. WhatamIdoing (talk) 22:55, 30 September 2013 (UTC)[reply]
@H-stt: Re: owners - there are plans to experiment with permissions (ie. in the first release, only the original author or admins can directly-edit a comment's text), but this is definitely an experiment, and the input in the past few threads about this are definitely understood.
Re: bubbles - the plan is to have the best of both systems - we'll still be able to watchlist entire pages ("boards" in the dev-terminology), but we'll also be able to watchlist specific-threads. I think all Wikimedians enjoy stumbling upon random and tangential knowledge - losing this capacity is not an option. Quiddity (WMF) (talk) 23:31, 30 September 2013 (UTC)[reply]

A question

Apologies if I've misunderstood this, but some of the posts above suggest that Flow is going to change (or do away with?) the concept of an article talk page. Rather than a talk page being a place that no one owns and that all contribute to, we're going to have Facebook-style comments, where individuals own their posts, and there is no central place to discuss a particular article? I'm having difficult imagining how that will work. First, editors' posts sometimes need to be changed or removed entirely (e.g. personal attacks). But I'm also wondering how we're going to collaborate on articles without article talk pages. Where would we hold RfCs, for example? Again, apologies if I've misunderstood. SlimVirgin (talk) 02:10, 2 October 2013 (UTC)[reply]

I suppose you could say that the underlying concept will change, but in practice you'll still be able to get the same result. You will have a choice between watching "the whole page" (what I'll do with WT:MED) or "a section" (what a lot of people will do with ANI: just watch the one discussion that you care about, without having to wade through the unrelated stuff).
Also, what are now "sections" (individual discussions) could be connected to multiple "pages", which should be very handy for things like merge discussions, or RFCs that want to bring in people from a particular WikiProject or noticeboard.
If you're not watching a page, then you would just go to the discussion page and read everything there. It might not be called Talk:Example (because that name's already used), but "Flow-talk:Example" (or whatever the namespace is) would show you every conversation connected to that page.
As for changing people's comments: every project has their own ideas about how to handle this. Flow will have a userright that can be set to anything. If a project says that IPs should be allowed to change/vandalize your comments, then Flow's userright can be set to allow that. If a project says that only admins should be allowed to change/vandalize your comments, then Flow's userright can be set to allow that. WhatamIdoing (talk) 04:23, 2 October 2013 (UTC)[reply]
WhatamIdoing's examples and statements are pretty much correct. I would caution that until otherwise said, all flow features (good and bad) should really be treated as ideas we're experimenting with. Those particular ones (easy transclusion and persistence in multiple locations) are pretty baked in, but we're still working out all the interesting and awkward edge cases. Example: I transclude a thread on to AN/I and WhatamIdoing's userpage to complain about the Pioneers' performance against William Penn last season. The community agrees a message must be sent, and blocks her, leaving her talkpage access intact. Can she still contribute to the thread? And, more importantly, will Taylor be any use once he's got two functioning arms? Okeyes (WMF) (talk) 09:22, 2 October 2013 (UTC)[reply]
The question here is really very much in line with what I have repeatedly been bringing up on this talk page. I've been trying pretty carefully to follow how Flow is being thought about, and it seems to me that there still will be a specific "page" (or whatever we end up calling it) for each article that we have, that will be the centralized place for discussing the content of that page. One will have a choice of watching all the discussions there, or any subset of the discussions, and that will be the individual choice of each user. I think that's an improvement. One will also be able to link a particular discussion to more than one article, if it applies to more than one. I think that's an improvement, too. There will still be editors making comments and replying to other comments, but with some automation of signing and of what we now do with indenting, so it should still be the same general process of discussion (I hope!). What I keep worrying about is the user interface. I keep hearing some developers implying that they have already made up their minds that we are going to do away with concepts like "talk" and "discussion", and replace them with "posting" on "boards", because, in effect, they think that it's more "hip". I also note that other developers keep assuring me that those kinds of choices of terminology are going to be determined later on and one-by-one at each language of the projects, and only with careful consultation with, and listening to, the editing community. I have chosen to believe the latter group of developers for now. --Tryptofish (talk) 17:18, 2 October 2013 (UTC)[reply]
Thanks for the responses. If people have the choice of watchlisting only chosen threads on a particular talk page, I'm wondering how will they know when a new thread has opened on that page. SlimVirgin (talk) 23:45, 3 October 2013 (UTC)[reply]
That's a really good question. So, watchlisting of individual threads isn't actually going to be in the first release precisely because of this problem; we need to do some thinking and/or research on stuff like what that'll do to participation numbers for unrelated threads on the same page, for example. I guess the ideal is "people who care about the subject area rather than a particular thread still watchlist the page as a whole", but yeah, I get the problem :/. Do you have any thoughts on the issue? Okeyes (WMF) (talk) 23:49, 3 October 2013 (UTC)[reply]
That's an issue I've been wondering about too. As I see it, the ability to just watch some threads is useful on noticeboards, more than on article talk pages. For example, if I request page protection at WP:RFPP, I'm very interested in the thread where I made my request, but I'm not the least interested in anything else. But if I watchlist an article on a specific subject, I really ought to be interested in new discussion threads as they crop up. Suggestion: If someone watchlists a page, perhaps the default should be that they will be following all threads on the associated discussion space. --Tryptofish (talk) 23:56, 3 October 2013 (UTC)[reply]
The current thinking is that you can "watch" the page, which will then send you notices that new Topics have been created. Whether or not this automatically "subscribes" you to the Topic is one we'll be playing with; my current thinking is that "yes, it will" since you can always "unsubscribe" or mute them.
The reasons for watching/subscribing only single Topics are pretty broad. Many people end up watching user pages after warning them, say, and they really only care about the "warn" Topic.--Jorm (WMF) (talk) 23:57, 3 October 2013 (UTC)[reply]
I like that approach. I like that watching a page defaults to being informed about all discussion about it. And I like that each user can then make a choice about subscribing or not subscribing to each thing they've been notified about. --Tryptofish (talk) 00:03, 4 October 2013 (UTC)[reply]
Indeed. Or another example might be this single AN/I thread/whatever that I'm interested in/participating in - that, I care about. Legal threats over the Israeli-Palestine problem reported on the same page, not so much ;). Tryptofish's suggestion could make sense as a potential way of indirectly avoiding the problem, but I'd worry that it was unwanted or going to create a lot of noise - ditto jorm's idea. I appreciate AN/I is an edge case, but it's a pretty important edge case, and I suspect requiring people to unsubscribe from each newly created thread there could induce RSI ;). Alternately, we could have something along the lines of: pages can be watchlisted, threads can be added to your feed. That way people still have the incentive to watch entire pages if they're interested in the subject-matter, but don't have to be overwhelmed with things if they're only interested in a specific thread, because there are two different ways of paying attention depending on what you're looking for. Thoughts? I'm just screwing around with ideas at the moment; nothing I say should be taken as gospel, just "something one guy thinks might be interesting as an option". Okeyes (WMF) (talk) 00:05, 4 October 2013 (UTC)[reply]
I think on an article people care about, they are going to want to watch the whole page. If you're informed that a new thread has started, and it's called "Rewrite of the third section," and you don't care about the third section, you might not subscribe, but mid-thread that can morph into "let's discuss the lead while we're at it." So realistically I can't see a situation where an editor would want to watch only some threads on an article talk page. Same with noticeboards.
Oliver, can you explain more about the idea of editors having a feed (whenever you have time, no rush if you're busy)? SlimVirgin (talk) 01:31, 4 October 2013 (UTC)[reply]
I take the point that we don't want to create too much "noise". One kind of unwanted noise would be getting all those "notifications" that "this user has created a new discussion thread about xyz, do you want to subscribe?" Another kind is what we have now: tons of edits showing up on one's watchlist, when one is not interested. And I think that noticeboards are exactly where the latter consistently crop up. I think ANI is an excellent example. I'm not an admin. I suppose that many admins would consider it part of their business to watch everything at ANI, even sections where they have not participated. But I have near-zero interest in most threads there. From time to time, however, I become very interested in a particular discussion. I want to watch it closely, because of some involvement that I have in the issue. Right now, if I watchlist ANI, my watchlist will get bombarded with edits to all the other sections, in which I have near-zero interest. The ability to follow just the threads of my own choosing has been, for me, probably the most compelling reason to be optimistic about Flow. --Tryptofish (talk) 15:40, 4 October 2013 (UTC)[reply]
The Village Pump is another example of the same thing. For example, if I have a technical question at the Village Pump, Technical, I probably couldn't care less about all the other threads, while editors who specialize in that stuff may want to watch the whole thing. --Tryptofish (talk) 15:46, 4 October 2013 (UTC)[reply]
I'd watch single sections on article talk pages if I were only interested in a merge or move discussion. Otherwise, I'd usually watch the entire page. On noticeboards, however, I'd take the opposite approach: give me just the thing I'm interested in. WhatamIdoing (talk) 23:28, 5 October 2013 (UTC)[reply]

Feeds, as I understand them, are sort of like watchlists, only more directly useful. So take your watchlist, but only for talk pages (and noticeboards and such). Now instead of saying "here are the (*sigh*) 106 talk pages that have changes you haven't read yet, and if you want to read them, you have to click on each one of those 106 pages individually", the feed says "You have 106 new or updated discussions to read and here they are!" You wouldn't have to individually click through to each page to see what is said. It would be right there on the page so you could start reading immediately. It's not very different conceptually from the New Messages page that LiquidThreads has used for years (mw:Special:NewMessages, if you've watched any LQT discussions over at Mediawiki). WhatamIdoing (talk) 23:28, 5 October 2013 (UTC)[reply]

That's pretty much it, although the details are still being worked out (I would rather we didn't compare it to LiquidThreads, having tried to use that system :(). It'll include things like threads and posts from your user talkpage, which should solve for one of the problems with LQT - namely, giving you a billion different places to look to replace the current list of billion different things to look. It's somewhat outside the scope of the requirements for the first release, and won't be built until long after then. Okeyes (WMF) (talk) 17:06, 7 October 2013 (UTC)[reply]

No edit conflicts?

Tracked in Phabricator
Task T56739

It has been claimed that Flow will prevent edit conflicts within the conversation space. I am curious as to how this will be accomplished.

We have already established that administrators can edit posts, and there exists more than one administrator, so the following scenario is possible:

User1 posts the following message under Flow:

You can find info about SftToIPDoAC at http://www.rfc-editor.org/rfc/pdfrfc/rfc149.txt.pdf

Two administrators, AdminA and AdminB both notice an error in the above and each opens up an edit window so as to fix it. They come up with this:

AdminA version:

You can find info about SftToIPDoAC at http://www.faqs.org/rfcs/rfc1149.html

AdminB version:

You can find info about SftToIPDoAC at http://tools.ietf.org/html/rfc1149

They both save and then the undefined no edit conflict magic happens.

Which version gets posted? Last one saved? Or does Flow have a checkout / lock system so that one of the admins can't open an edit window? If so, can the first admin prevent editing for 24 hours by not checking in / unlocking?

Whichever version wins, does the winning admin know that he overwrote another admin instead of User1?

To illustrate why this might be a problem, consider the two admins posting followup messages without going over User1's post carefully to make sure some other admin hasn't changed the URL:

AdminA writes:

If you look at comment number three at the URL in User1's post, you will see a proposal to boost the packet size to over 4 GB.

AdminB writes:

If you click on the Errata link at the top of User1's URL, you will find a potential problem with Windows.

One of those statements will end up referencing the wrong URL and will be pointing the reader at something that does not exist.

Could we have some detail on what happens when two administrators try to modify the same post at the same time? --Guy Macon (talk) 21:45, 23 September 2013 (UTC)[reply]

There'd be an edit conflict in that case. But the point is that this scenario would be an extremely rare edge-case, instead of an everyday reality when adding anything to an even moderately-trafficked talk page. Maryana (WMF) (talk) 23:07, 23 September 2013 (UTC)[reply]
I don't want to be difficult, but the above highlights the communications problem we have. Until recently, the page that tells us what the plans are for Flow said No edit conflicts, ever.[11] and Jorm confirmed this when asked.[12] Now, when I ask essentially the same question, I get a different answer.
Can I trust the other statements made in the same document? The same document told me that the plan was that there would be "No unsigned posts in discussions—all posts and comments will be automatically signed and dated." - a feature that had 100% approval among those polled. How do I know that that didn't go away as well? Do I have to keep asking on that one as well? How can we have a constructive conversation about the Flow feature set when I cannot get a straight answer as to what that feature set is? --Guy Macon (talk) 08:31, 25 September 2013 (UTC)[reply]
I agree. The edit history proves that the WMF's story is changing all the time. 76 revisions! What a quagmire of quicksand and marmalade! Kaldari (talk) 19:52, 26 September 2013 (UTC)[reply]
Revisions are not bad. Changing the story as you learn new things is not bad. Telling us things that you know are not true and then later quietly deleting them is bad. (And before anyone tries to tell me that anyone ever believed the "No edit conflicts, ever" story, no, they did not. If anyone disagrees with me on this, simply tell me on what basis they believed that -- explaining in detail how they were planning on accomplishing it.) --Guy Macon (talk) 06:32, 27 September 2013 (UTC)[reply]
@ Guy Macon, to quote from the almighty and powerful Agile Manifesto, we are a team that values: "Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan." What this means is that we could spend the next 6 months negotiating a contract with you and every other Wikimedian over what Flow will and won't do (in all languages, across all projects – we'd have to hire a lot of translators!). And then in another year, we'd deliver something that looks like Liquidthreads, and you'd shake your head and wonder what went wrong...
Instead, we're going to spend the next 6 months knocking together a prototype, having people test it and say it's borked for foo and bar reason, fix foo and bar, release to a few pages onwiki, have people tell us that it absolutely needs to have zed, add zed, and release more widely only when all the big issues are fixed and there's consensus to move forward. Letting go of the former way of thinking about this project and embracing the latter is going to take a not-so-radical leap of faith on your part: Assume good faith. We're not here to destroy everything you love. We're not here to build something in a vacuum for the sake of riches and power (ha, like the Wikimedia Foundation is where we'd work if any of us cared about that). We're here to work with anybody who thinks that talk pages could be better, to create a kick-ass discussion system. Anybody! All you have to do is believe in these principles, and your voice carries just as much weight as anyone else on the development team. Really, it's that simple :) Maryana (WMF) (talk) 23:17, 26 September 2013 (UTC)[reply]
So those are our only alternatives? Either have you spend the next 6 months negotiating a contract with me and every other Wikimedian over what Flow will and won't do, in all languages, across all projects or have you tell us things that are not true?
I withdraw all my previous comments about Flow, because I no longer have any confidence that anything we have been told about Flow is true. I will watch this thread for replies for a while (probably without answering) and then I am going to unsubscribe from this page and focus my efforts elsewhere. (On reflection, I cannot in good conscience do that. This hurts Wikipedia.) --Guy Macon (talk) 06:32, 27 September 2013 (UTC)[reply]
It is not a question of development. It is a question of honesty. It is a question of doing your best to find the truth and to avoid telling things that are not true.
I have given you a link to Wikipedia:Neutral point of view. It indicates many ways of telling something that we are not sure about with qualifications that prevent the whole statement from becoming false. "Current plans indicate that there will be: No edit conflicts, ever." ([13]) is not one of them. Do you not see how that can be interpreted to mean "Now we have reached the point where we know that there will be no edit conflicts, ever."..? Thus it ends up being a promise. And are you willing to say you (WMF - I know it was not added - [14] - by you personally) are not bound by promises? Are you willing to say your word is worthless?
There is also a point of truth in advertising. You (WMF) are giving misleading statements praising the supposed benefits of your product, but do not tell us anything about its flaws. That is not good.
And the solution is simple: tell the truth, with all necessary qualifications. Truth, all the truth, and nothing but truth. It truth is simply "The WMF 'Flow' team cannot promise you anything, but we want to make a great communication system to replace the talk pages!" - write so. If the truth is "The current prototype can do X, Y and Z, but cannot do A, B and C." - write so. If the truth is "We hope that the next version of the prototype will be able to do X." - write so. If the truth is "As of Y-M-D, we expect to use this architecture/data structure/algorithm." - write so. Well, do you see the pattern emerging..?
The part about "All you have to do is believe in these principles, and your voice carries just as much weight as anyone else on the development team." also feels like "false advertising" (even if I am sure you said that sincerely). Really? You have also said ([15]) you are going to disregard the opinion of anyone who considers the current system to be good enough (and, presumably, to be in accordance with "those principles" - they are too vague to rule that out). Do you understand you end up implying that the ones on the development team will have no say too..?
And some of "these principles" are also unlikely to stand up to much scrutiny. "The Core features team is dedicated to the guiding principle of serving every human being with the ability to contribute to the Wikimedia movement.". Read it. You end up saying that even the illiterate will be able to contribute. I find that hard to believe... And the goals that are both ambiguous and ambitious are the best way to make the project a complete disaster - especially if the team has the best intentions. --Martynas Patasius (talk) 22:15, 27 September 2013 (UTC)[reply]
Guy Macon What really matters is the capacity of Flow to handle mid-air collisions, right? Nowadays there is not even a solid prototype, so none of us can really test. However, it is clear that if/when Flow runs in production it must handle edit conflicts effectively. In Flow users are supposed to edit only their own conversations instead of entire sections or full pages as we do here now. This diminishes radically the risk of edit conflicts.
But as you say, some users with special permissions might be able to edit somebody else's conversation and there exists a risk of edit conflicts. Well, if you really want to make sure that this risk is not forgotten then an option is to file already an enhancement request in Bugzilla (MediaWiki Extensions >> Flow). Or you can wait until a functional prototype exists, test this use case and if the bug can be reproduced then let's file it in Bugzilla.
And the same goes for automatically signed posts, or any other feature you care about: test it in the prototype when it's available or stamp it in Bugzilla already now as an enhancement request to make sure it's not overseen.--Qgil (talk) 04:59, 28 September 2013 (UTC)[reply]
If they had said that they think the final product will accomplish something that is at least theoretically possible, then "wait for a functional prototype and test" would be viable. That's not what they did here. The wrote -- in the main document that presents Flow to Wikipedia -- that they think the final product will accomplish something that is not theoretically possible. Not just hard. Impossible. Perpetual motion impossible. Turning lead into gold impossible. Traveling faster than C (speed of light in a vacuum) impossible.
Alas, this has an unfortunate implication. Anyone describing what they hope Flow will do must have at least some vague idea of how it will work. If I asked them to explain auto-signing, they would be able to give me a broad outline of how they plan on accomplishing this. Something like "user clicks on save button. Flow looks up the users signature. Flow appends the signature to the post. Flow appends the current time and date to the signature. Flow saves the comment." If you can't do that, you have no business editing the main document that presents Flow to Wikipedia.
Nobody at the WMF (or anywhere else for that manner) can describe the steps that they hoped will get us "No edit conflicts ever" because no such sequence of steps exists or can exist. So unless you think that someone at WMF is a liar (which they are not) or stupid (which they are not), the only reasonable conclusion is that, in their zeal to market Flow to us, they wrote "Current plans indicate that there will be no edit conflicts, ever", which is impossible, without having any idea how to do that. And asked about this, they claimed that they do know how to do this impossible thing. That is a COMMUNICATIONS problem. And when I asked WMF to please address the communication problem, I was accused of claiming that they are here to "destroy everything you love" and "here to build something in a vacuum for the sake of riches and power". Then they accused me of violating WP:AGF! --Guy Macon (talk) 13:26, 28 September 2013 (UTC)[reply]
Guy Macon, I just created Template:Bug and CCed you there. Some additional thoughts to improve the mood and decrease the amount of energies needed to address software related concerns:
  • They vs Us is not as useful as All Of Us trying to build together a great piece of open source software.
  • This is not a grammar competition. If a sentence could be improved, let's improve it. The point of that sentence probably was about conflicts between plain users, which is a problem in current Talk pages and it won't be in Flow. That sentence didn't accommodate your use case? Fine, since you have a point let's make sure the developers don't miss it. Hence the Bugzilla report.
Let's move on? Thanks to this discussion I will sure do my best volunteering testing for Flow, trying to hit those potential edit conflicts. Thank you for your help!--Qgil (talk) 17:02, 28 September 2013 (UTC)[reply]
Er, what is the point of that "bug report"? "That sentence didn't accommodate your use case? Fine, since you have a point let's make sure the developers don't miss it."? What "use case"? "Brandon Harris" also seems to be confused about your "bug report" on Bugzilla...
Did you actually look at the explanation - [16]? It is not a "bug" or "enhancement" (and definitely not a "use case"). It is a logical contradiction in the requirements. And you claim you and your team can do something about this "use case"? God Himself cannot instantiate logical contradictions!
So, when you say "They vs Us is not as useful as All Of Us trying to build together a great piece of open source software.", I see the equivalent of "Let us all build a great perpetuum mobile!" or "Let us all build a great Turing machine to solve the Halting problem!". That cannot be done. In principle.
"Thanks to this discussion I will sure do my best volunteering testing for Flow, trying to hit those potential edit conflicts." - the testing for that is trivial. Doing your best won't be necessary. If you find it non-trivial, I can write you a test scenario (would that count as "working together"?). Anyway, it is not time to test. It is not even time to write code. It is time to think.
However, "They vs Us is not as useful as All Of Us trying to build together a great piece of open source software." might be a good advice to you (and your team). After all, why should we join you? Maybe you should join us? That also ends in all of us working together, doesn't it..?
So, stop the "testing" and let's start from the beginning. I have written an analysis of your "research methodology" (the one that, presumably, has led you to conclude that you actually need this project) and intend to look at the results of user testing later. Look at this analysis and see if you agree.
So, shall we work together - but starting from no logical contradictions, sloppy research and irrational prejudices against the current talk page system..? --Martynas Patasius (talk) 18:55, 28 September 2013 (UTC)[reply]
I'm not in the Flow team, although I work at the WMF not very far from them. I just like the project and (in this particular case) I want to help testing that Flow handles edit conflicts well. You posted about it, you got me interested. Simple as this. A Bugzilla report is just that: a note about an issue that can be prioritized, discussed and resolved in a way more structured and closer to software development than a wiki discussion page. I'm sorry if you didn't find it useful today. Still, I'll watch the progress and (out of personal curiosity) I will test it whenever there is a chance.--Qgil (talk) 05:07, 29 September 2013 (UTC)[reply]
Ah. Well, actually, even after looking at the explanation of organisation of WMF in its wiki ([17], [18], [19]) I still have no idea who does what, who reports to who - not to mention, why... That's why I prefer to avoid talk about some subunits of WMF...
Anyway, you have handled this conversation rather well (especially considering that perhaps it would be a bit unfair to expect a journalist to be very good at programming and Mathematics). "I'm sorry if you didn't find it useful today." alone makes this your answer much better than the average other WMF representatives have managed to achieve. It's a pity your job seems to have relatively little to do with communication with community... --Martynas Patasius (talk) 16:59, 29 September 2013 (UTC)[reply]

I've got to say that I've been reading all of this discussion as it has gone along, and I'm pretty sure that I understand it, and yet it seems to me to be making too much of a fuss over something pretty minor. By that "something", I'm referring to the error in wording of the description of edit conflicts under Flow. Look, this isn't like the smoking gun from the crime of the century. --Tryptofish (talk) 20:41, 28 September 2013 (UTC)[reply]

Sure. Then again, closing Wikipedia down wouldn't be "like the smoking gun from the crime of the century" either. It's just a website, remember?
And usability is just not that important either - even the ones who specialise in it (like Joel Spolsky) admit it ([20]).
The point is twofold. First, I don't think it is nice of WMF to end up promising us things they cannot deliver - and then act as if it is our duty to applaud whatever they do, just because they have good intentions. Second, the project that starts with such problems is not going to be "a great piece of open source software". It means that the "Flow" team was too enthusiastic and not "philosophical" enough to see the impossibility of the promise they ended up making. If they were mistaken on this matter, what else have they missed? I'm afraid that many other assumptions of this project are faulty... Those two points make this question about as important, as "Flow" itself is. --Martynas Patasius (talk) 23:22, 28 September 2013 (UTC)[reply]
There is an additional point that I would like to emphasize. Imagine that you are someone on the Flow team who decides to discuss things with Wikipedia rather than just throwing something over the wall and seeing who complains. In order to encourage discussion, you describe the team's current thinking on various features, placing this description on Wikipedia:Flow with the usual "this may change" disclaimers.
So here you are writing this Wikipedia page. What, exactly do you write? Do you describe things that the team has put at least some thought into and actually plans on doing if they can, or do you just make some stuff up that you think will appeal to Wikipedia? Do you talk with someone who is working on Flow and ask "what, exactly will happen when two editors try to edit the same paragraph at the same time?" and then write that? Or do you just throw out "no edit conflicts, ever" even though you have absolutely no way of knowing whether what you write is true or even possible? Is the goal to provide an accurate description and update it as things change? Or is the goal essentially marketing; saying whatever it takes to get Wikipedia to like Flow?
OK, so now pretend that you are someone else at WMF. This time you are a developer with a lot of detailed knowledge about what works so far and what you are planning in the future. Imagine that you are reading a question on this very talk page, asking "How would edit conflicts be prevented? ... No matter what the editing style is for this new flow system, how would it completely prevent all edit conflicts?"[21]
How do you respond? Now we know that you don't have any working code or even the faintest idea how to write code that completely prevents all edit conflicts. We know this for the same reason that we know that you don't have plans for a perpetual motion machine -- it cannot be done. So how do you respond? Do you give a straight answer like "we don't know how. It's something I am going to look into doing later, but right now it's just an item on our wish list"? Or do you write a non-answer that does nothing to explain how you plan on doing it like "Uhm, Flow will prevent edit conflicts within the conversation space. It won't do anything about edit conflicts within articles"?[22] (Note that the question did not specify articles.)
The actual subject of edit conflicts doesn't really matter exempt as an example of WMF not giving us straight answers. The fact that WMF isn't giving us straight answers and that some folks at WMF become overly confrontational when we insist on straight answers is a big problem. So again I say, This Is A Communications Problem. We Are Not Getting Straight Answers. Fix It. This is not an unreasonable request. --Guy Macon (talk) 18:46, 29 September 2013 (UTC)[reply]

As one of the people who helped draft the section that Guy's complaining about, I would like to introduce a couple of facts:

  • It was described at the time as a draft that needed to be improved later. In this case, it appears that "improved" means "explaining at much greater length".
  • The context for this item was when you first post the message, and a plan to prevent 100% of edit conflicts in that situation is already in place. We never get "edit conflicts" when two people start different pages at the same time, and Flow will be using different "pages" for each post.
  • You certainly can prevent edit conflicts when editing pre-existing comments: you just lock all other users out of that comment until the first editor has either saved the page or timed out. You won't get an "edit conflict" when you tried to save the page; you would instead get a "sorry, someone else is editing this comment" error message when you try to open the edit window. Database designers do it all the time. Wikis don't happen to use this system, but it can be done. WhatamIdoing (talk) 23:24, 30 September 2013 (UTC)[reply]
  • That's still an edit conflict. We already stop one editor from making his edit. Whether we do this at the start (don't let him open an edit window) or at the end (don't let him save) is an implementation detail. It loses the A in CAP. See Wikipedia talk:Flow#Brewer’s Conjecture. Likewise, saying we don't get edit conflicts except when two people try to edit the same paragraph at the same time isn't really getting rid of edit conflicts. --Guy Macon (talk) 01:36, 1 October 2013 (UTC)[reply]
  • Well, so let's be clear here. The initial statement of no edit conflicts was largely valid, in the sense that people weren't able to edit the posts of others under any circumstance. There were some awkward edge-cases (if I write out a comment to a thread and hit submit after you suppress the thread, what happens?) but it was largely correct. If we're talking about multiple users being able to edit posts simultaneously, yeah, that'll cause problems - we can lock them out of the system, sure, but if that only becomes apparent when they hit 'submit' that's pretty much an EC. Yeah, I know, theoretically it's different, but it presents to the user in the same way - the system setting up an expectation of mutability and then not being able to follow through.
  • So "no edit conflicts" is definitely not accurate, although "highly reduced" would be. If you can point me to documentation that claims "no", I'm happy to correct it. Okeyes (WMF) (talk) 16:35, 1 October 2013 (UTC)[reply]
The "No edit conflicts, ever" language was removed a while back. The only reason we are still discussing it is because I want to improve the communication between Wikipedia and WMF. In particular, if someone asks "are you sure X will work? How, exactly, are you planning on doing X?" The answer from WMF needs to be a straight answer. "We don't know yet" is perfectly acceptable. Confirming that X will work when you have no idea whether that is true is not acceptable . I am not trying to be adversarial here; I just want straight answers. Please, have a meeting, discuss this among yourselves, and make a commitment to not say things when you have no idea whether they are true or not. Start doing that and everything will go a lot smoother. --Guy Macon (talk) 01:58, 2 October 2013 (UTC)[reply]
I think that's a laudable goal, and one I agree with (and will happily participate in - if you see people, including me, not giving a straight answer, tell me or wack me upside the head as appropriate). If you look at the recent comments on this page from me, Quiddity and Maryana I think you'll find that we're happily answering "I don't know" or "we haven't had that conversation yet" or "this feature should be treated as a proposal rather than anything else until stated otherwise" where appropriate. For full clarity; whenever you have software, you have two things: What The Software Looks Like In Utopia and what we can realistically build. When the process of talking about Flow started, everything at the WMF end was pretty chaotic and we didn't have the slate of people normally tasked with saying "no" to ideas a lot ;p. Things are on a more stable footing now, hence the change in tone, and I think we're aware that with future projects (and future developments in this project) we have to have the "no" people around in an early stage, before we talk to the community: it's unreasonable for us to set false expectations, tread all over them and then panic that people approaches us with scepticism. There's a causal relationship there. Okeyes (WMF) (talk) 16:34, 2 October 2013 (UTC)[reply]

Brewer’s Conjecture

I am going to try to explain why "No edit conflicts" is theoretically impossible.

The CAP Theorem, otherwise known as Brewer’s Conjecture, was formally proven to be true in 2002[23]

Wikipedia is a distributed system. If you try to edit a Wikipedia page while I try to edit the same page, our two computers are a distributed system. If there was one computer somewhere watching what keys we each hit and constantly updating our screens, that would be a different story.

We know that, in any distributed system. you cannot provide Consistency, Availability. and Partition tolerance. You have to pick two and lose one.

We cannot do without partition tolerance. You and I are not using the same computer, nor are our computers in constant communication.

Right now we do without availability -- the property that a request to edit the data will always complete. When I click the Save Page button after writing this, the write may fail and give me an edit conflict message.

We could provide guaranteed availability by dropping consistency. If you and I both edited a page at the same time Wikipedia could accept our edits and show each of us a different version. Not a workable idea, but it is possible.

What we cannot do, no matter how hard we try or how clever we are, is to provide Consistency, Availability. and Partition tolerance at the same time. Consider you and I reading the same Wikipedia page. If we each edit the page, our two versions become inconsistent, thus forfeiting consistency. If we could communicate we could get back consistency, but by doing that we just forfeited partition tolerance. Or we could stop one of us from editing, thus losing availability.

See http://ksat.me/a-plain-english-introduction-to-cap-theorem/

--Guy Macon (talk) 13:26, 28 September 2013 (UTC)[reply]

"Test: User messaging 1: Talk page basics" - the methodology

OK, so, now ([24]) we have the statement "Simultaneously, we know that freeform wikitext talk pages present a significant barrier to new users" cited to mw:Flow Portal/Research/User Test Data ([25]). I think we should go through that research and discuss it. It might: 1) show to what extent it does support the statement, 2) show the necessary requirements. Unfortunately, the analysis in mw:Flow_Portal/Research ([26]) is not very detailed, but that means we are almost certain to do better here.

So, I would like to start with the methodology of the first of two tests (with the hope to tackle the first video of that test next).

Thus, first of all, we have to look at the sample. The sample size is 5 (including the "Test 1.1" that is similar to "Test 1"). That is highly unlikely to be useful for more serious analysis, but, well, that is still better than sample size zero. A bigger problem is that there is no indication how the sample was chosen. There is some explanation on the page of the company "UserTesting.com" that seems to have been doing the testing ([27]) - which, by the way, hasn't been mentioned on the research pages -, but it says the "target audience" has to be specified. It means that we do not know what the sample is supposed to represent. It could have been random readers of Wikipedia, random non-readers of Wikipedia... Thus at the moment there is no reason to think that the sample is representative for "new users" to any extent. That part might need to be qualified. Still, it is data that we have and there might be some use for it.

Then we have the scenario. The description given on the page is:

"This is a test of Wikipedia's user-to-user communication systems. In this scenario, you have recently joined Wikipedia and tried a few first edits. A few days have passed since your initial login and you are now returning to the site, curious if anyone has noticed or objected to your edits."

It should be noted that, contrary to the assertion given with the test results - "The page was a very simple and common scenario." -, the actual scenario is neither simple nor common. The point is that, as it looks, the testers have not really tried editing Wikipedia any time before the test. However, the "normal" user cannot end up in the situation described in the scenario without doing any editing. Such user has to register (I suspect that that is what "joined Wikipedia" is supposed to mean, since all testers had to use the provided accounts) and to, well, "tr[y] a few first edits". Thus it could not have been the first time when the real user has seen "wikitext" or the basic interface of Wikipedia - and yet it looks like it was the first time for the testers. That can be expected to result in underestimation of the "user-friendliness" or "intuitiveness".

Then there are some general instructions:

"Remember, we're testing the interface, not you. If you're having difficulty with something, the problem is with our design. Please "think out loud" as much as possible; tell us your thought process during each task, and try to explain your general opinions as you arrive at them."
"If a task takes more than five minutes or so, just move on."

It should be noted that the use of help system or simple open-ended exploration ends up being discouraged (it is likely to take more than five minutes). That is not unreasonable if the testing was done to highlight the parts of the interface that deserve more attention, but once again - that can be expected to result in underestimation of the "user-friendliness" or "intuitiveness".

Then we get to the tasks:

"1. Log in using the account Silver waffles. Suppose this is the account you previously created."
"2. See if you can find out if you have new messages regarding your prior edits, including to an article you recall being about redemption. Where would you expect this to be found?"
"Spend no more than a few minutes on this."

It should be noted that it does not seem to be realistic to expect to get some messages because of some article edits. Also, only recalling some general area about the article doesn't seem realistic in such case (if the user cares about the article, won't he remember a bit more?).

Anyway, it is not really the test for "Flow" as much, as it is a test for Wikipedia:Notifications.

"3. You should have found your way to this page: http://en.wikipedia.org/wiki/User_talk:Silver_waffles - If not, go there now."
"What is your impression of the messages? Do they appear to have been left by a human or automatically?"

Of course, it is a trick question - the "good" answer is that it is a "templated" message, filled out with some parameters by a human. Should it count as "left by human" or "left automatically"..? Both, perhaps? This task seems to be pretty useless to me. Especially given that "Flow" is not going to make us write everything by hand (I hope).

"4. Now see if you can reply to the second message regarding the article you previously edited. Pretend you disagree with it and say so (you can use a reason if you want, but it's not required)."

First of all, "the second message" is unnecessarily confusing. Second, the name of the article hasn't been mentioned again (in the videos it can be seen that only one task is visible at the same time). Third, we should remember that there are many right answers (adding a reply on the same user talk page, on a talk page of the user being replied to; signature is optional, indentation is optional, heading is optional etc.). Fourth, that is one place where the tester is in an unrealistic position: a real user who did edit an article will know how to edit "something". And again - that can be expected to result in underestimation of the "user-friendliness" or "intuitiveness".

"5. Suppose you're not sure Orchaen solns (the user who left the message) will know that you replied. Does there appear to be anything further you can/would need to do to make sure they get your response?"
"Try to do this in whatever way makes the most sense to you."

The question is simply leading in the wrong direction (the correct answer is that nothing else is necessary). If the tester thought something like that was required, wouldn't he have done it during the fourth task..? It is not much of a reply if no one can see it. Thus the results of this task are meaningless and - once more - that task can be expected to result in underestimation of the "user-friendliness" or "intuitiveness".

So, in conclusion:

  1. The methodology of this test can be expected to result in severe underestimation of the "user-friendliness" or "intuitiveness" of the current talk page system.
  2. Two of five tasks (third and fifth) are worthless for just about any purpose.
  3. "Takeaways" (from mw:Flow_Portal/Research#Takeaways - [28]) like "None of the tested users were able to intuitively grasp anything about the use of User_talk pages." or "On average, it takes new users around 15 minutes to grasp the basics of user talk messaging." cannot be supported by such test.
  4. Statement "Simultaneously, we know that freeform wikitext talk pages present a significant barrier to new users" cannot be supported by such test without severe qualification (the "size" of the barrier is going to be greatly overestimated).
  5. The test might be useful if used correctly - to emphasise the parts of the interface that might need more attention.

So, would anyone disagree with such analysis..? --Martynas Patasius (talk) 00:08, 25 September 2013 (UTC)[reply]

I pretty much disagree with all of your conclusions.
For example, the third task (automated vs personal messages) is important to users' emotional reaction to the community. It's not a "task", but that doesn't mean that it's worthless. The English Wikipedia disallows automatic bot greetings to all new users precisely because we believe that automated welcome messages are not actually welcoming. Similarly, if you deal with new users very much, you will find that anxiety about whether the person knows that you've replied is pretty high, especially if no reply appears quickly. This is even more significant if the new editor is replying to a complaint about problems.
Similarly, you say 'a real user who did edit an article will know how to edit "something"'—but that "something" isn't a talk page, and that edit might have been made in VisualEditor, which means that the freeform wikitext system might be completely unfamiliar to the user. Also, you can get messages in response to uploading images, which is another task that new editors do, get (often very stern) messages in response to, and do not give them any experience with wikitext. WhatamIdoing (talk) 00:00, 1 October 2013 (UTC)[reply]
OK. First of all, thank you for reading and commenting. But maybe you could still give a more detailed comment? "I pretty much disagree with all of your conclusions." is rather useless without further details...
"For example, the third task (automated vs personal messages) is important to users' emotional reaction to the community." - you are not going to get a realistic "emotional reaction" with a misleading question in a situation where a tester has nothing at stake emotionally. As you can see, in the next sentence you did not use any findings of this test, just commented from experience and "first principles" - which is truly a more fitting approach in this case (although it is not perfect either).
Also, it has nothing to do with "Flow". Or do you claim that it is possible that we won't be able to continue writing "semi-automated" messages to the newbies with "Flow"..? If that doesn't change, this task only misdirects our attention.
"Similarly, if you deal with new users very much, you will find that anxiety about whether the person knows that you've replied is pretty high, especially if no reply appears quickly." - once again, I will note that you are citing no findings from the study. You can find some evidence in your experience - what does this test add? Once again we are giving the tester misleading instructions and look what happens. Well, the tester ends up misled - that's what happens. I'm afraid you cannot find much from such a "task".
"Similarly, you say 'a real user who did edit an article will know how to edit "something"'—but that "something" isn't a talk page, and that edit might have been made in VisualEditor, which means that the freeform wikitext system might be completely unfamiliar to the user." - a good reason to forbid the use of "VisualEditor", isn't it..? OK, OK. Anyway, as far as I understand, the test was done before the "VisualEditor" was deployed. Also, the "VisualEditor" is supposed to work with talk pages as well (eventually), isn't it?
"Also, you can get messages in response to uploading images, which is another task that new editors do, get (often very stern) messages in response to, and do not give them any experience with wikitext." - then the test scenario must talk about uploading an image and not about editing an article.
In other words, it looks like you did not really disagree with me on the level of sloppiness of this test (you did not really discuss it that much) - which is what my analysis concerned. You only claim that the problems the test was meant to find do exist - and in my analysis I did not claim they do not. But this specific test won't be very helpful with finding them and finding out what to do about them.
That is, if you want to find out how intuitive the talk page system is, you would probably do better to try some kind of a survey of potential users - asking them "Do you read Wikipedia?", "Did you ever try to edit Wikipedia?", "If you did try to edit Wikipedia, but stopped, why did you stop?" etc. Of course, there are lots of potential problems there too, but then you might get some information about real "emotional reactions" - if that is what you are after. --Martynas Patasius (talk) 02:19, 2 October 2013 (UTC)[reply]

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

Background

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

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

Flat, zero levels of nesting

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

Comment
Reply
Reply to reply
Reply


Examples of products using this pattern
  1. old YouTube
  2. Twitter
  3. Flickr
  4. PhpBB
  5. Simple Machines Forum
  6. Gawker
  7. Discourse
Pros/cons?

One level of nesting

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

Comment

Reply
Reply to reply
Reply
Examples of products using this pattern
  1. Facebook
  2. new YouTube
  3. Gizmodo
Pros/cons?

Two levels of nesting

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

Comment

Reply
Reply to reply
Reply
Examples of products using this pattern
  1. StackOverflow
  2. Medium
It's worth noting that on StackOverflow (and the other StackExchange sites) there are also separate "chat rooms" - essentially a zero level of nesting conversation - where free-form discussion is encouraged to take place. While it's important that we adhere to WP:FORUM (and Flow doesn't encourage too much forumy behaviour) it's also important to remember that one of the primary reasons for a talk page is to build consensus, and you can't do that without relatively free discussion.
On the subject of the StackExchange UI though, the ability to vote-up and vote-down questions, answers and comments might be an idea we want to borrow. We do a lot of polling and !voting on Wikipedia talk pages and we need a way for Flow to cope with that, including an easy way to count the !votes. WaggersTALK 13:13, 27 September 2013 (UTC)[reply]
@ Waggers, interesting, I didn't know about the StackExchange chat room space... I guess SO's front-page discussion system doesn't quite meet all the needs of its users, if they require an alternate method for backchatting. That's definitely true of Wikipedia, too; some project areas may need more structure in their discussions, and some may need less, so we want to stay open to different configurations. I see you're a member of a couple of WikiProjects – from your experience, do those feel more like StackOverflow-type spaces where people ask questions and want answers, or more like informal chat/forum between members?
On the consensus front: it seems to me that, in a way, StackExchange is also about building consensus (e.g., "what's the best answer for this question?"), and they've created the two-tiered system to encourage people to focus on the topic at hand, instead of spiralling off into back-and-forth 2-person tangents. You can still tangent in the comments, but those are just displayed in a way that makes it clear they're not part of the main discussion.
Polls, !votes, upvote/downvoting, and other methods of gathering the pulse of the crowd are really interesting. I don't think we're going to get to exploring those options in Flow the near future, but it's definitely something to think about. I'm not sure how the wider editing community feels about these methods, though. There may be some users who have used StackExchange and other sites (e.g., Slashdot) and like them, but I've heard people express some misgivings about creating those kinds of filtering mechanisms on Wikipedia. Maryana (WMF) (talk) 19:46, 27 September 2013 (UTC)[reply]
About polling, it's helpful to recognize that the consensus at the English Wikipedia is at WP:POLL. --Tryptofish (talk) 23:12, 27 September 2013 (UTC)[reply]
...Yep, the notion of "voting" without being able (or perhaps forced) to give an accompanying explanatory comment isn't what we want to encourage. I've put together a quick example of a typical consensus building discussion format - it would be good to see Flow supporting something like this kind of structure. WaggersTALK 07:30, 30 September 2013 (UTC)[reply]
@ Waggers, that looks like slide 25 of a deck I put together for Wikimania :)
The current structure of proposals evolved to look like this in part due to the technical constraints of Mediawiki – e.g., there's no concept of in-line annotation, so you can't make minor quibbles/critiques in place and have to put them in a separate section; there's no metadata associated with conversations, so you can't display the number of users participating at a glance. Flow won't be limited by those constraints, so we have a lot more room to experiment :) I'm curious, for example, what the purpose of a !vote section separate from the discussion section really is. Is it just to get a quick headcount? Give the closing admin/uninvolved user a visual cue in cases of WP:SNOW? What if we instead let people provide their detailed support/oppose comments in the "support" and "oppose" sections of a proposal and simply displayed the number of users commenting in each of those sections? Something like the headers in Gawker Media comments? Not saying we should do this; just wondering if there's more to the !votes section than, well, basically just a vote, and if discussion is really where all the important consensus-making happens. Maryana (WMF) (talk) 23:39, 30 September 2013 (UTC)[reply]
It depends. An RFA is pretty much a vote. Wiktionary is pretty much voting. In those discussions, a comment is about influencing other people's votes. On other pages, it's really the other way around: the analysis matters more than the !vote. User:Beeblebrox/The perfect policy proposal#Planning the RFC might be interesting reading. User:Beeblebrox could probably provide even more information. WhatamIdoing (talk) 00:42, 1 October 2013 (UTC)[reply]
Maryana, people organize RfCs in different ways. Sometimes, particularly with RfCs that you know won't attract much input, there's no need for a separate "survey" section. Where the RfC is likely to attract more attention, people add a separate survey section to make things easier for the closing editor or admin; I've closed a lot of RfCs and it's really difficult to pick out the main comment from each person, and just one from each, if the comments are only in a discussion section (where things get very repetitive). When the RfC is likely to be very large, people sometimes do add separate support/oppose sections and ask that the responses be numbered. That makes it more vote-like and easier to close.
Consensus matters a lot and so numbers do count; analysis counts only in the sense that the closing editor has to make sure that policy has been respected. So, for example, if 100 people vote for an umambiguous BLP violation and one against, the closing editor will (hopefully) close in favour of the latter. But where the policy issue could go either way, the numbers are obviously pivotal, and in those cases (and I think that is probably most cases), it does end up as a vote. SlimVirgin (talk) 00:55, 1 October 2013 (UTC)[reply]
SlimVirgin, WhatamIdoing, thanks, this is really helpful! As I said somewhere above, the Flow team won't be tackling complex consensus-building discussions like RfA, RfC, AfD, ArbCom, VPR, etc. for some time; one of the many reasons why we're planning to release on a page-by-page basis for now, not to entire namespaces. But when we do get to that bridge, I'll definitely be pestering you two for guidance/help :) Maryana (WMF) (talk) 01:10, 3 October 2013 (UTC)[reply]

Three levels of nesting

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

Comment

Reply
Reply to reply
Reply to reply to reply
Reply
Examples of products using this pattern
  1. Mailman
Pros/cons?

8-12 levels of nesting

(like the above, but even more nested!)

Comment

Reply
Reply to reply
Reply to reply to reply
Reply to reply
Reply to reply to reply
(outdent)

Reply

Reply
Examples of products using this pattern
  1. The Verge
  2. Reddit
  3. Wikipedia (effectively) after which people use {{outdent}}
  4. Quora
  5. Tumblr (3-5 is common, 11 is rare)
Pros/cons?
  • on a small screen, pretty much unreadable without a ton of work (clicking, scrolling, zooming, pinching), and all but impossible to add new comments
  • where do I respond (to the topic as a whole, to individual comments)? Maryana (WMF) (talk) 22:44, 26 September 2013 (UTC)[reply]
Why do we say that it is "all but impossible to add new comments"? New comments are added all the time on Wikipedia discussion pages. --Atethnekos (Discussion, Contributions) 19:07, 1 October 2013 (UTC)[reply]
I think that point was just in reference to small screens (particularly mobile), where deep indents (and particularly :*:: mixings) are harder to compose a reply to. Quiddity (WMF) (talk) 19:48, 1 October 2013 (UTC)[reply]
Yes, of course. Thanks. --Atethnekos (Discussion, Contributions) 19:52, 1 October 2013 (UTC)[reply]
Yep, if you've ever tried to edit a talk page on a phone, it's... well, not pretty. Even on a tablet, it's pretty painful and frustrating, and the number of users we have on tablets is steadily growing. Maryana (WMF) (talk) 00:04, 2 October 2013 (UTC)[reply]

30+ or more levels of nesting

Examples of products using this pattern
  1. Liquidthreads
  2. Thunderbird email subject lines
  3. Livejournal
Pros/cons?
  • yikes... Maryana (WMF) (talk) 22:44, 26 September 2013 (UTC)[reply]
  • Comment Writing as one who has never taken part in any of the above mentioned sites (and has no intention of joining any of them either...), I find it a bit hard to understand what is being talked about. I've seen the mock-ups of 'Flow', and can't see that it's any improvement over the current system. It only takes a moment to explain indenting to a newbie - and if they can't understand that, they're not going to make any sense of anything. If Flow works anything like as well as VE has, we're going to be in a mess. And not able to talk about it unless there is some sort of opt-out provided. That I can't see happening. It's going to be all or nothing. I get the feeling sometimes that there's a similarity to the highways departments that have to ban parking on a road to speed the traffic flow up, and then put speed humps in to slow the traffic down again. They have to be seen to be doing something in order to justify their existence. Peridon (talk) 07:45, 27 September 2013 (UTC)[reply]
    Well, frankly given the backlog of software improvements, if we were merely trying to justify our existence there's a ton of things we could be working on other than this - I would assume that you, like all of the users I speak to (me included!) have a ton of ideas for changes that would improve editing. I think there may be a point of confusion here, though; explaining indenting to new users, as you say, does not take very long - in principle. But then we have "when is it appropriate to outdent?" and "What do I do if I have multiple replies to multiple users?" and a ton of other awkward edge-cases that occur every day and aren't necessarily covered by "count the number of colons in the post you're replying to, then add one". Here, for example, it's asterisk, then asterisk colon, then asterisk colon colon, then.... and the same thing would happen if we had numbered rather than bullet-pointed entries. There are various different formats for discussions.
    For me the greater problem with talkpages and indenting - for new users and for existing users - has always been things like screen width and information density. Explaining indenting to new users - setting aside the edge cases - is easy. Reading the resulting talkpages, with comments offset from each other 8 or 9 times, can be an eye-ache that encourages people to (at best) skim-read discussions or simply not participate. The prime example here is tablets and phones, which don't deal well with horizontal scrolling and will need to horizontally scroll for more than a couple of levels of indenting, but I have the same problem on the laptop I'm using right now. Okeyes (WMF) (talk) 21:02, 28 September 2013 (UTC)[reply]
Nice to see a WMF representative admitting that indentation is not nearly hard enough to be a significant barrier. Can we put this point to the main page..? I think you'll have to agree that "Simultaneously, we know that freeform wikitext talk pages present a significant barrier to new users" overstates things and doesn't emphasise what you do.
Also, a discussion that is complex and long enough to have "comments offset from each other 8 or 9 times" is likely to be complex enough to get "people to (at best) skim-read discussions or simply not participate" by its length alone... Speaking of asterisks - I have deliberately used ":::" instead of "*::" in this post... Did you notice a difference until now..?
Anyway, perhaps the most important thing is that the tone you are using here is exactly what all WMF representatives should seek to imitate. There is nothing wrong with exploring different possibilities to improve the talk pages, as long as it is a truly free exploration that doesn't even rule out the answer "We have found nothing better than we had.". It is when we get the unreasonable hype of the product that doesn't even exist ("a great piece of open source software", "a kick-ass discussion system", "No edit conflicts, ever." and the like) that we start to "check for our wallet" (figuratively, of course). And such mistrust is not something you should strive to promote... So, thank you for the change of tone. --Martynas Patasius (talk) 00:12, 29 September 2013 (UTC)[reply]
Thanks! I think Maryana, Quiddity and others would agree with me that hype is not something we particularly want. We want to make the positives of this system clear, but there will be some negatives (no system is perfect for every user), and above all this early period is about experimenting, not setting in stone Precisely What Will Definitely Happen. We (the WMF and the community) don't have all the answers yet, be it as to what is technically possible or what is socially possible, and so it would be unfair of us to act as if we could see the future with perfect clarity.
One point of clarity would be that while I don't think teaching new users how to edit with indenting is necessarily the hardest thing in the world (although it does present some barrier, and there are lots of awkward edge-cases that raise that), a necessary skill for being able to reply to a thread is being able to read and understand it. High levels of indenting are sort of a problem there, since they make the page more difficult to comprehend - I had to pass over your post 2-3 times to fully get it, and I've been editing since 2006. So there is a barrier there, just an indirect one.
I think clarifying/expanding on "freeform wikitext" is probably worth doing, to prevent misunderstandings, although I don't see it as being analogous to "indenting" - more "indenting, and markup, and templates, and everything else". Do you have any thoughts on language, there? Quiddity, Maryana, your thoughts? Okeyes (WMF) (talk) 21:03, 29 September 2013 (UTC)[reply]
Regarding "freeform wikitext", the initial discoverability of all the systems seem to be the hard part - eg. all the newcomers who start new threads at the page top, or within an existing section (without a new header). All the difficulties with getting paragraph breaks to display properly (currently we mis-use the HTML definition list elements to create indents and paragraphs) with some people adding extra blank lines to create whitespace, and some people objecting per WP:LISTGAP, etc. The habit that some people have, of adding indents no matter who they're replying to, just to make the comment-separation clear.
Trying to explain any of these standards (even in person, with all the added ease that over-the-shoulder-teaching brings), to my friends and acquaintances who are less comfortable with computers (eg. the owner of a local antiquarian bookstore, who reads old books all day, and recently got online) is often frustrating.
I'm not sure how to condense that down into a brief sentence or two. Quiddity (WMF) (talk) 00:36, 1 October 2013 (UTC)[reply]
  • The question posed here is too broad. There is a plethora of different types of discussion here on just one language Wikipedia, and the level of appropriate indentation differs accordingly. Some discussion structures such as Arbitration Committee cases are highly complex with nested replies allowed in some sections but not in others; some are headed with multiple nested replies permitted, such as AFD or RFC; some are mainly unnested, while some are completely freeform. Perhaps the question could best be answered after having had sight of the taxonomy of discussion structures. Spectral sequence (talk) 15:56, 11 October 2013 (UTC)[reply]

Copy on interface elements

From Tryptofish (copied from above): "What is on my mind is a more cultural issue. It's not about how Flow would be put together, but more about the choice of words at the user interface, and about how to convey to new users the right, well, signals about how to work successfully on Wikipedia. It's not what you asked, in this case. One example would be where you and I previously discussed "nice". A more important instance would be choosing language that helps new users understand how WP:Consensus does and does not work, something I've raised in earlier talk threads about "talk" versus "discussion" versus "boards". I want to be careful not to mislead new users into thinking that Wikipedia is just like (fill in the blank, with whatever other website you wish), only to find subsequently that the community has certain cultural expectations that differentiate constructive editing from disruptive editing. TL;DR: Wikipedia ain't Facebook." --Tryptofish (talk) 23:10, 26 September 2013 (UTC)[reply]

Yes, copy is something we'll have to work out (we haven't really settled on a shared lexicon even within the team). However, it's also one of the easiest thing to change, so there's low cost to trying out new stuff and seeing what effect it has :)
This isn't something I'm too worried about for the first release – simply because brand-new users are very unlikely to stumble into a WikiProject discussion space (non-article namespaces are pretty well hidden; usually, newbies who join WikiProjects have been explicitly invited by someone because it looks like they're already doing good work), but it'll definitely be something to consider extremely carefully by the time we start tackling user and article talk.
To be fair, though, the terminology is already really muddled and confusing on Wikipedia – some things say talk, some things say discussion, and some discussion pages have giant "this is not a discussion!!!" disclaimers prominently tacked to the top... I like this quote from the Usability Initiative user studies: "when viewing discussion pages participants felt quite confident about what type of content and discussion was appropriate, until they encountered the most noticeable text on the page stating "this is not a forum," after which the doubts started to roll in." Maryana (WMF) (talk) 23:39, 26 September 2013 (UTC)[reply]
Yes, I agree with you about all of that. It's something that should be pretty easy to deal with later on, and it has to be done language-by-language anyway. That's another good reason to roll it out incrementally. --Tryptofish (talk) 00:31, 27 September 2013 (UTC)[reply]
Indeedy, and I'm glad to see that's our game plan :). Fwiw, even inside the WMF we're aware of these being placeholders and that they're inadequate for any wider release - I, personally, found the copy very confusing. Okeyes (WMF) (talk) 21:03, 28 September 2013 (UTC)[reply]
On the general problem, the options are basically these:
  1. We can invent totally new words that leave the new users completely befuddled, or
  2. we can use words that will (mis)lead some users into believing that Wikipedia is just like (fill in the blank with any other website that happens to use the same words).
I'm voting for #2. No matter what word we choose, some other website out there will be using the same one, and some user is going to use that website. The evils of educating editors about the difference between a "Wikipedia chat" and a "chat" as implemented on some other website (or whatever words get chosen) are far less than telling editors to pdhgaodn a maoighaoih on my tasdghkasldk whenever they want to tell me something. WhatamIdoing (talk) 00:10, 1 October 2013 (UTC)[reply]
Perhaps I didn't make sufficiently clear what I meant. I'm in favor of #3: We can carefully choose some new words, so as to minimize the extent to which we mislead new users in counterproductive ways, while retaining existing terminology when it has a track record of serving Wikipedia well. Wikipedia is primarily about building an encyclopedia, as opposed to, for example, being primarily about what somebody had for breakfast. --Tryptofish (talk) 00:18, 1 October 2013 (UTC)[reply]
Indeed; I'd argue the existing copy is not fit for purpose (or, for our purposes, at least) - again, this is internally a known. We need to pick language, as Tryptofish says, that balances the positives of referencing a common internal lexicon with the negatives of obfuscating what we actually mean to outsiders. When we get further towards something we can deploy on a sandbox (we finally got the first, full, experimental design today), there will be many opportunities to tweak the text one way or the other. Okeyes (WMF) (talk) 00:22, 1 October 2013 (UTC)[reply]
Tryptofish, That still leaves us with the basic problem: new word == nobody knows what it means.
You can carefully pick some old words, but every possible old word is going to be used by some other website somewhere, in a way that does not create a good association for some users. There are only 400,000 to 1.2 M words in the English language (depending on how you count), and there are hundreds of millions of websites. WhatamIdoing (talk) 00:51, 1 October 2013 (UTC)[reply]
We probably agree more than it sounds like. I suggest that we stop discussing it in the abstract sense, and instead look in terms of specifics. A specific example where I have commented before (now archived) is in terms of "talk" or "discussion" being better than "board", even though "board" is a term used internally by the developers. I don't mean to say that we should never use a term if the term has ever been used by another website, and I agree with you that doing that would be impossible! --Tryptofish (talk) 01:18, 1 October 2013 (UTC)[reply]
PS: When I talked about choosing new words, I meant words that were new to Wikipedia, and that we should do so carefully, not carelessly. --Tryptofish (talk) 01:21, 1 October 2013 (UTC)[reply]
The reported problem with "talk" is that new editors don't get it. It sounds like a live chat room, rather than a repository for messages. The problem with "discussion" in this context is that the discussion is the thing you put on the "board", rather than the "board" itself (discussion vs discussion page). I don't like "wall", which sounds casual. "Corkboard" or "chalkboard" or "whiteboard" aren't any more descriptive than just plain "board". We already have noticeboards.
"User message center" (and "article message center", etc.) might be descriptive, but I can't really imagine anybody using something so long in everyday speech. "Message board" might be okay, but people would just call it a plain board anyway. What other alternatives have you considered? WhatamIdoing (talk) 02:16, 1 October 2013 (UTC)[reply]
This sounds like a conversation we should have with more participants slightly later down the road. Terms like this can be (and regularly are!) wiki-specific. At the moment the UI for the first release exists as an SVG; we have some time to make this decision, and should do so with as many participants as is possible :). Okeyes (WMF) (talk) 16:19, 1 October 2013 (UTC)[reply]
I agree with you fully about that (having a discussion with much broader participation later on, and no hurry), and I think that's what I have been saying all along. At this point, I'm really not sure what WhatamIdoing is trying to accomplish in this discussion, but you can confidently expect that, when the time comes, I'll be speaking strongly against any terminology that sounds un-serious with respect to our existing procedures for consensus-building. --Tryptofish (talk) 18:33, 1 October 2013 (UTC)[reply]
I'm trying to get a head start on compiling the list of possible words. There aren't that many options, if you're planning to use existing English words. I came up with eight, but I doubt that we'll find twenty options.
I agree about avoiding "un-serious" words, but the response rates to banners (the one with the cute/non-serious cartoon mascot on it got a lot more people to click through to the discussion) might suggest that what's "obviously correct" to me may not actually be the most effective. WhatamIdoing (talk) 22:54, 1 October 2013 (UTC)[reply]

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
"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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
I thought I would respond here partially to the comments at [29], 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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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? Monty845 00:00, 4 October 2013 (UTC)[reply]
    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)[reply]
    Now here - if I got bits wrong, be bold :). Okeyes (WMF) (talk) 00:14, 4 October 2013 (UTC)[reply]
    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) Monty845 05:01, 4 October 2013 (UTC)[reply]
    Good point; amended as such :). Okeyes (WMF) (talk) 18:02, 4 October 2013 (UTC)[reply]

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

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. Monty845 05:04, 4 October 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
If you have never noticed problems like these: [30] [31] [32] [33] [34] [35] [36] then we obviously do not have the same watchlist. WhatamIdoing (talk) 23:32, 5 October 2013 (UTC)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

Fix edit-conflicts to allow editing other user comments

Indeed, the "elephant in the room" is the crucial need to redact or strike-out comments by others, in any message. If FLOW prevents edits to other's comments, then it becomes "Bride of VE" avoided by 97% of users. Compare to a forum, where a moderator pre-screens each post, to remove insults or deny the whole message if seeming to be a veiled insult (gibberish), and forum messages can be delayed for minutes/hours as moderators pre-screen the messages. Instead, a wiki benefits by quick semi-censored messages (limited by edit-filters), in rapid dialogues, with the safety net to redact insults, or strike updated words, by editing any user message. Hence, the whole system returns to the need to fix wp:edit-conflicts, such as by stacking multiple replies (at the same line) into LIFO order ("last-in, first-out"), which is also needed in articles with multiple insertions in a list. The diff3.c utility can auto-merge any updates separated by one line (even a blank line), but I think it can be set to allow zero-line separation (to merge adjacent-line edits). However, upgrading diff3.c to auto-stack multiple replies will be more complex, and multiple deletions at the same line will need to be auto-unstacked in reverse. Plus, if the 1st editor deletes a line, and the 2nd editor changes that same [deleted] line, then the line should re-appear as changed by the 2nd editor. Beware how some edit-conflicts could be quite complex to auto-merge, but the good news is that the vast majority of current edit-conficts (98%?) can be avoided by simple auto-merge at adjacent lines, plus combining non-overlapped edits to the same lines, then auto-stacking multiple replies, or auto-unstacking multiple deletes. To simplify auto-merging of same-line edits, then long lines (paragraphs) could be, internally, auto-split into 50-byte sections and treated as adjacent-line editing already supported by diff3.c, then auto-join the auto-split lines (back into paragraph lines) before saving the revision. Fixing of edit-conflicts might seem like a special one-trick pony of part-time work; however, auto-merging could become an impressive feature of Wikimedia by extending to auto-merge text inside paragraphs which have been moved, by developing a "weave merge" algorithm to assign internal line numbers which move when the paragraphs move, and then updating the moved words according to old internal line number. Bottom line: fixing edit-conflicts is essential to busy articles or talk-pages, and could become an impressive specialty for a long-term programming assignment. I think it should be quite clear by now, that the fixing of edit-conflicts by auto-merging is "elementary, my dear Watson". You do the math, it adds up the same every time. There is simply no alternative. None. Edit-conflicts should be fixed for busy articles or talk-pages. -Wikid77 (talk) 11:17, 2 October 2013 (UTC)[reply]

I'm confused; did you not read the above message that stated oversight, revision-delete and rollback-equivalent functions were all available? I've been editing since 2006; in that time I recall maybe twice seeing comments with problematic content of the type you mention being partly redacted, as opposed to being entirely removed or struck-through - both being situations Flow will handle from the get-go.
I get that fixing edit conflicts is clearly important to you, Wikid, and I think it's a laudable goal. But making edit conflicts an impossible occurrence is not the focus of this software at the moment, and I doubt it will be - that's a different project for a different time. If you want to argue for it as a strategic priority, I'd highly recommend approaching people in Platform or management to make it happen (and will happily provide names/usernames/email addresses to enable that), but it's not something that can be funded, defunded or productively discussed here. I'd prefer if we talked through the pros and cons of Flow's implementation rather than focusing on features that are, while important, not the stated desired outcome for this project. It'll be more productive, and doesn't deny your ability to have your say in front of people who, unlike us, can make the decisions you're looking for :). Okeyes (WMF) (talk) 16:25, 2 October 2013 (UTC)[reply]
The partial redacting of improper comments is very common in talk-pages of wp:BLP bio pages, where some editors think it is fine to quote the bartender said the man victimized many girls in the bar, versus police questioned the man about his actions regarding the girls. However, it is also common, in controversial topics, to insert "[citation needed]" near a prior editor's unproven remarks (altering their text but by superscript notes). Also, to completely revert a comment which contains an insult would complicate trying to discuss the message, which would be better understood if the insulting phrases were redacted while the bulk of the comment and signature+time remained on the talk-page. -Wikid77 (talk) 01:04, 3 October 2013 (UTC)[reply]
Please note that my comments below address technical aspects of auto-merging. I agree with Okeyes that auto-merging is not needed for Flow. Think of the following as an expansion on that, arguing that auto-merge is not only not needed, but is also very difficult to do.
While eliminating edit conflicts is impossible, making them rare is quite doable and very desirable. I am pretty sure that most of what you describe above can be accomplished by only bringing one paragraph into the edit window by default, with an option to edit the entire comment. This would be similar to how the current system allows you to edit one section or the entire page. I am also pretty sure that Flow as currently described already accomplishes this and more.
Auto-merge routines usually work fine, except when they don't. For example;
Editor one posts this:
METHOD FOR DISCOURAGING TELEMARKETERS
Mix uranium hexafluoride with a suitable carrier gas (noble gas, hydrogen, and methane).
Prepare a large quantity of uranium hexafluoride.
Use your molecular laser isotope separator to create Uranium-235 (see operator's manual)
Gather a large quantity of U-235 and insert into your neutron reflector.
Insert timed trigger device, mail to telemarketer.
Note: in the "gather a large quantity of U-235" step above, do not exceed critical mass or it will explode.
Editor two modifies it like this this:
METHOD FOR DISCOURAGING TELEMARKETERS
Prepare a large quantity of uranium hexafluoride.
Mix uranium hexafluoride with a suitable carrier gas (noble gas, hydrogen, and methane).
Use your molecular laser isotope separator to create Uranium-235 (see operator's manual)
Gather a large quantity of uranium-235 and insert into your neutron reflector.
Insert timed trigger device, mail to telemarketer.
Note: in the "gather a large quantity of uranium-235" step above, do not exceed critical mass or it will explode.
At the same time, editor three modifies it like this this:
METHOD FOR DISCOURAGING TELEMARKETERS
Note: in the "gather a large quantity of U235" step below, do not exceed critical mass or it will explode.
Mix uranium hexafluoride with a suitable carrier gas (noble gas, hydrogen, and methane).
Prepare a large quantity of uranium hexafluoride.
Use your molecular laser isotope separator to create Uranium-235 (see operator's manual)
Gather a large quantity of U235 and insert into your neutron reflector.
Insert timed trigger device, mail to telemarketer.
In the above example, it is nearly impossible for an auto-merge program to merge the edits from editor two and three. Not quite as hard but still quite difficult is having the auto-merge program correctly identify which edits it cannot handle.
"There is simply no alternative. None" is, quite frankly, laughable. There are other ways of reducing edit conflicts. Assuming the present system as a starting point, simply telling the editor "you are making too many changes too fast. Please wait five minutes before making another edit. Note: you can still revert your own edit immediately" would go a long way towards reducing edit conflicts. That way you get, at most, 30 edits per hour. It would also make it so that Wikipedia:Avoiding edit-conflicts#Using re-edits method always works. Another interesting idea is a hybrid between the prevent-from-saving-edit method and the prevent-from-starting-edit (lock) method. Tell the editor "another editor is editing this paragraph. Please wait two minutes before opening edit window". --Guy Macon (talk) 17:25, 2 October 2013 (UTC)[reply]
  • All edit-conflicts can be "fixed" by overwrite: Remember, the illusion of unfixable edit-conflicts can be refuted by simply overwriting the first user's text by the 2nd user. However, the nuanced approach tries to auto-merge as much as possible between 2 editors, yet the example above would likely be resolved by overwrite of the 1st edit by the 2nd. Another tactic would be to alter the "difference bracket" to see if a re-sync occurred better when more lines were included in the bracket. Currently, Wikipedia requires entire lines to match as a resync line, rather than matching by same prefix-or-suffix text. Anyway, there are many "tricks" which make auto-merging much easier than it might seem. Now, when I said, "There is simply no alternative" then I was referring to pretending that edit-conflicts would disappear by the alternative to prevent editing of remarks, and that is the alternative I meant was not workable, such as totally reverting messages to seem as though other people were not in a conversation, or had not posted a "!vote" in a survey. Users will soon ditch FLOW because they cannot be reverting all troublesome messages for one improper phrase. -Wikid77 (talk) 01:04, 3 October 2013 (UTC)[reply]
Now you are just being silly. There is still an edit conflict. You are just changing the way the system fails to complete one of the edits. That fixes nothing. --Guy Macon (talk) 03:10, 3 October 2013 (UTC)[reply]
I'm not entirely sure why users would reject Flow for merely substantially reducing an issue that occurs with talkpages already, rather than removing the issue entirely. If you want to discuss Flow proper (including comment editing), this is the place - if edit conflicts are your thing, again, I can point you to the people who can have conversations about this and make decisions - but you're unlikely to find time spent discussing it here productive. Our focus is on the software rather than a feature that falls largely outside it. Okeyes (WMF) (talk) 05:23, 3 October 2013 (UTC)[reply]

Down The Rabbit Hole Once Again

In response to Kww asking

"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"[37],

Okeyes (WMF) asked

"I'm not sure where the configuration thing is coming from - who made the statement that it would be done like that?"[38]

Threads where this was discussed and decided:
Wikipedia talk:Flow/Archive 3#Request for Comment on editing other user's comments with Flow
Wikipedia talk:Flow/Archive 2#Implementing the results of the RfC
Wikipedia talk:Flow/Archive 2#I can call spirits from the vasty deep

Specific posts where someone from WMF confirmed that it was decided:
22:09, 15 August 2013
22:58, 15 August 2013

My comments at the time: (note that NOBODY replied by disagreeing with the fact that it was decided):
11:39, 16 August 2013
10:27, 17 August 2013

It appears that we still have a communication problem.

We all agreed that the privilege required to edit comments would be configurable on a per-wiki basis. We had a WMF developer specifically confirm that the privilege required to edit comments would be configurable on a per-wiki basis.

Then my repeated requests to have someone from WMF update Wikipedia:Flow to reflect this decision ran into fierce opposition (and before someone says "fix it yourself", first you have to make it so that when I call spirits from the vasty deep add something to Wikipedia:Flow flow WMF is required to obey me).

And now once again I am replying to someone at WMF who appears to not be aware of what we decided.

I have said this before and been ignored, but the solution to this is dead simple.

Pick a page (Wikipedia:Flow would be a good choice) that documents, in broad strokes, WMF's current understanding about what Flow is. It will have some "we haven't decided yet" and "we don't know yet" entries, but it will also contain what we know we are going to do (autosigning posts, for example). This document should be kept short; broad strokes, not TL:DR detailed documentation.

When we decide something here on this talk page, update the page to reflect that decision. That edit will then be considered to be a promise/commitment. If the plans change, go back and update the page and post a message on the talk page. Something like "Remember that autosigning thing we agreed on? Looks like that is going to change because of...".

Every so often, key members of the Flow team should look the page over and make sure we don't have something in there that they will object to later.

I have no idea why the above idea is meeting with so much resistance. --Guy Macon (talk) 11:51, 3 October 2013 (UTC)[reply]

I wasn't aware it was meeting with any resistance - I hadn't seen it before :). Personally I think it's a fine idea - Quiddity, Maryana?
I wouldn't say we have a comms issue so much as the legacy of previous comms issues; see my comment above about the initial disorganisation as all the pieces got into play. Okeyes (WMF) (talk) 16:45, 3 October 2013 (UTC)[reply]
Not so much a communications issue so much as the legacy of previous communications issues... Yes I think that is a fair assessment. You have an extremely competent team there; Jorm (WMF) in particular is clearly technically brilliant. Maryana (WMF) in particular is really patient and helpful, even when dealing with the fact that some folks on this end have a chip on their shoulder. I am not going to name everyone, but you have a great team. You are striving towards the correct goals; clearly everyone on the WMF side is deeply committed to creating something great and fixing the known problems in the creaky old system we are using now. Even though I have some issues with our communication, I don't want anyone to lose sight of the good side.
As for the resistance, you can see it in the "I can call spirits from the vasty deep" thread. No matter how many times I asked, it never happened, and I finally gave up. This really is easily fixable. All we need is a single page at Wikipedia:Flow that describes in broad strokes WMF's current understanding about what Flow is and a commitment to keep that page updated as the project evolves. I am looking forward to seeing that. --Guy Macon (talk) 17:42, 3 October 2013 (UTC)[reply]
Re: Docs - Yup, updates are needed, and should be coming continuously and piecemeal over the next few days/weeks/months.
Re: editing other people's comments - I (as a volunteer) commented in the RfC, for the "restrict it to autoconfirmed" option, and I still believe that to be the most productive future option. And I do grok that a majority of the RfC respondents want to keep things exactly as they are now (unrestricted editing by anons, of anyones comments). However, I do also believe that this first release of Flow is a good opportunity to test and experiment with various fundamental options/assumptions that we have, like this one, at little cost, given the potential benefits. I'm curious as to whether there will be any noticeable improvements, or problems, with changing things like this.
Re: "Why and How often do I/we edit other people's comments" (the initial question that the staff really want feedback on) - I fix links about once a week (eg. [39], [40]), I remove personal attacks about once every 6 months (eg. oldid 573194736), and I make pedantic changes erratically if I'm well-acquainted with the editor (eg. [41] yesterday!). Quiddity (WMF) (talk) 19:18, 3 October 2013 (UTC)[reply]
Guy; thanks! I agree, this needs to come - I think Maryana and I are going to work with Quiddity on fleshing this out over the coming days and weeks, as he says, and hopefully will draft it in a transparent location. Okeyes (WMF) (talk) 19:25, 3 October 2013 (UTC)[reply]
A note: this mingle ticket may gladden your heart on that front. Okeyes (WMF) (talk) 22:51, 3 October 2013 (UTC)[reply]
I strongly, strongly, strongly object to the concept that it's a good time to "test and experiment" with not implementing things that you've already agreed to implement. It's never a good time to experiment with not doing what you said you will do.—Kww(talk) 22:17, 3 October 2013 (UTC)[reply]
I don't think we said we'd implement anything. If you mean Brandon's comment, Brandon does not lead on Flow as a product - Maryana does. As explained above, the initial...I guess, hype, around Flow, was when the project was at the stage where we didn't have anyone assigned to say "no" and bridge the gap between the ideal product (from your point of view, or our point of view, or a new user's point of view) and what could practically be achieved. Statements made back then about what Flow will or will not have as a feature should not be relied on, because the actual answer to most of them is "we don't know yet, let's play around with some ideas and find out what works the best". We're currently writing up a document, at Guy's suggestion, that sets out the status of various tasks - that, not promises made before the team was up and running, should be taken as definitive. I appreciate it's an annoying thing, but I think we can all agree we'd rather have a consistent pattern of interaction from hereonin than put our money where our mouths are for every single feature (good or bad) promised, regardless of whether that feature is a good idea. I'm sure if we were talking about something you dislike that had been stated to be an utter certainty, you wouldn't be so keen to demand that we implement them as promised - and those things are being experimented with and tested just as much as the bits you (or I) like. Okeyes (WMF) (talk) 22:51, 3 October 2013 (UTC)[reply]
I can't believe that you have any doubts as to why the WMF is viewed as untrustworthy. There's no technical reason for you to refuse to make this available as a configurable option on a per wiki basis. The WMF doesn't set policy for any Wikipedia versions, and that's what refusing to do this is effectively doing. Making it configurable makes WMF neutral on the policy question. Maryana's objections listed above are not technical: they essentially amount to her personal objection to a long-standing capability. Flow's task is to make a platform which each community can tailor to its needs, not to make each community conform to WMF's wishes.—Kww(talk) 23:03, 3 October 2013 (UTC)[reply]
I don't think I said anything about the WMF's trustworthiness or lack thereof - I certainly get that you see the WMF as untrustworthy, sure. Setting it on a per-wiki basis is, again, something we can discuss and use if there are fundamental use cases for having that feature available, but I disagree that it would make the WMF neutral on the system. The people deciding what that configuration is would consist exclusively of people not weirded out by the system, since people weirded out by systems tend to stop contributing to it, so it's going to be very self-selecting. That's not really neutrality ;). I'd underscore here that I am not saying we won't do it, just that it would be silly for us to immediately jump on the first option we see (be that "no comment editing" or "all comment editing" or "[blank] comment editing" without evaluating the alternatives, particularly when switching from one to the other is, as I understand it, relatively trivial technically. Okeyes (WMF) (talk) 23:11, 3 October 2013 (UTC)[reply]
Making it non-configurable is basically saying that WMF, and only WMF, will be able to decide the best way to use it, and whatever it decides will be forced upon every community. That's the essence of that "master/slave" relationship you mention in the discussion below.—Kww(talk) 23:19, 3 October 2013 (UTC)[reply]
Sure, except again, we're not saying it won't be configurable, we're saying we want to experiment with different models and see if there are good reasons to allow for it. If you care about making it configurable, write out use cases for comment-editing-of-others that aren't covered by the existing list: that's what I'm spending my afternoon doing. Okeyes (WMF) (talk) 23:27, 3 October 2013 (UTC)[reply]
I think I'm missing something here.
Did anyone (Maryana, in particular) ever say that this was going to be hardcoded? "Hard coded", as I understand it, means "if you want to change this, you have to get someone with commit access to go into the original source code and re-type something". I thought it was pretty well established that hardcoding something like this was, from technical standpoint, an inelegant and needlessly cumbersome approach and wasn't going to happen. I haven't noticed a single statement from anyone working on this project (a list that does not include me, BTW) that says the userright will be hardcoded.
What I'm hearing above is that it will be configurable and that—as proof of this—there is a desire by the staff to test different configurations. Now, I may be wrong, but it seems to me that it is not actually possible to "test different configurations" unless "the software is configurable" somehow. If someone's got a different understanding of those words, please let me know.
Kww, perhaps you could clarify this: Are you requesting that this be "configurable per project", or are you requesting that this be "configurable per project by any volunteer admin"? Those are not the same thing. WhatamIdoing (talk) 00:26, 4 October 2013 (UTC)[reply]
This last point should be among the scenarios tested (or rather something similar to how the Sichterrecht is currently handled on de.wikipedia). Technically, as far as I understand, it will be easy to configure, the question is, as has been noted, one of policy. At the moment we (or whoever will have the last call on this) have insufficient data to make an informed decision. Will restricting the userright in question to admins (or some other privileged group of users) destroy some useful (but maybe rare) workflows? Will something awful happen if we give this right to everybody? As a result of the experiments we should have some indications as to what is a good recommended/default setting for this userright and some ideas on how strong an argument must be made to restrict or extend this right to groups of users. --HHill (talk) 08:31, 4 October 2013 (UTC)[reply]
As I've read the discussion (and the responses from WMF staff seem to confirm), current thoughts are to experiment during deployment and then have WMF decide. My view is that it needs to be configurable per project at a minimum. There aren't many wiki-wide settings that are configurable by any admin, but yes, I think that should be the target, I certainly hope that the lesson WMF learned from recent events was "we need to make our software deliveries be of sufficiently high quality that they don't damage projects", not "we have to take steps to make sure people can't configure things." —Kww(talk) 14:00, 4 October 2013 (UTC)[reply]
If we weren't interested in factoring in community opinions and making software as good as it can be (or, at least, as least-bad as it can be - we can't make software that is all things to all people), we wouldn't be having this conversation. We want to experiment during deployment and then gather feedback to find out if there were substantive problems, as well as looking for substantive problems ourselves: if you want to help with this, provide use cases, as HHill is doing (something I am very grateful for). Demanding we make things configurable on a per-wiki basis and examine no other solutions is not something we're going to follow, and I'm just going to disengage from any statement demanding it. Okeyes (WMF) (talk) 17:29, 4 October 2013 (UTC)[reply]
Okeyes (WMF): I hope we can have a discussion about one aspect: what would be the criteria for justifying having the WMF lock any configuration options away from community consensus? That's what I'm having a difficult time with here. You seem to perceive me as demanding some particular configuration, when what's being requested is only that WMF not choose some particular configuration. What kind of results would you need to see that would make you decide that one and only one configuration was best for everyone? Incidentally, the insistence that meaningful contributions can only be made by writing use cases is pretty limiting: this is a wider ranging discussion than simply "Sally makes a personal attack in an otherwise meaningful contribution, and an admin removes the attack". This discussion is "What hurdle does the WMF have to overcome to insist that a configuration be controlled by them?" and "What hurdle does a community have to overcome to obtain local control over a configuration?"—Kww(talk) 17:49, 4 October 2013 (UTC)[reply]
That wider conversation sounds, frankly, wider than Flow :). If you're asking about Flow-specific configurations, ask Maryana; she's the product owner here, and I wouldn't pretend to being able to speak for someone other than myself. If you're asking about configuration variables generally, that's not something any of us can usefully answer. Okeyes (WMF) (talk) 18:05, 4 October 2013 (UTC)[reply]
OK, Maryana: can you address that issue at least as it pertains to Flow? What hurdle does the WMF have to overcome in order to lock a configuration option in place?—Kww(talk) 18:19, 4 October 2013 (UTC)[reply]
Your comment below really didn't engage this issue, Maryana. It really was two simple questions:
  1. "What hurdle does the WMF have to overcome to insist that a configuration option be controlled by them?"
  2. "What hurdle does a community have to overcome to obtain local control over a configuration option?"
—Kww(talk) 20:49, 4 October 2013 (UTC)[reply]
Please, let's gat back to the real issue. The question is not about editing comments of others. It is about collaboration! Writing texts together. It is about everything a wiki is, Wikipedia is. We need the ability to collaborate on texts "behind the scene", where currently the talk page is. If Flow is to replace the talk page (user or article talk), we will lose this shared space, as it will be supplanted by individual snippets. Dear WMF devs: talk pages are about more than just forum discussions, they provide a space for discussions, drafts, experiments and learning. And we need each and every function of article space there too, in order to work there. Unless Flow does all that, Flow is not the answer to our needs. Please abandon it now, before you spend even more time and money on a dead horse. rgds --h-stt !? 14:32, 4 October 2013 (UTC)[reply]
I agree: we need all of those things. One thing we're talking about, which needs more fleshing out (but was mentioned above, I think?) is the idea of a scratchpad, a la a current wikipage or an etherpad, that can be used for those kind of things. The problem with that is that it's a component that is some way in the future, and we can't really deploy widely without it. Okeyes (WMF) (talk) 17:29, 4 October 2013 (UTC)[reply]
  • Comment: It looks like people are missing some of the key points in the Community engagement document, so I'll just copy the main one here, so you can't claim to have missed it:

The first release is a "sandbox" release, in which the set of features that we've identified as the minimum viable product will be put on a test wiki (ee-flow.wmflabs.org). (...) At the end of this process, we'll discuss with community members whether the first release of Flow is ready to be piloted on a WikiProject discussion space, or whether there are still outstanding issues that need to be fixed before it goes live. Ultimately, it'll be up to WikiProject members to make the call.

(emphasis added for added emphasis).

E.g., it'll be up to WikiProject users to decide whether they want to trial Flow in their discussion spaces. If any of the features is a complete non-starter for them, we'll change the features before we release. And after we release the trial (again, just to the specific pages where users have agreed to test them), and users decide they need changes to behavior, we'll change it. Absolutely nothing in Flow is set in stone. I keep repeating this; why do I get the feeling nobody's listening? :) Maryana (WMF) (talk) 18:42, 4 October 2013 (UTC)[reply]

Maryana, just to be clear, when you talk about WikiProject discussion space, do you mean talk pages used by WikiProjects, such as Wikipedia talk:WikiProject Military history? Or do you mean the article talk pages that certain WikiProjects have tagged? SlimVirgin (talk) 23:26, 4 October 2013 (UTC)[reply]
The former, so in practise we're talking literally two talkpages. I think that's a pretty decent testing environment, and good for minimising disruption - it also means that the barrier that needs to be overcome for features to be complete non-starters is pretty low. Okeyes (WMF) (talk) 16:58, 7 October 2013 (UTC)[reply]

I'm just starting to look at Flow, and it seems to be VE revisited... To start with this specific section, the page (and Okeyes above) currently states: "For the first release, we're focusing on the WikiProject discussion space." Then why is the FAQ[42] stating: "In the first phase, we are only looking at User talk pages for deployment. Conversations on Wikimedia projects are very complex things. We need to start with the "simplest" use cases first. We'll then take what we learn from this and apply it to the more complicated discussions going forward." Please make sure that your documentation is a bit consistent. Fram (talk) 14:03, 8 October 2013 (UTC)[reply]

Thanks; feel free, in future cases, to WP:BOLDly update it yourself (although not too BOLDly, obviously). We're a small team (on the community side there's 3 of us), so things will slip through the cracks occasionally. Okeyes (WMF) (talk) 17:22, 8 October 2013 (UTC)[reply]
Note that the enwiki FAQ (which I suspect most people will go to) does have the correct content - thanks, Quiddity. Okeyes (WMF) (talk) 17:23, 8 October 2013 (UTC)[reply]

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
--Tryptofish (talk) 21:04, 4 October 2013 (UTC)[reply]
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)[reply]
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)[reply]

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

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

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
That makes sense; thanks. Okeyes (WMF) (talk) 17:20, 8 October 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@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)[reply]
"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)[reply]
@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)[reply]
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)[reply]
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)[reply]
Well I guess we'll have to see how it works out. 138.162.8.59 (talk) 20:35, 10 October 2013 (UTC)[reply]
(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)[reply]
Better? More improvement suggestions welcome; it's a wiki! :) Maryana (WMF) (talk) 20:52, 10 October 2013 (UTC)[reply]
Thanks. I'm off to bed, will take a look tomorrow! Fram (talk) 20:55, 10 October 2013 (UTC)[reply]
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)[reply]
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)[reply]
"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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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"." ([43] - 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.".[reply]

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 ([44]) 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." ([45]) - 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)[reply]

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

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)[reply]
I see. That's ... ambitious. Is there pre-existing research and development to build on? Spectral sequence (talk) 21:14, 11 October 2013 (UTC)[reply]
Into things like what the workflows are, or what capabilities the workflow system will need? Okeyes (WMF) (talk) 21:37, 11 October 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
Thank you for clarifying that. Spectral sequence (talk) 21:14, 14 October 2013 (UTC)[reply]
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." ([46] - by "Maryana (WMF)", 23:05, 3 October 2013 (UTC))..? And now those same "community members" are actually expected to develop the software..? Really..?[reply]
And "wikitext" elements like colons supposedly "are a barrier to participation for new users and provide a bad user experience for many existing users" ([47]), 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)[reply]
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)[reply]
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 ([48])..? --Martynas Patasius (talk) 19:42, 14 October 2013 (UTC)[reply]
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)[reply]
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)[reply]

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

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

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

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

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

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

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

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

Would it be feasible to provide each Flow with a "watchlist" so that new discussions, or discussions with new comments, are highlighted. Possibly in a table of some kind? At the top? With contents? Spectral sequence (talk) 09:35, 11 October 2013 (UTC)[reply]
As I understand the design, Notifications take care of highlighting new content. Though that only solves the case of being updated of new additions, but sometimes you also want to review old content; Wikipedia talk pages have high archival value, being often referenced and consulted either to find unresolved requests for the page or discussions where some particular consensus was achieved. The Flow structure doesn't seem at all adequate to support those use cases, as the only tool to dig into the past are permalinks to specific topics (not to the whole ordered page contents at a particular time) and maybe keyword search. Diego (talk) 09:49, 11 October 2013 (UTC)[reply]
Diego Moya, I added your comment to Wikipedia talk:Flow/Design FAQ – we're trying to keep design-related discussions mostly on that page, and reserve this one for general questions/discussion about Flow features/strategy/rollout, etc. (it's totally okay to have some overlap, but I think it helps to have a separate page where we can get into the nitty-gritty implementation detail discussions). Maryana (WMF) (talk) 19:08, 11 October 2013 (UTC)[reply]
I'm curious, how do you classify and separate between design and discussion of functions? For me, having a table of contents is a feature / required functionality. A design discussion would be how to style that table of contents when available, how many items to show, which controls, etc. Diego (talk) 21:54, 11 October 2013 (UTC)[reply]
Not speaking for the team, but: I'd classify that as design in the sense that functionality is "the ability to do a thing" versus "how that thing is implemented". So "a heuristic for deciding what I should/should not have to pay attention to" is a feature/functionality. "Oh, we can use a TOC for that" is a design thing. Okeyes (WMF) (talk) 23:01, 11 October 2013 (UTC)[reply]
I probably would've posted it here, thinking of it as a "feature" not an "aesthetics" aspect, but it's an abstract/subjective distinction, depending on definitions/interpretations. Huzzah for confusing/complex language! Quiddity (WMF) (talk) 06:50, 12 October 2013 (UTC)[reply]
In such case, wouldn't "being able to communicate with others" be the only "feature", with everything else counting as "design"..? --Martynas Patasius (talk) 19:36, 13 October 2013 (UTC)[reply]
The features aren't just "being able to communicate". People also use talk pages to:
  • Check whether an issue has already been discussed and decided
  • Understand the background to a long-running discussion
  • Look for links to a specific article or source
  • Research the arguments made in the past by key participants
  • Prove that they predicted a problem years before anyone else did
  • Hunt for long-forgotten statements they hope will discredit potential admin candidates, WMF liaisons, etc.
Give such a wide range of uses I wonder whether we're paying sufficient attention to the volume of data on talk pages. For example, imagine the last nine years of Village pump (technical) ported to Flow. There's the current page with 42 topics on it, plus 168 archived pages (A–AX plus 1–118) with (average) 108 topics per page. That's over 18,000 topics. If that was presented as a "table of contents" on my screen it would be 438,000 pixels high, which is over 300 feet at 120dpi. There's no way a TOC can cope with that. - Pointillist (talk) 21:52, 14 October 2013 (UTC) Oh, by the way, if you're thinking that user talk pages don't attract many topics, check out User Talk for Iridescent, SandyGeorgia, Newyorkbrad, Eric Corbett, DGG, and Jimbo Wales. - Pointillist (talk) 22:07, 14 October 2013 (UTC)[reply]
Good point. It raises the question of what the unit of presentation would be for a Flow structured discussion. That applies both to the table of contents and also for the results of searches. Spectral sequence (talk) 20:40, 15 October 2013 (UTC)[reply]

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

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

At least you can reply to the main comment -- I can't. It allows me to enter a reply, but nothing happens when I click the green Reply button. Similarly I can't add a new topic. And yet strangely I can change the title someone else has given to a discussion. That seems odd. Spectral sequence (talk) 16:22, 11 October 2013 (UTC)[reply]
The hazards of watching development work happen in real time :) Replying to posts/other replies is just a separate chunk of code that got finished but hasn't yet been deployed on ee-flow... should be there by the end of today! Maryana (WMF) (talk) 18:46, 11 October 2013 (UTC)[reply]

A comment on language

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

Even "Flow" has several different meaning:

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

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

Also referred to as Flow are

  • Discussion structure, that is, a formal description of a discussion within a workflow, occurring in both in "source" and "executable" form
One might imagine that these would have names such as FreeFormDiscussion, GeneralRFC, AFDDiscussion, ... .
  • Structured discussion, that is, an instance of a discussion with a given structure thought of as actually taking place somewhere.

It would be considerably clearer if we said, for example

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

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

Flow software questions

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

A condition of employment with the Foundation is that all software is released under an Open Source license, so yes. Flow is licensed under the GPL, as is most of our software. --Jorm (WMF) (talk) 17:59, 14 October 2013 (UTC)[reply]
Thanks for that -- I think it's a point well worth emphasising in this project, even if applies more generally, because it will be relying on a significant amount of work by the community. Spectral sequence (talk) 18:35, 14 October 2013 (UTC)[reply]
It's a good point to make. I just had a sit-down with both Brandon and Maryana (well, I ran over to their desks and went "what do you think of...") about the idea of crediting people who help with the process of building, say, the workflows extension, in the extension documentation proper so there's a tangible outcome for users who help with this (beyond Flow working). Looks like that's what we're going to do :). Okeyes (WMF) (talk) 18:15, 15 October 2013 (UTC)[reply]
Glad to hear it. It's also consistent with the spirit of CCA on attribution, so would be what contributors primarily of content might be expecting. Spectral sequence (talk) 20:38, 15 October 2013 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Wikipedia_talk:Flow&oldid=577338095"