Tryptofish (talk | contribs) →A question: my opinion on it |
MPinchuk (WMF) (usurped) (talk | contribs) |
||
Line 561: | Line 561: | ||
:::::If by granular editing, you mean removing parts of posts, the most common reason would be a personal attack, or inadvertent BLP violation or outing. So if someone were to write: "X is a moron and completely wrong about this," someone else might remove "a moron and," then will usually leave a note below the post saying it was edited per [[WP:RPA]]. But if it's a wikifriend of the original poster who's doing the removing, they might remove the attack without leaving a note, in the interests of drama reduction. Or someone might write: "Susan, I disagree," having forgotten that Susan prefers not to be known by her real name, in which case another editor will quickly remove the name, without leaving a note because that would defeat the purpose. [[User:SlimVirgin|SlimVirgin]] <small><sup>[[User_talk:SlimVirgin|(talk)]]</sup></small> 03:15, 2 October 2013 (UTC) |
:::::If by granular editing, you mean removing parts of posts, the most common reason would be a personal attack, or inadvertent BLP violation or outing. So if someone were to write: "X is a moron and completely wrong about this," someone else might remove "a moron and," then will usually leave a note below the post saying it was edited per [[WP:RPA]]. But if it's a wikifriend of the original poster who's doing the removing, they might remove the attack without leaving a note, in the interests of drama reduction. Or someone might write: "Susan, I disagree," having forgotten that Susan prefers not to be known by her real name, in which case another editor will quickly remove the name, without leaving a note because that would defeat the purpose. [[User:SlimVirgin|SlimVirgin]] <small><sup>[[User_talk:SlimVirgin|(talk)]]</sup></small> 03:15, 2 October 2013 (UTC) |
||
::::::Yeah, these are all plausible use-cases, and I've seen them happening (I saw one yesterday, actually). Another good example is when users strike-through chunks of the post rather than redacting it entirely, which Flow can sorta handle; "hide" is equivalent to rollback in function and intent except it merely collapses the post - any [autoconfirmed/whatnot/still to be decided] user can still see it, so it's a rough strike-through equivalent. My question would be how often the partial redaction situations happen, and how often they happen in circumstances where the original author wouldn't be willing (or pressured) to handle it themselves? [[User:Okeyes (WMF)|Okeyes (WMF)]] ([[User talk:Okeyes (WMF)|talk]]) 16:28, 2 October 2013 (UTC) |
::::::Yeah, these are all plausible use-cases, and I've seen them happening (I saw one yesterday, actually). Another good example is when users strike-through chunks of the post rather than redacting it entirely, which Flow can sorta handle; "hide" is equivalent to rollback in function and intent except it merely collapses the post - any [autoconfirmed/whatnot/still to be decided] user can still see it, so it's a rough strike-through equivalent. My question would be how often the partial redaction situations happen, and how often they happen in circumstances where the original author wouldn't be willing (or pressured) to handle it themselves? [[User:Okeyes (WMF)|Okeyes (WMF)]] ([[User talk:Okeyes (WMF)|talk]]) 16:28, 2 October 2013 (UTC) |
||
:::::: {{U|SlimVirgin}}, while removing personal attacks from otherwise constructive comments might happen in some high-drama corners of the wiki, I doubt it's something that occurs even close to frequently on most WikiProject talk spaces, which is where we're planning our [[Wikipedia:Flow/MVP|first onwiki release]] :) If it's really a huge problem for the WikiProject members who choose to trial Flow, we can always change the comment editing permissions – but I want people to give this system (which, as Oliver said, has ''other'' easy ways of dealing with vandalism, spam, and personal attacks) a real shot before they dismiss it as untenable, and the WikiProject space is pretty safe-to-fail in that regard. |
|||
:::::: I'd also like to play devil's advocate for a moment here and ask whether this is really the kind of communication you'd like to encourage people to have. I'd argue that the ability to edit others' posts has created a culture that excuses (and thus tacitly encourages) personal attacks, since the attacker knows the body of his/her comment will be unaltered even when it's prefaced with flagrant ad hominems. Someone will have to clean up the mess, but the point will get through. This is a choice that the existing talkpage software has made for us, but we can choose to try another way. Perhaps users who are prone to issuing personal attacks will think twice about doing so if it's highly likely that their entire comment will simply be hidden? I don't know for sure whether this is true or not, but I think it's worth giving it a shot on a couple of discussion pages for a limited time and seeing what happens. [[User:Maryana (WMF)|Maryana (WMF)]] ([[User talk:Maryana (WMF)|talk]]) 17:25, 2 October 2013 (UTC) |
|||
*Why is this coming up again? Allow the privilege required to edit comments to be configurable on a per-wiki basis. Let each wiki choose what privilege is required and determine local procedures for gaining that privilege. Why should WMF try to dictate a one-size-fits-all solution when it's so easy to make it configurable?—[[User:Kww|Kww]]([[User talk:Kww|talk]]) 16:38, 2 October 2013 (UTC) |
*Why is this coming up again? Allow the privilege required to edit comments to be configurable on a per-wiki basis. Let each wiki choose what privilege is required and determine local procedures for gaining that privilege. Why should WMF try to dictate a one-size-fits-all solution when it's so easy to make it configurable?—[[User:Kww|Kww]]([[User talk:Kww|talk]]) 16:38, 2 October 2013 (UTC) |
Revision as of 17:25, 2 October 2013
This page has archives. Sections older than 30 days may be automatically archived by Lowercase sigmabot III when more than 5 sections are present. |
Smaller and offsite announcements/mentions
Continued from Wikipedia:Flow#Announcements
- Wikipedia:Wikipedia Signpost/2013-03-11/Technology report - Article Feedback tool made opt-in only (brief)
- Wikipedia:Wikipedia Signpost/2013-01-21/Technology report - First Quarterly Review makes for interesting reading (brief)
- Wikipedia:Wikipedia Signpost/2012-12-31/Interview - Interview with Brion Vibber, the WMF's first employee (brief)
- Wikipedia:Wikipedia Signpost/2012-09-10/Technology report - August engineering report published (brief)
- Wikipedia:Requests for comment/Article feedback - January 2013 (numerous brief mentions)
- http://blog.wikimedia.org/2013/05/02/wikimedia-engineering-april-2013-report/#Editor_engagement_features
- http://blog.wikimedia.org/2013/04/12/wikimedia-foundation-report-march-2013/#Editor_engagement
- http://blog.wikimedia.org/2013/03/13/wikimedia-foundation-report-february-2013/#Editor_engagement
- http://blog.wikimedia.org/2013/03/12/engineering-february-2013-report/#Editor_engagement_features
- http://blog.wikimedia.org/2013/02/17/wikimedia-foundation-report-january-2013/#Editor_engagement
- http://blog.wikimedia.org/2013/02/07/engineering-january-2013-report/#Editor_engagement_features
- http://blog.wikimedia.org/2012/12/06/engineering-november-2012-report/#Architecture_.26_Platform_support
- http://blog.wikimedia.org/2012/10/03/engineering-september-2012-report/#MediaWiki_infrastructure
- http://blog.wikimedia.org/2012/09/04/engineering-august-2012-report/#MediaWiki_infrastructure
- WMF Editor Engagement mailing list (most of May 2013)
- Wikimedia tech ambassadors mailing list, 16 May 2013
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
- 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)
- 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)
- 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 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)
- 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)
- 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)
What is Flow?
Having encountered the linked term "Flow" in a Portal article (with no explanation), I came here to find out what Flow is. The lede is of no help, saying it is a proposed change and it is not something else. Only after getting well into the article did I get an idea of what Flow is -- sort of. Can some-one please say what it is in the lede, and not just what it is about. For example, "Flow is a proposed change to the talk pages of Wikipedia that would (attempt to) make them easier for novices to use by ...[include the salient characteristic of the changes or deficits to be corrected]." — Preceding unsigned comment added by Kdammers (talk • contribs) 07:18, September 19, 2013 (UTC)
- @ Kdammers check out the main page now and lemme know if that makes a little more sense :) Maryana (WMF) (talk) 17:40, 20 September 2013 (UTC)
- 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)
- 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.
- 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)
- Please do not accuse editors making good-faith inquiries of baiting. That is rude. Thanks. — Scott • talk 11:27, 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)
- "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)
- 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)
- 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)
- In response to Guy, I should put myself forward as one who does "... think[ing] that our current system is acceptable."
- 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)
- Just posted on the Project page:
- "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)
- Thank you both for your prompt replies.
- 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, speaking of feedback, a new section arises :) Chime in! Maryana (WMF) (talk) 22:48, 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)
- @ 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)
- 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)
- 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)
- @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)
- 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)
No edit conflicts?
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)
- 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)
- 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 Template:Bug and CCed you there. Some additional thoughts to improve the mood and decrease the amount of energies needed to address software related concerns:
- They vs Us is not as useful as All Of Us trying to build together a great piece of open source software.
- This is not a grammar competition. If a sentence could be improved, let's improve it. The point of that sentence probably was about conflicts between plain users, which is a problem in current Talk pages and it won't be in Flow. That sentence didn't accommodate your use case? Fine, since you have a point let's make sure the developers don't miss it. Hence the Bugzilla report.
- Let's move on? Thanks to this discussion I will sure do my best volunteering testing for Flow, trying to hit those potential edit conflicts. Thank you for your help!--Qgil (talk) 17:02, 28 September 2013 (UTC)
- Guy Macon, I just created Template:Bug and CCed you there. Some additional thoughts to improve the mood and decrease the amount of energies needed to address software related concerns:
- 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)
- 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)
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:
- 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.
- Two of five tasks (third and fifth) are worthless for just about any purpose.
- "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.
- 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).
- 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)
Request for your feedback: Let's talk about nesting!
- Background
Talk pages are completely unstructured data; Flow is structured data. Unlike talk pages, which were created before the existence of smartphones, we have to account for how Flow will look on phones and tablets, which are currently ~20% of our readership traffic and swiftly growing. That means we have to make some choices about how we want discussion threads to look – specifically, how to make it clear who's talking to whom without creating an unreadable mess.
Take a look through the list of discussion communities and their nesting levels below (feel free to add more examples to it, too). If you've had discussions on any of these sites (or just browsed through them for a minute as a reader), what are the pros and cons you took away from the experience? (E.g., confusing to follow long conversations? hard to read on a phone? just right?) I'm seeding this with my observations, but you're welcome to add your own. This isn't a vote; I'm just trying to kicking off a conversation :)
Flat, zero levels of nesting
(flat conversations, one reply button, replies go to the bottom of the stack)
Comment
Reply
Reply to reply
Reply
- Examples of products using this pattern
- Pros/cons?
- works great on mobile!
- hard to have nuanced debate in a flat format
- difficult for users to skip content that irrelevant to them
- can be hard to keep track of who's talking to whom Maryana (WMF) (talk) 22:44, 26 September 2013 (UTC)
One level of nesting
(initial comment, all replies to that comment are flat)
Comment
- Reply
- Reply to reply
- Reply
- Examples of products using this pattern
- Pros/cons?
- looks good on mobile
- brings focus to the topic, not tangents/flamewars
- doesn't seem to be intended for robust user-to-user debate Maryana (WMF) (talk) 22:44, 26 September 2013 (UTC)
Two levels of nesting
(initial comment, answers, and replies to comment/answers that are less prominent)
Comment
- Reply
- Reply to reply
- Reply
- Examples of products using this pattern
- brings focus to question-answer interplay, not off-topic comments
- no confusion about where to respond
- begins to complicate mobile views of content
- by Jeff Atwood's account, intended to actively suppress free-form discussion.. WP:NOTFORUM? Maryana (WMF) (talk) 22:52, 26 September 2013 (UTC)
- It's worth noting that on StackOverflow (and the other StackExchange sites) there are also separate "chat rooms" - essentially a zero level of nesting conversation - where free-form discussion is encouraged to take place. While it's important that we adhere to WP:FORUM (and Flow doesn't encourage too much forumy behaviour) it's also important to remember that one of the primary reasons for a talk page is to build consensus, and you can't do that without relatively free discussion.
- On the subject of the StackExchange UI though, the ability to vote-up and vote-down questions, answers and comments might be an idea we want to borrow. We do a lot of polling and !voting on Wikipedia talk pages and we need a way for Flow to cope with that, including an easy way to count the !votes. WaggersTALK 13:13, 27 September 2013 (UTC)
- @ Waggers, interesting, I didn't know about the StackExchange chat room space... I guess SO's front-page discussion system doesn't quite meet all the needs of its users, if they require an alternate method for backchatting. That's definitely true of Wikipedia, too; some project areas may need more structure in their discussions, and some may need less, so we want to stay open to different configurations. I see you're a member of a couple of WikiProjects – from your experience, do those feel more like StackOverflow-type spaces where people ask questions and want answers, or more like informal chat/forum between members?
- On the consensus front: it seems to me that, in a way, StackExchange is also about building consensus (e.g., "what's the best answer for this question?"), and they've created the two-tiered system to encourage people to focus on the topic at hand, instead of spiralling off into back-and-forth 2-person tangents. You can still tangent in the comments, but those are just displayed in a way that makes it clear they're not part of the main discussion.
- Polls, !votes, upvote/downvoting, and other methods of gathering the pulse of the crowd are really interesting. I don't think we're going to get to exploring those options in Flow the near future, but it's definitely something to think about. I'm not sure how the wider editing community feels about these methods, though. There may be some users who have used StackExchange and other sites (e.g., Slashdot) and like them, but I've heard people express some misgivings about creating those kinds of filtering mechanisms on Wikipedia. Maryana (WMF) (talk) 19:46, 27 September 2013 (UTC)
- About polling, it's helpful to recognize that the consensus at the English Wikipedia is at WP:POLL. --Tryptofish (talk) 23:12, 27 September 2013 (UTC)
- ...Yep, the notion of "voting" without being able (or perhaps forced) to give an accompanying explanatory comment isn't what we want to encourage. I've put together a quick example of a typical consensus building discussion format - it would be good to see Flow supporting something like this kind of structure. WaggersTALK 07:30, 30 September 2013 (UTC)
- @ Waggers, that looks like slide 25 of a deck I put together for Wikimania :)
- The current structure of proposals evolved to look like this in part due to the technical constraints of Mediawiki – e.g., there's no concept of in-line annotation, so you can't make minor quibbles/critiques in place and have to put them in a separate section; there's no metadata associated with conversations, so you can't display the number of users participating at a glance. Flow won't be limited by those constraints, so we have a lot more room to experiment :) I'm curious, for example, what the purpose of a !vote section separate from the discussion section really is. Is it just to get a quick headcount? Give the closing admin/uninvolved user a visual cue in cases of WP:SNOW? What if we instead let people provide their detailed support/oppose comments in the "support" and "oppose" sections of a proposal and simply displayed the number of users commenting in each of those sections? Something like the headers in Gawker Media comments? Not saying we should do this; just wondering if there's more to the !votes section than, well, basically just a vote, and if discussion is really where all the important consensus-making happens. Maryana (WMF) (talk) 23:39, 30 September 2013 (UTC)
- It depends. An RFA is pretty much a vote. Wiktionary is pretty much voting. In those discussions, a comment is about influencing other people's votes. On other pages, it's really the other way around: the analysis matters more than the !vote. User:Beeblebrox/The perfect policy proposal#Planning the RFC might be interesting reading. User:Beeblebrox could probably provide even more information. WhatamIdoing (talk) 00:42, 1 October 2013 (UTC)
- Maryana, people organize RfCs in different ways. Sometimes, particularly with RfCs that you know won't attract much input, there's no need for a separate "survey" section. Where the RfC is likely to attract more attention, people add a separate survey section to make things easier for the closing editor or admin; I've closed a lot of RfCs and it's really difficult to pick out the main comment from each person, and just one from each, if the comments are only in a discussion section (where things get very repetitive). When the RfC is likely to be very large, people sometimes do add separate support/oppose sections and ask that the responses be numbered. That makes it more vote-like and easier to close.
- Consensus matters a lot and so numbers do count; analysis counts only in the sense that the closing editor has to make sure that policy has been respected. So, for example, if 100 people vote for an umambiguous BLP violation and one against, the closing editor will (hopefully) close in favour of the latter. But where the policy issue could go either way, the numbers are obviously pivotal, and in those cases (and I think that is probably most cases), it does end up as a vote. SlimVirgin (talk) 00:55, 1 October 2013 (UTC)
Three levels of nesting
(initial comment, reply, replies to replies, replies to replies to replies)
Comment
- Reply
- Reply to reply
- Reply to reply to reply
- Reply to reply
- Reply
- Examples of products using this pattern
- Pros/cons?
- starts to break down on mobile
- following threads gets more difficult – long tangents Maryana (WMF) (talk) 22:52, 26 September 2013 (UTC)
8-12 levels of nesting
(like the above, but even more nested!)
Comment
- Reply
- Reply to reply
- Reply to reply to reply
- Reply to reply
- Reply to reply to reply
- Reply to reply
- Reply to reply to reply
- Reply to reply
Reply
- Reply
- Examples of products using this pattern
- The Verge
- Wikipedia (effectively) after which people use {{outdent}}
- Quora
- Tumblr (3-5 is common, 11 is rare)
- Pros/cons?
- on a small screen, pretty much unreadable without a ton of work (clicking, scrolling, zooming, pinching), and all but impossible to add new comments
- where do I respond (to the topic as a whole, to individual comments)? Maryana (WMF) (talk) 22:44, 26 September 2013 (UTC)
- Why do we say that it is "all but impossible to add new comments"? New comments are added all the time on Wikipedia discussion pages. --Atethnekos (Discussion, Contributions) 19:07, 1 October 2013 (UTC)
- I think that point was just in reference to small screens (particularly mobile), where deep indents (and particularly :*:: mixings) are harder to compose a reply to. Quiddity (WMF) (talk) 19:48, 1 October 2013 (UTC)
- Yes, of course. Thanks. --Atethnekos (Discussion, Contributions) 19:52, 1 October 2013 (UTC)
- Yep, if you've ever tried to edit a talk page on a phone, it's... well, not pretty. Even on a tablet, it's pretty painful and frustrating, and the number of users we have on tablets is steadily growing. Maryana (WMF) (talk) 00:04, 2 October 2013 (UTC)
- I think that point was just in reference to small screens (particularly mobile), where deep indents (and particularly :*:: mixings) are harder to compose a reply to. Quiddity (WMF) (talk) 19:48, 1 October 2013 (UTC)
- Why do we say that it is "all but impossible to add new comments"? New comments are added all the time on Wikipedia discussion pages. --Atethnekos (Discussion, Contributions) 19:07, 1 October 2013 (UTC)
30+ or more levels of nesting
- Examples of products using this pattern
- Liquidthreads
- Thunderbird email subject lines
- Livejournal
- Pros/cons?
- yikes... Maryana (WMF) (talk) 22:44, 26 September 2013 (UTC)
- Comment Writing as one who has never taken part in any of the above mentioned sites (and has no intention of joining any of them either...), I find it a bit hard to understand what is being talked about. I've seen the mock-ups of 'Flow', and can't see that it's any improvement over the current system. It only takes a moment to explain indenting to a newbie - and if they can't understand that, they're not going to make any sense of anything. If Flow works anything like as well as VE has, we're going to be in a mess. And not able to talk about it unless there is some sort of opt-out provided. That I can't see happening. It's going to be all or nothing. I get the feeling sometimes that there's a similarity to the highways departments that have to ban parking on a road to speed the traffic flow up, and then put speed humps in to slow the traffic down again. They have to be seen to be doing something in order to justify their existence. Peridon (talk) 07:45, 27 September 2013 (UTC)
- Well, frankly given the backlog of software improvements, if we were merely trying to justify our existence there's a ton of things we could be working on other than this - I would assume that you, like all of the users I speak to (me included!) have a ton of ideas for changes that would improve editing. I think there may be a point of confusion here, though; explaining indenting to new users, as you say, does not take very long - in principle. But then we have "when is it appropriate to outdent?" and "What do I do if I have multiple replies to multiple users?" and a ton of other awkward edge-cases that occur every day and aren't necessarily covered by "count the number of colons in the post you're replying to, then add one". Here, for example, it's asterisk, then asterisk colon, then asterisk colon colon, then.... and the same thing would happen if we had numbered rather than bullet-pointed entries. There are various different formats for discussions.
- For me the greater problem with talkpages and indenting - for new users and for existing users - has always been things like screen width and information density. Explaining indenting to new users - setting aside the edge cases - is easy. Reading the resulting talkpages, with comments offset from each other 8 or 9 times, can be an eye-ache that encourages people to (at best) skim-read discussions or simply not participate. The prime example here is tablets and phones, which don't deal well with horizontal scrolling and will need to horizontally scroll for more than a couple of levels of indenting, but I have the same problem on the laptop I'm using right now. Okeyes (WMF) (talk) 21:02, 28 September 2013 (UTC)
- Nice to see a WMF representative admitting that indentation is not nearly hard enough to be a significant barrier. Can we put this point to the main page..? I think you'll have to agree that "Simultaneously, we know that freeform wikitext talk pages present a significant barrier to new users" overstates things and doesn't emphasise what you do.
- Also, a discussion that is complex and long enough to have "comments offset from each other 8 or 9 times" is likely to be complex enough to get "people to (at best) skim-read discussions or simply not participate" by its length alone... Speaking of asterisks - I have deliberately used ":::" instead of "*::" in this post... Did you notice a difference until now..?
- Anyway, perhaps the most important thing is that the tone you are using here is exactly what all WMF representatives should seek to imitate. There is nothing wrong with exploring different possibilities to improve the talk pages, as long as it is a truly free exploration that doesn't even rule out the answer "We have found nothing better than we had.". It is when we get the unreasonable hype of the product that doesn't even exist ("a great piece of open source software", "a kick-ass discussion system", "No edit conflicts, ever." and the like) that we start to "check for our wallet" (figuratively, of course). And such mistrust is not something you should strive to promote... So, thank you for the change of tone. --Martynas Patasius (talk) 00:12, 29 September 2013 (UTC)
- Thanks! I think Maryana, Quiddity and others would agree with me that hype is not something we particularly want. We want to make the positives of this system clear, but there will be some negatives (no system is perfect for every user), and above all this early period is about experimenting, not setting in stone Precisely What Will Definitely Happen. We (the WMF and the community) don't have all the answers yet, be it as to what is technically possible or what is socially possible, and so it would be unfair of us to act as if we could see the future with perfect clarity.
- One point of clarity would be that while I don't think teaching new users how to edit with indenting is necessarily the hardest thing in the world (although it does present some barrier, and there are lots of awkward edge-cases that raise that), a necessary skill for being able to reply to a thread is being able to read and understand it. High levels of indenting are sort of a problem there, since they make the page more difficult to comprehend - I had to pass over your post 2-3 times to fully get it, and I've been editing since 2006. So there is a barrier there, just an indirect one.
- I think clarifying/expanding on "freeform wikitext" is probably worth doing, to prevent misunderstandings, although I don't see it as being analogous to "indenting" - more "indenting, and markup, and templates, and everything else". Do you have any thoughts on language, there? Quiddity, Maryana, your thoughts? Okeyes (WMF) (talk) 21:03, 29 September 2013 (UTC)
- Regarding "freeform wikitext", the initial discoverability of all the systems seem to be the hard part - eg. all the newcomers who start new threads at the page top, or within an existing section (without a new header). All the difficulties with getting paragraph breaks to display properly (currently we mis-use the HTML definition list elements to create indents and paragraphs) with some people adding extra blank lines to create whitespace, and some people objecting per WP:LISTGAP, etc. The habit that some people have, of adding indents no matter who they're replying to, just to make the comment-separation clear.
- Trying to explain any of these standards (even in person, with all the added ease that over-the-shoulder-teaching brings), to my friends and acquaintances who are less comfortable with computers (eg. the owner of a local antiquarian bookstore, who reads old books all day, and recently got online) is often frustrating.
- I'm not sure how to condense that down into a brief sentence or two. Quiddity (WMF) (talk) 00:36, 1 October 2013 (UTC)
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)
- 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)
- On the general problem, the options are basically these:
- We can invent totally new words that leave the new users completely befuddled, or
- 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)
- 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)
- 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)
- 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)
- 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)
Editing the comments of others
Hey all
So, one of the ideas for Flow we're experimenting around with is limiting or removing the ability for users to edit the posts of others. The user experience argument is pretty clear; discussion medium does not work without the certainty that the comment you are replying to is genuine, and that your comment will not itself be tweaked or corrupted by others. The argument from existing users is also pretty clear: we have a lot of workflows that centre around being able to edit or interleave comments by others. I've tried to list the use-cases I can think of (and the ones at WP:TPO) at mw:Flow Portal/Editing comments. If you can think of any others, please list them if you're comfortable on MW.org or provide them here if not; I'm fully aware we don't know everything, and there are a ton of different workflows in this area. Thanks! Okeyes (WMF) (talk) 19:01, 1 October 2013 (UTC)
- Please have a closer look at peer reviews (e.g. en.wp, de.wp) which occur on article talk pages (or sometimes even user talk pages) as well. --HHill (talk) 21:10, 1 October 2013 (UTC)
- Those are a good point; they're included under "GAN/FAC" in practise, I think. When do they happen on user talkpages? Okeyes (WMF) (talk) 21:31, 1 October 2013 (UTC)
- If author A specifically asks author B to review article X, this review is sometimes given as a reply on B's talkpage. If this happens (it does occur only rarely, but I have seen such cases on de.wikipedia), the review is usually rather on the short side and thus unlikely to be edited by A (but might be moved to talkpage X). Not all collaboration is done in formal and regulated places ;-) --HHill (talk) 22:07, 1 October 2013 (UTC)
- That's a really good point; I'll include it in my example of "why our existing solution for GANs is not necessarily workable". Okeyes (WMF) (talk) 16:57, 2 October 2013 (UTC)
- Oliver, as that page you linked to shows, there are lots of occasions where other editors' talk-page posts need to be changed or removed – libel, BLP violations, outing, personal attacks being the most common. But at the same time there is strong consensus that it should only be done where necessary, and usually by striking certain words, or removing comments entirely, rather than altering posts in ways that can't be detected. As a matter of interest why would the WMF consider removing or limiting that ability? In other words, is there evidence that being able to edit other people's posts causes problems? SlimVirgin (talk) 02:20, 2 October 2013 (UTC)
- "Being able to edit posts of others isn't a problem for the editor, but is unexpected behaviour for the editee if the editee is new" goes the argument; while the idea of being able to remove posts entirely is common (moderation is a net-wide thing), being able to tweak comments in such a granular way isn't - as much as I love John Scalzi's work on the subject ;p.
- I agree - the examples you give are important (and frankly I don't think any of us would be willing to work on software that didn't provide for them). But, as you say, it tends to be a 'whole hog' kind of thing; if someone posts personal information in a comment, you roll back the comment and oversight rather than just excising that chunk of the post. Things like suppression and revision-deletion will be built into Flow before we consider even a limited release, so at the moment I'm looking for things that require granular editing that we've missed - there are undoubtedly some :). Okeyes (WMF) (talk) 02:56, 2 October 2013 (UTC)
- If author A specifically asks author B to review article X, this review is sometimes given as a reply on B's talkpage. If this happens (it does occur only rarely, but I have seen such cases on de.wikipedia), the review is usually rather on the short side and thus unlikely to be edited by A (but might be moved to talkpage X). Not all collaboration is done in formal and regulated places ;-) --HHill (talk) 22:07, 1 October 2013 (UTC)
- Those are a good point; they're included under "GAN/FAC" in practise, I think. When do they happen on user talkpages? Okeyes (WMF) (talk) 21:31, 1 October 2013 (UTC)
- If by granular editing, you mean removing parts of posts, the most common reason would be a personal attack, or inadvertent BLP violation or outing. So if someone were to write: "X is a moron and completely wrong about this," someone else might remove "a moron and," then will usually leave a note below the post saying it was edited per WP:RPA. But if it's a wikifriend of the original poster who's doing the removing, they might remove the attack without leaving a note, in the interests of drama reduction. Or someone might write: "Susan, I disagree," having forgotten that Susan prefers not to be known by her real name, in which case another editor will quickly remove the name, without leaving a note because that would defeat the purpose. SlimVirgin (talk) 03:15, 2 October 2013 (UTC)
- Yeah, these are all plausible use-cases, and I've seen them happening (I saw one yesterday, actually). Another good example is when users strike-through chunks of the post rather than redacting it entirely, which Flow can sorta handle; "hide" is equivalent to rollback in function and intent except it merely collapses the post - any [autoconfirmed/whatnot/still to be decided] user can still see it, so it's a rough strike-through equivalent. My question would be how often the partial redaction situations happen, and how often they happen in circumstances where the original author wouldn't be willing (or pressured) to handle it themselves? Okeyes (WMF) (talk) 16:28, 2 October 2013 (UTC)
- If by granular editing, you mean removing parts of posts, the most common reason would be a personal attack, or inadvertent BLP violation or outing. So if someone were to write: "X is a moron and completely wrong about this," someone else might remove "a moron and," then will usually leave a note below the post saying it was edited per WP:RPA. But if it's a wikifriend of the original poster who's doing the removing, they might remove the attack without leaving a note, in the interests of drama reduction. Or someone might write: "Susan, I disagree," having forgotten that Susan prefers not to be known by her real name, in which case another editor will quickly remove the name, without leaving a note because that would defeat the purpose. SlimVirgin (talk) 03:15, 2 October 2013 (UTC)
- SlimVirgin, while removing personal attacks from otherwise constructive comments might happen in some high-drama corners of the wiki, I doubt it's something that occurs even close to frequently on most WikiProject talk spaces, which is where we're planning our first onwiki release :) If it's really a huge problem for the WikiProject members who choose to trial Flow, we can always change the comment editing permissions – but I want people to give this system (which, as Oliver said, has other easy ways of dealing with vandalism, spam, and personal attacks) a real shot before they dismiss it as untenable, and the WikiProject space is pretty safe-to-fail in that regard.
- I'd also like to play devil's advocate for a moment here and ask whether this is really the kind of communication you'd like to encourage people to have. I'd argue that the ability to edit others' posts has created a culture that excuses (and thus tacitly encourages) personal attacks, since the attacker knows the body of his/her comment will be unaltered even when it's prefaced with flagrant ad hominems. Someone will have to clean up the mess, but the point will get through. This is a choice that the existing talkpage software has made for us, but we can choose to try another way. Perhaps users who are prone to issuing personal attacks will think twice about doing so if it's highly likely that their entire comment will simply be hidden? I don't know for sure whether this is true or not, but I think it's worth giving it a shot on a couple of discussion pages for a limited time and seeing what happens. Maryana (WMF) (talk) 17:25, 2 October 2013 (UTC)
- Why is this coming up again? Allow the privilege required to edit comments to be configurable on a per-wiki basis. Let each wiki choose what privilege is required and determine local procedures for gaining that privilege. Why should WMF try to dictate a one-size-fits-all solution when it's so easy to make it configurable?—Kww(talk) 16:38, 2 October 2013 (UTC)
- We're not; again, this is something we're trying to discuss and work out whether it's needed or not. I'll try to avoid ambiguity here: I am trying to ascertain whether there are probable use cases for building this feature in by default, so that we can make an informed decision as to whether it's necessary (and so something we have to have) or a nice-to-have. I'm not trying to "dictate" any solution - if I was, we'd just provide that solution and wouldn't be discussing it with you. In the future I'd ask you to read the thread before commenting and avoid assuming we're taking the stupid action here (which would be, as you say, dictating without consultation or community participation). I appreciate other development processes have not been particularly smooth, but the WMF is not one monolith. Okeyes (WMF) (talk) 16:57, 2 October 2013 (UTC)
- You heard tones in my question that weren't there, but I do think your basic approach is problematic. We're able to do it today. It's done today. That should be sufficient use case to provide it. You have concerns that it could be abused, and have concerns that it may be a feature that's a relic of our use of talk pages and isn't generally suitable for all environments. That's a sufficient argument for making it configurable. We all know from experience that different wikis have different policies for such things: that's sufficient argument for making the combination of privileges itself be configurable.
- What I object to is the notion that removing an existing capability is being discussed, and I don't understand why we keep having to have these discussions. Please don't release anything until it's able to do what we already can do.—Kww(talk) 17:16, 2 October 2013 (UTC)
- We're not; again, this is something we're trying to discuss and work out whether it's needed or not. I'll try to avoid ambiguity here: I am trying to ascertain whether there are probable use cases for building this feature in by default, so that we can make an informed decision as to whether it's necessary (and so something we have to have) or a nice-to-have. I'm not trying to "dictate" any solution - if I was, we'd just provide that solution and wouldn't be discussing it with you. In the future I'd ask you to read the thread before commenting and avoid assuming we're taking the stupid action here (which would be, as you say, dictating without consultation or community participation). I appreciate other development processes have not been particularly smooth, but the WMF is not one monolith. Okeyes (WMF) (talk) 16:57, 2 October 2013 (UTC)
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)