Wikipedia talk:Flow/Archive 1

Archive 1

Archive 2

Archive 3

→

Archive 5

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)

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

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)

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)

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 [2] [3] [4] [5] [6] [7] [8]. 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)

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)

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)

Ad

{{Flow ad|ad=1}}

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)

{{Flow ad|ad={{CURRENTDOW}}}} 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)

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)

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)