Wikipedia talk:Flow

Main article: MW:talk:Flow

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 — Preceding unsigned comment added by Sharihareswara (WMF) (talk • contribs) 14:14, 16 May 2013 (UTC) Template:Irony mark

Changing the redirect WP:FLOW

I plan to change WP:FLOW to redirect to Wikipedia:Flow as the walled garden essay does not mention flow or flowers or anything else, so I can't see a reason for that redirect. Uness someone wants to stand up for it. Thanks! heather walls (talk) 21:01, 15 May 2013 (UTC)

Yeah, done. --MZMcBride (talk) 00:19, 16 May 2013 (UTC)

Editing comments by other people

Editing comments by other people is a feature, and a good one. Unlike the horrible signatures, the ::::::: indentation or the replying-on-the-same-page weirdness, the availability of this feature is not badly confusing by itself. Its actual use may be a bit confusing, but its usefulness is still quite apparent. People who edit other people's comments usually do it in a social and helpful way and we should keep it. It's comparable to editing other people's answers on Quora, except in Wikipedia we don't even need the approvals (it's a wiki etc.) --Amir E. Aharoni (talk) 21:10, 15 May 2013 (UTC)

Can we allow for that feature (possibly enabled through workflows) in a manner we get that benefit without the avenues of abuse that are opaque to new users? Many editing interfaces allow for comment editing by convention to a restricted class of users. While restricted class of users doesn't make sense, restricted behaviors do. Ideas? -- tychay (tchay@wikimedia) (talk) 22:18, 15 May 2013 (UTC)

What avenues of abuse? --MZMcBride (talk) 00:07, 16 May 2013 (UTC)

Perhaps he means problems like [1] [2] [3] [4] [5] [6] [7]. Many new users don't realize that they should not correct or blank other people's comments.

Haven't either of you encountered a new user accidentally removing someone else's comments while posting, or deliberately vandalizing them? Why should it even be possible for an IP to change your comments, e.g., adding the word "not" in the middle? WhatamIdoing (talk) 01:18, 16 May 2013 (UTC)

Malevolent change of the original poster's intent is vandalism like any other. It's possible in articles, where it's, um, quite damaging, too. There is, however, a significant difference between articles and talk pages in this context: Articles are not signed by persons in an immediately visible way, and talk page comments are clearly attributed to a person. So a modified talk page comment could say something like "written by Stacey (and modified by Sharon)" to make it immediately clear. But modification must remain possible, because much of it benevolent.

Changing other people's comments by accident may happen in the current talk pages. If I understand correctly, however, the whole concept of Flow is making a clear distinction between replying and editing, so such accidents are supposed to be reduced by design anyway. --Amir E. Aharoni (talk) 07:15, 16 May 2013 (UTC)

Following this line of thought, it seems to me that each new comment is then the logical equivalent of a new article, with a history of its own. With an unbounded history, a more practical suggestion than just "modified by..." might be something more like "last modified by ..." with a link to the complete history. Pardon me please, I have been waiting over 50 years to use this one comma revision as an example of the dangers of allowing edits: "pardon impossible, to be sent to Siberia" -> "pardon, impossible to be sent to Siberia". --AJim (talk) 14:27, 16 May 2013 (UTC)

(de-indent) Vandalism and spam are huge concerns on a site where anyone can edit. One major benefit of the current system is that it allows for very easy removal of vandalism and spam. Any viable successor will need to be equally (if not) more robust. If someone comes along and adds several spam comments that nobody else can edit or remove, that's a huge problem. --MZMcBride (talk) 14:31, 16 May 2013 (UTC)

Another great example: this fix to a post on Meta-Wiki. Using "Meta Wikipedia" is deeply offensive to a lot of Wikimedians, as it's emblematic of a Wikimedia Foundation culture that focuses primarily (some would say exclusively) on Wikipedia. A wiki makes it easy to address this type of issue quickly and cleanly (edit the subject line --> finished). This is a great beauty of wikis that should be treasured, in my opinion. --MZMcBride (talk) 19:07, 18 May 2013 (UTC)

If you cannot edit other people's comments, then this will cause a great deal of problems with many Wikipedia processes that work on talkpages. Many people fail to implement the processes correctly, and others come around and fix it (like broken Requested Moves templates/nominations) And there's the need to close discussions (like when an RFC ends) If you can't edit the entire thread and other people's comments, then these will all break. -- 65.94.76.126 (talk) 12:16, 24 May 2013 (UTC)

I believe that they're starting with user talk pages because they're simpler (e.g., no RMs or RFCs), but these issues are on the list, probably under the heading of "deal with the horror that is ANI". Also on the list is a way to have talk-page sections that anyone can edit, so that you can collaborate on writing article text before moving the refined text into the article (or policy page). WhatamIdoing (talk) 01:38, 26 May 2013 (UTC)

The ability for non-admins to edit the comments of others is something I see a lot of users wanting. Please implement "edit others comments" as a separate permission from other administration permissions (done right, each action should have a separate permission anyway). This way the permission can be granted to all users, auto-confirmed users or any other group using $wgGroupPermissions. Would the developers being willing to give this permission to auto-confirmed users if there was a community consensus for it? – PartTimeGnome (talk | contribs) 18:25, 27 May 2013 (UTC)

I really like this idea, but not for autoconfirmed users. I think it should be bundled with the reviewer (or possibly rollbacker) user right. If you look at Wikipedia:Reviewing you will see that the trust level is about the same, and if you look at Wikipedia:Requests for permissions/Approved/May 2013 and Wikipedia:Requests for permissions/Denied/May_2013 and examine the history of the editors in each group I think you will see what I mean. This also has a beneficial side effect; right now, if someone misuses reviewer or rollbacker (or perhaps just isn't competent to use them), that right can be revoked without the drama of a block or ban. The same should be true of editing other people's comments. --Guy Macon (talk) 03:34, 28 May 2013 (UTC)

Would you request an edit through something like the current {{editrequest}} or {{editprotected}} request templates? -- 65.94.76.126 (talk) 14:39, 31 May 2013 (UTC)

I posted an RfC and so far "anyone can edit" is ahead by a three to one ratio, but assuming that one of the other choices pulls ahead, then all you would have to do is reply to the offending talk page comment with "please delete the above" or "could someone please remove the bit about the Piggers winning the Nobel Prize in the above comment?" Unlike the case with article pages, you can post your own comment after the offending comment explaining why it should be deleted or edited.

As an IP editor, your edits to articles are something we want to see more of, which is why we always try to get semiprotection lifted as soon as possible. Editing other people's talk page comments, on the other hand, is something we generally discourage except in special cases (posting someone's email address or phone number, for example) Also, talk pages get far fewer readers and far less spam and vandalism so there is a bit less of a hurry. --Guy Macon (talk) 05:29, 30 June 2013 (UTC)

Flow content in xml dump?

Will the conversation end up in the same database as old style talk pages? And thus stay part of the xml dump? Data miners may find it convenient to keep articles and discussions in one file. (avoid issues with async deletions of articles but not talks, or vice versa) Erik Zachte (talk) 22:08, 15 May 2013 (UTC)

This is an interesting question, and one I'm not really able to answer with accuracy at this time. The data model we are currently working with assumes that each post is its own "page", with metadata pointing to its location/thread/etc. I should think this would export just fine; data miners would just have to be aware of the metadata inherent in it.

Do you know if this is a problem with LiquidThreads?--Jorm (WMF) (talk) 22:13, 15 May 2013 (UTC)

I think LiquidThreads 2 (and earlier) save data to the page space (though maybe not as XML). The decision as to where the data will live hasn't been set. Right now the advantages of using the existing pages tables would be we inherit a lot of stuff for free (oversighting), while moving it elsewhere would allow it to be built for scalability from the start (instead of jury rigging things on external storage). I think the engineers working on Flow would have to make the final decision. -- tychay (tchay@wikimedia) (talk) 22:20, 15 May 2013 (UTC)

Every LiquidThreads post was its own wiki page written to the Thread namespace. I'm pretty sure these were included in the XML dumps by default. LiquidThreads used a "thread" table to store information about the structure of the conversation. The side benefit of this was that it made it easy to do other kinds of analysis on the discussions, which would have been much more difficult to do if you had to infer that structure from wiki pages and revision history in the XML dumps. In other words, with LiquidThreads, you got the best of both worlds in terms of analysis: It worked with Erik's scripts, and you could gain new insights from the additional structural data. Caveat: I'm working from memory (which is shoddy) and some notes from some analytics scripts I wrote three years ago, so you'll have to check with Werdna to confirm. --Eekim (talk) 14:19, 16 May 2013 (UTC)

One Flow portal is more than enough

Hi. There should only be one Flow portal. Currently we have Wikipedia:Flow and mw:Flow Portal. Duplicating all of this content between mediawiki.org and this site makes no sense and simply isn't sustainable. --MZMcBride (talk) 00:09, 16 May 2013 (UTC)

I assume they're trying to prevent any possibility of editors missing information, because of "Almost all of us do our work on this Wikipedia, not on meta or the mailing lists" type reasons. (Ie. some of the Echo rollout complaints)

Are you suggesting that we keep the bulk of the information about Flow, on mediawiki, and only leave a short synopsis at this page? (I do agree that direct-duplication seems bad at first glance, but customizing the content would probably require more effort in the long run, and might lead to more complaints...)

What balance would you suggest we strive for, in this particular instance/project? –Quiddity (talk) 00:36, 16 May 2013 (UTC)

Generally I'd suggest using Meta-Wiki. This is what it was designed for, after all. However, the Wikimedia Foundation is quite clearly focused only on the English Wikipedia. I'm not sure I see a reason to beat around the bush about it. --MZMcBride (talk) 00:38, 16 May 2013 (UTC)

The fact the WMF is focusing on the English Wikipedia (is it really ?) does not mean we should collectively forget the only linguistic versions AND the other projects as well. If there is only one portal, then it should be on meta. Anthere (talk)

A third location?! meta:Flow exists, but is just a 1-sentence pointer to mw:Flow...

Are you volunteering to defend the devs against all the shit-throwing that seems to happen when the rabble don't feel adequately informed? Good for you! :D

More to the point, can we separate idealism from pragmatism, in this topic?

Maybe we should try this format (gratuitous duplication of content, from mediawiki to here), for this project (Flow rollout), and see how it works, and then try learning lessons for the next project based on how it works? Or if not that, then at least offer a non-abstract alternative suggestion? –Quiddity (talk) 00:49, 16 May 2013 (UTC)

Sorry, you seem to have missed my meaning. I was saying to use this site (en.wikipedia.org). The duplication is already causing synchronization issues. Gratuitous duplication is actively harmful and wasteful. --MZMcBride (talk) 01:21, 16 May 2013 (UTC)

It's better to have this duplicated content only in one place, regardless of what that place is. πr² (t • c) 01:46, 16 May 2013 (UTC)

(edit conflict) If this is going to affect all Wikimedia projects, it should be on Meta. The page can remain on the English Wikipedia as well, focusing on enwiki issues. The MediaWiki content should focus on technical details, like the implementation of extensions or special syntax/parserfunctions/API props/modules introduced. Meta's purpose is to coordinate Wikimedia projects, although it seems this has been replaced by messages on the English Wikipedia "Project" namespace (for better or for worse). This should also be announced globally via Global message delivery, of course. It makes little sense to have the same content on several domains--this should be replaced with an interwiki redirect before the duplication and linking becomes too widespread. πr² (t • c) 01:28, 16 May 2013 (UTC)

• Transclusion is the best workaround for this problem. The content should be located at Meta but made to feel seamless for readers from this project. This is ironically a problem very closely related to what Flow aims to address.   — C M B J   02:03, 16 May 2013 (UTC)

  Can you transclude between projects now? :/. Ironholds (talk) 02:10, 16 May 2013 (UTC)

Bug 4547   — C M B J   02:12, 16 May 2013 (UTC)

So, no. I don't think fixing such an icky bug is going to happen to enable us to avoid duplicating project documentation. Ironholds (talk) 02:17, 16 May 2013 (UTC)

The fact that 90% of the people we want to talk to absolutely loathe leaving their home wiki is why we're having multiple portals. It's as simple as that. I certainly don't want to shut people out of the conversation because we dump them into unfamiliar waters, nor do I want it said anywhere that "the conversation was held on another wiki where I wasn't present and didn't go." So I think multiple portals are required and not a problem. --Jorm (WMF) (talk) 02:16, 16 May 2013 (UTC)

There is some merit to local pages for each affected wiki with customized information. English Wikipedia has issues distinct from that of Meta, MediaWiki.org, etc. I would recommend one of the pages being deemed the master page so that we can make sure that information and updates are consistent across all pages. Harej (talk) 04:14, 16 May 2013 (UTC)

When I started this section, I'd honestly forgotten that I'd already discussed this with Brandon. I guess the plan is to put individual portals on every project (e.g., there's now a Meta-Wiki portal). This is really messy and painful, but given the lack of interwiki transclusion support (or even partial page interwiki transclusion support) and the reluctance of people to step outside of their home wiki, I concede that it's a problem without a great solution. :-/ Bleh. --MZMcBride (talk) 19:04, 18 May 2013 (UTC)

Documentation

Is there any documentation describing what Flow does, and how it handles situations commonly encountered on many pages? How does it appear to those with scripting disabled? Is there a history so a user can review an old discussion on their talk page? Can archived discussions be searched? Can any user delete trolling, or misguided posts, or spam? What happens when trolling is deleted (will the subject or user name be visible)? How can editors review deletions and revert them where appropriate? What happens if someone becomes logged off while posting? Presumably their IP would be displayed—can an admin revision-delete it? Is it possible to close off-topic opinion pieces? Johnuniq (talk) 07:35, 16 May 2013 (UTC)

No: there is no documentation because the product does not exist yet. WhatamIdoing (talk) 21:27, 16 May 2013 (UTC)

Feedback steps

I have three questions (that I've thought of so far):

1. Do the deves have any mockups of what Flow is expected to look like on desktop and mobile devices?
2. Will Flow be turned on at testwiki or another development wiki to let project users see how it operates and give feedback before it's turned on here?
3. Will each wiki be given an opportunity to opt-in or opt-out of parts of Flow (like with LiquidThreads and AFT) or will all of it be turned on at all wikis regardless of community consensus or dissent?

Thanks. MBisanz ^talk 10:37, 16 May 2013 (UTC)

For questions one and two, I think you want Wikipedia:Flow/IP. Question three is likely addressed by Wikipedia:Flow/FAQ. --MZMcBride (talk) 14:33, 16 May 2013 (UTC)

@MBisanz: To answer number two: we always deploy first to a test wiki for stress testing, though often the ramshackle nature of those wikis makes them unsuitable for testing of the user-facing portions of a new feature. We also typically turn a feature on at one of the editor engagement Labs instances for testing before we deploy it anywhere. Whether we invite Wikimedians to come and try them out there as well is up to the folks working on Flow, but like MZ said, I think the best thing to do right now is try the prototype. Prototypes like that approximate the current thinking about how the functionality works, though they're likely to change (esp. from a visual design standpoint) before deployment. Steven Walling (WMF) • talk 18:18, 16 May 2013 (UTC)

Thanks Steven. I'm wondering what happens if after seeing the final iteration of prototypes, a community decided they didn't want it deployed to their project? I see that the FAQ says the foundation will keep urging people to adopt it, but that's only once it's deployed to a project. MBisanz ^talk 12:14, 17 May 2013 (UTC)

The point of releasing the prototype and the discussion portal early (there isn't even a repository for the Flow code yet [8]) is to have the feature be substantially shaped by feedback from the community, so that it meets our needs for a better discussion system. The goal is to avoid a situation where the feature appears out of nowhere fully-formed and inflexible to change, so that editors have to make a "take it or leave it" decision. I answered your question about test wikis the way I did just because I wanted to point out we have a ton of them that we use, even if I'm not sure which one might be most appropriate for use by community members. Steven Walling (WMF) • talk 18:09, 17 May 2013 (UTC)

Thanks, now I understand. The reason I was interested in the test-wiki setup is because I couldn't view the prototype on the first two machines I tried. Trying it now, I like the format, but I don't like the (apparent) inability to edit comments. But that's something to include in the feedback stage. Do you know if they have a mobile prototype mocked up yet? Thanks. MBisanz ^talk 19:09, 17 May 2013 (UTC)

I haven't done a mobile prototype because I was asked to focus on the desktop experience for this (which I think is the correct path). A mobile version will likely be similar, but with a simplified interface (like, no comment threading, for instance).

As far as editing comments goes, 'tis a prototype and I can only include so many "features" based on the time I have available versus the difficulty of "faking them up" in a useful manner. I'll add something like this to my to-do list, though.--Jorm (WMF) (talk) 19:26, 17 May 2013 (UTC)

Jorm, thanks for responding. I certainly understand the limitations of prototypes and don't want my requests for examples to waste your time that could otherwise go to coding the actual product. MBisanz ^talk 03:15, 19 May 2013 (UTC)

Disagreement with 2.4 Contextual Interest

"When I post a new message on someone's talk page, I really only care about that message. I don't care about the tens of other topics that are happening there. And yet, if I want to watch for replies in my topic, I have to see everyone else's. On some high-volume talk pages, my topic (and unread responses) may very well be archived away before I get back to reading them!"

Actually, user talk page are used for other purposes in addition to sending messages to a person.

In my own work in WP, I normally go to a user talk page when there is a problem with their contributions; what I will say there can depend very much on what else I find, first there, and then in their contribution history. The present system works extremely well for this., except when they delete things from their talk p., and if I suspect this, I need to check also their talk p. history.

I , and other people, have talk pages that are watched by a very large number of people--sometimes several hundred; most of whom do not really plan on posting there, but want to see what is being discussed there, under the assumption that some of what they find out about may be interesting. Sometimes, they are there because they intend to join in discussions initiated by others if they find it concerns them also, or if interested.

I'm concerned that the emphasis on specific information flow may be damaging to general project-wide awareness. DGG ( talk ) 19:09, 16 May 2013 (UTC)

From what I've read, you will still be able to watch other people's boards (exactly like watching someone's user talk page now).

Much of this is currently written from the perspective of all users at a wide variety of projects (WMF and non-WMF alike). I'll try to focus the content on what matters to us, here, when I've got some time (check back next week). WhatamIdoing (talk) 21:31, 16 May 2013 (UTC)

I replied over on mw.org but I'll mirror it here:

"Talk page are used for other purposes in addition to sending messages to a person, or joining in a discussion."

This first point is my primary reason for arguing that the "Board" remain distinct from the "Feed". The fact that Boards will be used as "quick glances" into the life of an editor is super-important to me. We have been discussing what other things might need to appear on the board in addition to discussions. Block noticies? If they are an administrator, should we indicate that they have performed administrative actions (e.g., "Bob blocked Vandal23342")? What about main space contributions?

These are the kinds of questions that we're wanting answers to.

(And, by the way, it is currently planned that deleted posts and topics will remain on the board, just noting that the topic was deleted and by whom. So you won't have to check the history to see that this has happened.)

"There are also some people whose talk p. is watched by a very large number of people--sometimes several hundred , most of whom do not really plan on posting there, but want to see what is being discussed there, under the assumption that some of what they find out about may be interesting."

This is exact and precise use-case for being able to subscribe to other users' boards. The Feed/Subscription model will actually make doing this easier, not harder.

The end vision of Flow is not to restrict information flow - far from it. And, in fact, the entire point of the project (from my mind) is to actually increase project-wide awareness.

Right now, if you want to see what's going on with the seven WikiProjects you're a member of, you have to go to seven different pages and see if they've been updated (or view diffs from your watchlist, which is painful). Think about a future point where new posts and new requests on those seven boards automatically flow into your feed. This increases collaboration power.--Jorm (WMF) (talk) 19:52, 19 May 2013 (UTC)

Flow without javascript

Will Flow work without javascript? In other words, will people be able to read & post if they have javascript disabled or not available? 64.40.54.218 (talk) 23:30, 18 May 2013 (UTC)

Yes, but this is not reflected in the prototype. The experience will be significantly different, of course.--Jorm (WMF) (talk) 01:25, 19 May 2013 (UTC)

Oh thank goodness! I came here to ask the exact same thing, since if communication became impossible without JavaScript, I would essentially be unwillingly retired. You have no idea how relieved I am to hear that that's not the case. Sophus Bie ^(talk) 12:23, 19 May 2013 (UTC)

Having now looked at mw:Talk:Flow_Portal, if that's what Flow will look like, then while communication isn’t impossible without JavaScript, it is nearly unreadable. Every section displays as one undifferentiated blob of text. That's LiquidThreads, not Flow. I don't know what Flow will look like. I sincerely hope this will be fixed before Flow is rolled out, especially since I'm not the only one affected: User:PartTimeGnome, User:Risker, and User:Geitost are three other editors that I believe would be affected by this, for example. Sophus Bie ^(talk) 12:47, 19 May 2013 (UTC)

mw:Talk:Flow Portal is using LiquidThreads, not Flow. I don't think there is a deployable version of Flow yet, so we can't check how usable it will be without JavaScript. I hope the developers are reading this and will take it into account. (This should be the kind of thing a developer always considers when writing for the web, but the Notifications debacle would indicate otherwise...)

Regarding how that talk page looks without JavaScript, I wrote some CSS a while back to make LiquidThreads pages easier to read without JS. (See my reply to you on mw:Talk:Flow Portal for more detail on this.) – PartTimeGnome (talk | contribs) 17:29, 19 May 2013 (UTC)

That CSS code is gorgeous! I will definitely be using it. Sophus Bie ^(talk) 20:16, 19 May 2013 (UTC)

Yes, that’s great, thank you, looks very much better now. I’ll also use that at translatewiki.net now. :-) --Geitost 11:07, 20 May 2013 (UTC)

And reading unobtrusive JavaScript should be a must to all developers before developing anything new. Wikidata, translation interface and notifications are teaching us the opposite. --Geitost 15:57, 20 May 2013 (UTC)

@PartTimeGnome: is that CSS in bugzilla somewhere ? Can't hurt actually adding it to LQT I think, even if we don't plan to use it on more websites, it would improve existing deploys. —TheDJ (talk • contribs) 12:18, 2 June 2013 (UTC)

It's not in Bugzilla. I've no objection to adding it to LQT; I've dual-licensed it as GPLv2+ so it now shares MediaWiki's licence. It would probably need a bit of work to add it LQT, however. It contains four non-translatable English strings added using "content:". The "(outdent)" text could be replaced by an arrow like the one at the start of this comment. The other strings are non-essential and could simply be removed. More significantly, though, I suspect this CSS would interfere with the formatting added by JavaScript – does MediaWiki already have a way to deal with this? (E.g. a way to place the <link rel="stylesheet" ...> for this CSS inside <noscript> tags?) – PartTimeGnome (talk | contribs) 17:34, 2 June 2013 (UTC)

Conversion of old discussions

It would be nice to have an option for admins to convert all discussions on some particular page or a list of pages to the new discussion format (use the page history for that), so that we can get rid of a tremendous number of archives that we've got on many Wikimedia projects. --DixonD (talk) 10:59, 22 May 2013 (UTC)

How would that help? Archives can be searched, and it is easy to link to a particular section on a particular archive page. It is not clear whether that would be possible in Flow. Johnuniq (talk) 11:39, 22 May 2013 (UTC)

Of course, it has to be possible. Otherwise, Flow just cannot replace the current discussion format. --DixonD (talk) 00:11, 25 May 2013 (UTC)

It is really difficult to take raw wikitext and convert it into structured data. It nearly always has to be hand-massaged. Further, most archive pages lose the history of the discussion; while there are signatures there is no machine-readable attribution for any one comment (which means we'd really have to rebuild the Flow board from scratch using the history). I'm certain that we'd welcome volunteer efforts to build software to do this conversion, but I can't see it being part of an official Foundation product any time in the near future.--Jorm (WMF) (talk) 17:44, 22 May 2013 (UTC)

You don't need to parse timestamps if you have a history. And you do have a history of the particular page for which archives were created in past. That's what I was saying - about possibility to have all past discussion for some particular page (and I didn't mention about reading raw archive pages). So it seems that actually I don't really understand the transition process to the new discussion format. What are you going to do with existing wikitext on discussion pages that are to be transferred to Flow? --DixonD (talk) 00:09, 25 May 2013 (UTC)

Existing wikitext pages will not be transferred to Flow. They will be moved into an archive.--Jorm (WMF) (talk) 03:41, 25 May 2013 (UTC)

But could it be possible to provide at least API for admins for creating comments from other users and linking somehow to them in other way? So that we can do reconstruction of the Flow board by our own. --DixonD (talk) 13:50, 25 May 2013 (UTC)

Even if we could provide an api - or even allow people to walk through the revision history, creating Flow boards as they go - the problem is decidedly non trivial. Consider the following (typical) conversation exchange:

I think things are bad on this article here -- [[User:JoeBobBilly|JoeBobBilly]] ([[User talk:JoeBobBilly|talk]]) 13:50 25 May 2013 (UTC)

:No, you're wrong -- [[User:FreddyBear|FreddyBear]] ([[User talk:FreddyBear|talk]]) 13:52 25 May 2013 (UTC)

:No, ''you're'' wrong. -- [[User:JoeBobBilly|JoeBobBilly]] ([[User talk:JoeBobBilly|talk]]) 13:55 25 May 2013 (UTC)

::You're both wrong -- [[User:Jorm|Jorm]] ([[User talk:Jorm|talk]]) 13:58 25 May 2013 (UTC)

:No, I think they're right -- [[User:Whatamidoing|Whatamidoing]] ([[User talk:Whatamidoing|talk]]) 14:10 25 May 2013 (UTC)

Who is responding to whom? And when? We understand it only because we read it in context. Computer-assisted parsing will not be able to handle this, especially because the "colon" rule for indentation is so poorly applied. It's a user agreed convention, not a software enforced one. (and then, of course, trying to parse this specific comment is madness as well) --Jorm (WMF) (talk) 20:56, 25 May 2013 (UTC)

Then it would not be possible to have a visual editor-like system where we have both the new interface and the ability to edit the source. It might have addressed a number of concerns. Cenarium (talk) 21:15, 28 June 2013 (UTC)

FLOW and Wikipedia talk page processes

How will this be compatible with talk page polls, like that used in splits, mergers, WP:RM requested moves? And how do you mark a discussion closed? -- 65.94.76.126 (talk) 22:10, 25 May 2013 (UTC)

A talk-page poll is a discussion with a bunch of people replying to a question. That's really no different from a plain old discussion in which a bunch of people reply to a question. Someone will start the discussion (just like now) and everyone will click the 'reply' button (rather than typing an asterisk to make a bulleted list).

Discussions are marked 'closed' by clicking the little 'closed' button (and adding an edit summary/comment about why you're closing it). WhatamIdoing (talk) 02:03, 26 May 2013 (UTC)

Will this allow the adjustment of broken processes? (such as found at WP:RM where people fill in the nomination incorrectly, and someone has to come around and fix it) -- 65.94.76.126 (talk) 04:29, 27 May 2013 (UTC)

As I understand it, the plan is to have that kind of message in an anyone-can-edit section, rather than in a just-for-me comment. However, even if they don't manage that, then it's possible that the proposal above to allow trusted non-admins to edit other people's comments would be another way to address this issue. WhatamIdoing (talk) 03:16, 29 May 2013 (UTC)

You may want to see this thread on MediaWiki, which describes how various processes will work with Flow. -- Ypnypn (talk) 18:55, 30 May 2013 (UTC)

Example

I don't really want to embarrass this newbie, but this situation has reminded me what a mess we have created with our clunky talk page system. New editors are basically getting blocked because they don't know how to reply to talk page messages. This can't be good for any of us, including the four or five experienced people who have invested all this time explaining the system. I'm looking forward to a simple "reply" button. WhatamIdoing (talk) 00:28, 27 May 2013 (UTC)

Effect on Special:Statistics

Since each comment will effectively be a separate wiki page, what effect will this have on Special:Statistics? If every comment gets counted as a page, the number of pages will balloon very quickly. If this is likely to happen, adding a separate count of all pages excluding comments would be useful. – PartTimeGnome (talk | contribs) 18:15, 27 May 2013 (UTC)

Comparison of old and planned user-talk discussion systems

I would like to request a few additions to the "Comparison of old and planned user-talk discussion systems" table. They are:

You see rapid fire vandalism on a talk page and roll it all back with one click.

You see an incorrect link in a talk page comment and fix it.

You SPA tag all of the posts by a particular user.

You collapse an off-topic comment or thread.

You edit a comment with permission of the author.

You add a section heading, splitting one thread into two.

You remove a section heading, combining two threads into one.

You edit an inappropriate section heading.

You see that someone is top-posting and re-order the posts.

You put together a series of diffs for use when reporting a situation on a noticeboard.

You create a link to a talk page as it existed at a particular point in time.

You create a diff that spans several comments.

You are an admin and you revdel an "outing" comment.

--Guy Macon (talk) 08:24, 21 May 2013 (UTC)

I really think that addressing the above test cases would be useful. It look like some of them will have answers that amount to "doing that addresses a situation that can never arise with the new system" while others will have answers that amount to "that is a functionality of the old system that we are taking away with the new system". Right now the Comparison of old and planned user-talk discussion systems chart looks a lot like advertising the positives while ignoring the negatives -- and I am saying that as someone who thinks the positives outweigh the negatives by a huge margin. Will someone be addressing the above any time soon? --Guy Macon (talk) 22:58, 22 May 2013 (UTC)

Hello! Yes, I'll address them, and you're right, most fall into those categories. I'm fairly swamped right now and I can't get to this immediately but I will.--Jorm (WMF) (talk) 01:13, 23 May 2013 (UTC)

No hurry. --Guy Macon (talk) 02:06, 23 May 2013 (UTC)

I'd add "A bot delivers a weekly news digest to your talk page." Presumably Echo/Notifications handles this? πr² (t • c) 16:12, 23 May 2013 (UTC)

Old	New
You see rapid-fire vandalism on a talk page and roll it all back with one click.	Currently in design, so no answer yet. One-click reverts don't exist, actually (minimum two clicks).
You see an incorrect link in a talk page comment and fix it.	Only admins will be able to edit other people's comments.
You SPA tag all of the posts by a particular user.	You "reply" to all of the posts with an SPA tag.
You collapse an off-topic comment or thread.	You "close" an off-topic comment or thread.
You edit a comment with permission of the author.	Only admins will be able to edit other people's comments.
You add a section heading, splitting one thread into two.	You enter "thread split" mode, select the posts to split, and create a new thread.
You remove a section heading, combining two threads into one.	You merge two threads.
You edit an inappropriate section heading.	You edit the heading.
You see that someone is top-posting and re-order the posts.	You do nothing: Posts will automatically be ordered correctly.
You put together a series of diffs for use when reporting a situation on a noticeboard.	You will still be able to link directly to each comment.
You create a link to a talk page as it existed at a particular point in time.	? (The relevant comments will always be available; the links won't change due to archiving.)
You create a diff that spans several comments.	This doesn't make with Flow.
You are an admin and you revdel an "outing" comment.	You are an admin and you click the "delete" button to delete the user's post (which is right next to the "close" and "oversight" buttons in the prototype).
A bot delivers a weekly news digest to your talk page.	The bot can post a message to your board just like any other user.

Here's a start at the comparison. Feel free to fill in or to correct my guess at the answers. WhatamIdoing (talk) 02:00, 26 May 2013 (UTC)

Is there any chance that someone on the Flow team might fill in some of the above cases? --Guy Macon (talk) 01:33, 31 May 2013 (UTC)

You see that someone is top-posting and re-order the posts.

You do nothing: Posts will automatically be ordered correctly.

I don't think that will work if the person "topposted" by posting messages into the common area that's planned for FLOW which anyone can edit (the section that's supposed to contain the talk page disclaimers, wikiproject banners, previous deletion notices links) -- 65.94.76.126 (talk) 15:02, 31 May 2013 (UTC)

---

Above is an assertion that "Only admins will be able to edit other people's comments". That's a fundamental issue which anyone with enwiki experience would know is rather important. Last time I looked at as many places as I could find that mention Flow, I could not see any consideration of that point, so where does the assertion come from? Is that the "official" view? Johnuniq (talk) 00:14, 1 June 2013 (UTC)

Again I ask, is there any chance that someone on the Flow team might fill in some of the above cases and confirm that the guesses we made on the rest are correct? We are coming up on two week with no answers. Is there really no person on the Flow team who has time for this? With all due respect, Wikipedia:Flow#Planned features looks like the sort of all-good-no-bad material that we sometimes see from paid editors. In the real world, any new system will have a bunch of things it does better and a few things it does worse. You don't have to show only the improvements. All you have to show is that the upside outweighs the downside (which it clearly does) and that there are no dealbreakers. --Guy Macon (talk) 16:01, 2 June 2013 (UTC)

I am the only person officially working on Flow right now. There is no "team" as such (yet). My apologies about delays. I've answered in the table above.--Jorm (WMF) (talk) 21:16, 2 June 2013 (UTC)

This doesn't make with Flow. Is there some sense missing? ;-) So what would you do, post a list with links to each comment? Will there be a history page? — HHHIPPO 22:19, 2 June 2013 (UTC)

I think that this may have been me asking the wrong question. Let me be more verbose:

Currently: an editor makes a long series of rapid-fire edits to a talk page. Clearly he hasn't figured out that he can use the preview button instead of the save button. I want to make a diff, but no single edit makes a whole lot of sense, so in the history I select the radio buttons for his last edit and the last edit by another editor before his first edit, thus creating a diff that shows the net change to the talk page.

For this to even apply to Flow, there would have to be some sort of page history with a line item for each edit. If I understand Flow correctly, I should be able to link to a comment rather than to an edit, which would give me the latest version (you can edit your own comments, right?) This solves the "no individual edit shows the entire change he made" problem.

However, I am not sure what will happen if I do need to post a diff to an edit or to two consecutive edits out of a string of ten rapid-fire edits. This sort of thing is often needed when putting together evidence for a ANI, RFCU, or ArbCom entry after someone posted something and later modified it. --Guy Macon (talk) 01:11, 3 June 2013 (UTC)

Okay, I understand your use case better, and it's one I've thought about. I'm guessing we're looking at a situation where someone says "Yeah, yeah, I agree, but FUCK YOU" and then edits it to say "Yeah, yeah, I agree, but I think this is uncivil" or something along those lines - you want to illustrate bad faith or something along those lines.

There will likely be a kind of "history for a comment" pane that can be accessed. I cannot promise it will behave like you're describing (to be honest, the way a history page works today is insane with regards to usability) but you'll be able to point to a trend. A user who edits his own comment four thousand times is unlikely. The use case you're describing is important when the discussion is a single "flat space", which we'll be solving for.--Jorm (WMF) (talk) 01:16, 3 June 2013 (UTC)

One-click reverts don't exist, actually (minimum two clicks). The "Old" column is talking about rollback, which "allows the last user's edits on a given page to be undone with a single mouse click". I've not used it myself, but I've seen many other users describe it in similar terms. If this is incorrect, our documentation on rollback needs updating... – PartTimeGnome (talk | contribs) 01:57, 3 June 2013 (UTC)

It's two clicks, possibly more: you have to click to the history view first, and then click rollback, ata minimum. That's two.--Jorm (WMF) (talk) 02:00, 3 June 2013 (UTC)

Ah, I suppose it depends where you're counting from... Note that rollback is also available from the the watchlist and recent changes, without any need to even view the article. – PartTimeGnome (talk | contribs) 02:10, 3 June 2013 (UTC)

I've moved the items that seem to have accepted answers to the table on the main page. Here's what seems to be left:

Old	New
You see rapid-fire vandalism on a talk page and roll it all back with one click.	Currently in design, so no answer yet. One-click reverts don't exist, actually (minimum two clicks).
You SPA tag all of the posts by a particular user.	You "reply" to all of the posts with an SPA tag.
You create a link to a talk page as it existed at a particular point in time.	? (The relevant comments will always be available; the links won't change due to archiving.)
You create a diff that spans several comments.	This doesn't make with Flow.

These are probably correct (although I suspect that the word sense is missing from that last one), but I thought I'd wait a bit before posting them. WhatamIdoing (talk) 00:42, 11 June 2013 (UTC)

As a possible partial answer to rapid-fire vandalism, it should be possible to delete a comment and all replies with a couple clicks, rather than having to delete each reply individually.

But I disagree that that having new comments appear in your "feed" is adequate to handle the question of determining what changes were made in the thread; you might need to be able to see the entire thread with new comments marked. (And would this would mean you have "watchlist pointers" in each thread, or a mark whether you've seen each comment. I'm getting to like the (changes since last view) feature. Have we lost that entirely, now?)

And, there may still be contexutal edit conflicts. If someone writes comment B as a reply to comment A, and comment A is then edited, (or even, watching timestamps, if comment A is edited between the time comment B is started and when it is saved), there could be serious misinterpretations. — Arthur Rubin (talk) 20:55, 28 June 2013 (UTC)

Just because the software doesn't block edit conflicts, it doesn't mean they weren't really there. — Arthur Rubin (talk) 20:56, 28 June 2013 (UTC)

Flow and the visually impaired.

I am about to try an experiment, and I would like others here to join me. The NonVisual Desktop Access (NVDA) screen reader and eSpeak speech synthesis program are widely used open-source screen readers. Although my vision is normal, I am going to attempt to do everything I normally do on my computer with my monitor turned off using just the screen reader. One of the things I aim to do is to test Wikipedia:Flow to see how well it works for the blind.

I would like to persuade other users to do the same experiment. If we have a few users running screen readers, we will be able to smoke out accessibility problems early. Here are some links that might help to get you started:

http://webaim.org/articles/nvda/

http://sourceforge.net/projects/nvda/

http://www.nvaccess.org/

http://community.nvda-project.org/documentation/userGuide.html

http://www.marcozehe.de/articles/how-to-use-nvda-and-firefox-to-test-your-web-pages-for-accessibility/

http://espeak.sourceforge.net/

Please report any success, failure, or questions in this thread so we can all learn from your experience. Thanks! --Guy Macon (talk) 14:29, 31 May 2013 (UTC)

I'm going to tell you that if you try to use this on the prototype, you will fail, utterly and completely. So I'd just ask that you not try to do that because the prototype is just exactly that - a prototype - and exactly zero effort has gone into making it accessible. It is held together with sticks and bailing wire and trying to test it as if it were real-world software is going to be non-productive.--Jorm (WMF) (talk) 18:02, 31 May 2013 (UTC)

Good point. Nothing wrong with starting with a no-optimized prototype. In fact, early optimization is a good way to screw up a software project. Let us know when you have something testable.

I expect to find some interesting things on the rest of Wikipedia, though.

BTW, it should not be assumed that any accessibility problems require changes on our end. It might turn out to be a lot easier to submit a patch to the open-source NVDA project to make it work better with wikimedia pages. --Guy Macon (talk) 18:33, 31 May 2013 (UTC)

@Guy Macon:. Such an experiment in itself (for Wikipedia) is very welcome btw. Wikipedia:WikiProject_Accessibility has some interested users, and if you create a good report and send it out into the world, I'm sure at least several developers would be interested in it. —TheDJ (talk • contribs) 12:15, 2 June 2013 (UTC)

For whatever it's worth, I actually quickly tested the prototype with JAWS (not an exhaustive test, but I didn't think it warranted it) and didn't find any accessibility issues. Graham87 12:18, 7 June 2013 (UTC)

Ad

A couple of us have been playing with a new {{Flow ad}} that we hope users will want to place on the individual user talk pages (I don't think it would be as appropriate on other pages, since Flow won't reach other talk pages for a long time). We've set up a few different slogans and come up with some more ideas. Feel free to add your suggestions to the list (currently located on the template's /doc subpage; I suppose that we ought to move it all to the template's talk page now that it's out of userspace). WhatamIdoing (talk) 21:44, 9 June 2013 (UTC)

Is there a clear statement somewhere of what Flow is planning to do—with a few details beyond modern messaging system? Until there is such a statement, I do not think further marketing would be desirable.

What wikitext markup will work? Will tables work? Images? Will templates work? While many templates on talk pages could be replaced with something else, the whole point of many discussions is to discuss a template, with demos. What about other talk pages and noticeboards? Having one system on user talk pages and something completely different everywhere else is obviously undesirable, so what is proposed? Johnuniq (talk) 02:08, 10 June 2013 (UTC)

If people don't know that it's being planned, then how will they have any practical opportunity to provide their views at the design stage? It's not really useful to come back the day before the deployment and say, "Oh, by the way, how do I carry on a discussion at [:Template talk:Unreferenced] about my proposed change, if Parsoid prevents me from showing people what I'm talking about?" Making people aware of this planning process, so that they can say "I really need this specific functionality" now, instead of when it's too late, is the point. WhatamIdoing (talk) 17:36, 10 June 2013 (UTC)

What's so irritating is that there is no documentation on a proposal which aims to completely replace all talk pages at Wikipedia (it starts with user talk, but it has to aspire to replace all discussion pages including noticeboards as it would be silly to have two different discussion systems). What is being planned?

Documentation needs to state the facts, and things which are not known would simply be described as that. But currently no clue is available about intentions or motivation ("modern messaging system" might sound good for management, but many editors are clever enough to recognize that as a content-free slogan). For example, documentation would clarify whether it is hoped that templates will be supported, or whether it is intended that templates will not be supported. Would a new right be created, and users with that right would be able to edit/delete messages? The initial release may restrict that right to administrators, but is the intention to make the right available for other groups (such as rollbackers) if desirable? Anyone with experience at Wikipedia knows that spam/trolling/junk needs to be removed ASAP, and running to an admin for every piece of nonsense removes autonomy and responsibility from editors. Similarly, general documentation for the points raised at the various places Flow has been discussed needs to be put on one page by the person working on the project—useful software cannot be written without a clue about the direction. Johnuniq (talk) 23:18, 10 June 2013 (UTC)

Did you check the project page, for this talkpage? There's a lot of documentation, all listed in the sidebar, at top. (It's a cross-Wikipedias project (all languages) hence most pages linked in the sidebar are located at mediawiki. Plus that's where the software developers (both volunteer and paid) do their work).

And it's all in the planning and prototyping stages right now, so this is exactly why we're discussing it now!

(Note that the various wordings of the {{Flow ad}} (click it, there is documentation there too!) were written by WhatamIdoing and myself, and are a totally unofficial attempt to bring more editors into the discussion. If you have suggestions for improving the wording in each of the flow ads, it'd be appreciated. My examples were invented after reading through many of the official documentation pages.) –Quiddity (talk) 23:52, 10 June 2013 (UTC)

John's correct that there's no documentation, in the sense of a Help:Flow page that tells people exactly how to do things. But there is certainly information available about the general idea. mw:Flow Portal/FAQ might be a good place to start.

(On the question of templates, previous discussions seem to have gotten confused about templates in signatures, which are (1) already banned here anyway and (2) specifically rejected for Flow's early versions, and templates on pages, which is unknown, because the problem with using templates has nothing to do with Flow and everything to do with Parsoid. Having said that, the use cases document many instances of things that Flow is required to support that happen to currently be handled through templates, and those functions will be supported, even if Flow doesn't technically "use a template" to achieve the same end.) WhatamIdoing (talk) 00:05, 11 June 2013 (UTC)

Yes, I read all the docs I could find when Flow was first mentioned (and I am not looking for a "how to", just plans). I reviewed the sidebar—the linked pages have quite a bit more info than when I last looked, so thanks for the reminder. However, most of the pages are very generic and not useful as statements of intent. No doubt nuggets of information are on many of them, but it seems mw:Flow Portal/Basic information has most details (am I reading that correctly? it will no longer be possible to watch a problematic user's talk page?). It is a bit hard to separate the background thoughts from the current aim of Flow, and a quick skim did not answer my questions. The concern about templates is that editors sometimes need to discuss templates (not that they want to use them for decoration). One small example is here. Johnuniq (talk) 00:48, 11 June 2013 (UTC)

You are not correct, except in a very technical sense: you will "subscribe to the problematic's user's board" rather than "watch his talk page", but the effect will be the same. It's the second item in the table at Wikipedia:Flow#Planned features.

You will be able to discuss templates. mw:Flow Portal/Use cases says that template support is part of the Minimum viable product ("MVP"). WhatamIdoing (talk) 01:04, 11 June 2013 (UTC)

My reading of mw:Flow Portal/Basic information#User subscription and permissions is that if X subscribes to Y's board, then Y is notified, and Y has to approve X's subscription. It is reasonable to monitor a user, but notifying them of your intention is likely to be counterproductive, and asking their permission is not reasonable. I'll take your word for it regarding templates, but I can't see that on the use cases page. Johnuniq (talk) 01:41, 11 June 2013 (UTC)

Unfortunately, this mentioned template support is only for the thread metadata, that is the thread header, and not for the comments themselves, which would make the whose system totally unworkable, as noted at mw:talk:Flow. Cenarium (talk) 09:17, 29 June 2013 (UTC)

Regarding "using templates has nothing to do with Flow and everything to do with Parsoid", the decision to restrict Flow to only being used with the VisualEditor (which depends on Parsoid) is to do with Flow. Were the normal source editor permitted, it could be used for those cases where the restrictions of Parsoid make the VisualEditor unsuitable. – PartTimeGnome (talk | contribs) 18:54, 11 June 2013 (UTC)

Template:Flow ad If I've got this right, then {{Flow ad|ad={{CURRENTDOW}}}} will cycle through the various options, one per day. WhatamIdoing (talk) 00:18, 11 June 2013 (UTC)

RSS feed from a board

Jorm (WMF), I'm sorry if this doesn't make sense, but I'm a little out of my depth. I believe that it's currently possible for anyone (not just a registered editor) to set up an RSS feed on a user's talk page. Assuming that's so, will the same thing be possible on a user's Flow board? WhatamIdoing (talk) 15:02, 11 June 2013 (UTC)

That is a very good question, and one I hadn't thought deeply about. I should think it should actually be easier to do with Flow, from a technical standpoint. I'll have to bring that up with Erik on the implementation side. There's possibly some goofiness given that we're not going to be storing things on the local wiki.--Jorm (WMF) (talk) 18:56, 11 June 2013 (UTC)

It's disappointing to hear that this hasn't really been thought about. Very important to get RSS working. II | (t - c) 17:06, 21 June 2013 (UTC)

I haven't thought about this in detail because, as someone who has implemented RSS feeds multiple times, I know that it's a total non-issue and can be done in about 10 lines of code. It's not on my radar of difficulty.--Jorm (WMF) (talk) 21:17, 1 July 2013 (UTC)

So here's what I want you to think about: In at least some configurations, I can only "subscribe" to your board if you give me permission. But I can have an RSS feed to exactly the same information without even having an account. Does the "permission" module actually make any sense for a public wiki? (I can see the utility for private/corporate wikis, but that's not what we have here.) WhatamIdoing (talk) 20:22, 9 July 2013 (UTC)

A bit dubious

Wikipedia:Flow is just...why? Why is modern intrinsically better? If talk pages become like that I will not use them any more. Talk pages here are like articles: anyone can edit any part of them. Why should we change that? So you can edit other people's comments. So admins have to use revisiondelete to remove objectionable content. How is that bad? Refactoring comments is part of how talk pages work - it's actually an important part of how they work, just read the relevant guidelines and you'll see why. Flow will remove that ability from most of us. I see no benefit in relegating comment refactoring to 'trusted users' - the only 'benefit' there is that you have to jump through more hoops in order to be able to refactor comments. Why? Whatever for?

As for automatically moving comments to the proper place, there is a banner on many talk pages stating explicitly that new comments go at the bottom, and there is a notice when editing any talk page, as follows:

This is a talk page. Please respect the talk page guidelines, and remember to sign your posts by typing four tildes (~~~~).

There is no reason to have the software do what editors should be able to do for themselves, is there? If they can't or won't do it for themselves, are they really the sort we want to encourage?

I know it sounds illogical and power-user-ish, but one of my fears for Wikipedia is that it is becoming a social networking site with only secondary emphasis on being an encyclopedia. These new proposals I am encountering lately seem to confirm this. True, the resemblance to a social networking site may now be only in the terminology proposed (feed, message board, etc.), but it is not impossible that one day it will extend farther, into parts that really matter. Wikipedia is an encyclopedia. Changing how it works for no reason other than 'users expect and deserve a modern interface' does not appear to harmonize with that. Where does it end? Where do we draw the line? For we must draw a line. Encyclopedias are not quite a thing of the modern world, and if we are to truly modernise Wikipedia we may end up destroying it. By that time I will have left, perhaps by force (requesting a block); I am sure you will not miss me as I am not a major editor, but some of us who are major editors may leave as well, and then where will you be?

I fear I have written a lot of nonsense. Are my concerns valid or have I got it all wrong? Cathfolant 00:05, 28 June 2013 (UTC)

Ych...that was badly worded. And not terribly civil. Take it with a grain of salt, please. Cathfolant 00:42, 28 June 2013 (UTC)

Fear not that it be coming, for it already did. Look at the WP:Teahouse and tell me how "profiles" contribute to encyclopædia-building. Tell me what is the value of the "Teahouse First Birthday Badge" or the "Great Question Badge". Tell me what is the point of userboxes like "This user is gay/a fan of U2/Scientologist". Tell me why we tolerate guestbooks and excessive style customisation in userspace, to the point that no two user pages. Fear it not, it is already hear.

You have not mentioned any specific editor yet, and you worry about being uncivil? Please. I think that the obsession of (at least some part of) the community with "civility", "WikiLove" or "assuming good faith" is actually one of the contributing factors to the "socialnetworkification" of Wikipedia.

Though I disagree about Flow. This is something that we actually need. For some people, even putting a colon at the start of a line can be a problem. And yet they might contribute something that the technocrats will not. Putting it in the article space right away might not be the best idea — but these users should at least be able to get the information out there, so that others can handle incorporating it. There might be a reason for a barrier to entry for editing (users should learn the editing policies first, for one), but there is no such reason for a barrier to discussing improvements. This is something we should make as simple as possible, and no simpler. On another hand, Flow can help with reducing editors' egos — everyone's talk pages will look the same, and fancy signatures will disappear. This is a huge plus.

If you have objections about specific issues, raise them here or on mw:Talk:Flow Portal. (Now that you mention it, I kind of agree with you about post redacting, for instance.) Keφr 07:05, 28 June 2013 (UTC)

You realise feeds and message boards on the internet predated both wikipedia and anything remotely resembling a social network site right? Nil Einne (talk) 20:36, 28 June 2013 (UTC)

There are many things I don't realise, and that was one of them. Just the same, they have become associated with social network sites, and that is why their appearance here gives the impression that Wikipedia is turning into one of those.

I do not agree with 'profiles' either, something that has also appeared on Wikia wikis (one of the many reasons I generally stay far, far away from them, in fact), for this reason. I haven't looked at the Teahouse but if that's how it is there I'll take your word for it.

About civility - that was the wrong word. I saw my post as fairly vague, somewhat attackish and not all that helpful, but not necessarily 'uncivil' in the strict sense. I believe actually that the civility guidelines are intended to keep Wikipedia encyclopedic and prevent it from becoming like a social networking site; a closely related principle is that of commenting on content and not the contributor, which seems clearly meant to promote an atmosphere of building an encyclopedia and refraining from discussing the users. The barnstars, WikiLove and things can similarly be construed as being intended to encourage users to contribute more by letting them know their work is appreciated. The userboxes also may have started out as a way of providing information directly or indirectly relevant to the wiki; I would say mine are in some way or another, but that can't quite be argued to be the case for other boxes, I'll admit. I don't believe any of it, except maybe some of the userboxes, is really intended, consciously, to create a social network atmosphere. That is only its effect.

I suppose you could be right about colons and that. I wasn't sure what to do with them at first either and I still make the occasional mistake; and I've seen a lot of comments left in the wrong place - apparently the notices about how to comment on talk pages aren't doing the job in every single case.

However, I don't necessarily agree about using Flow to get rid of signatures (it would eliminate the need to sign, but we have bots for that, don't we?). This one could in theory be easily changed by removing the signature customisation thing from Special:Preferences. I'm not sure how much they really correlate with big egos, but in any case I've reset mine to the default: Cathfolant (talk) 21:38, 30 June 2013 (UTC)

About ease of editing talk pages. I am actually worried that Flow will not make it easier, only different, or maybe even harder. Yes, it will be easier for new users, but established users will have to get used to a whole new way of doing things. I think I'd feel more intimidated by a forum-looking bunch of threads that was automatically archived and rigidly ordered than by a wiki page exactly like an article where I was fully in control of what I was doing - this could be just me though. I am a bit of a control freak and I like to know exactly how things work. I don't like to be forced to spend less effort on doing things correctly. However, I suspect there are a lot of us who feel the opposite.

Finally, I don't understand how some of the properties of Flow are actually different or an improvement. For example, what difference does it make if a bot delivers a paper to your talk page or to your 'message board'? I suppose the idea is that you'll have a board instead of a talk page? This is confusing. Or clicking an edit button instead of an edit link. A lot of these changes seem designed just to be more like a forum and not necessarily easier to use. Can anyone explain this? Cathfolant (talk) 21:56, 30 June 2013 (UTC)

Some of these, like the bot delivering a message to your board, are meant to have as little change as possible. The only reason these are mentioned is because people have rather oddly jumped to the opposite conclusion about every feature that isn't explicitly mentioned (and even many of the ones that are, because WP:Nobody reads the directions anyway). WhatamIdoing (talk) 14:05, 1 July 2013 (UTC)

Request for Comment on editing other user's comments with Flow

Background: Wikipedia:Flow is a planned improvement to MediaWiki talk pages. As with any major software change, some things that used to be difficult or impossible will become easy, and some things that used to be easy will become difficult or impossible. This is the nature of software upgrades and is specifically not part of this RfC.

This RfC is about a proposed policy change which has been bundled with the technical changes: Who will be allowed to edit another person's article talk page comments? Clearly there is no technical reason that forces a particular answer to that question; it could be anyone, autoconfirmed users only, administrators only, bureaucrats only, nobody, or even a newly-created user group.

When thinking about the question of who will be allowed to edit another person's article talk page comments, please don't make the mistake of only considering some kinds of talk page comments. The policy must be able to deal with every situation: a vandal who doesn't like a well-thought-out comment from an established user, a vandal-fighter who is cleaning up after a spammer who hit hundreds of pages, two edit warriors who have decided to go after each other with guns blazing, and all of the other examples found in WP:TPOC.

Another aspect to consider is workload. The English Wikipedia has 47,404,845 registered users, 121,501 active editors and 859 administrators. Any time you take work away from ordinary editors and give it to administrators, you need to ask whether they will be able and willing to shoulder the extra load.

Please note that administrators have all the powers of rollbackers, rollbackers of reviewers, reviewers of autoconfirmed, and autoconfirmed of unregistered. Thus you only have to support the lowest level that is acceptable to you; you don't have to explicitly support reviewers or administrators if you support autoconfirmed users. That's a given. --Guy Macon (talk) 12:45, 28 June 2013 (UTC)

Survey: who should be allowed to edit another person's article talk page comments?

Use: # '''Support:''' (Reason) --~~~~

Support all users

This includes IP Users (see Wikipedia:User access levels#Unregistered users). This is what we allow now.

---

1. Support: I see no reason to change existing policy from a social standpoint merely because of a technical change. We can deal with abuses the same way we do now. No need to fix something that isn't broken here, and if Flow allows it technically, then I see no reason to not allow it. --Jayron32 15:33, 28 June 2013 (UTC)
2. Support: No reason given to change. Edgepedia (talk) 17:07, 28 June 2013 (UTC)
3. Support. If we don't let IPs edit talk page comments, we might as well not let them edit at all. Treating IP editors like other editors is a well-established principle here, and not allowing them to refactor talk page comments is essentially denying that they can become established, trusted users, even if it may let in vandalism. Also per above. Cathfolant 17:23, 28 June 2013 (UTC)
4. Support Yes, you shouldn't normally edit other people's comments, but exceptions always happen, and as Cathfolant says, this would place additional barriers (of which too many already exist) between registered and nonregistered people. The existing system is substantially better than this coming Facebook-style setup; since WMF are forcing it on us, we'd better do our best to blunt its changes by retaining as much as we can. Nyttend (talk) 21:04, 28 June 2013 (UTC)
5. Support. Note that WP:NPA states that "Derogatory comments about other contributors may be removed by any editor." --Apteva (talk) 00:12, 29 June 2013 (UTC)
6. Support There is no reason to pre-emptively deny permission for something so basic just because a new software feature would allow us to do so, and there is certainly no reason an admin should be required to remove talk page vandalism or trolling, and of course I very strongly support the idea that users be allowed to remove anything they like from their own talk page. Beeblebrox (talk) 01:06, 29 June 2013 (UTC)
7. Second choice per Nyttend, the first being the consignment of this project to landfill. MER-C 03:04, 29 June 2013 (UTC)
8. Support - per all above, it's doubtful we would want to change a core principal of Wikipedia. Mlpearc (powwow) 03:18, 29 June 2013 (UTC)
   • Is "Make sure that all users have the ability to add the word not to your personal signed comments (or remove it)" actually a core principle of Wikipedia? Is it actually a core principle that someone be able to remove your "support" comment and replace it with a "Letting people change other people's comments is stupid" comment that appears (to anyone not searching through the diffs) that you personally oppose this? WhatamIdoing (talk) 09:49, 30 June 2013 (UTC)
9. Support - Yes. Editing by all has never been a problem, it there is no significant advantage to changing it. Legoktm (talk) 21:50, 29 June 2013 (UTC)
   • If it's "never been a problem", then why do I have to keep making reverts like these?[9] [10] [11] [12] [13] [14] [15]. WhatamIdoing (talk) 09:49, 30 June 2013 (UTC)
10. Support. I've waited a while to decide since when I first saw the RfC, because I really had to think about it. After all, we're talking about who can do something that usually should not be done anyway. And if I'm reading the table on this page correctly, the current plan is to limit it to administrators, which strikes me as a lousy thing to inflict on administrators. In the status quo, anyone can change someone else's edit on an unprotected talk page, and anyone else can revert that change. Unless reverting is going to get a lot more difficult under Flow (will it?), I don't see that much need to change this aspect of policy along with changing the interface. But I've taken very seriously the arguments made for autoconfirmed, and I agree that it's going to be an increasing problem to deal with vandalism and general stupidity, so we may end up eventually having to put restrictions on non-autoconfirmed users after all. And I'm someone who has one of those "registration should be required to edit" user boxes on my page, even though I generally get along just fine with IPs and I'm not really convinced that we should actually do what the user box endorses (go figure). But I'd like to try starting out without those restrictions. --Tryptofish (talk) 22:23, 29 June 2013 (UTC)
11. Support - IPs are human too! I agree with most of what was said above. Talk page comment refactoring isn't a common form of vandalism, and I see no reason why we can't continue the existing policy. Michaelzeng7 (talk) 01:36, 1 July 2013 (UTC)
12. Support Don't see any reason why we should change this. Armbrust ^{The Homunculus} 18:35, 1 July 2013 (UTC)
13. Support. The current setup works well, and comment-vandalism is extremely rare. -- Ypnypn (talk) 02:47, 2 July 2013 (UTC)
14. Support. If it ain't baroque, don't fix it. rʨanaɢ (talk) 11:55, 2 July 2013 (UTC)
15. Support I agree that no change from traditional practice is warranted at this point. If it turns out to be demonstrably problematic on a large scale in the future, this may be considered again. Though we can anticipate that problems are likely to arise punctually on some active talk pages (e.g. Talk:Barack Obama), the proper way to handle that is by providing a form of page protection by which admins can restrict other users' comment editability. Cenarium (talk) 21:11, 5 July 2013 (UTC)
16. Support I don't think the status quo is broken, so I don't want to "fix" it. --BDD (talk) 16:52, 8 July 2013 (UTC)
17. Support. It's a wiki. --Yair rand (talk) 06:01, 9 July 2013 (UTC)
18. Support There are as many problems with IPs editing talk page messages than there are articles, where most are contributive, and User talk pages are not seen often by vandals who go to more-read articles. ~~Ebe123~~ → report 19:27, 13 July 2013 (UTC)

Support autoconfirmed users

(See Wikipedia:User access levels#Autoconfirmed users).
These are the editors who can edit semi-protected pages. We have 47,404,845 autoconfirmed users, 121,501 of whom are active editors.

---

1. Support: This one seems most appropriate. In the current setup, even IPs and new accounts can edit others' TP comments, so restricting the ability to confirmed users may eliminate a bit of vandalism. I've most often edited TP comments to remove e-mail addresses or other contact information, and it would be a pain for a regular user to have to contact a rollbacker or reviewer in such instances. In my experience, any users who improperly edit others' comments are quickly reverted, and I'm sure it will be the same with Flow. --Deor (talk) 13:59, 28 June 2013 (UTC)
2. Support. I want the first person who spots it to be able to remove template vandalism or inappropriate/harmful urls or spam. Spam, in particular, is starting to take over smaller projects, and will only get worse here as our RC patrol corps dwindles. As well, I think users should be able to manage what is and is not on their own board, including having the right to remove or alter messages that they feel are inappropriate. Risker (talk) 06:28, 29 June 2013 (UTC)
3. Support. Risker's argument above convinced me to change my support from "reviewer" to "autoconfirmed". I carefully read the arguments above supporting "all users" and my conclusion is that autoconfirmed is a better choice. IP users would still be able to revert article vandalism, which is where at least 95% of the vandalism happens. Except in certain well-defined cases, our policy already forbids editing another editor's signed comment, and it is not reasonable to expect a new IP editor to know what those well-defined cases are. --Guy Macon (talk) 17:33, 29 June 2013 (UTC)
4. Support - on consideration, I think there's good reason to limit IPs from being able to edit other users' comments. I wouldn't go any further, though: in general, this is an option that should be available to all users when necessary. But it seems reasonable to keep it from the newest users, who will be less aware of when editing other users' comments is appropriate and more inclined to vandalise them. Robofish (talk) 21:01, 30 June 2013 (UTC)

   • Not all IP editors are new, hence my vote. Cathfolant (talk) 22:07, 30 June 2013 (UTC)

5. Support. I've fixed (and seen fixed) many old instances, of IP-users deleting/mangling/altering the comments of other editors (Similar to WhatamIdoing's examples above. Or this example from yesterday, where I had to search through a lot of diffs, to determine who had deleted what, and when.). It's rare that an IP-user fixes the comments of another editor (It definitely occurs, but it's rare proportionally). –Quiddity (talk) 22:39, 30 June 2013 (UTC)
6. Support. With this new system in place, I think a minor restriction like this just naturally comes with the territory. In particular with its user-friendliness and similarity to other web forums it can be argued that unhelpful IP editing and trolling of other users' comments would actually increase once they notice that they "can actually do that here". -- œ^™ 02:10, 1 July 2013 (UTC)
7. Support I've seen too much mangling of talk page comments by IP users. If something needs prompt action on a talk page, one of the 100,000 plus active autoconfirmed users can handle it. Edison (talk) 19:51, 11 July 2013 (UTC)

---

Support reviewers

(See Wikipedia:User access levels#Reviewer). You become a reviewer by asking an administrator to make you one, and any administrator can revoke the permission. These are the editors who who are able to review other users' edits to articles placed under pending changes protection. We have 8,831 reviewers.

---

1. Support: The level of trust needed to review pending changes is roughly equivalent to the level of trust needed to edit another user's talk page comments. This and rollbacker are the user rights on this list that are most easily revoked if they are abused. --Guy Macon (talk) 12:21, 28 June 2013 (UTC) ^{Note: Risker's argument above convinced me to change my support to autoconfirmed. --Guy Macon (talk) 17:19, 29 June 2013 (UTC)}

---

Support rollbackers

(See Wikipedia:User access levels#Rollback). You become a rollbacker by asking an administrator to make you one, and any administrator can revoke the permission. These are the editors who who are able to "roll back" several changes at once instead of one at a time. We have 7,687 rollbackers.

---

1. Support: (Reason) --~~~~

---

Support administrators

(See Wikipedia:User access levels#Administrators). You become an administrator through the requests for adminship process. We have 859 administrators.

---

1. Support: (Reason) --~~~~

---

Support another user group not listed

Note: if you want to create a new user group, please explain in detail why none of the current user groups are suitable.

---

1. Support: (Reason) --~~~~

---

Threaded discussion

Please respond here rather than inserting a threaded discussion into one of the support lists.

---

• Comment: To find out what user permissions you have, go here and type in your user name (without the "User:") --Guy Macon (talk) 14:13, 28 June 2013 (UTC)

• For starters, i would like a bit more clarity on what exactly we are talking about here. Currently anyone can edit another person's comments, but in most cases they shouldn't. Are we talking about technically restricting the ability to edit other people's comments or just a rule change? It's not clear from what I am seeing here so far. You also mention workload. What workload is there that is generated by the ability (need?) to edit other people's talk comments? That's totally unclear to me. Would this mean that only users in this new restricted group could archive user talk pages? Beeblebrox (talk) 14:32, 28 June 2013 (UTC)

• We are talking about the software not allowing certain people to edit other people's comments, and the question is who. Flow will make many things that are now policies or guidelines moot. For example, if I don't sign this, you might point out that I should, template me, etc. Once Flow is running, it will be impossible for me to not sign my comment.

The workload issue is this: Right now, if I see that someone has posted !!!PIGGERS ARE AWESOME!!! !!!GO PIGGERS!!! I can click my handy rollback-vandal button and it instantly goes away and the user's talk page opens so I can drop a template there. If Flow takes that ability away from me, I will have to ask you and you will have to do a bit of extra work (or maybe a lot if Flow makes it cumbersome for you). There are 85 active editors for every administrator, so you might have to spend a fair amount of time doing things like that for me and 84 of my close personal friends. And that's assuming that every administrator pitches in equally. --Guy Macon (talk) 15:48, 28 June 2013 (UTC)

Re: "Would this mean that only users in this new restricted group could archive user talk pages?" as far as I can tell (details are sparse) manually archiving will be as impossible -- for everyone from a new IP editor to Jimbo -- as not signing your posts will be, because the entire concept of archiving will be gone. WP:FLOW says "No need to archive discussions—old posts will automatically 'fall off' the page, and can be retrieved by scrolling down or searching for them.". --Guy Macon (talk) 16:08, 28 June 2013 (UTC)

Thanks for clarifying all that. Beeblebrox (talk) 01:08, 29 June 2013 (UTC)

I think it would be a mistake to not make a readily accessible automatic archiving system whose speed could be configured per talk page, since users may be tempted to comment in old discussions, manually 'hatting' threads as proposed would be too time consuming. A further issue is that we often 'deactivate' talk pages which are no longer in use and put their archives in the archives of another talk page (e.g. WT:PC). Cenarium (talk) 19:53, 28 June 2013 (UTC)

I guess we'd have to set an upper limit for automatic archiving, for example 3 months (configurable in mediawiki space), valid for all pages, with the possibility for, for the sake of argument, autoconfirmed users, to set a quicker automatic archiving period on a given talk page, to manually archive threads (which would be different from hatting, since hatting would let recent discussions visible until archived), and unarchive threads. Then we would need a way to deactivate a talk page and link the archives of this talk page from abroad. Cenarium (talk) 19:58, 28 June 2013 (UTC)

You may wish to familiarize yourself with the actual documentation describing the way that archiving works before commenting on it.--Jorm (WMF) (talk) 20:08, 28 June 2013 (UTC)

I did, and I maintain that not allowing a quicker archiving period to be configurable on specific talk pages, would make the system unwieldy. On very active talk pages, the archiving speed can be set as fast as every 36 hours. We need a system that can handle both quick archiving and easy access to archives, even recent ones. One of the reason liquid threads failed is that it couldn't handle very active talk pages. I'm unsure as to the meaning of "based on the type of discussion" but it doesn't seem to mean per talk page to me. Being able to deactivate talk pages, redirecting them to others and linking their archives is also important, I don't see it addressed, a way to do that would be by allowing admins to move threads to another talk page. I'm aware this is in development, and this only concerns user talk in first release, though some user talk pages are also highly active (jimbo for example), those are just preliminary suggestions. Cenarium (talk) 20:38, 28 June 2013 (UTC)

Why wouldn't archiving just work by line count instead of time based archiving? It seems that a huge wall of text is what we want to avoid and line count would be better than straight time. I believe the archival systems already allow that option. 174.118.153.129 (talk) 02:57, 29 June 2013 (UTC)

Isn't it premature to talk about required policy changes due a technology/extension that hasn't had a line of code written for it yet? YuviPanda (talk) 16:45, 28 June 2013 (UTC)

@Cenarium:: is it that you want topics to be shuffled off into the Great Unreadable Void sooner, or that you want people to stop responding to them sooner? The first seems anti-constructive to me; the second is clearly solvable in software by adjusting the "time to stale" element on a topic. But this assumes that a single page "owns" a topic in Flow, and that's just not the case at all. Topics are self-owned entities. They may have multiple "associations" - multiple Boards wherein they appear - but that doesn't mean that the exist in only one location.

Consider a hypothetical future where a vibrant, fully fleshed AFD workflow exists. A topic about an article's deletion could appear in multiple places: a list of AFDs, the Board of the nominator, the Board of the person who created the article, the article itself, etc., etc. Each of these may choose to have different "stale" and "close" times. Which takes precedence?--Jorm (WMF) (talk) 01:38, 1 July 2013 (UTC)

(EC)Isn't it a bit premature to hire an architect to design a house before one nail is driven? Not capturing Software requirements before coding is a classic rookie mistake. Read about it at Software development process and Requirements engineering. --Guy Macon (talk) 17:04, 28 June 2013 (UTC)

I don't think Yuvi needs a primer on software development and I think that referring to the development team as "rookies" is rude. Feel free to be rude to me, but not other members of the staff.--Jorm (WMF) (talk) 20:08, 28 June 2013 (UTC)

And how was I to know that he was a member of the staff? Nothing in his question or signature indicates that. Do I now have to check the home page of everyone who asks a question on an RfC on the off-chance that they might be a staff member? Now that I do know, I am at a loss as to why he appeared to advocate coding before capturing requirements. He couldn't possibly have meant that (I am sure that he has read The Mythical Man-Month just like everyone else working in software development) and thus I can only assume that somehow I have somehow completely failed to parse his actual meaning. --Guy Macon (talk) 22:42, 28 June 2013 (UTC)

Not commenting as a staff member (and in this case IMO irrelevant, since I've nothing to do with Flow). Ignoring the attempts to 'school' me, with articles of currently dubious quality(Requirements engineering) - can you tell me why this should be dealt with right now, as an RFC for a particular solution ('who can edit whose posts') - rather than as discussions about the underlying problems (which, from my reading, primarily seems to be 'vandals!') and their potential solutions? YuviPanda (talk) 13:50, 29 June 2013 (UTC)

You gave no indication that you were anything other than what you appeared to be from your post -- someone who knows nothing about software development. Thus my "schooling" you by pointing you to the Wikipedia page on the topic that you gave every appearance of being ignorant of was entirely appropriate given the information I had at the time. If you wish to be treated specially because you are a software developer or WMF staff member, you need to mention that fact. I cannot read your mind and it is unreasonable to expect me to read the user page of everyone who asks a question before I reply. I advise that you and Jorm drop the WP:STICK. I did nothing wrong.

As for "why this should be dealt with right now" That has been dealt with in detail in another section. Do a search on "What functionality, exactly, will I be losing here" and you will be at the top of the relevant discussion. --Guy Macon (talk) 21:34, 30 June 2013 (UTC)

And how was I to know that he was a member of the staff? - my next question would be why you feel it is okay to be rude to anyone, let alone staff members? I would encourage you to assume good faith - not just about intent, but also skill level and mastery of technique. Posting links to articles does not make you an expert in using them.

Additionally, it seems to me that you are railing about us engaging in the process that you are advocating - that is, attempting to determine user scenarios and needs before implementation. If you feel that this system is failing, I'm willing to work to make it better. However, I am not willing to stand by while a colleague is attacked simply for asking a question, especially since it was me who pointed out that Yuvi was staff, not him (and he would have been perfectly happy not to have that come up, I should think).--Jorm (WMF) (talk) 01:33, 1 July 2013 (UTC)

I WAS NOT RUDE. Your repeating that claim does not make it true. You are making a false accusation. And you are doing it publicly and against someone who chooses to post under his real name and thus has a real-world reputation to defend. Yes, that was my choice and does not mean that I should get any sort of special treatment, but common courtesy also has a place on Wikipedia.

Furthermore, you appear to have badly misinterpreted WP:AGF, claiming that It is, in your words, "not just about intent, but also skill level and mastery of technique" Nowhere in WP:AGF or any other guideline or policy does it say that I need to assume that all wikipedia editors are experienced in the fundamentals of software development or have any other technical skills, nor is the the slightest hint that -- lacking any evidence to the contrary -- it is in any way rude to assume that someone does not know that capturing requirements should precede writing code or pointing them to a Wikipedia page that explains that concept.

You might also wish to consider whether Yuvipanda needs or wants you to "defend" him or her, especially with methods that resemble trying to put out a fire with petrol.

I asked you nicely to drop the WP:STICK. Now I am going to have to insist. If you think that I was rude -- which I was not -- take it to WP:ANI instead of hijacking this RfC with false accusations. This is my last response on this subject. Further attempts to accuse me of things that I did not do will be ignored unless you make them in the appropriate venue. --Guy Macon (talk) 04:25, 1 July 2013 (UTC)

• Will this restriction be placed into the rights of the article/talk pages or from the editor's permission rights? There may be some interesting possibilities depending on which end the rights or permissions are inserted. For instance: editors could have a permitted list or a blocked list of groups or users and control their own pages. Certain groups would be permanently permitted to edit their comments and less as desired with experience or stature.. 174.118.153.129 (talk) 16:55, 28 June 2013 (UTC)

• Everything I have read indicates that the basic scheme will be Role-based access control. Keep in mind that the old and new systems will have to coexist side by side for a while --Guy Macon (talk)

• I'm sorry, but the English Wikipedia is not in a position to provide policy for all wikis. Flow is a movement-wide project. The English Wikipedia may advise (and hopefully will) and provide what it believes are its requirements, but it is not in a position of authority for 800+ other wikis.--Jorm (WMF) (talk) 17:07, 28 June 2013 (UTC)
  • This RFC concerns the English Wikipedia only, I don't see anything that would let presume otherwise, even though it may be a bit premature. If editing other users' comments is a userright, it should be configurable at project level ? Cenarium (talk) 17:43, 28 June 2013 (UTC)
    • The English Wikipedia is in a position to request an alternate mechanism to "Flow" for talk pages if it is not appropriate; perhaps going back to subpages (Article/Talk). On the other hand, it seems unlikely that this would be configurable at the project level; it's more likely that "editFlowComments" would be a separate userright, and the project can choose where to bundle it. (I know, that still makes it a project decision, for the most part, but it could even be unbundled.) — Arthur Rubin (talk) 19:12, 28 June 2013 (UTC)
      • Could you two please move the above discussion to a separate section? These are things that are well worth discussing, but not in the middle of an RfC that is asking a specific question. --Guy Macon (talk) 22:47, 28 June 2013 (UTC)
• Comment: Will we have an edit history for each comment? If someone edits my comments, I want it pointed out in an edit history that another user has edited my comments, and the comment marked as such until I review the edits.Martin451 (talk) 00:46, 29 June 2013 (UTC)
• Comment: This should be an all or nothing approach. Either let everyone edit comments made by others, or go down the other approach where only trusted users are allowed to edit, and only for gross violations (BLP,personal attacks etc.), if I make a mistake in a link, then post a new message with the correct link. Third option is to let the user decide who can edit their comments.Martin451 (talk) 00:46, 29 June 2013 (UTC)

• How would each of the above be applied in the case of obvious vandalism? An article talk page comment that just says "!!!GO PIGGERS!!!" is still an article talk page comment and deleting it is a form of editing it. --Guy Macon (talk) 01:03, 29 June 2013 (UTC)

Arbitrary Section Break 1

A Gentle Reminder: This RfC is for answering one specific question: "Who will the software allow to edit another person's article talk page comments in Flow?". If you want to discuss anything else, please put it in a separate section. Some minor explanatory discussion about Flow itself is OK; for example if someone asks "will the software still allow a user to forge another user's signature?" it would be appropriate to point out that whatever we decide about editing other people's comments, signatures will be automatic and uneditable for everyone. It would not be appropriate to then go off on a tangent discussing, for example, whether you should be allowed to edit your own signature. That discussion belongs outside of this RfC. I need all of your help to keep this RfC on topic. --Guy Macon (talk) 23:29, 28 June 2013 (UTC)

This entire section appears to me to conflate two processes and ideas. They are conflated in wikitext and talk pages because of software limitations, which is saddening. They are:

1. Vandalism control / Removal / Moderation
2. Actual comment editing.

The problem here is that (currently) one addresses vandalism via editing comments. This is a limitation inflicted by the software. New, better software will not have this limitation and will be able to handle moderation differently, better, and faster.

We are saying that it is insane that any user can just go in and change the meaning of my words at whim. This is vandalism, and a petty vandalism, but one we can solve for simply by limiting the ability for people to do that.

Removing posts that say "PIGGERS IS AWESOME!" is a different matter. That's comment deletion or oversight, not editing.

"moderation" != "editing".--Jorm (WMF) (talk) 01:43, 1 July 2013 (UTC)

It may very well be that the policy that is in the lead in the RfC right now is "insane" (I voted against it) but that is for the community to decide. Currently any editor has the ability to remove "PIGGERS IS AWESOME!" from the middle of another editor's comment while leaving the rest of the comment in place. You may think that this should be changed and that any editor should be able to delete a comment but only admins should be allowed to deleted part of one (I personally think that IP editors shouldn't be allowed to do either) but unless you can explain how some essential feature of Flow absolutely requires such a change, it isn't your place to make that decision. --Guy Macon (talk) 04:25, 1 July 2013 (UTC)

This discussion seems kind of pointless to me. The software-design question amounts to "Will the ability to edit (or vandalize) other people's comments be available based on some userright or another?", and the answer is already yes (because we've already been told that at least admins will be able to, and how else would admins be able to do this, if not because some userright makes it possible?). Who exactly will get the userright is not something that the WMF is likely to care about, just like they don't much care who we make admins or who we make rollbackers. WhatamIdoing (talk) 20:17, 1 July 2013 (UTC)

Some practical questions

So...nothing in the description tells me how I would be able to go over to someone's "board" and just read the conversations there, choosing to participate or not, without actually subscribing; in fact, I almost get the impression that the only people really aware of the discussion are the two involved in the conversation, and for the rest of us we don't even get to see it, let alone participate in it. This really, really needs to be clarified: user talk pages are often full of rich, multifaceted discussions involving many editors, particularly in the case of experienced users. Or will someone who "subscribes" to that user's page read everything?

How do the subscriptions interact with the watchlist? As it is, right now all I have to do, with popups, is cursor over the diff/history to get a sense of whether or not the change is something I care about enough to open the page. Will I have to go someplace else to check my "subscriptions"? will I be able to do a quick cursor check?

How will edits to these boards show up in user contribution histories? Will there be edit summaries?

This page talks about user talk pages, but they're not the primary area of disputatious editorial discussion nor the primary area of collaborative discussion. Those are article talk pages. Indeed, most of the talk page "problems" that are described are much more frequently seen on article talk pages than they are on user talk pages. One of the "selling points" for Flow is that it is intended to improve collaboration. However, collaboration takes place on the article talk page, not the user talk page (user talk discussions relating to collaboration tend to be "please check x" or similar short messages that almost never exemplify the "problems" Flow is supposed to resolve). So, I want that question addressed directly, please. Is it the long-range goal of this project to eliminate talk pages for all content spaces?

I'm also confused by the bullet point "A place for an 'introduction' to the page, which can contain free-form text, user boxes, templates, etc.". That sounds like a userpage. Are you also planning to eliminate userpages?

As an aside, I have to tell you that 'diffs' are a lot easier to deal with than it seems the entire WMF staff seems to think. While I'm not quite as tech-dumb as I once was, I learned how to use diffs and understood them much more quickly than I understood any other aspect of editing other than wiki-linking. I think you do people a disservice by insisting that diffs are really hard and only used by power users; if I could figure out diffs within my first couple of editing sessions with a grand total of zero technical knowledge at the time, I'm pretty sure most people can. I'm really not that smart. People who can't cope with with diffs are destined to never be more than casual users; diffs are inherent in wiki-editing and are an essential part of communication and analysis in just about every content space. They will remain so even in this system, when one wants to link to a series of comments, which is very common, in my experience. Risker (talk) 06:05, 29 June 2013 (UTC)

(Commenting in-line because the next part of the thread goes into different places; I'm addressing @Risker: here.)

So...nothing in the description tells me how I would be able to go over to someone's "board" and just read the conversations there, choosing to participate or not, without actually subscribing - You would do just as you do today, go to their board and read the conversations. You don't need to be subscribed to a conversation to see it; I'm not sure where that idea comes from. Subscriptions are useful in that they will appear in your Feed but that's a couple releases out.

It is absolutely not the goal to remove discussion spaces from content spaces. In fact, the goal is to strengthen these spaces.

The "Introduction" space is an area at the top of any given Board for inclusion of non-conversation or workflow data. In the Article space, this would be things like WikiProject and assessment templates. No, we are not planning to eliminate user pages (and even if we were - and we are not - that would be a totally different project).

Re: Diffs: I hear you and I'm on your side. However, I think that using diffs as a substitute for threaded conversations is madness. Linking to multiple comments (or, rather, a "comment range") will be totally doable in Flow.--Jorm (WMF) (talk) 01:49, 1 July 2013 (UTC)

When I wrote the above RfC I purposely focused only on article talk pages for the exact reason you describe above: Flow is planned to roll out first on user talk pages, then later to article talk pages and finally to noticeboards, help desks, village pumps, and other heavily customized discussion areas. In fact, when this becomes closer to being implemented I intend on suggesting that the first roll-out after the usual "try it on 100 selected pages" business be to roll it out for every IP editor and see how that goes.

While the above is a good plan to reduce the effect of early bugs, you are indeed correct in your conclusion that we need to design for article talk pages and not just user talk pages. In fact you make an absolutely critical point.

I also agree that we are lacking a good description of what is being planned. Look at Wikipedia:Flow. It does not mention any potential downside, even with weasel wording. Frankly, it reads like an advertisement or PR press release.

If you follow the links in the infobox on that page, you get to more detail, but you also find that the authors of that page are recommending -- and might even force, through design decisions not yet made -- policy changes. Look at my RfC. It came from WP:FLOW stating "Admins will be able to edit other people's comments; a userright might allow trusted non-admins to do the same." Whether or not you think that is a good idea, that is a policy change, not a description of new software. If you read between the lines, you can sense a bit of frustration on the part of the WMF staff over me bringing this proposed policy change to an RfC.

There are other policy recommendations embedded in what should be a software change. Some are uncontroversial, such as removing my ability to forge a comment from you -- at least until someone sees it in the history and drops a hammer on me. To their credit, WMF has been upfront on that detail -- signing will be automatic, and forgetting to sign or faking another user's signature will be impossible. But there are other restrictions that need to be discussed. Let's look at the example you picked: diffs. Imagine that I make three edits to a talk page. Right now you can generate a diff of edit 1, edit 2, edit 3, edit 1+2, edit 2+3, or edit 1+2+3. Which you choose to diff depends on what you are trying to show. Right now my question about a diff spanning several edits has been sitting there with this answer:

Q: You create a diff that spans several comments.

A: This doesn't make with Flow.

So what happens if someone posts the following sequence of edits with a few minutes between each?

1. Guy is a
2. Guy is a Whigmaleerious Rhadamanthine Lintlicker.
3. Guy is
4. Guy is a Binary Plantigrade
5. Risker is a Binary Plantigrade.

Can I show a diff or something like a diff that just shows the target being changed from Guy Macon to Risker? That just shows me being called a Binary Plantigrade (and not just a diff showing "a Binary Plantigrade" being added?) I can do all of these things with diffs. What functionality, exactly, will I be losing here?

Another example: look at https://www.mediawiki.org/wiki/Flow_Portal/Basic_information (Subscription Access Preference section) it says:

"Require Authorization The user must grant permission to those wishing to subscribe to them (this is the default setting)."

That is a policy change. Right now I cannot prevent you from watching my talk page or even know if you are watching. Suddenly you have to ask and I have to give permission? Whether you think that is a good idea or not, it is a policy change. We need to discuss and approve suggested policy changes, especially ones that will be enforced by the software. --Guy Macon (talk) 08:50, 29 June 2013 (UTC)

Not to mention that according to the plan, templates could not be transcluded within comments, which is a total blocker. See MW:Talk:Flow. Cenarium (talk) 09:20, 29 June 2013 (UTC)

The way I see it, there are two entirely separate classes of issues here. The first issue is all about new software, and getting that new software right will require a lot of discussion. The second issue is all about policies, and can be solved instantly by WMF getting the clue. They simply have to stop the software developers from trying to set policies except where the software requires it. They should have simply said that who can edit other user's comments is an optional setting that the English Wikipedia can change. They should have said that requiring authorization in order to watch a user talk page is an optional setting that the English Wikipedia can change. They could have done that and refused to express an opinion about how those settings should be set.

The WMF software developers should make sure that whenever possible "what the English Wikipedia does now" is one of the options, and they should deploy Flow with every option set to "what the English Wikipedia does now". This requires no detailed discussion in order to decide how to do it. The WMF software developers need to simply stop trying to set policy. It really is that simple.

Once we have put a stop to all policy-changes-because-some-coder-thinks-they-are-a-good-idea, we will be left with areas where the "what the English Wikipedia does now" option doesn't fit with the software design. Not allowing us to forget to sign a comment and not allowing us to forge a comment are good examples of this; it would be an extra effort to allow either of those existing "features" to remain, and nobody is asking for them. --Guy Macon (talk) 11:02, 29 June 2013 (UTC)

A related issue is the discussion below about renaming talk pages to boards. Take a look at https://www.mediawiki.org/wiki/Flow_Portal/Basic_information and read the section on "Subscribe" v. "Watch". it says "One can 'watch' or 'guard' pages or articles, and this works, but 'watching' people brings negative connotations into the mix." and "'Subscribe' is the only term that fits all areas and doesn't imply creepiness." While they make a good point, once again we are having a WMF software developer making a decision that has nothing to do with developing software. Here on the English Wikipedia, we have an established procedure that lets me or anyone else propose renaming talk pages to discussion boards, rename watching to subscribing, etc. And if I was persuasive enough and got consensus, the change would happen. Having the WMF impose that sort of change by fiat is very likely to result in what we have seen so many times before; a huge storm of protest on the English Wikipedia and the WMF sitting there absolutely baffled as to why this keeps happening after they have worked so hard at meeting our needs. --Guy Macon (talk) 17:10, 29 June 2013 (UTC)

"once again we are having a WMF software developer making a decision that has nothing to do with developing software". Let me get this straight. The developers are creating a discussion system which is built on different concepts than the previous one. A system which distinguishes things that were conflated, and conflates things which were distinct. And you want to forbid them from inventing some vocabulary for that purpose, and by the way eliminating some unfortunate connotations? Relax. Keφr 17:41, 29 June 2013 (UTC)

Partially correct. Of course I have no problem with naming changes that are required by software changes (although the names should stay as similar as possible to the old names) but I absolutely do not want them to do anything even faintly resembling "and by the way eliminating some unfortunate connotations". That is not their place. If they want to eliminate some unfortunate connotations, they need to do it the way you, I or Jimbo need to do it; by getting consensus from the community to change the name. Hey, I have opinions on naming too; I personally think "Talk Page Stalker" is a terrible name. And in theory I could be hired by the WMF as a software developer (should they for some strange reason need someone who specializes in 4-bit microcontrollers that have 64 nybbles of RAM and cost well under five cents each). If that happened would it be OK for me impose my naming preferences on the English Wikipedia without seeking consent? I wouldn't even need to change the Wikimedia software, just a template or two. --Guy Macon (talk) 19:57, 29 June 2013 (UTC)

• Now wait a minute, if Cenarium has it right, templates can't be transcluded in comments? So every single one of our user talk templates, including the blocking templates, will no longer work? That's not ok. Beeblebrox (talk) 16:45, 29 June 2013 (UTC)

And having to ask permission to read a page, any page, anywhere is completely antithetical to the Wikipedia ethos. That can't be allowed to happen. Beeblebrox (talk) 16:47, 29 June 2013 (UTC)

So we will not restrict reading, simple. (Though I would not mind if some way of relatively private communication, for sensitive matters, existed on Wikipedia, besides e-mail.) Keφr 17:05, 29 June 2013 (UTC)

Most user talk templates are substituted anyway, so the tools can be rewritten to simply insert the relevant markup directly. I guess that the functionality of some of the other templates could be built into Flow, but I am not sure what are the plans of the WMF in this regard. Keφr 17:02, 29 June 2013 (UTC)

Arbitrary Section Break 2

Other questions: How will discussions like requested moves or articles for deletion work? Those require a decent amount of template functionality; will they have to be redone entirely? NW (Talk) 18:46, 29 June 2013 (UTC)

If Flow can't transclude templates in comments, best to stay away from it. But then again, this is valid for all talk pages, not just noticeboards. As I noted at mw:talk:flow, to give one example citation templates are used extensively in talk pages, if we group them together, likely on tens of thousands of pages as a lower bound in main talk. And templates that are susceptible to be used on articles or modified are often displayed in comments, as checking the numerous transclusions of infobox templates in talk pages would show for example. In user talk space and project space, it's even more intensive for some other kind of templates (userlinks, etc). Cenarium (talk) 19:06, 29 June 2013 (UTC)

Yep. And how is a noticeboard like WP:AE supposed to function? NW (Talk) 00:25, 30 June 2013 (UTC)

Now that is an interesting question. Clearly we don't want the developers to spend a bunch of time solving this before we are even sure how Flow will be designed for the simple user talk page case, but just as clearly we don't want the developers to paint themselves in a corner by making decisions now that will later cause problems when Flow is expanded to cover WP:AE. Take a look at the different ways we handle this now:

• Wikipedia:Arbitration/Requests/Enforcement: "Click here to add a new request" link, then preloaded Wikimarkup. Well, sort of preloaded. There is also a collapsed "Text to copy" box.
• Wikipedia:Dispute resolution noticeboard/request: A series of forms with error messages if you fail to fill them out correctly.
• Wikipedia:Administrator intervention against vandalism: Same preloaded Wikimarkup scheme as AE, but of course the actual preloaded Wikimarkup is completely different (you have to scroll past a bunch of administrator instructions) and you get to it by clicking on the edit tab at the top. Oh, and did we mention that, unlike every other noticeboard, WP:AIAV deletes your entry no matter what the result was, leaving you wondering what action was taken?
• Wikipedia:Administrators' noticeboard/Incidents: another "Click here to start a new discussion thread" link, but this time it opens a blank editing window with no preloaded Wikimarkup. This is actually a rather nice way of doing it...
• Wikipedia:Requests for mediation/File: this time you get a text box to fill out and a real button to click. Clicking it brings you to a page that says "You do not have permission to edit this page, for the following reason: This page is currently protected and can be edited only by administrators.", a long list of useless "What can I do?" suggestions, they waaay done at the bottom, some collapsed instructions. Surprise! following those instructions loops you back to the error page! You also get what looks like preloaded wikimarkup, but it isn't editable.

Don't even ask what happens when you suggest that any of the above noticeboards might want to do things the way some other noticeboard does them...

If I was managing this project, here is what I would do; I would ask the developers to come up with a high-level plan for this. This should be a short paragraph, no more. Something like this:

• "We will write a program in Python that runs on server XYZ. Input to this program will be from an HTML form that is invoked by clicking on a button in Flow. Output will be a standard Flow message just like the human-generated ones, but this one will be machine generated. For now we will stub this code with a module that accepts a single line of typed-in text, applies ROT13 to it, and posts it to Flow with the signature of the user who filled out the form. Later we will expand that ROT13 program into something suitable for WP:AE, WP:DRN, WP:SPI, WP:AIAV, etc."

By doing it that way, the developers can delay getting the details right, but still be confident that none of the decisions they are making now will screw up the basic "Get input --> process it --> post Flow message" functionality they will need later. --Guy Macon (talk) 03:21, 30 June 2013 (UTC)

Here's the part where I think to myself, "I really suck at explaining things" and then I get irritated because I don't get to talk enough about what Flow actually is.

It seems people think that Flow is just a discussion system. It isn't. Discussions are a byproduct of what Flow actually is.

"Flow" gets its name from two places: the first is the idea of a metaphorical "stream" of activity - a "flow". But the second is what it really is: a "workflow engine". One of the most important features of Flow (to my mind, at any rate) is the inclusion of a "Workflow Description Language". This is a system whereby each individual wiki can create, modify, and remove the workflows they use in a structured and sane manner.

Flow is a big bag of Lego bricks. Each of these bricks has a function and a set of behaviors. Users of a wiki (admins, typically) will be able to use these bricks to design processes.

Let's take a hypothetical example of an workflow, making an MFD (and I'm gonna get this wrong but bear with me, please):

1. Ankit creates an article, "Foobar"
2. Brenda decides that the article needs to die.
3. Brenda goes to the article's Board and clicks the "Initiate Workflow" button. She selects "Nominate for Deletion"
4. Brenda is given a form to fill out. It requires a reason, etc. She clicks the "Save" button.
5. A new "topic" is created, flagged with the "MFD" workflow. This workflow knows how to do a bunch of things. It knows that it has a life-span of, say, a week. It does the following:
   1. Attaches itself to a Board of "current MFDs"
   2. Notifies Ankit on his Board and auto-subscribes him to the Topic
   3. Auto-subscribes Brenda to the topic
   4. Maybe it notifies (via Echo) up to three or four other authors who contributed to the article that it's been put into MFD state
   5. Maybe it notifies other editors who commonly work in that category (who knows?)
6. The topic now accepts "enumerated comments" (select "keep", "delete", "comment", etc.) and give a reason
7. Auto keeps a tally
8. After 7 days, it knows to ping a group of administrators (those who subscribe to the workflow, perhaps), saying, "Admin response requested"
9. An admin closes the topic with a "delete" button.
10. The workflow deletes the article
11. The workflow moves itself into an "closed" MFD state.
12. If the "Foobar" article is opened again, the workflow knows to move the topic back onto the article as a "previous discussion"

I'm not saying that's how it should work - that's up to the local wiki to decide. I'm saying that's how it could work.

This is the entire point about Flow. Making workflows easier. Discussions are workflows. They are a byproduct.--Jorm (WMF) (talk) 02:04, 1 July 2013 (UTC)

The above is, in my opinion, exactly the way to go.

If I may be so bold, I would like to suggest a better way of communicating the above.

Right now, Wikipedia:Flow says the following:

• "What you do now: You want to edit someone else's comments to fix an incorrect link, with or without the original person's permission."

• "What you will do then: Admins will be able to edit other people's comments; a userright might allow trusted non-admins to do the same."

Might I suggest something like the following?

• What you will do then: Editing other people's comments will still be possible, with the exception of signatures, which will be uneditable. There will be an additional option that you don't have now to restrict the ability to edit other people's comments to certian userrights. If that option is set to "anyone" it will be the same as it is now."

My suggested alternative wording ephisises what Flow can do and deemphasizes any WMF opinions about what English Wikipedia policy should be. It conveys the opposite attitude of statements like "We are saying that it is insane that any user can just go in and change the meaning of my words at whim." The RfC I posted clearly shows that, so far, that is exactly what the community wants. They want any user to be able to just go in and change the meaning of your words at a whim.

My suggested alternative wording above also helps to explain something new about Flow -- that signatures will not be treated as an editable part of a post. You can't not sign your post. You can't forge someone else's signature. You can't edit your signature. In this case the change is driven by the software design. You don't sign. The software signs for you. Yes, it is taking away an ability, but for a sound technical reason and with overwhelming consensus for it. (I can prove this with an RfC if anyone really wants to make that an issue).

I hope that you can see what I am getting at here; that your communication about Flow needs to be all about new features, new limitations, and new configurable options, and not at all about the fact that you personally think that a long-standing Wikipedia policy is insane. --Guy Macon (talk) 05:27, 1 July 2013 (UTC)

• We would then have something similar to the edit filter, with the possibility for admins and users in the workflow-editor usergroup to create, edit and delete workflow types ? They could be called upon by users on specified pages (in a namespace such as user talk, on listed pages, etc). So this would streamline several processes and replace some scripts. This is indeed interesting, however this could not possibly address an impossibility to transclude templates in messages, as I noted several times. It's critical to be able to show how templates display in comments, and inline templates are necessary for efficient communication as well. Cenarium (talk) 23:43, 5 July 2013 (UTC)

  You have exactly the right of it, regarding workflow editing. I don't know that the abuse filter system works exactly like how we'll get to it, but it's a good analog for understanding.--Jorm (WMF) (talk) 23:49, 5 July 2013 (UTC)

"Board" versus "Talk"

I'd like to ask about the plan to rename user talk pages to user boards. One of the things that I like about "talk" as a term is that it emphasizes the fact that we are having a discussion, one in which one hopes that each user is listening to what other users are saying. The word "board", as it is often used online, is similar to the word "wall", having connotations of a place where you can stop by, post something, and kind of leave it there, with less of an expectation of thoughtful, two-way communication. For that reason, I wonder whether it might be better not to change the terminology to "board". Those of you who have thought about the proposal, what do you see as the reasons that "board" would be an improvement over "talk"? Here, I'm referring only to the term used, not to any of the features of the system. --Tryptofish (talk) 16:12, 29 June 2013 (UTC)

I posted some thoughts on this in the "Some practical questions" section above. --Guy Macon (talk) 17:12, 29 June 2013 (UTC)

Yes, the question of "subscribe" versus "watch" is a related question. But here, I'm specifically interested in "board" versus "talk". --Tryptofish (talk) 17:17, 29 June 2013 (UTC)

Leaving aside the general issue of WMF trying to make this sort of decisions at all (discussed above), "board" is used a lot of ways on the rest of the Internet. Although the term goes back to the days of dial-up bulletin board systems and Usenet networks, to most users it means something like what you see on social networks or the comment sections of blogs, both of which have a completely different set of connotations than a Wiki talk page. "talk page" is pretty much only used on Wikis, and gives the user a subtle hint that the rules here are different. Of course it doesn't matter what you or I think; the only question we need to ask is "Where was this discussed and what evidence do we have for a consensus to rename talk pages to boards?" --Guy Macon (talk) 18:18, 29 June 2013 (UTC)

I'm trying (not too successfully so far!) to keep this discussion focused on the merits, rather than on the process. If there's a good reason for calling them "boards", then fine, and I'll be satisfied (for now) with the process. But, as you correctly point out, people come to Wikipedia with preconceptions from their experiences elsewhere online. In this case, I worry that "boards" sound too much like a wall on, for example, Facebook. It's important that we continue to maintain a culture of discussion and WP:Consensus-building, and there's a cultural difference between "talking" and "posting on a board". If we're making the discussion process more user-friendly, I'm all for it, but if we're dumbing Wikipedia down, I'm strongly against it. --Tryptofish (talk) 18:38, 29 June 2013 (UTC)

I apologize for using this thread as a stalking horse. I strongly agree with your analysis above. In addition, there are a bunch of other Wikis out there that use the "talk page" terminology. Do we really want someone coming here from Wookipedia to have to adapt to another name? --Guy Macon (talk) 20:43, 29 June 2013 (UTC)

No problem, thanks! --Tryptofish (talk) 21:24, 29 June 2013 (UTC)

About that issue of "subscribe" versus "watch", discussed also in the section above, I'm actually fine with the idea of "subscribing to a discussion", if it's communicated that way. For example, if I could "subscribe" to what is now just one section of a talk page, instead of having to watch the entire page, that would be a very useful feature indeed. --Tryptofish (talk) 20:27, 5 July 2013 (UTC)

While I understand the connotation in the same old-school terms (being aged enough to remember having called a computer on the phone and flipped a switch on my modem to connect to it in it fifteen minute increments so that users could connect as well) I doubt most of our new users would make that connection. I have to say I don't understand why it is necessary or desirable to rename talk pages regardless of what software we use on them. People will just keep calling them talk pages anyway. Oversight was superseded by suppression years ago and yet even those of us who do it still refer to it as oversight. That tendency seems to me enough of a reason not to do it. It could be confusing to the very users such changes are intended to entice. Beeblebrox (talk) 20:51, 29 June 2013 (UTC)

Although it's true that experienced Wikipedians will likely to continue to call them talk pages out of habit, I'm not really worried about experienced users here. What worries me is newcomers, and of course, a lot of the reasons for Flow are to make editing easier for newcomers. It's not really that they would actively "make that connection". Rather, it's that they would subconsciously carry over habits from other online sites, just as experienced users will carry on the habit of calling it talk. We all see new editors who initially don't get it, that WP:NOTWEBHOST, and all of the other Wikipedia "nots". Picture someone coming here and thinking "ooh, everybody's got a board! great place to post my vacation photos!". We're doing no one any favors with that. --Tryptofish (talk) 21:24, 29 June 2013 (UTC)

I should clarify what I was driving at: new users will see the term "board" but then see more experienced users using the term "talk page" and they won't know what that is referring to. I see your point too though, I'm certainly in no hurry to see WP become any more like Facebook. Beeblebrox (talk) 02:41, 30 June 2013 (UTC)

Oh, I misunderstood that, and it's something that hadn't even occurred to me. But you are right, and that's even worse. --Tryptofish (talk) 20:13, 30 June 2013 (UTC)

(I killed the outdent template so that I could respond in the correct context. See? There's a reason for the madness - if I had just replied at level 1, it would look like I was responding to Beeblebrox, when I'm not).

"Board" versus "Talk". Well, there's a reason for that change (and let's keep in mind that we're not talking in "user facing" terminology at this point, just software terminology).

First, we want there to be no mistake that we're talking about something different from a "talk" page.

Second, it is envisioned that the "board" becomes something much more than a "structured talk page". The Board is and will become many things beyond discussions. I think a major problem we've got right now is the conflation of a "feed" and a "board" - a "feed" being a stream of data and events that concern the user's interests, and the "board" being a stream of data and events about the user (and not their interests).

In the current "minimum viable product" design model we are not including a "Feed". The reason for this is that we don't have a lot to put in it (in release 0 or even 1), but there will be stuff to apply going forward. As such, the elements that we thing should be in a Feed (but will be available in R1) will have to go into the Board. The Board would then have two different view models: the first person (e.g., your view of your Board) and the third person (my view of your Board). These will not be identical, even if we only account for the elements that You have read versus the ones I have read.

The term "Board" was chosen because it's just that: a bulletin board about you. A place for people to pin messages.

Now, to the idea about "being too social network", I say "nuts". This is the year 2013. We have scads of tests and data that show new users simply do not understand what "Talk" means. This is the reason why the "talk" tab was labelled "discussion" for so long (and then reverted back, because too many templates said "leave a message on the talk page"). This is an artifact of history, and it's one we'll do well to get rid of and move on with our lives on.--Jorm (WMF) (talk) 01:24, 1 July 2013 (UTC)

I am quite aware that this is the year 2013. I can confidently assure you that I was never under the impression that it was any other year. You can say "nuts" all you want, but it doesn't amount to a reasoned reply to the concerns expressed by me, and by two other experienced editors, in this talk thread. Your reply, unfortunately, is a textbook example of why a lot of experienced editors feel negatively about WMF staff. It seems to me that the WMF works for the community, not the other way around. A great deal of what you said, about the differences between a board and a feed, is irrelevant to the difference between calling it a "board" and calling it "talk". Yes, it's going to work differently than talk pages do now; I get that. The fact that, from a software conceptual point of view, it may be accurate to call it a "board" does not mean, from a user-to-user interaction point of view, that it's better to call it a "board" than to call it "talk" or "discussion". I actually would have no objection at all to calling it "discussion", and that would probably be an improvement. But if the idea is that we are going to start "pinning messages" to one another, instead of carrying on discussions, then we have a problem. If your data appear to show that users don't intuitively know exactly what "talk" is intended to mean, and that they will come with an intuitive sense of what "pinning on a board" is, then we will be inviting them to come to Wikipedia with a misconception of how to edit collaboratively on a wiki. I'd rather have someone come here, wonder "what exactly does talk mean?", and then learn how to discuss things and arrive at WP:CONSENSUS, than to come here, think "oh, I can pin stuff here!", and then have to unlearn what they started to do. Your explanation of "board" has actually made me more convinced than before that "board" is going to be counterproductive as terminology. --Tryptofish (talk) 00:03, 2 July 2013 (UTC)

• So, I'd like to ask where we stand at this point. Three experienced editors have expressed concerns in this talk thread, and one of us (me) has expressed the opinion that the reply from the WMF staff person did not resolve those concerns. Is the WMF now going to seriously consider what has been said here? Should the editing community open an RfC, to determine editor consensus? --Tryptofish (talk) 19:44, 3 July 2013 (UTC)

• Just so everyone knows where I stand and what my plans are, I believe that I expressed my concern about software developers writing their policy opinions into software or documentation. I didn't get explicit agreement, but I suspect that they will stop doing that. If it continues, I have the option of reluctantly dealing with it one policy at a time through RfCs. that being said, I don't see the board/talk issue as an example of what I am talking about, because there are significant changes in the software that could justify another name. So you can count me as agnostic on the talk/board issue, leaning towards an "anything that isn't in use by Facebook, Twitter, etc." position. --Guy Macon (talk) 20:06, 3 July 2013 (UTC)

• It's obviously something that I am interested in, and it seems to me that your "anything that isn't..." position would be comfortable with either "talk" or "discussion", and not so comfortable with "board". That's the way I feel, too, but not so much "leaning" as "deeply concerned". Do you have any evidence to believe that the developers are now reconsidering what sounded like a pretty strong commitment to "board"? --Tryptofish (talk) 23:42, 3 July 2013 (UTC)

We are not reconsidering "Board" at this time, no. And I'm curious as to what sites you think use the term "board"? I can't think of any. Twitter has "stream"; Facebook uses "feed" and "timeline." --Jorm (WMF) (talk) 23:53, 3 July 2013 (UTC)

• Thank you for the clear answer (misguided as it may be). You have given me very clear guidance that it is going to be appropriate to ascertain what the consensus of the editing community is on the English Wikipedia. As to what other sites I think use the term "board", as Risker correctly points out just below, it's widely understood that "board" is synonymous with "messageboard". The fact that you apparently think that, if some of the widely known commercial sites use other terms than "board", then there's no problem (or that you imply that you know what is good for the WP:CONSENSUS process here on-Wiki because you are more familiar with those commercial sites than I am), simply goes to show that you should not be making decisions about what terminology the editing community on this project should be using. --Tryptofish (talk) 19:36, 4 July 2013 (UTC)

• Okay, let's be clear on two points here. The first is that when we say "board", we're not discussing what the term is on enwiki - we're discussing what the software concept is called. That's not something that falls under the consensus policy, and if you think it is then I'd suggest you re-read it and take into account the section about the community not having control over technical decisions. What the software concept is called, what the code refers to the object or class as, is totally unrelated to what it's called on the English-language Wikipedia. We could call it "Happy-Fun-Talky-Place" on enwiki and still have the software refer to it as a board. Each project can call it a totally different thing, because it's just a string in a localisation file.
• Now. If we are going to call it, on enwiki, something other than "board", this is a question for a wider pool of people than is gathered here. I'm perfectly happy to say "sure, enwiki can call it something special" - we do with everything else (pending changes is not called pending changes by the software, it's flagged revisions. Oversight isn't oversight, it's a different value for the rev_deleted field), but it needs to be something the community as a whole can buy into. More than that, it needs to be something concrete. Flow is not yet in the stage where names for individual functions or components are something we should be spending our time on - we should be spending time making sure that it functions, making sure there are no components that are missing. Deciding what it's called, on a single project, is frankly a waste of everyone's time. There's going to come a time when that conversation is worthwhile, but it's not now, and not here.
• Second: the fact that Brandon has (WMF) postfixed on his username does not mean he's some crazy naive lunatic we've dunked down on a talkpage and let fly with whatever comes into his head. Brandon has been working on Wikipedia and its complex systems since he joined us in 2010. In his personal capacity he's been around on and off since 2006. He knows what he's talking about, and what he's talking about is nothing to do with dictating what the software is called on enwiki. The name he's talking about isn't one anyone here has to ever see; it's a software concept. He's never implied that commercial sites > on-wiki consensus, he's never tried to dictate what terminology the on-wiki community use. That you don't understand that he's talking about what the software refers to it as internally makes me wonder how closely you've read his comments here. A particular highlight might be his statement, in this section, "let's keep in mind that we're not talking in "user facing" terminology at this point, just software terminology". Okeyes (WMF) (talk) 21:43, 4 July 2013 (UTC)

• You might want to consider what is and isn't being communicated. He could have simply said "we are calling it a board, but the English Wikipedia can call it anything they want -- it's an option in the configuration." That would have satisfied everyone and stopped the debate in its tracks. Instead we saw statements like "The term 'Board' was chosen because it's just that: a bulletin board about you." and "We are not reconsidering 'Board' at this time, no."

I implore you, please think about what you are communicating. If someone disagrees about what you call something and the name is a configuration option (which pretty much every name is, otherwise you would not be able to deploy the same software in England, Germany and France) just say that. Don't defend the word you are using internally. Don't tell them that the word they like is "an artifact of history, and it's one we'll do well to get rid of and move on with our lives on". No, no, no, no, no! That just pours gasoline on the fire. Just tell them it is configurable and that the English Wikipedia gets to choose the name, not the Wikimedia foundation. End of discussion.

Clearly you are frustrated by what you see as multiple participants on this page misunderstanding you, but are you considering the possibility that the words you write might have something to do with these misunderstandings? --Guy Macon (talk) 22:17, 4 July 2013 (UTC)

Having recently had a set-to with another WMF staffer who pointed out that GuidedTour (the software extension) is not the same as "guided tour" (a software-driven guided tour designed to assist users in learning how Wikipedia works, using the GuidedTour extension)....I think it's really time that the Engineering Department understand how much difficulty this type of terminology causes in communication between primarily-tech and primarily-non-tech users; it's bad enough in English, and I understand from some anecdotes that it is even more problematic when there is a language barrier overlaid. It's not a problem unique to this particular software; it's a systemic issue and has a lot to do with the fact that software initially designed for one purpose can be multi-tasked in many cases. Let's see if we can come up with a better name that can be attached to both the "page" (for lack of a better term) and the underlying software, so that we can avoid this sort of communications misfire. Risker (talk) 22:30, 4 July 2013 (UTC)

Well, what Guy Macon and Risker have said pretty much covers what I could possibly have wanted to say, and I thank them for that. To underline what Guy said, if the reply to me had been that "board" was a term used internally by developers to describe what was being developed, but that the English Wikipedia could call the pages that use board structuring by whatever name the English Wikipedia likes – "talk", "discussion", whatever – that would have been the end of it, and no further discussion would have happened or would have been needed. Seriously, was I supposed to get that from "'user-facing' terminology"? I started this talk thread with what I think was a perfectly reasonable question, and I responded to the answers I was given, in plain English. I'd like to think that I bring some positive attributes to my editing here, but mind-reading is definitely not one of them. --Tryptofish (talk) 20:14, 5 July 2013 (UTC)

• Just to pipe in here, for a lot of people "board" means "messageboard" or "forum", which is not really what I would want to see my talk page turn into. I'd really suggest avoiding this terminology because it's used elsewhere to mean something quite different than this is intended to be. Wikipedia is notorious for misusing English when naming things ("Arbitration Committee" that categorically does not arbitrate anything, for example), but when it comes to interpersonal communication, that's really sending the wrong message. The reason people don't understand what the talk page is for is because nobody's talking, they're writing. When it was called "discussion page" at least they understood the concept better. Let's see if we can find a more descriptive term that doesn't bear on an existing techie term. Risker (talk) 23:55, 3 July 2013 (UTC)

Yes, I agree with you on everything you said here. I'd be fine with changing "talk" to "discussion", which gets across the key idea very well without running into the talking/writing confusion. However, if WMF dictates to us that we must call it "board", then the effort to find any other term will be made more difficult. --Tryptofish (talk) 19:36, 4 July 2013 (UTC)

"Board" versus "Talk" section break

• I want to be absolutely clear about this. Is it correct to say that "board" is the word that describes how Flow will work, but that the English Wikipedia will be able, under Flow, to continue to call talk pages "talk pages", or whatever other name the project chooses? Yes or no? If yes, will this fact be clarified on the WP:Flow page? --Tryptofish (talk) 20:19, 5 July 2013 (UTC)

We will run user tests to see which terminology is best understood by users to describe and understand the process. There will be data. I can't imagine that, if there is sufficient data to support "Board" over "Talk" or even "Discussions" that you will be averse to using the data-driven terminology? Or are you mad-set against the term, no matter what? If the data pans out that "Board" doesn't work, so be it (though I doubt that will be the case, though "Discussions" may be better). --Jorm (WMF) (talk) 20:50, 5 July 2013 (UTC)

So, what you are saying here seems to contradict what Okeyes said above. You are saying that there are still going to be some studies by WMF, and depending on the results of those studies, the English Wikipedia will have to adopt whatever term the WMF chooses. In real life, I'm a scientist, and I understand data, and I know how data can be biased. Does that make me "mad-set"? Well, I'm not exactly foaming at the mouth, no. But I believe strongly that any appropriate data set must include the WP:CONSENSUS of the editing community. It's not about my personal preference for a word; it's the community's preference.

It appears that the answer to my "yes or no" question is either "no", or that the answer depends on whether Jorm or Okeyes is giving the answer. So let me turn the question back to you: if whatever term your studies settle on is then put before the English Wikipedia editing community in an RfC, and the consensus is that the community as a whole objects to that term, is it the WMF's position (not Jorm's personal position, but the official position of the WMF) that the result of that RfC will be of no importance? --Tryptofish (talk) 21:14, 5 July 2013 (UTC)

The answer is "my job is to reverse the editor decline trend". If that means that we are to use one word over the other, then that's what we'll use. If you want a definitive WMF opinion, you should ask Erik Moeller, though I suspect he's going to say exactly what I've been saying: we're going to be data driven, and we're going to do what is best for the projects.--Jorm (WMF) (talk) 23:16, 5 July 2013 (UTC)

Aaaaand here we are, back to having a WMF software developer making a decision that has nothing to do with developing software because he knows^{[Citation Needed]} how to reverse the editor decline trend. No consensus-seeking required. Next step: we get to see what we have seen so many times before; a huge storm of protest on the English Wikipedia and the WMF sitting there absolutely baffled as to why this keeps happening time after time after they have worked so hard at meeting our needs. Guy Macon (talk) 00:26, 6 July 2013 (UTC)

I don't believe I said I knew how to reverse it; I believe I said that it was my job to do so. And there are things we are going to do.

I would greatly like it if we could attempt to be more civil and have less hyperbole. As it sits, I don't think this conversation is a productive use of my time and will now disengage from this topic.--Jorm (WMF) (talk) 01:00, 6 July 2013 (UTC)

I'm going to pretty much skip over what Guy said, and reply to what Jorm has said. In my opinion, reversing the editor decline trend is a very good goal, and one that I am happy to buy into. I can also readily understand that this is, specifically, Jorm's job assignment, and I'm entirely sympathetic to the idea that it's unfair for me or anyone else here to criticize Jorm for what someone else has assigned Jorm to do. Really, I'm not hostile to any of that!

Part of reversing the editor decline trend is making the project attractive to new editors, and using terminology that new editors will find familiar and recognizable. I accept that. But there are other parts of it, too. Another part is making sure that the terminology we use does not mislead new editors into coming here with misunderstandings that will end up making their editing experiences less enjoyable. And, in a related aspect, we need to make sure that new editors can understand how to work effectively with other editors in order to improve our articles. Not only I, but Guy, Beeblebrox, and Risker, have all had a lot of experience with those processes of editors working together, so our opinions should not be disregarded. There's nothing really to be gained by attracting new editors, only to have them subsequently leave because their editing experiences went badly.

Someone new to Wikipedia, on seeing the word "board", is likely to think either of "message board", or, perhaps "notice board" (the latter, a term we do use here, but specifically in the context of dispute resolution). If they look at the top of Encyclopedia, they currently see the word "Article", and right next to it, the word "Talk", in a blue link. Likewise if they find their way to my user page. Those article and user talk pages have a different flavor than do dispute resolution notice boards. And the processes of carrying on discussions that move us towards WP:Consensus are different than what happens when someone pins stuff onto an online message board. If the word in blue changes from "Talk" to "Board", it makes a difference, and it's not about being more familiar from past experience with boards as opposed to "talk". It can be as simple as not knowing about WP:NFCC#9, and thinking it's cool to post a copy of an image they found somewhere else, or as significant and potentially disruptive as entering into a discussion without understanding WP:VOTE. I can sympathize with a newbie who follows a link to a "board" and does those things, because it's understandable that they would think that way. But I can also predict that they will end up encountering the kinds of experiences that can cause them to leave the project. And that is avoidable if the way we communicate is based on what we have come to learn from experience.

That's what I think, and it sounds like three other editors here think similarly. We may need to hold an RfC to involve a much larger sample of the community, but the folks to whom Jorm reports have a serious obligation to take what that community says seriously. --Tryptofish (talk) 20:15, 6 July 2013 (UTC)

I'd suggest that an attempt to come up with alternatives, that are both illustrative of the concepts underlying the software, and also less-ambiguous to non-techies, might be a good idea; rather than disputing the existing terms and who gets to have input on naming them.

The devs are not obliged to follow onwiki consensus (per WP:CONEXCEPT), but if we have intelligent suggestions to make (rather than just criticisms) then they're likely to be happy that we're collaborating, and welcome the good ideas just as they would welcome a good pull-request in a software dev situation...

To make good suggestions, we need background research and proposals. Perhaps someone could make a survey of the real-world examples that other sites use, e.g. as in this research for the Notifications (found via mw:Echo (Notifications)/Feature requirements). First some research and a neutral tabular listing, and then some thoughts/opinions on the connotations associated with the various possible terms, and only then (potentially) an RfC asking for further input if we can't come to any solid (or even tentative) conclusions. If we leaped directly to the RfC stage, we'd have far more heat than light, as editors who've barely (or not even) glanced at the multiple mw:Category:Flow doc subpages chime in. –Quiddity (talk) 22:26, 6 July 2013 (UTC)

I looked at that link to real-world examples. The limitation with using that analysis as research for our purposes is that it starts from the assumption that what is best practice at other websites, and Facebook is the one they looked at first, will be best practice here at Wikipedia. For software design, that's probably OK. For editor-to-editor communication in an encyclopedia environment, it will lead to problems. --Tryptofish (talk) 20:47, 7 July 2013 (UTC)

Keeping in mind the context -- a question about whether the English Wikipedia will be allowed to choose a name for English Wikipedia use only -- the problem I have with the statement "my job is to reverse the editor decline trend. If that means that we are to use one word over the other, then that's what we'll use" is that it contains an implicit assumption that Jorm's opinion on what term we must use is somehow superior to Tryptofish's opinion that that the English Wikipedia should be allowed, under Flow, to continue to call talk pages "talk pages", or whatever other name the project chooses by consensus. It is self-evident that the WMF can, if they wish, let us make that decision -- they certainly are not going to tell the Polish Wikipedia that they must replace the Polish "Dyskusja" with the English "Board". I doubt that anyone is even going to tell the Polish Wikipedia that they must replace "Dyskusja" with "Tablica". I do not see this as being covered by the "in a separate domain" language of WP:CONEXCEPT --Guy Macon (talk) 08:44, 7 July 2013 (UTC)

Thank you, Quiddity, for making me aware of CONEXCEPT, since I either did not know about it before or had forgotten about it. It does seen to me that what we are talking about here is the fourth bullet point there. In a legal sense, that's true, and I certainly can't argue with that. But there is also a good practices sense that is worth considering. Just as Jimbo had every legal right to make the project "for profit", he made a conscious choice not to do it just because he could have done it. Same thing here. Although WMF can invoke CONEXCEPT, is it really prudent for them to do so?

Although I've said a couple of times here that I see a lot of good reasons to change "talk" to "discussion", to say that now is the time to explore that, because of Flow coming, seems to me to miss the point – first, because if it wasn't urgent before, it isn't now, and second, because it sounds like WMF doesn't want to work on that along with editors here. Is "talk" really broken? It's really not about what Quiddity called "illustrative of the concepts underlying the software". New editors don't need to look under the hood (and neither do old editors)! Sure, developers are keyed in to the software concepts, but editors need to learn about how to edit as part of a community.

And Guy made an excellent point about languages: if WMF insists on any terminology in English, how will that translate across projects? Will the research that is being started be carried out only in English? Indeed, the fourth bullet point of CONEXCEPT seems to me to cut both ways: just as there are limits to what the English Wikipedia can tell other Wikipedias to do, the English Wikipedia retains some local autonomy. After all, we aren't talking about the English Wikipedia refusing to enable Flow. We're just discussing which words will appear on-screen.

Please re-read what I said just before. This is about what words appear in blue at the top of pages, not about whether or not to implement the underlying software. And it's not in opposition to "reversing the editor decline trend". What I've been talking about should be understood as helping with that goal. But if the research by WMF simply asks prospective editors: "what do you think 'board' means?" and "what do you think 'talk' means?" – and concludes that respondents had an easier time picturing what they think a "board" would be – that's going to miss something crucial. And I'm pretty sure that's where the proposed research is heading. Newbies will come here thinking they know what is meant by "board", and then they'll run into bad experiences when their preconceptions prove to be at odds with how editing really works. Coming, instead, thinking "talk, hmmm, what's that?" – and then finding out – doesn't seem to me to be so awful. The reason that editors in this discussion have expressed concerns about terminology is entirely consistent with the goal of "reversing the editor decline trend". --Tryptofish (talk) 19:48, 7 July 2013 (UTC)

Quick note, before I head outside into the sun.

I think one of the ideas behind the name "board" is to denote the differences that they will have from the current "1-page-for-a-single-associated-page" ("talk" or "discussion"). Understanding this intent, require understanding how "boards" will function: they'll be able to contain "threads" and "workflow modules" from multiple places. In the far future, we're going to talk less about specific "talkpages" and more about specific "topics" or "threads" or "#tags" or "processes" or etc.

E.g. (afaik) In a "page-deletion workflow", or a "user block workflow", a "topic" (subsection/thread) will be transcluded into multiple locations ("boards"). See mw:Flow Portal/Basic information#Boards for a hint of those details (and fleshed out details throughout the rest of the subpages there). Flow is not a replacement for "discussions"; it is a workflow streamlining system, which "discussions" are just an aspect of. –Quiddity (talk) 23:05, 7 July 2013 (UTC)

As a quick note of my own, before I respond more substantively to you, I see a comment by an IP below, that says, in part, that it would be a good idea to make the link to the talk/whatever page more conspicuous, to make more people aware that one can discuss improving an article. That's something I can happily support, too.

Now back to what you said. I think that you are correct. And that's part of what I see as a cause for concern: the choice of word seems to reflect how the software works, rather than how the editing process works. Although "discussions" are, indeed, just one aspect of how Flow works, the important thing is to encourage discussion, rather than to show off how cool Flow is. That the software has all of these new capabilities, all of those ways to organize portions of a discussion independently of one another, strikes me as excellent. What I'm worried about is how we communicate with new editors. It's important that they understand why this isn't, for example, a place where everyone has an avatar (see that same comment below), but is a place to discuss, cooperatively, how to improve content. It's far less important that the first thing they are "told" is that subsections can be transcluded. --Tryptofish (talk) 22:28, 8 July 2013 (UTC)

• Based on a discussion at Wikipedia talk:Consensus#Decisions by WMF software developers, I feel the need to ask, again, what I have asked before. I would like someone from WMF to explain, in plain English rather than in software-speak, whether or not, with implementation of Flow, the English Wikipedia will be able to continue to have the word "Talk" (or some other word of the English Wikipedia's choice) appear in blue at the top of pages, as the link to what will be called "Talk pages" (or whatever the English Wikipedia chooses to call them). This is a Yes or No question. I'm not referring to how boards will be presented in terms of software development. Call this "user-facing" if you wish, but I'm referring to what new editors will see when they look at their computer displays when they first come to Wikipedia. Yes or No. --Tryptofish (talk) 16:46, 10 July 2013 (UTC)

 Done, in #A note: board versus talk versus flow versus Cygnus X-1, below, where the answer is essentially "yes". --Tryptofish (talk) 18:01, 10 July 2013 (UTC)

What should research look at?

I've been trying to figure out how best to move this discussion towards a productive outcome, and I think that it would be good to consider how to improve the planned research about how to reverse the editor decline trend, in terms of how to have an evidence-based choice of the best word for "talk" or "board" on the English Wikipedia. What should the research include? What should it steer clear of? --Tryptofish (talk) 22:43, 8 July 2013 (UTC)

Per the explanation at #A note: board versus talk versus flow versus Cygnus X-1, this discussion is about the eventual research to be conducted about the user interface on the English WP. That research isn't happening right away, but it should still be helpful to WMF to provide editor suggestions here. --Tryptofish (talk) 18:16, 10 July 2013 (UTC)

Tryptofish's suggestions:

1. Don't simply assume that what has worked best at other kinds of websites will also work best here. Instead, consider what will help orient editors towards editing an encyclopedia cooperatively, in the ways that Wikipedia works towards WP:CONSENSUS.
2. Don't simply ask which words potential new editors recognize at first sight, but instead examine what assumptions they associate with those words, in terms of how editing works. If someone says "Yes, I know exactly what that means I should expect", don't assume that what they expect is what we think they should expect. Maybe they are envisioning something that will lead them to get off to a rocky start as an editor, in a way that would harm their retention, and we shouldn't want that.
3. Consider input from experienced editors, as our experiences are a form of data, too. Don't blow us off. Let's say there ends up being an RfC about "board" versus "talk", and the community says something that the developers didn't expect. That's useful information.

Thoughts? Other ideas? --Tryptofish (talk) 22:43, 8 July 2013 (UTC)

Side-discussion about a proposal to alter the relationship between WMF and WP.

Here is an idea; have the WMF make it a configuration option and stop telling us what to do in situations where it takes extra work to not let us make our own decisions. That's right; extra work. If WMF does nothing special to address this, there is already a configuration option that allows it to be called "Board" or "Dyskusja". As has been repeatedly pointed out, if the first WMF response had been "That's a configuration option. We are going to send it to you set to 'Board' because that makes sense to us but if you want to call it 'Talk' or 'Discussion' or even 'Dalek Supreme Council Meeting Minutes', you can." that would have been the end of this. Why is this even an issue? --Guy Macon (talk) 23:32, 8 July 2013 (UTC) I suppose one possible answer is WP:CONEXCEPT, and another is that it's good to base decisions on research. But I think your question should be answered by WMF, not by me. About configuration options, my biggest concern is with the default setting, because that is what new editors will see first. Anyway, it IS an issue, whether it should be or not. I'm working with the situation we have, not the situation that I wish we had. You should, too. --Tryptofish (talk) 00:04, 9 July 2013 (UTC) Oh, and one more thing. If WMF shows no interest in engaging with these suggestions, there will be an RfC. --Tryptofish (talk) 00:08, 9 July 2013 (UTC) I have proposed a clarification of our policy. See Wikipedia talk:Consensus#Decisions by WMF software developers. --Guy Macon (talk) 04:31, 9 July 2013 (UTC)

Indenting in the new system

In a lot of ways, I think that the proposed new system for indenting is going to be a very helpful improvement. I frequently see new editors getting confused by talk page indentation, and making it more user-friendly is a good idea. However, I wonder about some situations where users will want, for good reasons, to use non-default indentation, and I want to ask how those situations would work. One is where two users both want to reply to the same post. The second of those two repliers may want to use the same indentation as the first, to show that they are replying, not to the first user who replied, but to the same user that person was replying to. Another situation is where someone chooses to use Template:Outdent. In each of these cases, there is a valid reason to override the default, and there may be other examples. Will it be possible to do these things, without getting into a sort of edit war with the software? --Tryptofish (talk) 16:18, 29 June 2013 (UTC)

Indentation is just a visual artifact. If the software is to be done right, and I assume it is, this will be a non-issue. The software will be built in terms of threads and posts, not indented text. So each user could choose to view a thread in a different way - flat, tree and outdented at whichever level they please. Something like LiquidThreads, only less obnoxious. Hopefully. Keφr 16:58, 29 June 2013 (UTC)

I guess you can understand why I would have questions, when the chosen precedent is something about which we have to hope for less obnoxiousness. Knowing that each user can set a preferred outdent for viewing is helpful, thanks. But what about each editor being able to indicate, when editing, where the reply has been aimed at, in a manner that will not disappear when other users view it? --Tryptofish (talk) 17:09, 29 June 2013 (UTC)

Well, I guess you will just click the reply button under the post you are replying to, and then magic happens, right?

Though I have no knowledge whether custom viewing modes would be available as a preference in a vanilla installation — maybe a userscript will do that — I just say that it will be technically possible to do reliably. And I am assuming here that Flow will have unlimited threading.

Current content of mw:Flow_Portal/User_to_User_Discussions suggests that thread depth will be limited. I am not particularly enthusiastic about this. Keφr 17:33, 29 June 2013 (UTC)

Indentation will be automatic. The use of Template:Outdent is a work-around for the limitations of the current software - namely, that after X degrees of indentation, the threading becomes meaningless and impossible to follow. To reply to a specific comment, one does just that - reply to that comment. The indentation of your reply will automatically be correct, and will correctly be placed within the comment tree (e.g., at the bottom of the closest point where indentation can occur). This is complicated to describe in text; in the coming days (hopefully this week) I'll have a new version of the prototype with correctly places comments (it is a bit of a bear to get this working in Javascript, but I did it in my current copy).

The biggest problem arises when one wants to indent at "level 0" - that is, reply directly to the title of the topic. This is a bit of a pain in the ass, usability-wise, and frankly doesn't make a lot of sense in a conversation flow. Most of the time the people use "outdent" to avoid deep nesting. Flow is designed to handle this fluidly.

(I encourage you to read some of the thinking about this)

Currently, we are aiming to have threads become "flat" after 5 or 6 levels of nesting. Beyond that, nested comments tend to become less productive (echo chambers), more hostile (no, screw you), and difficult to read (smaller text boxes). That is not to say that the metadata of the nesting is lost; this is retained, and if those deeper threads are split out, they'll automatically align correctly.

I hope this helps.--Jorm (WMF) (talk) 01:15, 1 July 2013 (UTC)

Yes, thanks, it does. I don't know if it answers everyone else's questions, but it answers mine. --Tryptofish (talk) 00:13, 2 July 2013 (UTC)

Brandon (temporarily) AFK

Hey all :). Sorry about this, but Brandon's up in Tahoe over the weekend and has...pretty much nil bandwidth, so he'll not be able to get back to you until Monday, looks like :/. He's very sorry about this - hence poking me via his mobile to drop this note. Okeyes (WMF) (talk) 17:12, 29 June 2013 (UTC)

If I were him, I would choose Antarctica. Keφr 17:52, 29 June 2013 (UTC)

Thanks for letting us know, Okeyes. I understand he's the lead for this particular product, and I'm happy to let him have a peaceful weekend. I trust he'll return refreshed and eagerly reviewing the participation here. Risker (talk) 20:49, 29 June 2013 (UTC)

From what I've been hearing about the weather down that way, he'll return burned to crisp... Beeblebrox (talk) 22:26, 30 June 2013 (UTC)

It was crazy hot and I got some sun but my people don't burn. I'm catching up now; will respond in a bit. Spoiler: I may snark a bit.--Jorm (WMF) (talk) 01:06, 1 July 2013 (UTC)

Editing own comment in the interactive prototype

I made a comment in the prototype and then wanted to try editing it, but for the life of me I couldn't find an edit link (just the Reply button). Am I missing something obvious here, or has that just not been implemented in the prototype yet? rʨanaɢ (talk) 11:57, 2 July 2013 (UTC)

Comment editing has not been implemented in the prototype.--Jorm (WMF) (talk) 17:00, 2 July 2013 (UTC)

FYI, in the version of the prototype I am working on (to be published soon), comment editing is included. As are about a gazillion other functions (topic deletion, restore, suppression, history view; comment deletion, restore, history view, edit). I did a major refactor recently that has allowed a lot of new functionality to be implemented easily.--Jorm (WMF) (talk) 23:18, 5 July 2013 (UTC)

Page protection

I wonder how page protection would be handled. We have to protect talk pages from time to time due to abuse. In Flow, I can see at least two forms of protection: one preventing posting comments (as new threads or in existing threads) and one preventing editing other users' comments (the former automatically implying the later). I think that both would have their uses. Cenarium (talk) 21:19, 5 July 2013 (UTC)

Well, this is a sticky wicket, and one I've spent no small time thinking about. Let's leave aside "editing comments" for a moment, or even "creating new topics" and instead focus on simply "adding new comments to an existing topic."

Let us be clear about the major differences between talk pages and Flow board topics:

• Talk page threads are "owned" by the page they are on, and are thus naturally bound by the protection rules of the page.
• Flow topics are not owned by anything, really. They will have a tracked point of origin but they can appear in multiple boards.

Topics have weird protection issues - if a topic appears on board A and board B, and board A is protected, can I not then edit the topic on board B? This is problematic.

Now, a simple solution would be to apply the greatest security to all topics. If it's on A and B, and A is protected, all threads on A have A's protection (and cannot be edited from B).

But what if we're dealing with, say, an AN/I thread about a blocked user. The topic exists in three places: AN/I, the blocked user's board, and then the board of the user who started the AN/I thread. The blocked user shouldn't be able to edit AN/I, but should be able to edit their own talk/board, yes?

So three dimensions of complication: user rights, page protection, and the board from which the topic is accessed.

Complicated. I have thoughts, but I'm actually more interested in hearing your ideas about it before I reveal mine (so that I can better understand your reasoning).

Let me also say that there is a fourth dimension to this problem (which I've alluded to before, regarding comment editing), that makes it even more complicated (but also more awesome). I'm going to leave it as an exercise to the reader to see if they can figure out what the fourth dimension is.--Jorm (WMF) (talk) 23:27, 5 July 2013 (UTC)

I believe the fourth dimension would be the age of the message, which I assume will be handled better than we do now; archive bots are nice, but they are a rather blunt tool. Right now, on some high-volume talk pages the answer gets archived before you get a chance to read it. On some low-volume talk pages a question from 2006 sits unanswered at the bottom of the talk page until someone replies in 2013 with a request for more detail. --Guy Macon (talk) 09:13, 7 July 2013 (UTC)

Interesting guess, but no. Topics will be able to be "closed" and summarized - like a hatnote - by anyone (and then re-opened by anyone). While a topic is in the closed state, it will accept no edits or comments. This is different than a topic that has grown "stale" - has had no responses in, say, 30 days (or 2 weeks, or whatever - configurable number). A stale topic will allow you to respond/add comments to it, but you'll be warned that the topic is really old, and probably you should make a new one.

Note that we may not actually want to warn people not to respond to stale topics. An older topic will have subscribers; a new topic will not. This is something that we can't know the answer to immediately and will have to learn organically.--Jorm (WMF) (talk) 17:23, 7 July 2013 (UTC)

This really depends heavily on the implementation details, and on that count I have some ideas as you know already. So before delving further on protection, I'll think on the general framework a little further. Cenarium (talk) 15:25, 8 July 2013 (UTC)

Haven't read the details of this program so apologies, this is high level

Think outside in. Please consider how things work in the "real world" rather than making iterative changes on the current Wiki model. There are a lot of screwy things on Wiki (people editing each other's talk, no avatars, ability of anyone to edit a user's wall, etc.) Every other site (linked in, forums, facebook, diet sites, etc.) has the opposite. And that is BS to act like we're all serious and not social. Also think of the functionality. Why should a user page or a talk page have the same structure as a collaboratively edited article?

Making changes to the Wiki layout and code and such is really the one "lever" that the WMF can use for making change. You can't reorganize the moderation structure, change article formats, even the damned MOS. But you have control over the software. Think of the new users and be open to the huge real world.

Or look at how poorly talk pages are used for reader feedback (they work OK for article development by hard core users...but some ability to chat back and forth with the real "customers" is not really there. For some reason, no one clicks on there...they just don't. Maybe if you had another window (old "article talk" became "article construction talk" and have a new one for "reader feedback" (and make it easy to edit, like a forum). Yeah, there would be some overlap, but right now...there's just NOTHING. Maybe getting direct feedback and discussion with real readers (not been here since 2004 regulars) would make people who write articles feel more energized, or affect how they write to improve it (e.g. cleaning up the mess of math project people), or even by engagement...leading to some readers (hopefully the better ones) deciding to get involved. But this para is just idle ideas.

TCO (talk) 19:08, 7 July 2013 (UTC)

P.s. It's easier to ask for forgiveness than permission. Just change stuff and act apologetic when the regulars scream. (Yeah, be open to real usability issues and learning from bugs and all that. But some of the static is just the same crap you hear whenever someone changes the background color on a message board. Risker crying about the edit button moving without consultation was a hoot). Oh...and I'm trolling, but I mean it too.

Yes, avatars! Where are my avatars?! Obviously the killer app that Wikipedia desperately needs is avatars with every user message, to foster a sense of friendliness and community. Right now, when someone makes an ill-advised or mistaken edit and gets a big template full of jargon on their talk page threatening them with all kinds of consequences, it alienates people. But with avatars, all that will be fixed! Then new editors will see things like:

"Please refrain from making unconstructive edits to Wikipedia. Your edits appear to be disruptive and have been reverted or removed."

and feel all warm and fuzzy inside, and go on to read a hundred or so policy pages and eventually make another edit without getting reverted or templated by another Twinkle user.

And an observation with regards to article talk pages: perhaps more readers would take a look at them if there was some indicator the page existed other than a tiny tab jammed up into the top edge of the screen where they'll never look in the first place, since the only thing they're looking at is the big chunk of black-on-white text taking up the majority of the screen. --108.38.191.162 (talk) 20:10, 8 July 2013 (UTC)

To add a data point to my assertion, it appears that some non-veteran editors are posting non-VE-related questions to Wikipedia:VisualEditor/Feedback, apparently because the VE interface has a big "?" link in the editing area that directs you to the Feedback page. So this would seem to support the claim that people are more likely to notice something if it's prominently placed in their area of focus. --108.38.191.162 (talk) 00:20, 10 July 2013 (UTC)

• Yep, I know it was a hoot, TCO. Except that my already-meagre edit rate dropped noticeably (both under username and IP), and I just didn't bother fixing things that I used to fix all the time. And there's still no evidence that it improved anything other than to implement a change that someone thought would be a good idea several years ago based on interviews with a handful of people, several of whom said they wouldn't edit Wikipedia no matter what the interface. I'm all in favour of evidence-based changes and decisions. I'm very much opposed to making changes based on outdated statistically unsound research.

  In the case of "Flow", I'm just really not seeing the vision here, much as I'm trying. When I look at the prototypes, I'm not seeing "great communication", I'm seeing what my mom used to call "goop mélange". I see some stuff I like; the better organization of indenting, for example. I dunno; I'd not consider this anywhere near the priority of, for example, actually rewriting MediaWiki core so that all the extensions being built don't have to weigh down the process of editing and communicating any further than they already are. I'm getting sick of page loads over a minute on high speed connections to fast computers, and that isn't going to get fixed without some awfully major work under the hood. Risker (talk) 23:41, 10 July 2013 (UTC)

A note: board versus talk versus flow versus Cygnus X-1

I'm going to try and provide a single, relatively concise summary of where we stand here, just to wrap things up. Two caveats; first, I have to go into a bit of background. This background may be fascinating, boring or wrong depending on the detail to which you know how MediaWiki works. Second; very TL;DR. So. What we've got here is a discussion over the user-facing terminology with flow: specifically, whether a user's talkpage will be called their board or, well, their talkpage. The software plan says "board", some editors feel very strongly that it should be "talk".

What I want to underscore is that the software terminology does not have to (and in many cases does not) translate into user-facing language. For us to build software that works on every project, in every language, we need to localise the user-facing terminology. Because of this, every extension we build contains a localisation file that contains language-specific strings. Users using the english-language Wikiquote are sent to "discussion" pages. On the german-language Wikiquote, "Diskussion" pages. In addition, as you'll probably note on enwiki we send users to "talk" pages. This is because not only is user-facing terminology customisable on a per-language basis, it's also customisable on a per-wiki basis by modifying pages in the MediaWiki namespace - which any admin can do. The long and the short of it is that what the software calls a page - be it talk, discussion or diskussion - is nothing to do with what is presented to the user. It just controls the terminology developers and product people use internally to describe different components, and things like variable names within the code.

What we're discussing at the moment is the terminology, internal to the software, not the user-facing strings. Us calling it a board does not mean the community has to call it a board, or that the UI will say "board". We can call it, just for enwiki, board or talk or Cygnus X-1 look, I'm a Rush fan, okay? We don't have to decide that right now, and indeed, I believe we shouldn't, for two reasons. The first is that we've got a relatively small number of people here. If we do decide to rename it, we should rename it with the presence of a lot of editors - we should have community-wide consensus for what is ultimately a community-driven, community-wide change. While I really appreciate the time people here have put into discussing this problem, and the arguments on both sides, I don't see that many people participating in the conversation.

The second is that, ultimately? We have bigger fish to fry. This is a conversation that can be held off for however long; if we decide to change things, the technical alteration required is trivial. What isn't trivial is the software as a whole - the components, the rationale behind them, and how it actually functions. That's something complex, something time-sensitive, and something I think we should prioritise discussing so we can get it right as early as possible. When we've got something built, we can discuss user-facing terminology then; it's not a discussion with an expiry date.

Now, when that discussion happens, I can't promise that the community will get its way, if the full community decides on a name. Part of this is because, well, I don't like making assurances that people will get their way and then finding out that they have decided to call it Cygnus X-1 :P. Part of it is because I, as I'm sure applies to all of us, like making judgments based on data. What I'd really like to see (and what I know the Flow team is planning on) is actual data on whether the user-facing terminology, board or talk, makes an impact on how easy the purpose of the software and the software itself is to understand. That data may show that actually, board really is easier - or it may show that talk is. I don't know; I don't think any of us know. And I don't think we should make a decision until we do.

So, to summarise; we're not binding people into having user-facing terminology that always, definitely, no-holds-barred matches what the software calls things. We're just explaining what the software calls things. That can shift for users and remain constant for the software; we have the capacity to trivially do that. But if we're going to do that, we should do that in the presence of data, in the presence of a lot more editors, and when we've settled the substantive issues. Because talk versus board isn't attached to a ticking clock, and how this software works is. I hope this clarifies things. Thanks, Okeyes (WMF) (talk) 17:45, 10 July 2013 (UTC)

That was a very helpful explanation, thanks! (And I don't mind the length at all. I was happy to read it.) For me, the key piece of information is the existence of localisation files for each Wiki. That makes all the difference in the world! So long as no one else from the WMF comes along and contradicts that, I would say that all of my previous concerns have been answered to my full satisfaction. For me, no more problem. There, that wasn't so difficult, was it? --Tryptofish (talk) 18:12, 10 July 2013 (UTC)

No problem. I would like to reiterate I don't think we can come to a consensus with who we have now, and that I can't guarantee any consensus would be implemented - but that it's implementable, regardless of what we call the software component, is not in doubt. Okeyes (WMF) (talk) 22:27, 10 July 2013 (UTC)

I fully understand, and I fully agree. I'm not looking to call talk/whatever pages what I, personally, want. I simply wanted to make sure that the process would be one in which the community, as a whole, will be able to give input, and the input will be received in a constructive spirit. I am satisfied that this will be the case. I intend what I suggested about research in the last sub-section of the discussion thread above to be helpful in that regard. --Tryptofish (talk) 22:33, 10 July 2013 (UTC)

Indeed, a very helpful and clear explanation. Much thanks for writing all that. :) –Quiddity (talk) 22:34, 10 July 2013 (UTC)

I'm now wondering how customizable it is. I mean, any admin with sixty seconds and a flame-proof suit can change it for the whole site, but I like the earlier suggestion of "Happy-Fun-Talky-Place", and I think it would be the perfect label for pages under discretionary sanctions. Or maybe ""Happy-Fun-Blocky-Place" would be even better. WhatamIdoing (talk) 23:25, 10 July 2013 (UTC)

Actually, for April Fool's in...2011? I made the tagline "from Wikipedia, the free encyclopedia" read "from Wikipedia programmer Brandon Harris", on every article. It lasted all of 2 minutes before he shouted me into taking it down. We're a fun community :D. Okeyes (WMF) (talk) 10:10, 11 July 2013 (UTC)

Okeyes, I was here the entire time and did not participate in the conversation because my questions were being asked, and answered, by people much more experienced than me. There may have been others who did not participate for similar reasons. It got pretty hot at times; then you showed up and did what you do so well - Liaison. Thank you, and thanks to all who participated. Respectfully, Tiyang (talk) 19:39, 13 July 2013 (UTC)

Talkback templates, how to let others know a conversation is occuring?

Talkback templates seem to me to have a dual purpose. 1) Yes, they have the readily apparent "hey, I replied to your post over here, come see what I had to say" function. 2) They let 3rd parties know that a conversation is happening and where that conversation is. Why would we care or want to let a third party be able to notice that a conversation is occurring? RfA's, for instance. Why not comb through a user's contributions? Because a user, especially an anti-vandal user, may have thousands of contributions that have nothing to do with any conversations and, if someone is interested in seeing how a specific person interacts, posts, and responds to other people, then some way should be found to call out which edits are just edits and which edits are conversations. That's part of the use of talkback templates, that a note is left on a user talk page so that 3rd parties can see that something is happening with that person. Banaticus (talk) 09:17, 12 July 2013 (UTC)

How would edit conflicts be prevented?

How would edit conflicts be prevented? People might still be working from a different start point. To have live constant updating of a page, we'd need some sort of constant AJAX update (which, for extremely busy pages, might make the page almost as fluid as water). If pages aren't constantly updating themselves while you read a page (after the initial page load), then people might be starting from two different points, which would lead to an edit conflict. For instance: "John is a hat." Two people (Bob and Steve) view a page and they both decide to edit that, and they both click edit, but suddenly the timer goes off on Steve's oven and he has to go check his cake. Meanwhile, Bob edits the page to say, "John is a wide brimmed hat." Meanwhile, Steve comes back, types in, "John is a straw hat." In this case, it would be ok for the software to mash the sentences together, "John is a wide brimmed straw hat" but that won't always be the case. No matter what the editing style is for this new flow system, how would it completely prevent all edit conflicts? Banaticus (talk) 09:28, 12 July 2013 (UTC)

For those who are unfamiliar with the basic problem of computer science that Banaticus is talking about, I highly recommend reading A plain english introduction to CAP Theorem by Kaushik Sathupadi. It isn't long; when I printed it out it fit on one double-sided page. --Guy Macon (talk) 19:37, 12 July 2013 (UTC)

Related: https://bugzilla.wikimedia.org/show_bug.cgi?id=41338 --Guy Macon (talk) 21:05, 12 July 2013 (UTC)

So, it's been a couple days. I'll let this stand for a couple more days, then I'll edit the main article to remove that assertion. Stating that Flow will prevent all edit conflicts seems highly speculative to me, if not misinformation -- I don't think preventing all edit conflicts is possible when you have a huge number of editors who all want to edit a single page (such as the Zimmerman/Martin page, Barack Obama's page back during the election, etc.). Banaticus (talk) 22:13, 14 July 2013 (UTC)

Uhm, Flow will prevent edit conflicts within the conversation space. It won't do anything about edit conflicts within articles. I'm not sure where the idea that it would stop article conflicts came from. Flow is not for articles. It is for talk/discussion.--Jorm (WMF) (talk) 22:21, 14 July 2013 (UTC)

Pre-impressions and questions + analysis

I tried the prototype, I liked it. The thing I found the most difficult about it was that it was very hard to tell what level of indentation a comment was at when the indentation became complex. In the wikicode I can just read the tally of colons. In the Flow prototype for some replies I had to employ methods such as moving my mouse cursor onto the left most edge of the comment and then holding it in place while I scroll up until it aligns with a sister that is directly under the parent. Or measuring the distance from the margin. Wouldn't it be easy just to include a numeral with each comment which communicates the indentation level?

My question is, when this is implemented, is it even going to be a wiki? Will all the edits made by a user in Flow discussions be listed in his Special:Contributions? --Atethnekos (Discussion, Contributions) 06:49, 13 July 2013 (UTC)

I'm comparing more and now I'm not so sure if I like it. In the wikicode, I find the the majority of the screen gets filled with the data that I'm on the discussion board to see—i.e., it's efficient. In the Flow prototype, there is a lot of blank space, and then repeating headers, and reply buttons, and just generally a lot of cruft which doesn't contribute to the discussion—i.e., it's inefficient. --Atethnekos (Discussion, Contributions) 09:18, 13 July 2013 (UTC)

Comparison & Review

I've done some comparisons and obtained some numbers:

I made an example "old" discussion at User:Atethnekos/cfflowtest. I used text generated by [16]. The bare text is at User:Atethnekos/cfflowtestbaretext. I then re-created this discussion in the flow prototype (working backwards at each level so as to match the order in the "old" example); I also had to adjust text appearance size down one level in the flow prototype to match the "old" example.

I've compared the number of characters and words of the discussion (not signatures, etc.) that are visible in each form: old view, old edit, and Flow prototype. I also compare with the old view and edit when the margins are narrowed so that the width of column of text is equal to that of the Flow prototype; I just used my tab-bar for this, for ease. Graphics are below.

• In the old view (example 1): 5199 characters, 753 words; up to "Mauris feugiat...sollicitudin magna";
• In the old edit (example 2): 3323 characters, 479 words; up to "Aenean sed...porttitor vel";
• In the Flow prototype (example 3): 1126 characters, 158 words; up to "aliquam semper...ridiculus mus.";
• In the old view, margins narrowed (example 4): 2950 characters, 411 words; up to "Pellentesque pharetra...sed dapibus";
• In the old edit, margins narrowed (example 5): 1442 characters, 202 words; up to "Phasellus accumsan...semper dapibus.";

Comparison graphics for Flow prototype

• 
  Example 1, old view; 5199 characters, 753 words
• 
  Example 2, old edit; 3323 characters, 479 words.
• 
  Example 3, Flow prototype; 1126 characters, 158 words.
• 
  Example 4, old view, narrowed; 2950 characters, 411 words.
• 
  Example 5, old edit, narrowed; 1442 characters, 202 words.

comparison graphics

Thoughts: The Flow prototype may be more easily digestible for new users. However, for those editors who have for a long time already kept to a diet of meaty discussions, they may not want something so milquetoast. I think it's normal for those who have dealt with monitors and text input (whether computer programmers or writers) to have a demand for more content on their screens. Perhaps even the level of discussion can be affected by this. I think certainly without good-use of screen real estate, the efficiency of reading and responding to discussions goes down. If longtime editors are needing more time to absorb and respond to discussion, then I think it's natural that in the long run they will contribute less discussion content rather than contribute more time to make up the gap, and so the quality of the dialectic will go down.

If the margins on Flow can be widened, then maybe the gap can be made up. But I think the narrowed-margins examples show that further redesign would be required as well to bring parity with the old ways. --Atethnekos (Discussion, Contributions) 17:54, 13 July 2013 (UTC)

There are a few threads at mw:Talk:Flow Portal that touch on this. As I wrote there: I think the Prototypes, just like the earlier static-mockup-illustrations, are more for demonstrating the concepts and features and possibilities, rather than for the aesthetics. Software devs tend to make clear and simple models initially, and leave the aesthetic-fine-tuning until later... So: Ignore the design, focus on the abstract concepts of "workflows". (Everyone agrees that the prototype is not representative of the final design.) Hope that helps. –Quiddity (talk) 19:06, 13 July 2013 (UTC)

Thanks for the response. I suspected as much, I just thought I would lay out my thoughts as I had them.

I'm trying to understand the concepts as well. I had two questions above toward that end: Are Flow discussions going to be wikis? Will edits made in a Flow discussion show up in Special:Contributions? --Atethnekos (Discussion, Contributions) 19:52, 13 July 2013 (UTC)

Yes, changes will show up in contributions, though that is going to be a far more complex problem to solve than I think people understand. The central issue is that Flow contributions will be stored in a separate database, and not in the local wiki database. This brings many different issues to the table. In this case, it means that a query to return all of your contributions will have to be run against two databases instead of one (which is a performance hit). However, the performance gains for having Flow conversations on a separate database will far outweigh this.--Jorm (WMF) (talk) 20:41, 13 July 2013 (UTC)

Sounds bold. Thanks for the insight. I think I have a final topic of questioning: Will it be possible in Flow copy references and citation templates from the article as they are edited (in either text editor or VE) and then paste them into the discussion and have them viewable there both as edited and as rendered? --Atethnekos (Discussion, Contributions) 21:02, 13 July 2013 (UTC)

That. . . is one of the problems. Yes, you will be able to include references and the like (as much as the VisualEditor allows). However, since the Flow data will be kept on a separate database, the localized links (links to pages on the local wiki) may break if they are not properly composed with interwiki prefixes, depending on how the Flow post is viewed. And this is me letting a big cat out of the bag; I will leave it up to the reader to determine exactly which cat I am referring to.--Jorm (WMF) (talk) 21:25, 13 July 2013 (UTC)

Thanks so much for the insights. I really feel like I'm starting to understand what Flow will be. Is it just plain not going to be possible to allow such work (references and citations) in Flow with the texteditor (as opposed to with VE)? I only ask because last time (if I'm remembering correctly) that I was asking about the goals of VE in the IRC channel, the developers seemed to imply that there was no intention anymore (although at one time there was) to replace fully the texteditor, because they didn't have intentions to make VE as efficient as the texteditor for experienced users. --Atethnekos (Discussion, Contributions) 08:43, 14 July 2013 (UTC)

Roadmap

Flow is coming. From wikitech-l:

• June: started architectual discussions.
• July: have/or will hire for Front End engineers.
• August: work on the API design.
• September: First experimental release of the user-to-user discussion workflow (probably limited to an opt-in group).
• December: Goal date for the full production release of the user-to-user discussion system.

More at mw:Roadmap#Flow. Johnuniq (talk) 08:06, 13 July 2013 (UTC)

In that case, it's not too soon to think about #What should research look at?. --Tryptofish (talk) 18:40, 13 July 2013 (UTC)

New Version of the Flow Prototype Released

A new version of the Flow Prototype has been released. Please read the release notes here. This version has many changes, not the least of which is that it approaches full functionality.--Jorm (WMF) (talk) 21:19, 13 July 2013 (UTC)

What do you mean by "full functionality"? If it doesn't have Wikipedia templates (or, at least, allowing "free-form" content to be attached to individual "flow" messages/objects, not just one per "talk page" or one per "thread"), then it will not be suitable for discussions about detailed Wikipedia article formats. — Arthur Rubin (talk) 09:52, 14 July 2013 (UTC)

There have been numerous attempts at Wiki-editors over the past many years. None of them have really managed to handle templates and tables (and most couldn't handle tables either). You'd need a wiki-parser to truly handle templates, which would seem to mean that editors would need to download a client to edit Wikipedia. Templates are amazing and super powerful, but there is a learning curve for that. It's like Ruby or JavaScript or C++ or any other programming language -- there is a learning curve, but you can start off easy with simple applications and then go on to create absolutely amazing things. The best thing, in my opinion, that could be done is to make templates simpler, by actually using a programming language (such as the current push to put lua into the wiki). Right now, for instance, the citation templates (to grab a really common example) are a gigantic tangled ball of yuck. I think it would be far more productive to go through complicated "multi-call" templates like that and to streamline them with actual programming calls. I started out learning wiki syntax by making simple templates like userboxes, etc. Then came the decision that userboxes and other user-material weren't "real" templates and shouldn't be in template space but rather should be in user space, and then people figured out how to do format language strings with repeated template calls and templates just became far more complex and difficult to learn. I've worked my way through them, keeping up as they changed, but it's difficult for new people because more functionality is simply tacked on to old stuff. I just feel that time would be better spent making templates easier to parse (for everyone, not just computers), than to try to create something that can parse on the fly all the snarled complex webs that now exist. Banaticus (talk) 22:21, 14 July 2013 (UTC)

WMF intends for Only VisualEditor to be usable on Talk pages under Flow; representative states he would "dearly love to kill off Wikitext".

Jorm is a representative of the Wikimedia Foundation, who are in charge of all of us. He's responsible for developing "Flow", the new talk page system. And he's saying some things that no member of the WMF should be saying.

""You should strive to achieve Zen acceptance that the only editor for Flow will be the VisualEditor. If, by the time Flow is released, the VisualEditor supports a native code editor, it will likely be there. But nothing is promised - nor can it be." - Jorm (WMF)"

He went on to add "It is entirely possible that the data for each post will not be saved as wikitext because there are considerable performance issues that arise when doing so. If this is the case, things like templates will simply be unable to be supported." and further added "I would dearly love to kill off Wikitext."

I apologise if the links are a bit weird - they use LiquidThreads there, and linking to individual threads is buggy.

Is Jorm acting in a rogue manner? Perhaps. But until the WMF denies it, we need to presume this is true. Adam Cuerden ^(talk) 00:36, 15 July 2013 (UTC)

If you're going to spam this exact same misinformation to a zillion places, could you at least get my name right? --Jorm (WMF) (talk) 00:39, 15 July 2013 (UTC)

How is it misinformation? They're exact quotes. Adam Cuerden ^(talk) 00:46, 15 July 2013 (UTC)

Quotes that are taken out of context and supplied with maximum hyperbole. This isn't helping anything.--Jorm (WMF) (talk) 00:51, 15 July 2013 (UTC)

I don't see how they're out of context. I read all the threads. If you have a different viewpoint, state it here. Adam Cuerden ^(talk) 00:57, 15 July 2013 (UTC)

Look - one thing we know for sure is that Flow needs to be designed with the VisualEditor and HTML5 first and foremost in mind. We can't design it around all the legacy assumptions and affordances of wikitext. That doesn't mean that some kind of source or markup mode is necessarily impossible, but it may be different "under the hood" than wikitext as we know it. We definitely want to make sure that you can continue to post to Flow boards with older browsers, and since VisualEditor doesn't support them, we'll likely have to provide a fallback mode.

As for templates, one of the goals of Flow is to offer a more user-friendly method than {{subst:}}ing templates into talk pages for leaving standard messages or enabling more complex workflows. That doesn't mean that templates within a Flow message will necessarily be unavailable (clearly some support for templates will be required), but we want to make sure that we can offer intuitive interfaces for the most common and most important tasks without forcing users to manually find the right templates.

Flow is still in the prototyping stage, and we're continuing to analyze these use cases. As we do so, some requirements will increase in priority and others will be dropped. But Flow will representa big and dramatic shift from talk pages as we know them, and we want to make sure that we let users know early that change is coming.--Jorm (WMF) (talk) 00:58, 15 July 2013 (UTC)

1. Is a theoretical VisualEditor-based support of Wikimarkup the only path you intend to persue for Wikimarkup being used in Flow? Yes or no?
2. Do you intend to work with the VisualEditor team to make sure that Wikimarkup support exists? Yes or no?
3. Are you willing for Flow to not support any or even all preexisting templates? Yes, all. Yes, some, or No?
4. Will the communities be allowed to decide whether Flow gets activated on their Wiki?
5. What mechanisms will be in place to prevent breaking of template-based projects on talk pages?
6. What is being done about making sure the visually impaired can use Flow, if it has a default VisualEditor?
7. English Wikipedia uses a lot of templates on talk pages that form core parts of project functionality. These include:
   1. Wikiproject templates
   2. Good- and Featured- article-related templates, and related (e.g. Did you know)
   3. Notifications of past discussions.
   4. Links to archives. How will Flow prevent all these from breaking?
8. What about bots? Will they break?
9. Will talkpage archives break?
10. What about sections of Talk: namespace being used to develop articles? How will Flow be turned off for those sections?
11. Before launch, if any of the features above cannot be supported, will you still activate Flow on Wikipedias?
12. If VisualEditor's A/B test data comes back negative for VE, what then?

Adam Cuerden ^(talk) 01:15, 15 July 2013 (UTC)

Responses, in order:

1. No, but it is the strongest candidate, and that's where we are.
2. No. It's not my job, and I'm not going to tell them how to make their sausages.
3. Yes. There will likely be many templates that Flow will not support. This is a VisualEditor thing, though.
4. Not my call. I'd say that it isn't likely, however.
5. Outreach work to help people convert.
6. As I've said several times, there will be a fallback for these situations.
7. Flow will not prevent those from breaking. Flow will provide different, better ways of managing these workflows. That is what this project is about entirely.
8. Archive links remain the same.
9. Bots will not break.
10. Talkpage archives will not break.
11. Flow will likely have functionality for "collaborative" topics, which handles that use case. This is still being designed.
12. Not my call. The answer is likely "yes," however, because we will be rolling out an opt-in version.
13. Not my call, and I can't speculate.

I hope this answers your questions.--Jorm (WMF) (talk) 01:22, 15 July 2013 (UTC)

Prototype has a strong emphasis on when a post was made

The current prototype has a strong emphasis on when a post was made, which is often irrelevant, particularly on article (or even user) talk pages where discussions can and will span years.

There's also a feature in the prototype that brightly warns a user against replying to posts older than thirty days. This seems pretty bad. --MZMcBride (talk) 00:59, 15 July 2013 (UTC)

I can't think of a single style of conversation wherein people do not know who is talking before the comment is made. Talk pages (signature at the end) are the only ones where you read a whole block of text before you know who is speaking. That's disconcerting and was brought up several times in the user tests as to not being intuitive.--Jorm (WMF) (talk) 01:02, 15 July 2013 (UTC)

As far as the warning thing, I hate it, too, but it's there because it was a feature asked for. It is to illustrate how something could be done to avoid resurrecting dead threads. Personally, I think that we'd want to have people go to existing threads, since those threads will have subscribers already.--Jorm (WMF) (talk) 01:02, 15 July 2013 (UTC)

Space taken up by a single-line reply

This has been brought up a few times previously, but with the release of an [The updated prototype, it doesn't seem to be addressed yet: currently a single-line reply takes up approximately seven lines of space. --MZMcBride (talk) 01:00, 15 July 2013 (UTC)

Instructions with each reply

The reply instructions ("click here to reply to X; be nice!") in the current prototype seem to quickly become grating and I think are indicative of a design that needs improvement (i.e., it should hopefully be unnecessary to provide users with instruction about how or where to reply). Thoughts? --MZMcBride (talk) 01:01, 15 July 2013 (UTC)

Compatibility (unsupported browsers, no javascript, etc.)

Thanks to all the developers that are pouring their heart and soul in to the new applications designed to improve the WMF projects. I am sure the developers are making certain that things are compatible for everybody. But just in case anybody has forgotten... Flow and the VisualEditor are intended to work hand in hand. Both Flow and the VisualEditor support certain browsers and also require javascript. Unfortunately there will be a group of users that can't use Flow or the VisualEditor for one reason or another. It would be very helpful if that group can still have some form of limited communications within the Flow interface (i.e. basic raw text, unformatted, disorganized, etc.), so that they can still interact with others. Thanks. 64.40.54.201 (talk) 01:17, 15 July 2013 (UTC)