Wikipedia talk:Flow/Archive 4

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1 Archive 2 Archive 3 Archive 4 Archive 5 Archive 6 → Archive 10

Older Announcements

Smaller and offsite announcements/mentions

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)

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

Guestbooks?

What happens to guestbooks under flow? Will they remain an exempt area like talkpage archives? ϢereSpielChequers 05:11, 31 August 2013 (UTC)

I don't think any firm conclusions have been reached, regarding how deeply Flow will eventually be deployed - ie whether it runs into all subpages automatically (which is where guestbooks are generally stored (more than 75% in usertalk, the rest in user)), or if it only appears by default at the root level. I imagine the latter is more likely, but only testing, and feedback from testing, will really get us any closer to an answer on that. –Quiddity (talk) 22:13, 31 August 2013 (UTC)
If the decision was that all guestbooks had to be in userspace as opposed to usertalk space then I doubt that anyone would make a fuss as it would be easy to move them all (I'm assuming that userspace will remain outside of Flow as that is where we stash userboxes and an awful lot of complications). But if one implication of flow was that guestbooks had to go then I think that would be more contentious. ϢereSpielChequers 15:51, 2 September 2013 (UTC)
Yup, userspace will remain outside of Flow. –Quiddity (talk) 21:35, 2 September 2013 (UTC)

Archives

Will existing talkpage archives be affected by FLOW? ϢereSpielChequers 05:11, 31 August 2013 (UTC)

Nope, they will be left-alone. I believe current thinking is that they'll be linked at the page-top, as with the current {{archive box}}. –Quiddity (talk) 22:04, 31 August 2013 (UTC)

Redirects

Will we still be able to redirect a page that has FLOW formatting? ϢereSpielChequers 15:51, 2 September 2013 (UTC)

We'll have to be able to (it's a core function in all sorts of things like page-moves/merges/etc), but as the Flow code has only just started to be written, I don't know if it will use the current method, or require a new method. –Quiddity (talk) 21:54, 2 September 2013 (UTC)

Signatures

Is it true that custom signatures will go when Flow comes in, or is it just that custom signatures will cease to work on pages where flow applies? ϢereSpielChequers 15:51, 2 September 2013 (UTC)

The FAQ answers this one, at Wikipedia:Flow/FAQ#What happens to my custom signature? - but there will be some sort of visual highlighting system so that it is easy to find all posts we've personally authored.
Personally, I understand the utility of being able to recognize the colours/design of the signature of a colleague/friend/nemesis/etc, but I'm also looking forward to end of this madness (and beyond). –Quiddity (talk) 21:51, 2 September 2013 (UTC)

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‎

@ 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)
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)
  • 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)
    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)
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)
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)
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)
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)
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)
"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)
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)
Please do not accuse editors making good-faith inquiries of baiting. That is rude. Thanks. — Scott • talk 11:27, 23 September 2013 (UTC)
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)
"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)
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)
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)
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)
  • 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)
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)
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)
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)
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)
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)
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)
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)
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)
"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)
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)
Thank you both for your prompt replies.
— | Gareth Griffith-Jones | The Welsh Buzzard | — 21:49, 26 September 2013 (UTC)
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)
@ Tryptofish, speaking of feedback, a new section arises :) Chime in! Maryana (WMF) (talk) 22:48, 26 September 2013 (UTC)
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)
@ 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)
All good. --Tryptofish (talk) 00:27, 27 September 2013 (UTC)
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)
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)
"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)
@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)

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)

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

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)

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)

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)

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)
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)
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)
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)
@ 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)
I'm just going to leave this here... :) --Guy Macon (talk) 08:23, 16 October 2013 (UTC)
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)
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)
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)
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)
Guy Macon, I just created T56739 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)
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)
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)
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)

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)

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

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

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)

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

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

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)

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

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)

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

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

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?"[30]

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)

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)
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)
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. [31], [32]), 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. [33] yesterday!). Quiddity (WMF) (talk) 19:18, 3 October 2013 (UTC)
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)
A note: this mingle ticket may gladden your heart on that front. Okeyes (WMF) (talk) 22:51, 3 October 2013 (UTC)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
  • 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)

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

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

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

User "expectations"

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

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

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

For what it's worth, user expectations for discussion systems generally are pretty widely known - not necessarily here but in the HCI and design worlds generally. I'm going to ask people if they can point to any documentation of general research (ping, Maryana). But it's true that Wikipedia and Wikipedians are going to be distinct in what they expect and in what they need. I'm not going to promise a survey (I can't promise things generally) but I think it's an interesting idea and something that would be worth doing if we could set it up easily. Okeyes (WMF) (talk) 17:51, 21 October 2013 (UTC)
I seem to recall asking that question at 21:14, 11 October 2013 (UTC). It seems rather late in the day to be collecting the documentation of the general research; and surprisingly laid-back to suggest that it might be worth collecting user expectation if it could be done easily. Can it really be that you currently do not have a clear overview of what users are going to need? (And if you do, perhaps you could point to it, please) Spectral sequence (talk) 18:13, 21 October 2013 (UTC)
I think Dank said it best:

Some new college campuses are built without sidewalks, so that the designers can see where the students are wearing ruts in the grass before the sidewalks go in. By the same theory, I think our free-form style (up till now) has given us a lot of very detailed experience suggesting what features Wikipedia talk pages do and don't need.

We have a pretty good idea of what our existing users need, just based on how they've been using talk pages for the past decade. We're tackling their needs first and foremost in the first release, because a good Wikipedia discussion system needs to be usable by current Wikipedians :) When it comes to people who aren't currently Wikipedians but could potentially be if we eliminated some of the user experience and interface barriers, as Oliver says, there are a lot of general best-practices from all the other discussion systems on the Internet that most people are familiar with and are comfortable using.
All that said, I definitely think there's value in reaching out to the class of people who aren't in either of those groups – e.g., users who've made some edits on Wikipedia but are still fairly new and may be struggling with the complexity of talk pages. We'll be working on a variety of methods to get feedback from those users (in-person user testing, more formal user experience research like card sorting, contextual inquiry, etc.), and a survey could certainly help. The reason this kind of research is not a more urgent need at this point, from my perspective, is that we're still a long way away from giving Flow to new users. Very few brand-new Wikipedians make their way over to WikiProjects – those tend to be more experienced user communities – so they're not our immediate target audience. Maryana (WMF) (talk) 21:06, 21 October 2013 (UTC)
I hope that "We have a pretty good idea of what our existing users need" turns out to be correct. Is that pretty good idea written down anywhere? It might be a good idea to expound it to the existing users just in case there might be some point that has been overlooked. Spectral sequence (talk) 21:15, 21 October 2013 (UTC)
Liz's initial comment seems to be based off the table on the Flow page; the personas and goals here may also help. I'm laid-back about the prospect of using that specific route to collect user expectations, let's be clear, here. Okeyes (WMF) (talk) 22:55, 21 October 2013 (UTC)
Sorry, but those designers do not have a problem of sidewalks preventing movement elsewhere. Or with sidewalks being incompatible with paths and older versions of sidewalks... Thus the analogy breaks down... And even if it didn't, they still need to mark those discovered paths on a map...
Thus I'd like to echo "Spectral sequence": such kind of knowledge is not very useful unless it is written down. In a structured way (It would be rather ironic to have unstructured process documentation of the project to create structured talk pages, wouldn't it..?). And supported by evidence (no, badly thought out research like the one I criticised in Wikipedia talk:Flow/Archive_4#"Test: User messaging 1: Talk page basics" - the methodology - the one that is supposed to show the "barriers" for new users you were talking about - just won't do).
Finally, the lack of useful documentation on this matter (if you had such documentation, you would have given us a link, right..?) coupled with such great optimism does make me wonder about possibilities of groupthink (the comment about "persons" by "Okeyes (WMF)" right above - [35] - could be a sign that the members of project team did not stop thinking individually, but such signs do not appear to be very common)... --Martynas Patasius (talk) 23:00, 21 October 2013 (UTC)

I'm somewhat confused about how we got from a conversation going "have you considered running a survey?" "that's a great idea, I'll see what people think" through to people complaining we don't have enough documentation. Summarising existing research is on our to-do list. As of earlier (I'm sorry I didn't have the time to post so directly), surveying incoming users for their expectations is on our to-do list. We're working on these; give us time. Martynas: I'm sorry if you feel we're suffering from groupthink and being overly optimistic, although I'm not sure how given our general attitude of going "we don't have all the answers, that's why we're talking about experimenting" (if admitting fallibility is an example of or consequence of groupthink, colour me happy to be a drone, but I don't think that's what's going on). Okeyes (WMF) (talk) 00:27, 22 October 2013 (UTC)

Then let me help you. At 17:51 on 21 October you wrote "For what it's worth, user expectations for discussion systems generally are pretty widely known - not necessarily here but in the HCI and design worlds generally. I'm going to ask people if they can point to any documentation of general research", in answer to a comment about surveying new users. I think that was what established the link between surveying new users and documentation of research.
However, the word "expectation" is overloaded here. I have an expectation that developers will provide full support for mathematics markup in Flow, in the sense that I assess the probability of it happening as above zero. I also have an expectation that developers should provide full support for mathematics markup in Flow in the sense that I believe that it is right and proper that they should do so. I also have a requirement that developers provide full support for mathematics markup in Flow, in that I will be unable to contribute if they do not. It would be more helpful to talk in terms of requirements (for user-friendly discussion structures, for example) than expectations.
I am concerned that this seems a rather late stage to be saying that summarising existing research and surveying user's expectations is still something you plan to do. In the absence of that work, it is hard to see what is informing your planning process. Spectral sequence (talk) 06:40, 22 October 2013 (UTC)
Aha; okay, I see the possible disconnect here. So, when I say summarising existing research, I don't mean "find the research and use it to justify what we're doing (or, not justify, and then stop doing those things", I mean surfacing the things that have been thrown around within the design and Product teams to justify these decisions so that the community can see them. An example of this is the references in the design FAQ; my statement isn't "we should probably find justifications, because we don't have them" it's "we have justifications, we should be transparent about them". Sorry for the confusion. Pinging Maryana to find out if she wants to make this sort of thing Design's responsibility or Product's ;p. Okeyes (WMF) (talk) 17:49, 22 October 2013 (UTC)
And I see another possible disconnect here: although you collectively "have a pretty good idea of what our existing users need" and are "tackling their needs first and foremost in the first release", there does not seem to be a clear published statement of what that "pretty good idea" actually is. Why not share that pretty good idea with the community of existing users, to make sure that your idea of their needs is as good as you think it is, right now, and before spending too much time and effort on meeting what might turn out to be an inaccurate notion of those needs? Spectral sequence (talk) 19:34, 22 October 2013 (UTC)
We've documented quite a lot of it already, and made it available to the community: see mw:Flow Portal/Research/Experienced User Responses and mw:Flow Portal/Use cases, for example. Okeyes (WMF) (talk) 17:24, 24 October 2013 (UTC)

User "expectations" and long-term data

Sorry to repeat what I said in Please provide indexing "table-of-contents"-like functionality (Oct 14th) but AFAICS you haven't acknowledged the issues around data retention yet. I'll try to make it clearer:

  • Access to past discussions is useful so that already-concluded discussions aren't restarted unnecessarily. That's not to say that older decisions are entrenched, just that if someone re-opens an issue there's an expectation that they've had a look for any prior discussion. This can cause friction between experienced and inexperienced editors.
  • Analysis of contributors' interactions is also very important for Wikipedia's governance processes—much more than in typical discussion systems.
  • So it must be easy for people to do searches and quickly scan search results for relevant material.
  • I'm concerned that you've underestimated the amount of searching that goes on currently. There's no way you could measure it because experienced users currently do their research using "search archive" and offsite queries (e.g. Search [[WP:VPT]] for "ironholds"). To use your metaphor: you might be able to estimate how many students have walked over the grass, but you can't count the ones who watched through windows and webcams.
  • I also suspect you've underestimated the amount of data involved. A popular discussion page can accumulate over a thousand topics every year. That's far more than anything I've seen WMF developers and liaisons mention in use cases.

In a nutshell: if you design Flow based on how discussion systems generally work, you'll get it wrong. Please specifically consider long-term high-importance systems such as Bugzilla, Stack Overflow and maybe Hansard. Thanks and good luck - Pointillist (talk) 23:22, 21 October 2013 (UTC)

I would say the existing user needs and user expectations in the minimum viable product are just that; needs for the minimum viable product. We've got searching (and an infrastructure that lends itself to searching) as a high-priority thing for the project overall. I'm sorry if I'm asking you to repeat things you've already said, but: are you arguing for more prominent search infrastructure, or to move away from infinite scrolling, or both, or...? Okeyes (WMF) (talk) 00:31, 22 October 2013 (UTC)
@Okeyes (WMF): Thanks. I'd like to see two MVP processes rather than one. The existing Flow MVP gives feedback about how people create topics and posts. A second MVP – let's call it "Pool" – should address how people search, filter and link to older discussions, within a board and across multiple boards. Flow is micro, whereas "Pool" would be macro. For this purpose, you'll need to import the contents of some existing pages, inferring a threaded structure from archived posts. Data should come from an RfC, an AfD, and some high volume pages (e.g. article talk, user talk, help desk, ANI, etc).
The "Pool" MVP would have a distinct rationale, personas and goals, aligned with/complementary to Flow. Pool's user experience could draw on other collaboration platforms that have many users and long-term topics. E.g. compare Stack Overflow (SO)'s reputation with our mw:Mark as Helpful idea; SO's tagging and finding related topics with Jorm's cross-warren linking), SO's implementation of how to go back and edit a previous posting, and of course their opinion of threaded discussions vs our thoughts on nesting & thread depth.
The big benefit is that the design team can prototype all sorts of ideas that follow from our real-world experience, free from the requirement to be consistent with the current Flow implementation. I know that importing won't produce a perfect result, but it'll be mostly right. Having lots of real data would be very useful: it's great for exploratory testing, it tells you whether your user stories are realistic and it helps avoid "duh" errors with page layout and interaction design. - Pointillist (talk) 12:34, 22 October 2013 (UTC)
You've raised a really good point here, actually. So, for the purposes of others reading this (and just in case you're not certain about the definition - I wasn't until a week or so ago) an MVP is something that (a) won't immediately fall over and (b) contains the kernel of the main ideas and hypotheses you want to test. It's the start of any product, and exists solely to be safely thrown out at people willing to be early adopters. They come back and bring with them a ton of bugs, and validate or invalidate the initial hypotheses. Having a second MVP for Flow doesn't really make sense unless we want to split search and retrieval-related functionality into a different project, which is probably not(?) desired, but there is a weakness in the existing MVP around search. So, our hypothesis is that a decent search system and infinite scrolling > a table of contents, which is fine as a hypothesis. The problem is that we won't actually have a search system in the MVP, and so if early adopters struggle with the system, we haven't necessarily set things up so that we can explore ways to solve for the struggling - nor do we have an easy way to validate/invalidate the initial hypothesis. That kind of meta-navigation is pretty important to a heck of a lot of users and isn't in our initial plans: it's marked as "to be added before the wider deployment". Is that in line with what you were getting at? Okeyes (WMF) (talk) 17:49, 22 October 2013 (UTC)
Yes++. Even if you had a search system in the Flow MVP, there wouldn't be enough data to exercise it. That's one of the reasons I thought a parallel MVP might help, because if the MVP for validating search doesn't have to support the Flow editing paths, it won't need to be built using the same tools/data structures as the real Flow, so it can be knocked together quite quickly using a prototyping stack (eg a set or graph-based NoSQL store plus something like Angularjs for filtering). It shouldn't be a separate project. It's just an extra workstream in which the existing Flow participants can scout out future possibilities without being constrained by the current Flow design, and then feed back the lessons learned into the Flow core. - Pointillist (talk) 22:49, 22 October 2013 (UTC)
That makes sense (I'm repeating myself!) I'm not the person to make a call here, but I'll poke those who are - note that it's coming up on 6pm, so I'll probably be signing off for the night, but I hope to have something to say tomorrow. Okeyes (WMF) (talk) 00:16, 23 October 2013 (UTC)
Pointillist, these are all good things to mull over. The trouble is that the MediaWiki Platform team is currently working on a complete overhaul of site search – and until we have a good idea of how much of their work we can reuse/integrate with, it doesn't make sense to embark on a project to build our own search functionality specifically for Flow. Even if we were okay with duplicating effort like that, we just don't have the engineering resources to split off a separate "search" team from the core Flow team. The good news is that the first phase of the search overhaul should be nearing completion, so we'll have a better idea of how far the new site search can take us soon enough. But there's also the question of what users will actually want to search for, and how they'll want to do it (sorting/filtering? keyword search? search by date-range? all of the above?). I think that's a much bigger discussion involving a wider user community that's had some time to play with the MVP as it stands and see, precisely, where the holes lie. I just don't imagine us a) building a fully functional search feature without this kind of community input, and b) getting that input without putting out a real, working version of Flow somewhere on Wikipedia. Maybe the latter won't tell us where all the holes lie, but it'll definitely be better than not having any real Flow enabled page on Wikipedia at all :)
So I do hear what you're saying about search being a vital part of experienced users' workflows and complex enough to warrant being basically a separate product. I don't think it's going to be a complete blocker to releasing a limited trial version of Flow on a WikiProject page, where discussions aren't super high-velocity, and letting those users tell us what kind of search features they need as they stumble across searching needs. But ultimately, it's up to the WikiProject members who are interested in trying out the Flow MVP to decide if they're okay with that :) Maryana (WMF) (talk) 23:16, 23 October 2013 (UTC)
Thanks. I wasn't proposing you should build real code, just an MVP to see how search should work in this context. It's an example of what Jeff Atwood calls UI first software development. It's a way to get a wider perspective, not a new project! I wish I could explain this to @Jorm: & his colleagues directly 'cos I'm sure they'd understand. Anyway, I'll sign off with two observations:
  • The way you search and display results depends on what data and relationships are captured via Flow. So you can't finalize Flow's UI and data structures until you've validated how to search discussions. The metadata for traversing a directed graph of "agree", "disagree", "comment", "branch" etc relationships is completely different from the metadata used to search articles – and if you haven't captured the right attributes there's not much that ElasticSearch can do to help. Of course, if you're genuinely OK about throwing away the Flow MVP once you've tried it, that's not a problem. But so often stakeholders get blinkered by the MVP design and don't understand it's just an experiment (Atwood calls this the prototype pitfall).
  • Anyway, it's very important to give your MVP users the opportunity to test against long-term many-topic discussion pages. Ideally you should import some, as I suggested earlier. If that's too much trouble, use a script to create a representative volume of dummy data (at least 3 boards, 30 user identities, 300 topics, 3000 posts). Otherwise, how is anyone going to "stumble" across what they'll need in the live system?
All the best - Pointillist (talk) 00:07, 24 October 2013 (UTC)
Importing is on the to-do list; there are a couple of blockers at the engineering end at the mo :). Good to find someone else who follows Atwood's work! Okeyes (WMF) (talk) 16:20, 24 October 2013 (UTC)

Clarification

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

It was referring to this section of Flow Portal:

User expectations don't match the reality of talk pages today.

Expectations Current reality
  • Easy to distinguish topics
  • A "reply" button
  • Obvious and consistent comment authorship
  • Automatic "signing"
  • A simple comment field
  • Notifications of replies to all discussions
  • Conversations that thread to infinite depth
  • Comment authorship shown at the end of comment or not at all
  • Inconsistent reply system (whose talk page hosts the conversation?)
  • Wikitext/code
  • Notifications only when the conversation happens on their own talk page

which seem to be conclusions based on these limited studies:
Flow Portal/Research/User Test Data
Flow Portal/Research/Experienced User Responses
Liz Read! Talk! 17:32, 4 November 2013 (UTC)

Yeah; I hypothesised as such above :). Just an update - I'm writing out the survey now and will throw it past the participants on this talkpage to make sure it doesn't contain anything eggregiously stupid. We're also doing wider user testing, and hoping to enlist a visiting UX testing expert...person. To help write out the tests. Okeyes (WMF) (talk) 18:07, 4 November 2013 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Flow/Archive_4&oldid=1079900142"