Wikipedia talk:Flow/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

How would edit conflicts be prevented?

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

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

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

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

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

Pre-impressions and questions + analysis

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

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

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

Comparison & Review

I've done some comparisons and obtained some numbers:

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

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

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

Comparison graphics for Flow prototype

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

comparison graphics

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

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

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

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

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

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

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

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

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

I see that other people have been asking similar questions, so definitely no need to answer my last question here. I don't agree with any vitriol that is or is not directed towards developers, by the way. Any questions or concerns I might have are just inquisitive and I have full faith in the processes to lead to good results, even if there are hiccoughs along the way. Thanks again. --Atethnekos (Discussion, Contributions) 07:32, 15 July 2013 (UTC)

Roadmap

Flow is coming. From wikitech-l:

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

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

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

New Version of the Flow Prototype Released

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

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

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

Prototype has a strong emphasis on when a post was made

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

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

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

Space taken up by a single-line reply

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

Instructions with each reply

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

Prototype's use of green dots and the at sign

The current prototype uses green dots and "@" symbols that are confusing and come with no hints about what they mean. --MZMcBride (talk) 01:39, 15 July 2013 (UTC)

Green = "unread". The dot means that there are unread comments in the topic. The @ symbol is to call out "mentions". You see it when a topic is collapsed, to know that there are posts within that mention you, and then next to the posts in question (where you are mentioned). I'm not currently a fan of the @ thing. I'm not sure it's needed. The green dot may not be needed, either, unless we have a "collapse topics" thing going on. Again: prototype, and we're experimenting.--Jorm (WMF) (talk) 01:42, 15 July 2013 (UTC)

The Cathedral and the Bazaar

The The Cathedral and the Bazaar is one of the the classics of the open source and the free content movement and wikipedia has inherited that tradition. It contrasts a monolithic development structure by a handful of priests with a bazaar of thousands of developers each doing a little addition. The way the wikipedias discussion system has developed can be seen as a very bazaar style of development. A community of thousands have developed a raft of policies and procedures on how we interact. These have been facilitated by the template system which is again is a true bazaar system, any user, even IP's, can make a new template or alter existing ones. These have allowed a lot of systems to organically emerge: the user warning templates, barnstars, the project banners and article rating systems, templates specific to a particular policy system like arbitration or procedure like the teahouse.

What I'm trying to get round to is the question: is flow going to a cathedral system or a bazaar? We we be able to set up a new type of workflow? Say we want to set up a User Council with some sets of responsibilities and modes of communication not yet envisaged. Maybe with a single transferable vote system. Can we do this ourselves or will be need a support ticket to some external priest? Basically how customisable will it be?--Salix (talk): 20:03, 15 July 2013 (UTC)

We will be designing all the workflows, using the features that the devs create (including features that we request). They're just making the lego-blocks, and it will be up to us to create the structures from those blocks. See mw:Flow_Portal/Architecture#Big_Ideas (old and informal, but gets to the point), and mw:Flow Portal/Workflow Description Module, and also the comment above (which I added an anchor to) Wikipedia talk:Flow/Archive 1#What Flow actually is, which gives a few more details. –Quiddity (talk) 20:13, 15 July 2013 (UTC)

I like this bit in the Workflow Description Module:

Locally Editable Local wikis must be able to design and implement their own workflows.

even I don't really have a clue to what a workflow is yet. Is there an example of how one might be implemented?--Salix (talk): 05:50, 16 July 2013 (UTC)

Code-wise, I don't believe he's started on that aspect yet. The core "discussion" module is the main focus, to start with. But they're bouncing some very interesting concepts around. The final implementation is going to make a lot of things faster/smoother/easier, for all of us. Tons of integration and automation of what are currently laborious and multistep processes.

Slow and steady wins the race (with helpful researched feedback from us, along the way ;) –Quiddity (talk) 06:24, 16 July 2013 (UTC)

There's a sort of before-and-after comparison for a hypothetical {{unblock}} workflow at mw:Flow Portal/Block Module. The English Wikipedia would not have to use this (at all), or could make it be very different, but that might give you an idea of the sort of thing that would be possible. WhatamIdoing (talk) 22:53, 16 July 2013 (UTC)

Just making sure I have this straight

1. . Flow is replacing talk pages
2. . The only editor for talk pages will be Flow
3. . Jorm (WMF) won't tell the VE guys they will need to support wiki mark up because, he's going to force VE (via Flow) on all editors, despite WMF's promise that editing in Wikitext will always be an available option.

Because, I mean, making things harder for current users simply for one's own personal preference would be considered disruptive at best.

Ian.thomson (talk) 20:21, 15 July 2013 (UTC)

Sorry that this is a dumb question, but please bear with my non-proficiency. Does "editing in Wikitext" mean the same thing as clicking on the "Edit source" link does now? --Tryptofish (talk) 20:55, 15 July 2013 (UTC)

Yep. Flow'll get rid of that option for talk pages. Ian.thomson (talk) 20:57, 15 July 2013 (UTC)

I pointed out at WP:VisualEditor that Flow will force all editors to use VE on talk pages, and I was reverted and accused of making bad-faith false edits. WMF has no idea what they're doing, and we need to make it known to them. Ian.thomson (talk) 21:24, 15 July 2013 (UTC)

@Ian.thomson:, your statement is not exactly correct:

1. VE Team: VE is/will be rolled out as an option in Article and User namespace only. There are no (stated) plans to extend it to other namespaces, and there is a plan not to remove the standard (Wikitext?) editor.
2. Flow Team and @Jorm (WMF):: Flow will be rolled out replacing User talk pages, and eventually article talk pages. There is no plan to have any editor other than VE for Flow. (Actually, the Flow team lead seems to have no idea what editor will be used on Flow, according to their statements. The Flow team lead assumes it will be VE, but the VE team doesn't seem to have specific plans to make VE available to Flow. The Flow team has specifically reported that they have no plans to work on an editor.)
3. Me (and others): For Flow to be usable for discussing article page edits (on user talk, article talk, or Wikipedia talk pages), a Flow message must be able to include the same templates, parsed the same way, as are used on article pages. @Okeyes (WMF): seems to agree, and will bring it up when he returns to the office in three weeks.

If the VE team and the Flow team continue to operate without talking to each other (at least, the Flow team spokesman isn't talking or listening to the VE team members), Ian will be correct; you will be forced to use VE-format on "talk pages", and hence, "talk pages" will be useless for some discussions of article content. — Arthur Rubin (talk) 21:59, 15 July 2013 (UTC)

This is undoubtedly something that will be discussed more in coming days and weeks. I want to reiterate that we are at a very, very early stage with Flow, mostly discussing conceptual questions right now. Things can and will shift. Okeyes (WMF) (talk) 03:13, 16 July 2013 (UTC)

I understand we're at an early stage. I just want to make sure that the Flow team and the VE team talk to each other, and that the Flow team doesn't end up committed — to a methodology which will make Flow unusable for actual article discussions. Jorm has already said he wants to get rid of Wikimarkup; he needs to be told he needs to get rid of it in Wikipedia articles before Flow can be implemented without Wikimarkup and some kind of a Wikimarkup editor (whether the editor is VE or not). — Arthur Rubin (talk) 03:44, 16 July 2013 (UTC)

• Just a note here to the FAQ question we added. There will still be a wiki source option for editing talk pages, there is still no plan to remove the ability to use it. You may not be able to use all features of the new work flows on the wikitext editor but you will still be able to do basic page editing etc with wiki text. [Yes Brandon approved the FAQ text :) ] Jalexander--WMF 04:00, 16 July 2013 (UTC)

James, I'm sorry to push this. But what is in the FAQ doesn't actually deal with the fact that the use of talk pages is intended to be deprecated by Flow, and that people who do not use VE for whatever reason are likely to be left out of the conversation. As well, you've posted that on the FAQ for VisualEditor, not for Flow. I personally am finding that I still can't really get a grasp on the "vision" behind Flow, and I've read an awful lot. I'm trying to be open-minded, but the more I read, the less sense this is making to me. I do come away with the feeling that we're all being chastised, though, for failing to see the magical future or maybe for refusing to agree that the past and the present are hopelessly awful. Risker (talk) 04:12, 16 July 2013 (UTC)

I believe this is the solid result we were hoping for - confirmation that source-edit-markup will still be copy-pastable, between article and Flow-based discussions. I've poked staff to specifically confirm this feature (before I posted the below), and they did so. The FAQ update is the first sign of that, and hopefully the details will clarify (and the Flow FAQ get updated) over the coming days/weeks/months. VE will not be required at all, to communicate. Us source/markup lovers might not be able to utilize all the powerful additional features that Flow will have (in the same edit-action), but we will be able to do what we currently do. (That's my reading of it, at least). –Quiddity (talk) 04:35, 16 July 2013 (UTC)

I want far more than that: I want WMF to commit to a version of Flow that is completely agnostic so far as the software used to edit messages. Editors that edit in wikitext and editors that use VE should be able to collaborate without worrying about who edits with what technique.—Kww(talk) 05:22, 16 July 2013 (UTC)

• @Jalexander: Huzzah! And lo, peace spread throughout the room, emanating to the far reaches of the land.
  The copying of source-edit-markup from article to talkpage, was the use-case we were most worried about. If that's going to work, everything is much much sunnier. –Quiddity (talk) 04:23, 16 July 2013 (UTC)

Actually, that's not what it says. In fact, it still doesn't say that there will be talk pages, or that wikitext will be able to be used in conjunction with Flow. It just says that wikitext will not be disabled. Risker (talk) 04:38, 16 July 2013 (UTC)

I, honestly, can't speak for the larger vision of flow though I can certainly pass your comments up the chain to Brandon etc because that's certainly not what I'd like to hear. I added the section on the VE FAQ because that's both where we are focusing at the moment (and where people seem most likely to look) and where many of the recent comments seem to be pointed. I also, honestly, don't know if we have a Flow FAQ. I know that we do not anticipate removing normal wikitext editing from talk pages (you won't gain functionality in the wiki text editor, but you won't lose it either). From what I have been told what Quiddity says is correct (you would have to be transferring from the edit source mode to edit source mode but it will certainly be possible). Jalexander--WMF 04:45, 16 July 2013 (UTC)

• I'd like to make a few rather obvious suggestions to the developers about this issue. As someone who can remember when word processing programs on personal computers changed from something like wikitext (sort of) to graphical user interfaces, I think that the long-term goal of migrating to a GUI is actually a good thing. But it's just common sense to make the transition here in ways that don't cause us to lose long-time contributors. So, first, I suggest that the implementation of Flow not take place until the many bugzillas in Visual Editor have been solved. And second, I suggest allowing for users who want to stick with wikitext to have options of being able to do so (with whatever limitations of functionality that might involve), perhaps even by allowing for the development of a gadget that could be opted-into under user preferences, that would provide the wikitext edit box. --Tryptofish (talk) 23:02, 16 July 2013 (UTC)

Prototype has a very strong emphasis on author, not on message

The current prototype has a really strong emphasis on who made a comment, putting the author in a brightly colored box, before the content of his or her message. I'm not sure this is a great idea. Should authorship be emphasized so prominently? Talk pages have traditionally de-emphasized authorship by putting a signature at the end of the message. I think there are advantages to this approach. --MZMcBride (talk) 00:57, 15 July 2013 (UTC)

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

Perhaps you are unfamiliar with letters? Not that I have an inherent problem with the name at the top, but this is the second time in 10 minutes when I've seen someone discussing this tool who has missed something incredibly obvious. Risker (talk) 05:25, 15 July 2013 (UTC)

I don't know about you, but I always know who a letter is from before I open it. It's that name in the upper left corner of the envelope.--Jorm (WMF) (talk) 05:43, 15 July 2013 (UTC)

Whereabouts I am, at least, you get the address in the top right of the letter. The content follows. Okeyes (WMF) (talk) 07:14, 15 July 2013 (UTC)

Those must be some awfully stodgy love letters you two write. ;-) --MZMcBride (talk) 19:03, 15 July 2013 (UTC)

For giggles, I made a table:

Where do you find out who is speaking?

Communication type	Where you find out who is speaking	When do you find out
In person	Facial recognition or voice recognition	Concurrent
Paper letters	Name as part of return address on envelope or in letterhead or in top right or left of page or signature line or by recognizing the handwriting	Before or after, depending on the correspondent
Telephone conversations	Caller ID or voice recognition or information provided by caller	Before or concurrent
Video conferencing	Caller ID or facial recognition or voice recognition or information provided by caller	Before or concurrent
IRC/Internet chat	Nick tag at front of line	Before
Internet forums / Comments	Posting metadata next to comment	Before
Email	In the "From" line, before email is opened [E-mails generally use e-mail signatures at the bottom, though. A from line is metadata that's not quite comparable. Presumably Flow will work with Echo notifications. The notification will tell you who made a post (similar to a from line for an incoming e-mail). With e-mail, the content itself almost always comes before any signature, except when quoting.]	Before
Wikitext talk pages	Signature	After

That exercise was actually more fun than I thought it would be.--Jorm (WMF) (talk) 01:19, 17 July 2013 (UTC)

I've added some nuance to the table. However, I think the point that MZM is trying to make is that there is so much emphasis on the author that the message is very easy to ignore. Just having the author's name at the top should be sufficient, without all the bells and whistles. The key focus is the message. It's actually a fairly important wiki principle: that too great a focus on the messenger obscures the validity and content of the message, so ignore who it is from until you understand what is being said. Risker (talk) 02:36, 17 July 2013 (UTC)

 —SMALLJIM  19:42, 19 July 2013 (UTC) says:
Perhaps we should encourage everyone to start putting their sig first in anticipation of the change ;-)

Compatibility (unsupported browsers, no javascript, etc.)

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

Hi 64.40: It's always good to hear from you. Support (albeit somewhat limited) is already planned for visually impaired users, people without Javascript, and others who cannot use VisualEditor for one reason or another, and actually has been planned for months.

Eventually, if I repeat this fact often enough, I hope that even certain registered users will stop cross-posting this false rumor to an endless number of pages. WhatamIdoing (talk) 01:26, 15 July 2013 (UTC)

Thank you. I appreciate the clarification. The community can easily be whipped up on to a frenzy, and I'm certainly not immune to that as you can tell. Perhaps we should make an FAQ page so that when people are concerned about a false issue we can point them to WP:FLOW/FAQ#10 or whatever and tell them it's a non-issue. Anything that will help keep the community calm would be helpful for all concerned I think. Best. 64.40.54.201 (talk) 05:01, 15 July 2013 (UTC)

@WhatamIdoing:Hopefully, if we repeat the questions often enough, someone from WMF will issue a clear and simple pronouncement along the lines of "WMF recognizes that it has assured the English Wikipedia community that current wikitext will be supported, and that the use of the Visual Editor will not be made mandatory. No version of Flow will ever be released for use on English Wikipedia until it has full and complete support of wikitext and does not rely on the Visual Editor for any portion of its functionality." If you can get someone to say that, then all this sturm and drang will be alleviated. The reason for the tornado of complaints is Jorm's repeated insistence that he views Visual Editor as the only supported editing platform for Flow and that he is dependent upon its feature set in relation to wikitext and templates.—Kww(talk) 19:39, 15 July 2013 (UTC)

Ditto. Once and again you've answered that there will be some form of limited experience for those that can't use the VE, but this is not what is being asked - or at least not the only question, even if the only one you're answering. The important question is whether the replacement editor will retain full (or near-full) backwards compatibility with current wikicode (i.e. is it the same wikitext editor available now, or a new development for impaired users?) This FAQ doesn't answer the question. This is NOT a non-issue, this is a major point as the difference will have a huge impact in the community. Diego (talk) 06:54, 18 July 2013 (UTC)

• Thanks I see there was a new addition at Wikipedia:VisualEditor/FAQ#VEFlow recently. Thanks for the update and clarification. 64.40.54.109 (talk) 04:14, 16 July 2013 (UTC)

Table of content? and symbols

Looking at http://unicorn.wmflabs.org/flow/ it looks like there isnt any table of content? When I read WP:Pump or come to a new talk page the first is to look at the table of content. When reading the answers from WMF (on this page) I get the impression that they do not use Wikipedia (as editor). The talk pages isnt facebook, og another chat forum WP:NOTFORUM, but a working place for the article - it needs math and chemical formulas too - otherwise its diffucult to take about technical subjects... 90.184.223.136 (talk) 18:23, 19 July 2013 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Responses, in order:

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

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

I'll jump in to give an example of templates that Flow will likely not support: {{hat}} and {{hab}}. It will have built-in functionality to do the same thing, so why should it support them? WhatamIdoing (talk) 01:28, 15 July 2013 (UTC)

Alright. So...

1. How can this be opt-in if it can't fully support Wikimarkup? How will the messages by Flow-users be communicated to non-Flow users and vice-versa?
2. You have said FA, GA, Wikiproject and many other templates will break. Are you sure you mean that? Just to give some numbers, Template:ArticleHistory has over 34,000 uses. Template:WikiProjectBannerShell - aa box to hold other WikiProject templates - has over 600,000, and Template:WikiProject Biography - just one of the many wikiProject templates - has over 1,000,000. Template:WPBannerMeta - a common component of Wikiproject templates - has over five million uses. That's not something that can be hand-fixed, but it's very important to Wikipedia functionality.
3. Bots work by editing Wikitext. how will they not break on talk pages? An important example is that fair-use images are removed from talk pages by a bot, to prevent us from copyvio. Will VisualEditor be fully compatible with bot editing?
4. You say copy-pasting will work. I just tried it. Editing in VE, I highlighted a passage in W.S. Gilbert, then switched to another window, started editing another article, and pasted in. It did not work properly. It stripped all references, Wikilinks, italics, images, paragraph breaks and such, replacing references with numbers in square brackets, and everything else with nothing e.g. "The Observer newspaper in 1870 sent him to France as a war correspondent reporting on the Franco-Prussian War.[9]" instead of, if I had copied Wikimarkup, the correct "The Observer newspaper in 1870 sent him to France as a war correspondent reporting on the Franco-Prussian War."

   So... if I can't really copy things from one VE page to another, and there's no Wikimarkup support, how on earth can I copy-paste things onto the talk page?

5. You say a collaboration tool will be available. Will this tool fully support Wikimarkup? If not, can flow be turned off for selected pages in Talk space, to make sure that collaborative pages don't break?
6. You say that communities will not be able to decide whether or not Flow is turned on. Why? What's wrong with collaborating with the users, as was done with flagged revisions? Adam Cuerden ^(talk) 02:04, 15 July 2013 (UTC)

• Where exactly did Jorm say that all the templates at the top of the page will break? Let me be more specific: Jorm says that the templates at the top of the pages will be supported right here in the official documentation, in a specially designed metadata space. (He also proposes a possible improvement on them.) So why do you still think that they are all going to break? I repeat: the only use of templates that has been definitively ruled out is in signatures (Flow is effectively displaying the line out of the history page, not a "signature").

Answer to question 7, above. Adam Cuerden ^(talk) 14:10, 15 July 2013 (UTC)

• Did your copy-paste paragraph happen to have a ref tag at the end of the passage you copied? There's an open bug for that. This is supposed to work. I'm hoping that the bug will be resolved very soon. WhatamIdoing (talk) 05:10, 15 July 2013 (UTC)

@WhatamIdoing: VE does not support copy-paste between pages, only copy-paste within a page (edit session). Between pages, it will copy only what is displayed (to the reader) - that is, text. Templates, references, wikilinks, image links - all of that is either converted to plain text (e.g., "[1]" for a footnote) or simply ignored. There are no plans to change this limitation anytime soon, if ever (admittedly, "ever" is a long time). -- John Broughton (♫♫) 17:48, 15 July 2013 (UTC)

Many of Adam's complaints seem inappropriate, or may be dealt with correctly in Flow. (I was going to say "would likely" be dealt correctly in Flow, but I'm no longer convinced that the WMF is actually interested in functionality, only in ease of use.) (I particularly note that the templates at the top of the page are specifically (planned to be) supported in the "metadata space" in Flow.) However, if any templates or Wikimarkup actually used in articles (see, I've eliminated {{hat}} and {{hab}}) are not allowed in Flow "messages" (in workflows which actually correspond to "messages"), then Flow is not at all suitable as a sole replacement for article talk pages, and probably not even for user talk pages. Furthermore, it doesn't appear that there will be a copy-paste mechanism between articles and Flow messages.

As for templates breaking, I see no specific plans either to allow or to disallow templates in Flow. The only comment I have in that regard is that if any templates (used in articles) are not working in Flow messages, then Flow is not suitable as a talk page replacement. If any templates work differently in Flow messages than in mainspace, then Flow is not suitable as a partial replacement until those templates are forced to fail. — Arthur Rubin (talk) 05:37, 15 July 2013 (UTC)

Answer to question 7 above. I asked about Wikiproject, FA, GA, and other templates. Response "Flow will not prevent those from breaking. Flow will provide different, better ways of managing these workflows. That is what this project is about entirely." Read what Jorm wrote. Adam Cuerden ^(talk) 14:10, 15 July 2013 (UTC)

So how can I help kill off Wikitext too?

Its great for Wikipedia-type collaborative efforts both for generating articles as well as facilitating talk-page discussions about them but for those of us working on Wikisource, where the overall mission is to ... faithfully reproduce source documents as close to the original published versions as possible... (e.g. where content is more static than collaborative and facilitating ease of editing is not critical to article mainspace developmen)t, I'd much rather have the wikicode-usurped HTML tags for headings, lists, tables and similar on back under our control, And with their overall expected behavior restored without infringement by the "wikicode". -- George Orwell III (talk) 15:28, 15 July 2013 (UTC)

Why do I get this creepy feeling when someone called George Orwell talks about "faithfully reproducing source documents as close to the original published versions as possible..."? :-P Diego (talk) 12:10, 22 July 2013 (UTC)

Collaborative pages

Collaborative pages - which usually are in the Talk: or User_talk: namespace, as Wikipedia has strict rules against using the main namespace for non-article content, including drafts - will be dealt with "in some way". Frankly, this seems like the sort of thing that gets promised (such as an easy way to turn off VisualEditor) but which may disappear in the final project.

It is not good enough that Flow has a half-functional collaborative page. These have to be able to be imported directly into mainspace and work, so cannot be done through any sort of partially-functional wikimarkup simulator. This means either that Flow needs a way to be turned off completely on a specific page easily, without too many restrictions, or that it allows a fully-functional - templates, references, everything - Wikimarkup system.

Will the WMF assure us - with an unbreakable promise that Flow will be immediately shut off should it be launched without - that this will be a feature of Flow?

Second, and just as important - how will collaborative editing work on talk pages themselves? Same issues as before, but it basically needs Flow turned off for one section. If this is broken, then Flow is not suitable for Wikipedia, so it's important.

Thirdly, how can polls be held with Flow? With talk pages it's a simple matter of, say:

Support

1. User1's signature
2. User2's signature

Oppose=

1. User3's signature
2. User4's signature

Or, alternatively:

• Support User1's signature
• Oppose User2's signature.

That rapidly becomes unreadable if each comment is a giant box. How will this be handled? Note that comments next to supports and opposes are often key to their interpretation, so a mere polling gadget won't work. Again, this is a basic necessity of collaborating on Wikipedia, and if it's broken by Flow, Flow cannot be launched. What are the WMF's plans to handle this?

In all honesty, I suspect the WMF have not considered just how flexible Wikipedia's talk pages need to be to fulfil all the functions they've gained from being such open environments for the entire time wikis have existed, and how easily this could be broken with a restrictive system.

So... what can you say to reassure me? The thing is, VisualEditor is obviously a good idea in theory, it's just not ready yet. But changing Wikipedia's talk pages into a clone of forums or email breaks functionalities necessary to support Wikipedia, and so is dead in the water, and, if that's the full extent of the plan, development may as well end now. Adam Cuerden ^(talk) 05:23, 16 July 2013 (UTC)

If you would read the documentation rather than posting unresearched demagoguery, you would have the answer to that. For the last time, please read at the very least WP:Flow and mw:Flow Portal/Use cases. The word "voting" is on that first page. It HAS been included in the list of things that Flow will need to support, and intends to support. Your large posts full of hyperbole and hypothesis, are lacking in accuracy, and are spreading misinformation. Read more, rant less. –Quiddity (talk) 05:54, 16 July 2013 (UTC)

You seem of the opinion these texts are clear.

Alright, let me ask this: Is having a dozen different workflow modules - and having to select the right one for each discussion or part of the discussion - really going to be simpler to use than just signing your talk page posts and using indents? Particularly when we already have a bot that signs unsigned posts? Adam Cuerden ^(talk) 06:18, 16 July 2013 (UTC)

Note that the bot only runs on English Wikipedia but not on many other projects such as Commons. There was a request on Commons to get a signing bot, but ultimately nothing could be done as User:SineBot is closed source and the bot operator didn't respond when Commons users contacted him. There was also an attempt to contact the operator of de:Benutzer:CopperBot, but this seems to have failed too. At least there is still no bot on Commons which is signing posts. See Commons:Commons:Village pump/Archive/2013/04#Signature bot on Commons. --Stefan2 (talk) 11:37, 16 July 2013 (UTC)

Why not just add a request to WP:BOTREQ to see if someone is willing to develop a signing bot for Commons? -- 76.65.128.222 (talk) 08:15, 17 July 2013 (UTC)

You already have to choose between formats in RFCs, so why would this be any different? There are two boilerplate formats for RFC/U pages; RFA and RFB have their own; User:Beeblebrox/The perfect policy proposal lists four different styles for policy-oriented RFCs. Why is it easy to make it all up from scratch right now, but hard to look at a couple of pre-formatted options and click the button for the one you want? WhatamIdoing (talk) 22:57, 16 July 2013 (UTC)

Ok, I have read WP:Flow and mw:Flow Portal/Use cases (in fact I've added an important use case that wasn't there, wasn't I supposed to do that)? So let's me rephrase Adam's question, since you have only answered the least important part of it (in a very rude manner, btw). How are you going to support all the use cases that are supported by current talk pages but are not in the Use cases document, and those that aren't there because they haven't been invented yet? -but that would be possible with a wiki platform. (Note that the mw:Flow Portal/Workflow Description Module doesn't cut it, not by a long shot). Diego (talk) 14:04, 17 July 2013 (UTC)

I've primarily answered this, in your thread at mw:Talk:Flow Portal/User Stories#Drafting and collaboration. Addendum: Any features that are needed but aren't available (once Flow is actually in a beta-stage, months from now), will presumably be requestable, just as it is with any mediawiki code.

(Unrelatedly, the curtness of my initial reply here, is due to Adam's posting numerous copies of threads that (1) contained serious misinformation and (2) were inflammatory. Eg. [2], [3], [4], [5], [6], [7], etc. He has been asked to research a little more before posting long new threads, and to not mass-post new threads, and to word his postings in a less rabble-rousing/tabloid headline manner (e.g.). All of which, has the effect of fragmenting discussion - which creates more work for the editors correcting his misinformation, and makes it harder for the editors reading the threads to get an accurate or complete answer - and it makes the discussion hostile from the very start.) –Quiddity (talk) 18:41, 17 July 2013 (UTC)

Thank you for taking your time to answer. I appreciate the effort you're spending trying to clear things up. But I'm afraid something has gone quite wrong in the communication process, and probably in the initial analysis too.

You really need a community ambassador, someone with time to answer, that who doesn't get tired of answering and offering the same clarifications as many times as required, with direct line to the development team and who is in a position to answer the community questions with authority. So far, you're providing us with a stream of links to outdated an unauthoritative specifications, short answers to fragmented questions with severe misunderstandings on both sides of the fence. And you wonder why the editors most interested in the tool like Adam are getting all defensive when "reading between the lines" to try to infer how the new development is supposed to work? You're not providing a vision to which we can agree.

The impression we get is that every feature that is already working, right now, in the current platform will need to be reimplemented from scratch, after long and painful begging for it to be remade, with no guarantee of when or if it will be made nor how it will work; and that the already functional platform will be pulled from under our feet when the new tool is feed-forced unto the community that creates content with it. That you are not even talking of backwards compatibility is severely disturbing. You're simply not providing any assurance that the new tool will be apt to be used by the community to continue our current practices in building content; you're presenting it as a solution to improve new users workflow at the cost of crippling existing users' tools.

Now I don't think that this impression needs to be how things develop in the end, mind you. For a start, all this opposition would be moot if you guaranteed that, no matter what, the old tool would be always available on the side for the users that want to use it for their specific use cases, maybe at a separate namespace. Second, reading about Parsoid and the possibilies it offers to convert between wikiformat and the new internal representation, it's clear that at least someone in the WMF gets what it really takes to support an open knownledge framework on a wiki.

But it's not at all clear that the tools built on top of it will be capable of harnessing that power; all signs point that the proposed design will only support the rather limited set of use cases anticipated by the small development team, without the flexibility that we have learned to love from MediaWiki. Even if the design documents like this explicitly mention full support for complex wikitext (which in theory it's all that is required for backwards compatibility), you're providing contradictory messages here at the talk when saying that VE will be the only supported editor, and that you're not integrating with the old wikitext; and it certainly doesn't seem like testing that backward functions don't break is high in the development team priorities. Can you clear this up one way or the other, so that we know what to expect? Will all existing workflows need to be reimplemented in the new system before they are available again, or will there be some native support to keep the old platform working at those points where there is no replacement in the new tool? And finally, do you understand why having to ask for everything already working to be re-made again is a problem? Diego (talk) 22:30, 17 July 2013 (UTC)

• alternative there's a suggestion at the WMF Flow page about rolling out a "scratch" namespace that will have a page attached to every subjectspace/talkspace page pair, so it becomes a triplet. The collaboration workpage/sandbox version can then be on the scratchspace page. -- 76.65.128.222 (talk) 05:50, 21 July 2013 (UTC)

Wikipedia:Flow#Planned_features - VisualEditor

I was going to add:

Comparison of old and planned user-talk discussion systems

What you do now	What you will do then
Write or edit a message using wikitext markup	Write a message using the VisualEditor (wikitext functionality may be available, but is not in the Flow plan)

but I'm not completely sure of the details. Also, the "dubious" in the first sentence is unneeded IMO. πr² (t • c) 23:02, 16 July 2013 (UTC)

It is at least unclear, if not dubious. An editor affiliated with the Foundation has made a contrary statement. — Arthur Rubin (talk) 23:40, 16 July 2013 (UTC)

Okay. Here we go. Maybe this time the statement will stick and be clear:

• The primary editor for use in Flow will be the VisualEditor. This is the editor that the product is being primarily designed around and will be the one with "full features".
  • There are many assumptions as to the state of completeness that the VE will have achieved by the time Flow is rolled out. I cannot speak for the VisualEditor's product roadmap, however, so please do not ask me what the VE will support at that time. I do not know. I have some inklings, but I am loathe to speak them because so much is being mis-interpreted or ignored. If I said, "we expect Maths support" that will be interpreted as a promise and I'm not in the position to do that.
• A "fallback", lightweight wikitext editor is in the Flow plan. It is not advertised as the primary editor because it will not be as fully functional.
  • This editor will support text-to-speech and other functions used by screen readers and the like for accessibility.
  • This editor will possibly be limited to accepting a subset of the wikitext language (e.g., it will likely balk at complicated templates or things like parserfunctions). I am not sure about tables.
• Bots will continue to use the API, as will gadgets that make use of Flow functionality.
  • Some of the content injected through the API may need massaging at the source to produce "VE Friendly" content. There will be plenty of testing time for us to identify the most common issues and work to fix them.

Does this answer your question?--Jorm (WMF) (talk) 00:12, 17 July 2013 (UTC)

There's no room for a custom, "lightweight" Wikitext editor. There can be no features of Flow that are dependent on Visual Editor. You need to rework your plan while keeping in mind that Visual Editor is an optional feature that is disabled by many members of the community. Your product must have full functionality when used with standard wikitext. Not "lightweight" functionality. Not "limited" functionality. Not "fallback" functionality. No "balk[ing] at complicated templates". No "subset of the Wikitext language". Full functionality.—Kww(talk) 00:43, 17 July 2013 (UTC)

I think that if I went to the higher ups and asked for the resources required to make the standard wiki editor "fully functional" with Flow, I would be met with grave stares. There are plenty of features that Flow will support through the VisualEditor that it cannot with the standard editor. Autocompletion of usernames (for mentioning) or article names is but one. --Jorm (WMF) (talk) 00:54, 17 July 2013 (UTC)

(ec / to Kww)I wasn't going to say that, exactly. However, I was going to say that unless we can copy/paste between article sections, and Flow messages, and have them rendered identically (outside VE), with possibly some rare exceptions which are noted in the view (again, outside VE), then Flow is not an acceptable substitute for article talk pages. Period.

Autocompletion is an editor feature, not an editing (the way I see it) or rendering feature. I can see difference between VE and "standard" Wikimarkup editing should carry over to editing Flow messages; however, Wikimarkup editing of articles and of Flow messages should be the same, and rendering must be the same. — Arthur Rubin (talk) 01:01, 17 July 2013 (UTC)

I think you need to reconsider what you consider to be a "feature" of Flow as opposed to a feature of the editor if that's an example of what you are talking about. When I'm typing a message, I fully expect that the two different editors will be different editors: the series of keystrokes I have to enter to create an article link or reference an individual user may be wildly different. Once I create that message, however, Flow's behaviour in response to it should be identical, and there shouldn't be any capability that is denied to an editor because he creates his message by hand. Conversely, if VE's ability to create tables and templates is still crippled, that shouldn't mean that Flow can't represent those tables if an editor creates them manually by wikitext.—Kww(talk) 01:03, 17 July 2013 (UTC)

• It doesn't seem that your development team understand what is being asked, Jorm, or at least why it's being asked. We all acknowledge it's impossible to create from scratch a new tool that will support all the cases existing in the current software from day one. But precisely for that reason, it's imperative that the new tool is backwards compatible with the current platform and existing processes in a way that, when the tool doesn't support an existing use case or flow, the old system can still be accessed to complete the flow.

Now if that can't be done by integrating FLOW with the old editor, at least there should be a way to keep the old-style pages - be it by or retaining the possibility to create old-style pages and new-style pages in parallel, or allowing talk pages to be seen through both the new and the old interfaces (with the new view degrading gracefully on content that it doesn't understand - this is the approach taken by VisualEditor, who finally seem to get it).

Anything that doesn't limit the platform's functionality to the small subset of use cases that the small development teams can support, throwing away all the possibilities of the Mediawiki code developed in the last twelve years or so. When you say that the new threads won't even be stored as wikitext, it's clear that you don't understand this number one essential requirement. Diego (talk) 13:22, 17 July 2013 (UTC)

@Diego Moya: Jorm did answer my question fine, and understood what was being asked. Maybe he doesn't understand your questions. Anyway, I've added this to the FAQ and Planned features sections on enwiki, but not on other wikis. πr² (t • c) 17:11, 17 July 2013 (UTC)

I have a question about the word "lightweight" as it applies to the "lightweight wikitext editor". I understand that it won't have all of the new features of Flow, and that makes sense to me. What is unclear to me is whether or not it will have all of the present-day features of editing in wikitext. Will it be "lightweight" in that way as well? --Tryptofish (talk) 01:03, 18 July 2013 (UTC)

The Flow page's "Planned features" section appears quite explicit in stating it will not have all wikitext features: No "complete" wikitext editor, but a lightweight "fallback" editor supporting some wiki syntax will be available for users who cannot or do not wish to use the VisualEditor (old browser, no Javascript, speech-to-text, etc.). After reading various pages I am convinced there will not be compatibility between wikitext and Flow/Visual Editor (I strongly suspect it's impossible rather than just hard). Either have two interaction pages (maybe talk for old-school wikitext, and collaborate for Flow), or some way to exclude fragments of wikitext from Flow processing (kind of a two-way <nowiki> wrapper)? -84user (talk) 22:41, 18 July 2013 (UTC)

I'm pretty sure that the language you quoted was just added today, perhaps based upon a reading of this discussion. Therefore, I'm not sure whether that's true or not (a potentially amusing variant of WP:CIRCULAR!). But, if there will be present-day capabilities left out, I'd like to find out what those are, specifically. Presumably, the developers know what they are thinking about the wikitext editor, so I'd really like to see them clarify these issues. I fear that there is a danger that established editors will be left in a difficult situation. --Tryptofish (talk) 22:50, 18 July 2013 (UTC)

I added that based on Jorm's above reply to my question. πr² (t • c) 22:55, 18 July 2013 (UTC)

OK, I went back and re-read it. A lot of the answer seems to me to be saying that it won't be fully functional in terms of doing everything that Flow does. I do see where it also won't support some complex things like complicated templates. That doesn't necessarily present a problem when participating in discussions. Thinking about the way one writes text in a discussion (what you and I are doing right here), I'm trying to pin down whether or not the wikitext editor will be able to do what we do now. --Tryptofish (talk) 23:02, 18 July 2013 (UTC)

This discussion system (colons for indents, etc.) I have no idea. It will def. handle the Flow and the future. Basically the fallback wikitext editor will have to go through Parsoid (for many reasons, not the least of which is "if it can pass through Parsoid, it will be VisualEditor compatible" but also "this is the way of the future"). If it fails Parsoid (can't be parsed, the wikitext is malformed, etc), it's getting sent back with errors. This is why we say we'll be supporting a "subset" of the current wikitext lexicon. That has been taken to mean "only a small percentage - like 10%" but it will (hopefully) be closer to 95% in the future. And that missing 5% is stuff you really shouldn't be doing anyway.

There's a lot wrapped up in that, by the way, mostly about performance. See, we won't be storing comments as Wikitext. We'll be storing them as parsed and rendered HTML. That means that they will be crazy fast to load and display (unlike in LQT where things have to get parsed out of wikitext and into html and then assembled every time). --Jorm (WMF) (talk) 00:05, 19 July 2013 (UTC)

OK, thanks. I take it then that editors using the wikitext editor won't be left at too much of a disadvantage in taking part in discussions, except to the extent that they won't be able to take advantage of many of the desirable new features in Flow. --Tryptofish (talk) 00:42, 20 July 2013 (UTC)

Actually, if I've understood this correctly, most of the new Flow features will be available to people who don't choose to use VisualEditor. It's the people who can't use VisualEditor for some technical reason (e.g., no Javascript or an elderly browser) who will miss out on most of the new features, and they'll miss out because of the technical reason, not really because of VisualEditor. Choice of editor ought to affect only your experience in the editor (or "almost only"), not your experience with other aspects.

As an example of something you won't be allowed to do with the wikitext editor in Flow that you are allowed to do now, you will not be allowed to produce "illegal" HTML, e.g., the opening half of an HTML tag pair without the closing half. This is a Good Thing. WhatamIdoing (talk) 15:05, 23 July 2013 (UTC)

So, you are saying the wikitext editor in Flow will not allow templates. — Arthur Rubin (talk) 17:37, 23 July 2013 (UTC)

Unless 100% of templates involve unclosed HTML tags, then, no, that's not what I said. WhatamIdoing (talk) 18:46, 23 July 2013 (UTC)

No, you're right, it was Jorm who said that the wikitext renderer in Flow wouldn't accept templates, even if the editor would. However, there are a number of commonly used navigation templates which use (balanced) templates with unclosed HTML, although, when fully expanded, the HTML closes properly (at least usually). I have no objection to requiring Flow messages to have properly closed HTML, provided that (1) No wikitext renders differently under Flow and in articles, and (2) It is clearly marked exactly what HTML errors are preventing proper rendering when a message is rejected or fails to render correctly. — Arthur Rubin (talk) 21:14, 23 July 2013 (UTC)

Brandon, it occurs to me that Flow and VisualEditor are taking widely different angles on the way they plan to use Parsoid. The VE guys by necessity are taking a very careful approach to support full backwards compatibility with the existing corpus of articles, while your project is more a "start from scratch" attempt. This is not to blame on the base technology, which is the same in both cases, but a conscious decision on how to use it.

Now while the Flow design is a reasonable solution to the communication problem defined by its current use cases (as I understand it, it's intended to be used only at User talk first), it's not at all clear that it will be valid for the harder problem of generic article and project pages. Here the community is using the full power of a wiki platform to define new workflows and information repositories, both free-form and at several semi-structured levels. Things like User:Snotbot/AfD's requiring attention, User:Wcquidditch/wikideletiontoday, the Wikipedia:Article Rescue Squadron/Rescue list and many other review backlogs don't seem to have a place in a talk page following the structure of Flow prototype; or at least I can't see how. The proposed configurable Workflow module is centered around communication workflows, not collaborative editing. If you're planning to support this capability of the community to build their own tools on top of the communication platform, please explain your vision because it's not clear at all.

For the community to create these new designs, that spring up of necessity of their dynamics and goals, at least both features are required: a structure of the page that is stable in time, and advanced transclusion support so that any content fragment from other pages and articles can be shown. Storage of wikitext would be welcome too; the VE editor will be doing it, and if both are stored in parallel it doesn't impact performance; so dropping its not really a requirement (although, to be fair, having it is also not a necessity for the community worflows I'm talking about, provided the full semantic HTML5 + RDFa specification is supported by Flow).

None of these are guaranteed in Flow, and therefore making it the default communication tool will limit the capabilities of the most experienced editors, those participating in this tool-building. The risk you're facing is a huge backlash from this community and a complete rejection of Flow, which has potential to be more severe than that from the VE - the editor guys are taking the extra step and going through hoops to make sure it doesn't break any existing workflow and both old and new styles can coexist, while Flow is not doing that. Diego (talk) 06:20, 19 July 2013 (UTC)

Big deal. It there's no functionality one may use twitter for chatting and subpages for discussions. --93.75.134.116 (talk) 06:57, 19 July 2013 (UTC)

Wouldn't that defeat the purpose of having a unified conversation system built up from scratch to support our communication needs? Diego (talk) 10:51, 19 July 2013 (UTC)

This all seems very, very peculiar to me. Wikipedia ran OK in 2007 with regular Wikitext talk pages, with more editors. (True, I'm not sure if they talked as much; they were more busy writing articles than playing Survivor: ArbCom in those days) Still, computers have gotten a little better since then, haven't they, so why look for cut-rate solutions?

If Flow can't handle the full range of Wikitext, and you want to use it, the solution seems obvious: imbed it in regular Wikitext pages, just like you would a template or a Lua script. A talk page like this could have a line:

<flow id="2346898712" />

and in place of that tag you'd get your leaned-down conversational talk threads, and then someone could start a new subsection with a new flow, old fashioned Wikitext conversation about a template, etc. The headings and style inside and outside Flow might even look pretty similar (though you wouldn't want them to be indistinguishable). When starting a new thread you might enter the element <flow> and have a bot fill in the number; the WYSIWYG editor might have extra features to fill in that content right as you add the tag. Is that so hard?

To give you a free tip, ontogeny recapitulates phylogeny. It's nominally bad biology but it's a damn handy rule of thumb. It's like how a baby still learns on a "potty", a century after chamber pots went out of style. As people navigate deeper and deeper into a Wikipedia page, they should encounter newer and newer features; conversely, the root options, the places where everything starts, should be the oldest features and should change very little. Wnt (talk) 22:34, 19 July 2013 (UTC)

Actually, all of the stuff Diego's talking about is supposed to get easier under Flow. Instead of having "a page" that "transcludes" or "links" the AFDs onto it, you'll just add a tag. Anyone who wants to know what's on the ARS Rescue list will go look at the tag. Even simpler, if you want, you can "subscribe" to the tag and have the information automatically delivered to your feed. This is another case of Flow not needing the old methods to achieve the desired result. You need a way to get this list; you don't need "a page" or "transclusion" to do so. WhatamIdoing (talk) 15:18, 23 July 2013 (UTC)

Splitting threads

It does not sound easier to enter 'split mode', whatever that is, rather than just putting in a new heading. How is this an improvement? It does not sound like one. Adding a new heading is very simple as it is now. All you have to do is edit the section or the page and add the heading. But how would this work in Flow? It sounds as if one would have to jump through more hoops and do something considerably more complicated in order to split threads. I do not think this is better.

Also, please make this clear - is Flow a certainty or a proposal? I would like to know because I have decided that I will never use it on my talk page and I will use a user subpage for my talk if/when this is rolled out. Cathfolant (talk) 03:53, 20 July 2013 (UTC)

First, the topic split system has not been prototyped, so there's nothing for you to form an opinion about it being more or less difficult than the current system. I'd urge you to wait until there is something to talk about before making comments about what is and what is not better, since there is no objective position to make such claims from.

Second, Flow is a certainty.

Third, I'm sorry that you feel compelled to make drastic decisions before the software has even been written.--Jorm (WMF) (talk) 07:05, 20 July 2013 (UTC)

A lot of drastic design decisions seem to have been made already, though. Diego (talk) 08:56, 20 July 2013 (UTC)

I have made a drastic decision to avoid a drastic change. I disagree with most of the consequences of the change, but it's possible I will change my mind about some of them once I see what it's actually like, or if it is made sufficiently clear. Flow, like VisualEditor, is intended to make Wikipedia easier to use for new users. That is fine, but for (most?) established editors like me it will actually be harder to use. I think it is within my rights not to use a feature that is intended for the convenience of others but does not further my own. This is what I have already done with VisualEditor. Also, 'drastic' would seem to be a value judgement. How drastic is drastic?

I totally understand if you don't have the answers yet due to the software not having been written, but you have not told me how it will work. I have formed an opinion based on what I have read and asked for more details. Apparently those details do not exist yet beyond what has been said on the page already. It's fine if I'm not allowed to form an opinion about something that doesn't exist yet, but I think I am allowed to ask questions and raise concerns, which was what I did. Do you think my questions and concerns are legitimate? It seems that you do not, simply because the software does not exist. Is it wrong to suggest how it might or might not work once it does exist? Should I not comment on what has been put forth on the page? Cathfolant (talk) 23:55, 23 July 2013 (UTC)

Grave stares

Re: "I think that if I went to the higher ups and asked for the resources required to make the standard wiki editor "fully functional" with Flow, I would be met with grave stares." -- I give WMF grave stares for dumping $10M a year on local user-clubs and not having the bix to fund basic user software development. VE is a not-ready-for-primetime piece of crap and this is an even bigger catastrophe moving down the pike... Carrite (talk) 03:34, 22 July 2013 (UTC)

You would think that releasing a Visual Editor that had been shown to reduce the likelihood of a newbie making his first edit by 43% or a notification system that resulted in a 20% increase in the likelihood of a new editor being blocked would meet with grave stares. Apparently our expectations are unrealistic.—Kww(talk) 03:49, 22 July 2013 (UTC)

Wow! That link to the draft research page is absolutely jaw-dropping! Comparing new editors who used wikitext with new editors who had the option of using VE, the actual data displayed there is breathtaking. Really, it's worth looking at! Not even close, but overwhelming. --Tryptofish (talk) 20:41, 22 July 2013 (UTC)

I don't know about that. VE editors had every single edit reviewed by at least one person; non-VE users did not. Furthermore, VE editors were less likely to even attempt an edit, which naturally makes you wonder whether something odd was going on with the randomization. If the two groups were truly randomly assigned, then we ought to have seen the same willingness to click the 'edit' button in the first place. WhatamIdoing (talk) 16:22, 23 July 2013 (UTC)

Did the editors in the A/B test have the section links active? The appearing and disappearing "[Edit] [Edit source]" animation is a clear difference in the interface that launches the editor, which could explain that reluctance to press the link. Diego (talk) 17:15, 23 July 2013 (UTC)

I don't know. They were definitely present for part of the test, but I'm not sure if they were present for all of it. WhatamIdoing (talk) 19:00, 23 July 2013 (UTC)

No, WhatamIdoing, it still is jaw-dropping. Everyone was subject to the new edit patrollers. The very fact that the "test" population was less likely to even attempt an edit is extraordinary in and of itself. And the differences between the control and test population results were statistically huge. Maybe it was what Diego said, or maybe it was something else. But in any case, it sure runs up against the stated goal of reversing the editor decline trend! --Tryptofish (talk) 17:25, 23 July 2013 (UTC)

No, everyone was not subject to the VE-specific recent change patrolling. Only people who actually completed edits in VE were subject to that. Both paid staff and volunteers were specifically looking at all edits that had the VisualEditor tag. I personally looked at hundreds of VisualEditor edits, and zero non-VE edits. Nobody was specifically looking at the changes that used the old editor. Therefore the VE users received scrutiny from the normal RC process plus the special RC process for VE edits only, whereas the non-VE users received only the usual level of scrutiny from the normal RC process. WhatamIdoing (talk) 19:00, 23 July 2013 (UTC)

Then it depends upon whether or not those factors could, quantitatively, be able to account for all of the differences that were shown. At least some of the measurements were of things that were not dependent upon subsequent actions by other editors, and yet there were similarly large differences between control and test whether or not that was the case. After all, we are discussing this in the context of developers saying that they want whatever happens to be data-driven. Any good scientist knows that, when you have data, you evaluate it critically, considering all possible sources of error, but you never wish the results away simply because they don't conform to what you had wanted to see. --Tryptofish (talk) 19:07, 23 July 2013 (UTC)

Until they figure out whether the tracking system was working (a matter that apparently is in doubt, in case you haven't been following the Meta pages), then we don't know whether we can trust any of this. I think we're going to have to wait until they actually finish analyzing the data and writing the report. WhatamIdoing (talk) 22:54, 23 July 2013 (UTC)

That's really all anybody asks, WhatamIdoing: that they wait. Why does WMF insist on proceeding instead of waiting until it has evidence that anything it is doing is actually beneficial? Why did they proceed to deploy it to anonymous editors and new editors, and then to more and more language versions, when all the evidence they did have suggested that it was a harmful change? Why not pull this thing back, fix the hundreds of things they know are wrong, get support for fundamental elements of articles like tables included, and proceed when they have evidence that they have done something beneficial?—Kww(talk) 23:32, 23 July 2013 (UTC)

The main point, WhatamIdoing, is that it demonstrates that WMF proceeded without evidence to support them. When WMF didn't immediately pull VE in spite of readily apparent major bugs and widespread rejection, I had to assume that the results of the A/B test were so dramatic that it was driving WMF to keep the software enabled because of benefits that I couldn't perceive. Now, we find that the results of the A/B test were that VE had a negative impact, not a positive one. It's extremely hard to justify WMF's persistence in deploying the software with those test results.—Kww(talk) 17:37, 23 July 2013 (UTC)

I'm especially struck by how often I've been told right here on this talk page how much the WMF wants to be data-driven. --Tryptofish (talk) 17:41, 23 July 2013 (UTC)

What's going to happen to old talk pages?

What will happen to everything in the User talk: namespace, and the namespace itself, when Flow takes over? If there is no definitive answer, what ideas have been proposed so far? — Scott • talk 18:23, 23 July 2013 (UTC)

Please see #Conversion of old discussions, above. They apparently will just stay as they are, eventually to be archived. --Tryptofish (talk) 18:26, 23 July 2013 (UTC)

I saw that. This: Existing wikitext pages will not be transferred to Flow. They will be moved into an archive. doesn't explain anything. — Scott • talk 18:41, 23 July 2013 (UTC)

Sorry. I guess that I don't understand what you are asking. --Tryptofish (talk) 18:47, 23 July 2013 (UTC)

Where will the archives be, what format will they take, will they be editable, how will the archiving process handle the many, many existing and incompatible hand-maintained talk page archive formats, will the User talk: namespace still exist? None of these details have yet been explained, so far as I can see. — Scott • talk 19:01, 23 July 2013 (UTC)

You've asked five questions here, and so far as I can tell, the answer to all five is, "Why would it be any different from the way it is now?" I have never heard anyone say, for example, that Flow is going to touch the existing talk-page archives. It appears that it's going to simply ignore them. They'll presumably be just what they are right now: pages with stuff on them. WhatamIdoing (talk) 22:50, 23 July 2013 (UTC)

Jorm wrote the text that I quoted above. I'm just asking for a clarification of that exact statement. Thanks. — Scott • talk 22:55, 23 July 2013 (UTC)

Flow-enabled pages will "subsume" the User_talk space for areas they are enabled. The older talk page (or talk pages) will be moved to a different url (probably User_talk:Foo/Archived_Talk, but that's probably going to be a localized location). They will remain wikitext pages. Flow will then ignore them forever.--Jorm (WMF) (talk) 23:02, 23 July 2013 (UTC)

• Thank you. — Scott • talk 17:31, 24 July 2013 (UTC)

If that's the plan, it's a bad one. It would make more sense to have separate User_Flow and User_talk workflows. — Arthur Rubin (talk) 23:22, 23 July 2013 (UTC)

I'm curious as to why you think having two, conflicting workflows for discussion is an improvement.--Jorm (WMF) (talk) 23:25, 23 July 2013 (UTC)

1. A fallback until the bots are written to place announcements / warnings / ... in Flow, rather than on user talk pages.
2. A fallback if Flow cannot be made to work at all. We do not have a guarantee that installation of Flow will be delayed until the major bugs are fixed, and I, for one, would like to be able to continue leaving messages for editors.

If Flow works, and all the bugs which prevent constructive work are fixed, then user talk pages can be phased out. (This would probably be between "major" and "minor" bugs, except that some declared "enhancements" to include functionality in Flow which already exists in talk pages, and is required for the talk pages to be useful. I've already mentioned one such essential functionality which you didn't intend to include, at last report.) — Arthur Rubin (talk) 00:39, 24 July 2013 (UTC)

Well, first, as said multiple times, bots will continue to work as normal because they edit using the API rather than screen-scraping. That's a non-issue.
Second, I'm wondering if you're confused as to the roll-out plan. Flow will be opt-in during its initial roll-outs for testing purposes and there is talk of a plan to allow people to "roll back" that decision at any time. Transmuting a Flow board into a Talk page is actually fairly trivial; it's the other way around that's hard. Are you assuming that we'll be going full-bore, 100%, every talk page, every namespace at once? That's insanity, and if that's been your perception I apologize for not having made it clear earlier.--Jorm (WMF) (talk) 01:51, 24 July 2013 (UTC)

It's what happened with VE, so I think everyone's been assuming that Flow would be the same. Adam Cuerden ^(talk) 02:10, 24 July 2013 (UTC)

This is not true. VisualEditor is only enabled in two namespaces at the moment. Its introduction was also preceded by seven months of opt-in testing. "Full-bore, 100%, every talk page, every namespace at once" is exactly what didn't happen with VE. WhatamIdoing (talk) 15:18, 24 July 2013 (UTC)

The problem is that WMF continued to release it even after it failed testing. There's no point in doing testing if you ignore the results. The A/B testing indicated that it damaged the experience for new users instead of improving it, yet deployment continued. Experienced editors on English Wikipedia found it lacking to the point that they use the older editor by a 9:1 margin, and newer editors prefer wikitext by a 2:1 margin, yet it was rolled out to IP editors. IP editors also rejected it by a 9:1 margin, yet it was deployed to multiple language versions. A key part of testing is to review the results to determine what to do next, and there's no sign that WMF is doing that.—Kww(talk) 15:55, 24 July 2013 (UTC)

Well, no. The roll-out plan is (and has always been), thus (outdenting because colon-indentation sucks):

1. Limited, opt-in, minimal release for user_talk only
2. Expanded release to user_talk only (read: more aggressive marketing for people to upgrade/test, plus auto-enroll new user accounts)
3. Test deployments for other discussion pages and systems that opt-in (think Teahouse and Village pumps and the like)
4. Test deployments for article space talk pages (opt-in, per page)

And let's also be clear that it is hoped that, during this time, several extant workflow systems (like blocking/unblock request, etc.) will be ported over, and that (hopefully) other workflows (AFD, MFD, etc.) may be ported as well. Some of the above bits may happen in tandem, if the software is ready (e.g., test deployment to Teahouse and IP editors), and we'll know when we get there if it's ready or not. This is slow and steady. We cannot possibly push out a product that solves all problems on Day 0. We knew that going into it, which is why we've been so focused on "user talk" - it is the "simplest" set of use cases (which is why you don't see a lot of discussion about "how do I do collaborative editing on articles" in the design documentation: we know that's at least a year out). It is true that eventually we will turn it on for everyone and everything. But that's a long, long way off. --Jorm (WMF) (talk) 02:23, 24 July 2013 (UTC)

Knowing that, I'm actually far, far more optimistic about Flow. VE rather soured me on any new software launches, as, well, beyond the bugginess at launch, VE seemed to have some fundamentally misguided ideas that are very hard to fix after launch, notably, not being able to just accept Wikicode and make it into graphics in any way. It seemed like the sort of thing you'd get from asking people what they wanted in the first five minutes, and ignoring what they'd need later. Adam Cuerden ^(talk) 02:37, 24 July 2013 (UTC)

As long as you have essential features like complete wikitext support and supporting the ability to completely disable VE in the first release, that plan seems reasonable.—Kww(talk) 02:49, 24 July 2013 (UTC)

I hate to have to say this again, because I don't want to start things up all over, but "complete wikitext support" is not on the table. It simply isn't because the back end systems won't allow for it. We'll have a wikitext editor, and you'll be able to use it to do close to 95% of what you can do today. But that wikitext must pass through Parsoid, and if Parsoid rejects it, it will reject it. The concept of "complete wikitext support" includes support for several "broken" forms of wikitext that we cannot and will not support going forward (think "table_start" and "table_finish" templates). That's significantly unlikely to happen because the development effort required to support it would be astronomical and frankly not worth it.
We had a long discussion today about this, by the way, and came to the conclusion that the bulk of "bad" wikitext usage comes from us not providing alternatives to crazy template structures.
I'm not saying this to continue a fight or be hardline; I'm saying it because I don't want there to be any misconception or miscommunication. I frankly think you'll get exactly what you want but as I've said many times: I cannot promise 100% coverage of wikitext support.--Jorm (WMF) (talk) 02:56, 24 July 2013 (UTC)

And I hate to have to say this again as well: complete wikitext is mandatory. If you want to insist that the wikitext for an individual message is balanced, in the sense that it leaves no tags unclosed, I wouldn't even consider that a restriction on the wikitext you support, it's a restriction on the form of a message. However, if one message contains a matched "table_start" and "table_end", there's no justification for not supporting it.—Kww(talk) 03:13, 24 July 2013 (UTC)

Is there a statement of how a user talk page would handle complex stuff that does not work in the standard Flow? I saw some mention of a "free wikitext" section on a user talk page, or would a user have to use a subpage to hold tricky stuff? As an example, I was asked to analyze some external link dumps and I put the results on my talk (see here with a table and an image). Also see this section where the following wikitext is used:

*<code><nowiki>{{convert/sandboxlua|70|mi|km}}</nowiki></code> → {{convert/sandboxlua|70|mi|km}}

How would that work in Flow? Johnuniq (talk) 04:07, 24 July 2013 (UTC)

(ec)

Exactly, Kww. There is no justification for rejecting a message if parts of it (templates) are unbalanced, if the entire message is balanced.

(OK, here is something Flow, or even LiquidThreads, would be good at; I'm replying to a message from Jorm above). We need the system in parallel because certain bots, (disambiguation notice, bracketbot, etc.) try to place a message on Talk:Username. Until the bots are rewritten to try Flow first, or the API call to append a message to the talk page is converted (by MediaWiki, or Flow) to create a Flow message, we lose the use of those bots until they are rewritten. I see no reason to lose those bots, even at the user's option. — Arthur Rubin (talk) 04:15, 24 July 2013 (UTC)

Of course there's a good justification for rejecting messages if they don't parse, and that justification is "this message doesn't parse." We're extremely unlikely to be support broken Wikitext in the future. This is akin to suggesting that a computer with a 64bit processor continue to execute code compiled for a 16 bit processor in perpetuity. That's an incoherent request. We'll try our best but there is a bright line of demarcation where "effort to obtain" outweighs "value of" and it's pretty clear we're at that line.

And once again, I guess I need to re-iterate: this will be transparent to bots, unless they're a bot that doesn't use the API, which has been deprecated for ages. Bots that require the "edit comment" permission will have to be granted that by the local wiki, otherwise its business as usual.--Jorm (WMF) (talk) 04:34, 24 July 2013 (UTC)

No, Jorm, it's not equivalent to that at all. There's nothing wrong or obsolete about wikitext, and you need to treat its support as mandatory, not optional. If Parsoid can't parse valid Wikitext, that's a critical bug in Parsoid that needs to be repaired and a sufficient reason to delay the introduction of any other feature that depends on Parsoid. It's not a justification for delaying the feature. If the wikitext is actually flawed, and you rejected it because it is flawed, that's a completely different thing. The reason why so many people view your statements so skeptically and suspiciously is because you keep throwing up things that feel like red herrings. Why can't you commit to supporting all syntactically valid wikitext that doesn't introduce unbalanced tags? If you would commit to that, you wouldn't be getting into these constant arguments.—Kww(talk) 04:53, 24 July 2013 (UTC)

The reason why I cannot commit to supporting all "syntactically valid wikitext" is because, simply, I cannot.--Jorm (WMF) (talk) 04:56, 24 July 2013 (UTC)

You've provided no examples of syntactically valid wikitext that did not introduce imbalanced tags that you couldn't support. If you are certain that you cannot do it, then please provide an example of syntactically valid wikitext that does not cause unbalanced tags that you still feel you would be unable to support.—Kww(talk) 05:16, 24 July 2013 (UTC)

That's another good reason why Flow should be deployed in a parallel space, instead of replacing the current one. Editors in the fairly common situation of needing the extra un-syntactic wikitext will still be able to use it on their talk pages, which can be though of as a sort of whiteboard where article content can be dropped for review, and which should be active until (and if) all the old wikicode is truly deprecated.

Surely the default conversation interface should be the Flow Board so that newcomers find it easily, but experienced editors will know how to access talk pages to access this current functionality, the only one which is backwards-compatible with the whole existing core of Wikipedia content. Diego (talk) 06:04, 24 July 2013 (UTC)

Dual interfaces would take an already complex, impenetrable system and make it even more complex and impenetrable. There would be a subset of experienced users who would refuse to utilize the new interfaces "just because" and then only post warnings or whatever to "user_talk", which will be utterly confusing to new users (who may or may not already be used to flow boards). I'm sorry, but this is just not a viable solution.--Jorm (WMF) (talk) 17:13, 24 July 2013 (UTC)

Then include a "sandbox" section either at the top or bottom of Flow pages where content is rendered by the mediawiki engine instead of Flow (the same one that allows articles to be handled by both the VisualEditor and the source editor); it wouldn't make sense to use that section for conversation when Flow is besides it, but it would allow us to include content from all the existing corpus of knowledge. Losing support for all wikitext so that old articles can not be discussed is not a viable solution either. Your current plan would discard about 13 years of work in creating content. Diego (talk) 17:43, 24 July 2013 (UTC)

The current design thinking includes a "raw wikitext" header section but I don't think that's what you want. What I think you really want (and I think this is a good idea) is to be able to attach scratchpads to topics. I'm not sure that it would work with individual posts/comments - having scratchpads connected to them - but it might be worth investigating.

That feature - scratchpads in the topic - was written up a while ago, but only cursory. It may have gotten lost or buried in one of the design document refactors, and likely during one when I refocused on user_talk. I'm gonna have something to say about that - the focus on user talk - but I'll do that in a new section.--Jorm (WMF) (talk) 18:54, 24 July 2013 (UTC)

Yes, that feature - scratchpads that support all current content, i.e. all "raw wikitext" - would be a solution for the problem of constructive discussion of Wikipedia content. If the scratchpad wikitext is not forced through Parsoid, it would also be a solution to the problem of community-build backlog reviews of which I've talked elsewhere, and for which the Workflow creation module is an uncertain solution. It should be possible to display pages that are half built from the current rendering engine and half parsed by Flow, and it would support all required cases.

When editors require Flow to provide full wikitext support, I don't believe they're thinking of having them available at every comment - that's not how they're currently used at talk pages, and it should be easy to adapt around a page structure where only some sections display it. But the parts that can parse wikitext, those should be able to display everything that the article space can display; and I don't think the article space will be rendered through Parsoid for a long time, not until the content of 4,289,073 articles is updated to be Parsoid-compatible. The two use cases above comprise a lot of the coordination work that wikiprojects build for themselves, and not supporting them would disrupt the dynamics of many existing established work forces. Diego (talk) 21:05, 24 July 2013 (UTC)

Dear Jorm, let's get this absolutely straight. Unless Flow will be able to render every single aspect identically to every valid editor of the article name space, it must not and will not be rolled out! Talk pages are not independent social websites, but they have only one purpose: to discuss articles. For this we need to be able to copy every kind of content, format and structure between the article name space and the talk pages. Your job is to support us in writing Wikipedia, your job is not to build a flashy social website. The identical rendering of every possible content must be your paramount design goal. Everything else takes second place. rgds --h-stt !? 09:25, 24 July 2013 (UTC)

I don't think you understand what my job is at all. --Jorm (WMF) (talk) 17:13, 24 July 2013 (UTC)

Actually, I don't understand what your job is. <redacting comment which should be in another thread, along with most of h-stt's previous comment> What do you see as the purpose of Flow, and your job as it relates to Flow. (For that matter, what do you see as the purpose of user talk or user Flow pages?) — Arthur Rubin (talk) 18:16, 24 July 2013 (UTC)

My job is that of Senior Designer. It is my job to understand problems, determining whether or not they actually are problems, and then design solutions for those that are. That means, practically, that I do a lot of product design and it's my job to understand at a deep level the use cases we need to account for. It is also my job to understand the realities of the situation - the constraints - and make unfortunate and sometimes difficult decisions about the product based on those realities as well as prioritization of features and problems. It is further my job to (try) to balance communicating that to our various communities and actually do the work of building the design (which sucks, because sometimes I have to take from Peter to pay Paul but that's how it goes). There are other sundry things about my job that aren't relevant to this discussion (like my work in fundraising, or public speaking engagements, etc.). It is decidedly not my job to perform as a robot and to jump when the editor community says to jump. It is my job to listen to concerns, and to understand them as best as can be, but part of my gig is weighing those concerns against constraints and practicalities. --Jorm (WMF) (talk) 18:47, 24 July 2013 (UTC)

No one is asking you to perform as a robot. We are are trying to get you to understand that full support of wikitext is not optional, and you don't ever seem to acknowledge that. We are trying to ensure that after problems like Echo and Visual Editor that you actually succeed at building a useful tool. I'm still waiting for an example of syntactically valid wikitext that does not cause unbalanced tags that you still feel you would be unable to support, by the way.—Kww(talk) 20:11, 24 July 2013 (UTC)

I suggest you read the section below, entitled "Supported Wikitext". --Jorm (WMF) (talk) 20:19, 24 July 2013 (UTC)

What I would like to see

I've stated this elsewhere, but I would like to see a "user-wiki" (whatever name we want to name it), which takes full advantage of SUL implementation. Either one for each language (which would be preferable for various reasons) or just one overall for all mediawiki sites.

This segmentation of discussion between wikimedia sites is one thing which is holding wikimedia back from being "one community". And instead creates a perception that each "site" is a separate community/entity. In some ways they are, but in a lot of ways they are very much the same.

This would be rather easy to implement I would presume (the largest difficulty likely being naming conflicts, which is one of the reasons why I think a separate one for each language is probably a good idea). Just merely change how user: and user talk: are interpreted by the wiki. The new wiki would merely have user as it's Interwiki link.

Why do I note this here? because this change from "page" to "board" would seem the nexus point for making such a change.

The other benefits of this would be that all the user-related templates, categories, sub-pages, and user-related fun pages could all be interwiki'ed to the new wiki, which of course would have its own project and category and template namespaces. And afaict, it's a simple thing in the software to disable access to a particular namespace, so it should be simple enough to disable access (intially write access then after the interwiki-ing is done, read access) to the user and user-talk namespaces of each individual wiki.

Of course, there are other benefits, such as helping improve communication (and thus, collaboration) between contributors of the same language, in particular on the smaller wikis.

So back to Flow. I think that "if" this interface manages to do all the things we hope it can, while still allowing for direct editing of the wikitext if wanted, then starting "fresh" as if on a new wiki, would be a great thing all around. Annnd, this would serve as a great testing ground before implementing it to all the article/category/template/etc talkages in the wikis themselves. It would minimise disruption of the projects in its implementation, and you would have everyone of all wikis testing it before going fully "live".

What do I expect as opposed to it? "Different wikis have their own sub-cultures, and their own set of guidelines for certain things." The simple answer to that is simply to have consensual discussions concerning them in the projectspace of the new wiki. And better, easier project collaboration (especially amongst several wikimedia projects) should presumably be the foremost concern, as we are here to build reference projects (such as an encyclopedia). And I believe a strong healthy interacting community is necessary for that.

I of course welcome everyone's thoughts on this. - jc37 18:37, 29 July 2013 (UTC)

Jc37, I'm pretty sure you're going to get your wish.--Jorm (WMF) (talk) 19:12, 29 July 2013 (UTC)

A lot of the "user-wiki" stuff you propose is already on the Wikimedia Meta-Wiki. I, for one, would not like to see a separate "user-wiki" unless there is a good reason for not just using Meta for those proposed features. And we already have categories linked in Wikidata, if that's what you mean. πr² (t • c) 22:28, 29 July 2013 (UTC)

There are very good reasons, all technical. --Jorm (WMF) (talk) 22:48, 29 July 2013 (UTC)

Could you please you elaborate or link me to a page on MW.org ? πr² (t • c) 23:13, 29 July 2013 (UTC)

jc37's mention of the "change from 'page' to 'board'" made me think of something, having to do with that earlier discussion about "talk" and "board". The kinds of concerns that I and others raised there would probably not be an issue at all if we were to end up calling talk pages "talk boards" (or "discussion boards", etc.). --Tryptofish (talk) 23:18, 29 July 2013 (UTC)

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

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

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

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

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

What is the mess of math project people? Please feel free to comment at Wikipedia talk:WikiProject Mathematics. Spectral sequence (talk) 20:38, 9 August 2013 (UTC)

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

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

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

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

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

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

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

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

Handling complex stuff

Flow would be helpful for most people in most cases, but is there a statement of how a user talk page would handle complex stuff that (I assume) will not work in Flow? I saw some mention of a "free wikitext" section on a user talk page. Would a user have to link to that or to a subpage to refer to tricky stuff? As an example, I was asked to analyze some external link dumps and I put the results on my talk (with a table and an image, see here). Also see this section where the following wikitext is used:

*<code><nowiki>{{convert/sandboxlua|70|mi|km}}</nowiki></code> → {{convert/sandboxlua|70|mi|km}}

How would that work in Flow?

When preparing complex examples, I use a programmer's text editor, and paste the results into the edit window. Presumably that will work in Flow, if the same text would be ok if typed manually? I copied my comments to here from the above section (where they were lost) by editing the section, then copying the wikitext. Will that work in Flow, or would the copy just give the rendered text? Johnuniq (talk) 06:12, 24 July 2013 (UTC)

Your cut and paste thing should work just fine. Whether or not the convert template works is up to Parsoid; I think it probably will, but it will likely be subst'd to HTML in the saved version. That's an argument for keeping a wikitext version on the backend, mind you, and a good one.--Jorm (WMF) (talk) 17:16, 24 July 2013 (UTC)

Templates on user talk pages, and most non-metadata templates on all other talk pages, are supposed to be subst'd anyway. We don't bother for a handful of simple ones like {{thank you}} or {{tick}}, but all the welcome templates, Twinkle-delivered notices, etc. are subst'd so that the message actually delivered will be the one that remains on the page, even if the template is modified in the future. WhatamIdoing (talk) 19:43, 24 July 2013 (UTC)

I just noticed that. It is not the case that all templates on user talk pages should be subst'd, now, or in any new system. (Whether the wikitext and the HTML are stored separately is an implementation issue, which shouldn't affect users, and the HTML should obviously be subst'd.) Some templates are supposed to be "live" (subject to change when the template changes.) — Arthur Rubin (talk) 18:07, 15 August 2013 (UTC)

Right: there are a few that are supposed to be "live". But can you think of any that are supposed to be "live" and appear in a discussion? (So not userboxen or other things that people put at the top of the user talk page, but things that are actually normal, legitimate parts of a discussion/notification/comment [even if there is only one comment in the 'discussion'].) Whatamidoing (WMF) (talk) 21:48, 15 August 2013 (UTC)

Template test cases? Discussing how to use complex templates properly, even while the template may be being modified. Discussion of upgrades of the {{convert}} template is often done on the article talk page where the template isn't working in the desired manner. In some cases, it's not important that it be "live", but it's important that WYSI is what you would type; in other words the Wikitext has to include the template, but it's not important that the HTML represent the current use of the template. Most of the examples I have in mind would likely be in the Template talk namespace, but Flow is supposed to be eventually rolled out to that space. — Arthur Rubin (talk) 22:29, 15 August 2013 (UTC)

This sounds exactly like a use case for a scratchpad/collaborative authoring area. These will not be handled by Parsoid; they will use the php parser (and thus be stored as wikitext and not html 5).--Jorm (WMF) (talk) 22:37, 15 August 2013 (UTC)

A scratchpad would solve the problem, provided that a scratchpad can be embedded in any Flow post, not just a single collaborative area. I'm not saying a scratchpad would need to be embedded in many posts, but the option needs to be there. the use of examples in the Template talk page, as opposed the "documentation page" at Template:templatename/doc, could be met by a scratchpad/collaborative authoring area attached to the "board". Discussion of changes, even changes involving templates, should be subject to the usual thread ordering rules. Alternatively, the scratchpad might have (as an option) the same sort of archiving currently done on talk pages. — Arthur Rubin (talk) 01:55, 16 August 2013 (UTC)

Implementing the results of the RfC

Now that we have a clear consensus, does anyone object to changing...

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

...to...

Anyone will be able to edit other people's comments; a configuration option will allow this to be restricted to autoconfirmed users or administrators should the Wikipedia community decide to do so in the future.

...? If so, please suggest an alternative wording. Thanks! --Guy Macon (talk) 19:09, 10 August 2013 (UTC)

It would be far more accurate to say, "Flow will have a userright that determines who is able to edit other people's comments." The consensus at that RFC may well change over time. WhatamIdoing (talk) 20:56, 10 August 2013 (UTC)

At which point we would update the docs. Your version fails to answer the basic "What you do now/What you will do then" question in the table. --Guy Macon (talk) 21:23, 10 August 2013 (UTC)

Flow is not about English Wikipedia only. The design documentation works for all wikis, not just one wiki's consensus.--Jorm (WMF) (talk) 22:33, 15 August 2013 (UTC)

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

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

Don't notifications from Echo resolve the need for Talkback templates? Ocaasi ^{t | c} 02:16, 27 July 2013 (UTC)

No, because half the point of a talkback template is to let 3rd parties know that a conversation is happening and where it's happening. Why would we care or want to let a third party be able to notice that a conversation is occurring? Well, I gave one hypothetical example, but basically it's because it's an incredibly lengthy and complex process to do a review of a person or a topic and those sorts of templates make it a heck of a lot easier. Banaticus (talk) 07:06, 16 August 2013 (UTC)

Ah, third parties :-). I had not considered those! Ocaasi ^{t | c} 07:21, 16 August 2013 (UTC)

Wikitext solution

So right now I can copy any (I do mean any) wikitext from the article source and paste it into the discussion page and it will display as it would in the article. The current plan is that this will not be the case for according to Wikipedia:Flow/FAQ#Will_Flow_support_wikitext_or_use_the_VisualEditor.3F because the wikitext editor for flow will not be "fully functional" so not just any wikitext from the article can be copied, pasted and displayed as such.

Since this is such an important part of collaborative editing, why not just employ the following solution: Instead of replacing article discussion pages with Flow discussions, keep the current discussion pages and add Flow discussion in addition. That way the people who want to collaboratively edit as has been done can still do so, and people who want to have non-fully-functional Flow discussions can have those as well. --Atethnekos (Discussion, Contributions) 19:46, 10 August 2013 (UTC)

Fragmenting the discussion space is undesirable. Any changes made in flow or with a wikieditor should change the same talk page. Furthermore, dual talk pages are a major change, and would require an encyclopedia-wide discussion first.

When I look at, say, Unix time, I see two tabs at the top. One says "Edit Source" and the other says "Edit ^Beta" At Wikipedia:Flow/FAQ#Will Flow support wikitext or use the VisualEditor? it clearly says "A 'fallback', lightweight wikitext editor is in the Flow plan. It is not advertised as the primary editor because it will not be as fully functional." This tells me that, if the plans go through, I will still have an "Edit Source" tab (or possibly some other way of invoking the wikieditor.)

By "not fully functional", I think that the meaning is that the software that renders the edits into HTML will not be the same as the current software that renders all Wikipedia pages into HTML. This is clearly needed: the current software is old, creaky, and has had a bunch of features tacked on to it over time. Clearly Flow will not be able to do everything the same as the old software right out of the gate, especially when you consider the fact that what the current software does is often stupid. And just as clearly, the developers will concentrate on essential functionality first, and things like equations will no doubt be a high priority.

I think that this is a clear case of the basic truth that any complete software rewrite from scratch will result in you being able to do some things that you could not do before, and not being able to do some things that you could do before. If it were the other way around -- if we already had flow/VE and someone proposed our current system -- you would have a long list of essential capabilities that you would be losing. Right now you don't even know you need those capabilities.

I am not shy about criticizing the Wikimedia software developers when I think they are on the wrong path, but in this case I firmly believe that they are doing everything right. We may experience some inconvenience, but it will be clearly worth it in the end. --Guy Macon (talk) 20:37, 10 August 2013 (UTC)

I don't see why it would require a encyclopedia-wide discussion. I can make a second discussion page for Plato at Talk:Plato/Metaphysics right now without any encyclopedia-wide discussion first. No major change required. There, I and fellow editors can discuss rewriting the metaphysics section for the article while pasting parts of the article into it. All we have to do is keep that functionality, and then no features will have to be given up. Rather than a major change being required to keep fully-functional collaborative editing, rather all we have to do is sit back, relax, and not remove this capability.

I thought Jorm was being clear as to what he meant by fully-functional. To wit, he continues and says: "This editor will possibly be limited to accepting a subset of the wikitext language." What that clearly communicates to me is that there is no plan to allow copying and pasting all (I do mean all) wikitext from an article and have it display as it would in the article. Maybe Jorm will have to be even clearer! (Poor guy answers so much as it is, but confusion still seems to remain). --Atethnekos (Discussion, Contributions) 21:17, 10 August 2013 (UTC)

Atethnekos, the assumption that you begin with actually isn't true. If the wikitext includes a namespace switch, then it will not display the same on talk pages as it does in articlespace. WhatamIdoing (talk) 21:00, 10 August 2013 (UTC)

Could you give me an example? I'll have to admit exceptions to page title and protection settings/pending changes. --Atethnekos (Discussion, Contributions) 21:17, 10 August 2013 (UTC)

Sure: paste {{talkheader}} into an article talk page, and compare it to the same template pasted into template talk: (the place you'd most likely be trying to talk about how to change that template). You get different results in the main talk than you do in template talk. WhatamIdoing (talk) 23:55, 10 August 2013 (UTC)

Sorry, what I was talking about was any source from an article being used on a discussion page as such. As far as I know that and other such templates are not used in articles (e.g., [8]) --Atethnekos (Discussion, Contributions) 06:35, 11 August 2013 (UTC)

You will still be able to make a talk sub page (not the same thing as a "second discussion page for Plato", which you cannot do now). I see no reason why the subpage can't use the present system instead of Flow. If, however, if you want to add one to every page (which is how I interpreted your comments above), that would certainly require a encyclopedia-wide discussion. You would also be able to request that Flow not be implemented on a specific article talk page that needs equation support. --Guy Macon (talk) 21:34, 10 August 2013 (UTC)

"Equation support" means mathematics, I presume? But if we request it, will it happen? Can we request this in advance for all pages under Category:Mathematics? Spectral sequence (talk) 21:40, 10 August 2013 (UTC)

As far as I know, there is only one discussion page for Plato and that is Talk:Plato. If I then made Talk:Plato/Metaphysics to discuss Plato, it would be a discussion page, it would be for Plato, and it would be the second one. That's what I meant by "second discussion page for Plato". I would only imagine such discussion pages existing where people create them. --Atethnekos (Discussion, Contributions) 21:45, 10 August 2013 (UTC)

What you seem to be describing is exactly what I thought I was being novel in suggesting: Even when Flow is implemented, one can still have discussion in the current way. I think what you're saying is good for a lot of the people with worries to know. I think they are under the impression that once Flow is implemented they won't be able to have current-style discussion pages. --Atethnekos (Discussion, Contributions) 06:35, 11 August 2013 (UTC)

Ummm, let's think about that: an article with two places for discussion would end up with simultaneous debates in two places, with people running around adding "please see the other page". It's hard to see that as anything but a nightmare. Johnuniq (talk) 09:08, 11 August 2013 (UTC)

Lots of articles have two places or more for discussion, and it is not a nightmare (e.g., we have Talk:Christ_myth_theory, Talk:Christ_myth_theory/pseudohistory, Talk:Christ_myth_theory/definition, and Talk:Christ_myth_theory/POV_tag all for discussing Christ myth theory). --Atethnekos (Discussion, Contributions) 15:57, 11 August 2013 (UTC)

I tried to summarize this issue, at the end of the #Supported Wikitext thread above. Hopefully one of the developers (from either VE or Flow) will respond to that, once they've returned from Wikimania (which could be a few days after the official end, as many are staying for additional meetings). –Quiddity (talk) 21:09, 10 August 2013 (UTC)

Another aspect of wikitext is that some editors prepare comments in a text editor, then paste the wikitext into a talk page—like almost all of my messages, that's how I prepared this message. I think it is not possible to paste anything with markup into VE—would Flow allow pasting of a comment with wiki markup? Johnuniq (talk) 09:03, 11 August 2013 (UTC)

What we need from the Foundation is a commitment that, if any of a list of required features are still missing, Flow will not be rolled out to (a) general talk pages (other than opt-in), or (with a different list) to any article talk page without specific agreement. Copy-paste from an article section into a Flow message (or scratch pad embedded in a Flow message, and displayed as if it were that message), for any wikitext that will generate valid HTML (that is, not restricted to Parsoid), and support for math formulas should be among those requirements. But any list of requirements would be helpful. The Flow team apparently is not allowed to make those commitments, but somebody should. — Arthur Rubin (talk) 15:09, 11 August 2013 (UTC)

In every software project, from the teenage hacker pounding out spaghetti code on his kitchen table to the developers who write programs for aircraft flight controls, someone decides when it is ready to release. Often it is the developer. Sometimes it is a political decision by an idiot CEO. And often it is when the customer has tested it and accepted it -- but customers are notorious for not knowing what they need and not being able to define what they want. So one of the following is true:

[1]: The Wikimedia Foundation has published software requirements and a test/acceptance plan and we at Wikipedia have not discovered them.

[2]: The Wikimedia Foundation has created software requirements and a test/acceptance plan but chooses not to reveal them to Wikipedia.

[3]: The Wikimedia Foundation is creating software with no real software requirements and no test/acceptance plan.

If [1] is true, I expect that we will hear about it and be pointed at the documents we missed. Or we may be sent to something else and be told it is a proper set of requirements, repeat until someone blows their stack, which means that [2] or [3] is the real answer.

If [3] is true, I will be absolutely shocked. Nothing anyone from WMF has posted in any way indicates that they are the kind of developers who violate one of the most basic rules of software development. Of course working without requirements may be forced upon the developers from above; I don't know enough about Wikimedia management to even guess at how likely this is to be true.

That leaves [2], which I suspect is what is happening here. And I can't really say that it is a bad decision. It may be in the best interests of the project to not let us pull the carrots out of the ground to see how well they are growing. Having a stakeholder who is essentially a mob may require a rethinking off how requirements are handled. And they certainly do not want the English Wikipedia dictating changes that effect the other Wikipedias and the the many non-Wikimedia users.

The downside to all of this is that it often leads to 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. They don't much like it when I say that, but it keeps happening.

So what is the solution? I have some ideas, but I would first like to hear from others here, especially other Wikipedia editors who have real-world experience managing software projects. --Guy Macon (talk) 18:59, 11 August 2013 (UTC)

There is an interesting statement by User:Whatamidoing (WMF) at Wikipedia talk:WikiProject Mathematics#Mathematics in VE which may help to answer your question:

The exact details are unknown at this time.

Flow is expected to fully support VisualEditor's capabilities. Therefore, whatever you are (eventually) able to do in VisualEditor, you will (eventually) be able to do in Flow. Flow is not expected to support a small subset of broken wikitext configurations (most importantly, templates that produce half of an HTML tag pair). I don't have any reason to believe that math editing will be affected by this, because math doesn't seem like the kind of wikitext that produces unstable or illegal HTML.

But at this point in time, Flow is still in the vaporware stage. Between now and December, you should not completely believe any promises given to you about its features, unless those promises are about a deliberate refusal to write code for some feature. (To date, I am aware of exactly one such refusal having been made, and it has nothing to do with math.) Creating new software at this scale is inherently an uncertain process. What will be supported in the early days, the exact methods that will be supported, and what it will look like are all things that will not be known with any certainty until late in the game. Whatamidoing (WMF) (talk) 16:12, 11 August 2013 (UTC)

Since she is Community Liaison (Product Development), Wikimedia Foundation, I'm taking this as an authoritative statement informed opinion about the planning process. Spectral sequence (talk) 19:40, 11 August 2013 (UTC) Corrected, see below. Spectral sequence (talk) 21:04, 12 August 2013 (UTC)

Since I've also directly told you that Flow isn't my assignment and that nobody, not even the designer, knows exactly how all these details are going to work out in the end, you should not accept my statements as being authoritative. Flow will at some point have a community liaison (or several), but even their statements won't be "authoritative" in the sense that you seem to be hoping for.

Arthur, the requirements are laid out at Mediawiki, especially in the MVP (minimum viable product) statements in the mw:Flow Portal/Use cases. I don't know what the test/acceptance plans look like. In general, they subscribe to agile programming, so you should expect to see the initial deployment at the early, incomplete stage of development and testing that is typical for that philosophy. Whatamidoing (WMF) (talk) 20:52, 12 August 2013 (UTC)

I withdraw "authoritative statement". I assume that "informed opinion" is valid. Spectral sequence (talk) 21:04, 12 August 2013 (UTC)

I hope so, but at the moment, my opinions feel more informed by my lack of lunch than by anything else. Ask me again after I've had an emergency infusion of chocolate. Whatamidoing (WMF) (talk) 21:14, 12 August 2013 (UTC)

• Comment: erm, hi. If you're wondering why no feature requirements have been shared with the community yet, it's because this project hasn't officially gone beyond the early planning/ideation stages, so there simply aren't any yet. Relatedly, there hasn't been a product manager assigned to Flow until, well, just now. So, that's me, in case you're wondering (hi!). What does a product manager do? Among other things, she writes features requirements :)

There are countless schools and methodologies for creating software; every organization and team has a slightly different approach, so it's not very productive to talk about the Canonical Software Way^(tm) as if there were one. At the Wikimedia Foundation, we tend toward Agile, Scrum in particular, because it helps us release, learn from, and improve things quickly, with feedback from real users. This is why you will never see a seven-thousand-page manual of all the things Flow does and does not do, which would presumably be the one true gospel on all things Flow from now until the end of time – that's referred to as the Waterfall model and is pretty universally recognized as slow, inefficient, and guaranteed to balloon in scope, resources, and bureaucracy. What you will see instead (often and soon, I promise!) are bite-sized release plans for handling very specific kinds of onwiki discussions, along with the requirements for those particular kinds of discussions. For example, a user talk page has very different requirements from an article talk page; each of these needs to be approached with an eye toward how specific processes in those specific spaces work (e.g., template warnings and notices; speedy deletion discussions) and ways software can make them easier for the end-user. The idea is that we would choose one of those discussion spaces to focus on for a first release, try to make something that satisfies as many requirements/processes as possible, deploy a beta feature to a limited set of pages/users, then gather feedback/learn from our users and grow our feature set from there, before moving on to more pages/users or the next discussion type. It's not a one-size-fits-all, one-day-all-talk-pages-are-Flow-boards kind of scenario.

I hope all of that makes sense as an "authoritative statement" of sorts. If you're still confused/frustrated, let me know – and please don't stand between Whatamidoing and her lunch; that's just cruel! Maryana (WMF) (talk) 02:05, 15 August 2013 (UTC)

Please have all the WP:FLOW pages deleted until such time as there is something to say. The present mumbo jumbo is wasting a lot of time. Johnuniq (talk) 02:29, 15 August 2013 (UTC)

This comment strikes me as particularly unhelpful.--Jorm (WMF) (talk) 03:26, 15 August 2013 (UTC)

How would you evaluate my question at "09:03, 11 August 2013" above? Johnuniq (talk) 03:50, 15 August 2013 (UTC)

I would say "paste your comment into Flow using the non-VE editor," I suppose. People seem to think that VE is the Only Way, and that's completely untrue.--Jorm (WMF) (talk) 03:58, 15 August 2013 (UTC)

You mean the non-VE editor which will support only a limited subset of wikitext? If you're not providing a fully functional non-visual replacement, you can't offer it as the solution for common use cases. Diego Moya (talk) 10:42, 15 August 2013 (UTC)

I suspect this is a (widespread!) mis-interpretation of what Jorm originally meant by "limited subset", which he's tried to clarify in the top of the #Supported Wikitext thread above (by pointing out that most of what will not be supported, is stuff we don't and shouldn't be doing anyway - broken code) - I've tried to further clarify that, by making the brief list of examples at the bottom of that same thread, and I've asked the VE devs and Flow devs to look at it, and give it a brief response, once they're all back from Wikimania and/or holiday. Hopefully, that will solve this particular issue completely. –Quiddity (talk) 17:34, 15 August 2013 (UTC)

Nothing about Scrum says that you don't have a specification before you code, Maryana. Bear in mind that the Visual Editor release was a disaster because James and Erik failed to define a Minimum Viable Product for the first release that was actually useful. Please don't make the same mistake with Flow.—Kww(talk) 04:49, 15 August 2013 (UTC)

• Hi, Maryana. I'm glad to hear that Flow has a new product manager. I see a potential problem in the strategy that you've described for Flow. If you create Flow based on the requirements of only user talk pages, as you're planning, its software architecture will be tailored to just those use cases. If later it's found that other types of talk pages have largely different requirements (which is likely, given the ongoing discussion so far at MW:Talk:Flow) there's a high risk that the initial architecture will not be adequate to support those new scenarios, and that major re-structuring will be needed.

Changing the architecture of a working software product is hard; the best approach then would be to start a different project for the newly found requirements. Are you willing to do just that if the need appears? If not, if all kinds of talk pages are to be supported by a common infrastructure, then you really need to take into account major requirements for all situations from the beginning. Not by creating a big design up front, mind you, but by performing the complete field research that user centered design requires for successful user-facing applications. (UCD is not much different from SCRUM; the former focuses on what the user will need, and the later in how developers will build it, but they share largely common approaches). Diego Moya (talk) 10:17, 15 August 2013 (UTC)

This is unlikely to be a problem, since the design is based on research of all discussion pages, not just user-talk pages, and it's modular to boot, so expansion to support additional features is easy. Whatamidoing (WMF) (talk) 17:04, 15 August 2013 (UTC)

Thanks, Diego, these are excellent questions.

RE: If you create Flow based on the requirements of only user talk pages, as you're planning, its software architecture will be tailored to just those use cases. My point above is that we're not making product decisions based on one namespace or one kind of discussion. You're absolutely right that the backend architecture also can't be tied to one set of requirements if the product is later expected to meet a much wider set; I'm pretty confident that the backend approach we're taking is maximally generalizable. You should talk to Erik or Andrew about it if you're interested, or just spy on their onwiki activity on mediawiki.org.

RE:... by performing the complete field research that user centered design requires for successful user-facing applications – I'm curious to know what you think that means in the context of Wikipedia discussion. To clarify, I think you're absolutely right that research is required, but I'm wondering what kind of artifact you'd hope to see come out of it, since, obviously, it would have to be shared with the community (and perhaps not so obviously, it would have to strike the balance of simplicity and sophistication required to quell Wikipedians' fears that the staffers running the show are complete n00bs ;) ) Maryana (WMF) (talk) 17:30, 15 August 2013 (UTC)

Maryana, all that is exactly what we fear.

First of all, the question is simple: what conditions must be satisfied in order for "Flow" to be deployed? Elsewhere the answer is also simple: when the customer decides. In such case having no specification is a problem but not a completely disastrous one. In your case we are your customers, but it looks like WMF wants to make the decision without even caring what we think. Now, if you do not want to be treated as an enemy of all Wikipedians (I hope you do not), you must demonstrate that this impression is wrong. Telling us those conditions is one way to go in this direction. And yet, in effect, you are saying that you haven't really thought about that.

Second, "it helps us release, learn from, and improve things quickly, with feedback from real users" is useless unless you are actually willing to listen and learn. Look at this page. You have been given lots of feedback. What have you learned? You still say "For example, a user talk page has very different requirements from an article talk page" when that has been shown to be wrong. And what have you learned from "VisualEditor" disaster?

Third, releasing the worthless version of "VisualEditor" was bad enough. If you will release the worthless version of "Flow", it will be worse, as then you will inevitably break something. And it might get broken in the way that will be very hard - perhaps impossible - to undo. For someone will try to use your product. Things they are going to write will have to be saved and not discarded - whatever the cost.

Thus the first released version must be "almost perfect" already. Yes, there can still be some minor bugs, but the design must be "bugless". For you will only get one try.

So, anything reassuring for a change..? --Martynas Patasius (talk) 12:00, 15 August 2013 (UTC)

Martynas, I know you very strongly dislike this style of software development, but the WMF does not release "almost perfect" software for the first version of basically anything. They deliberately release half-finished work so that the real users can tell them very early in the game where they're screwing up, which may be in big ways ("This whole reference dialog is a disaster, and I don't care that it exactly followed the specification or what the original users said") or may be in subtle or detailed ways that the specification didn't mention, like the exact order of icons in some sub-sub-dialog screen or the best name for a button. The purpose is short-term pain for long-term gain. The major alternative produces a very well-known result: "just what I asked for, but not what I want". Wikipedia needs to achieve what users actually want, even if it's not what the originally surveyed users thought to ask for. The most reassurance you are likely to get on this point is that Flow's early stages will definitely be opt-in-only. Since you particularly dislike dealing with half-finished software, then I recommend that you personally choose not to opt-in, and leave the early days to people who suffer from "early adopter syndrome".

As for your particular points: Maryana is learning that some editors expect her to have magically read about a half million bytes of comments here, not counting all the comments at Mediawiki, within seconds of getting the assignment; she is learning that some users expect her to tell them the release conditions before the specification has been written; she is learning that some users expect her to have written the specification within minutes of getting the assignment to write the specification. She is also learning small things, like the apparent fact that several people here have not read the formal research that the WMF did months ago about the actual contents of a random sample of the discussion pages. To name only a few differences, consider WikiProject banners, vote-oriented RFCs, requests for images, and talk-page categories, which you'll find on article talk pages but not on user talk pages. Also remember that welcome templates, user block discussions, user warning templates, and barnstars are things that you'll find on user talk pages but not article pages. IMO these are not entirely trivial differences that should have no effect on the design. User-talk and article talk pages are not simply interchangeable. The research has actually shown that there is a difference, and that the user talk page does have very different requirements from an article talk page. There are some requirements that are the same (e.g., the ability to discuss article content on any discussion page), but there are some quite different requirements, too.

My recommendation is that you think about how long it will take her to read through the ever-growing list of comments and to write the specification, and then wait until she has had enough time to do that work. There will be time for you to comment on the specifications, and nothing will be set in stone until well after the initial deployment. In between now and then, please give her a fair chance to actually do that work. If you need to know what is intended before she has had time to write the specification, then please actually go read the use cases, which provide a lot of details about what types of actions and discussions Flow is required to support. Whatamidoing (WMF) (talk) 17:04, 15 August 2013 (UTC)

Yes, I do dislike the style of "Customers? Who cares about them!". But it has little to do with "Agile" software development, or software development in general. By the way, I have written why releasing "half-baked" product is a bad idea in this specific case. You have ignored those explanations.

I have also asked for some indication that feedback is being listened to. You don't have to read millions of bytes to learn something. I am also happy to accept "I will proceed to that right away!". I am not that happy to accept your post that can be perceived as mostly equivalent to "Eh, who cares about you!" (hopefully, that is a mistaken perception)...

As for the differences between talk pages and user talk pages... The point is that random sample is not good enough. You must support not the most common use cases, but all use cases. Otherwise you will break something. And here we have another easy-to-spot mistake: "talk-page categories" as example of something that does not happen in user talk pages. What about Category:Requests for unblock..? There are just 29 pages in it at the moment. You are very unlikely to get one of them in your sample. But you must support the related use case as well. And if you want to support unblock requests without supporting talk page categories, remember that if you will have "opt-in", both systems will have to work in parallel. --Martynas Patasius (talk) 01:48, 16 August 2013 (UTC)

We don't need a category to list requests for unblocking. We need a method of alerting interested people that a user has requested unblocking. That method need not involve a single category. "Change the use" and "break the use" are not the same thing. Whatamidoing (WMF) (talk) 15:01, 16 August 2013 (UTC)

I have already explained that in [9]. But OK, I'll do that again...

You can either replace the current talk page system with "Flow" at once or have them run in parallel for some time (hopefully, that is clear enough). If you replace everything at once, you can change everything including the way we work with unblock requests. But you intend to have both systems run in parallel. And then you have to make them compatible in everything. Since the current system uses categories and is unlikely to use something else, the new system will also have to use categories. Starting from the first released version. Q.E.D.

Also, let's face it: you have no idea how your "method of alerting interested people that a user has requested unblocking" that "need not involve a single category" would actually look like, do you..? Don't worry, I am pretty sure that no one in WMF does... Though, of course, that is exactly what worries me... --Martynas Patasius (talk) 00:05, 17 August 2013 (UTC)

Martynas, your fears largely seem based on the assumption that "deployed" means "will appear on all talk pages one day soon with no warning and no discussion." I can assure you that won't happen. Maryana (WMF) (talk) 18:24, 15 August 2013 (UTC)

Can you at least assure us that you won't deploy it without community consensus? The forcible deployment of VE has us all somewhat skeptical, Maryana.—Kww(talk) 18:53, 15 August 2013 (UTC)

I know you guys feel pretty burned by the VE experience, and I'm sorry for that. Trust me – if for no other reason than the sake of my own mental health (not to mention yours), I don't want a repeat of those flame wars with Flow. The only way the first release of Flow is going to work is through an opt-in process, meaning it will only be enabled on a subset of talk pages where users have agreed to test it out. Maryana (WMF) (talk) 21:21, 15 August 2013 (UTC)

No, my fears have little to do with deployment "all at once". The problem is that you will have to support the current system and all released versions of "Flow".

If you do not see the problem yet, let's look at the scenario, inspired by my exchange with "Whatamidoing" above.

Let's say that the first version of "Flow" is released. "Whatamidoing" opts in to use it. After that he gets in a "fight" and gets blocked for one reason or another. He wants to get unblocked. He writes an unblock request (let's assume that the first version of "Flow" actually supports that - it is an important use case, after all). How will the administrators see it? They are going to look at Category:Requests for unblock, just like now. If you will make unblock requests from "Flow" go elsewhere, no one will look there (not enough users will opt in on the first days to justify such effort). So, hopefully, you will do things right and after some "workarounds" the unblock request will end up looking like an "old" unblock request. Now, let's say, "Whatamidoing" gets unblocked after several tries and wants to go to "Arbcom" and argue about those rejected unblock requests. What then? He (and "Arbcom") needs to see those unblock requests. Even if "Flow" gets changed by then.

Or another scenario (shorter): what if someone opts in and out several times..?

So, to summarise, you will have to find a way to support the current talk page system and all released "Flow" versions forever. Perhaps you can convert the data. Perhaps you can think of some "sandboxes". But keeping such compatibility the hard part and it will have to be ready from the first released version. Thus I would like to advise you not to burn the bridges behind you...

In other words, as Lloyd George has once said (q:David Lloyd George), "There is nothing more dangerous than to leap a chasm in two jumps."... --Martynas Patasius (talk) 02:28, 16 August 2013 (UTC)

I can call spirits from the vasty deep

I have extensive experience managing software projects, including Agile. Maryana is right about Agile involving deliberately releasing half-finished work and seeing customer response, and I can tell you that it really does work well.

What Agile does not require is knowing that something is not acceptable to the customer and yet allowing it to remain in place. If it is code, it may take some work to change (hopefully not too much work; if your Agile project is hard to change you are doing it wrong) but Agile also involves documents that communicate "we are going to do X" to the customer, and those need to be immediately changed as soon as you know from customer feedback that the new plan is to do Y instead of X. Unfinished documentation is OK. Wrong documentation is not.

I opened an RfC on 28 June 2013 and in less that two days it became clear that the consensus was going to be overwhelming, and indeed it turned out to be unanamous. How often does that happen on Wikipedia? We have established that there are zero technical barriers to implementing the community decision from the RfC, and yet, a month and a half later, Wikipedia:Flow -- your main customer-facing documents -- still says "Admins will be able to edit other people's comments; a userright might allow trusted non-admins to do the same." Why has this not been updated? Who is the Scrum Product Owner, and why didn't we hear from her/him as soon as the RfC closed? An outdated and wrong user story is worse than no user story at all.

Yes, I could just update this myself. In fact I could edit all of the projects customer-facing documents. That would be very much like this passage from Shakespeare's Henry IV:

GLENDOWER: I can call spirits from the vasty deep.

HOTSPUR: Why, so can I, or so can any man, But will they come when you do call for them?

In other words, I can edit the documents, but I cannot make the developers do what the document says that they will do. --Guy Macon (talk) 19:17, 15 August 2013 (UTC)

A userright is the normal way of implementing this sort of functionality. As it says, this userright will be set to allow admins to do this, and it might be set to allow some or all non-admins to do the same. I'm not seeing an actual error here: this one user group is planned at minimum, and any other user group is possible. All I see is that nobody has enshrined the current community opinion about which user groups might get this userright on a page that is being treated by some people as if it were filled with irrevocable, immutable, money-back-guaranteed promises from the devs.

(BTW, the last time I read that RFC, there were people opposed to the majority viewpoint that IPs and new editors should be permitted to change and vandalize comments made by experienced editors, so "unanimous" is not the word I would choose to describe the outcome.) Whatamidoing (WMF) (talk) 22:06, 15 August 2013 (UTC)

The reason why it's going to be a userright is because that's the correct way of handling this type of thing. But also: enwiki does not have the right to force their consensus on other wikis. Flow will have inter-wiki conversation functionality on day zero. This complicates the matter significantly. --Jorm (WMF) (talk) 22:09, 15 August 2013 (UTC)

En-wiki does not have the right to say that everyone should follow en-wiki consensus, Jorm, but we certainly do have the right to ask that all new tools deployed on English Wikipedia support en-wiki consensus. If you can't get Flow to support what we say it needs to support, you shouldn't deploy it here.—Kww(talk) 22:56, 15 August 2013 (UTC)

I'm trying to figure out where the confusion is here. Flow will be able to do what you want it to do. We've said that multiple times. It's codified in the documentation that comment editing is a userright. How does this prevent the implementation of enwiki consensus? (A consensus which, by the way, I think is a bad idea, as I don't believe people understand that "comment editing" and "comment moderation" are separate concepts).--Jorm (WMF) (talk) 22:58, 15 August 2013 (UTC)

It comes from the fact that "Admins will be able to edit other people's comments; a user right might allow trusted non-admins to do the same" doesn't say "A separate user-right that allows the editing of comments will be supported, and each wiki will be able to independently determine what group of editors will be given that user right.—Kww(talk) 23:03, 15 August 2013 (UTC)

When I see comments like "I'm trying to figure out where the confusion is here", it makes me want to stop trying. I don't know how I could have made myself more clear. I am not confused. I am not rehashing questions that were answered weeks ago. The fact that this is a simple configuration option has already been established. I am not even asking whether it should be a separate user right, as Kww discusses above (and it is well worth discussing, IMO). All I am saying is this: NOBODY APPEARS TO BE IN CHARGE OF UPDATING THE MAIN WEB PAGE THAT THE WMF USES TO COMMUNICATE WITH WIKIPEDIA ABOUT FLOW TO REFLECT DECISIONS THAT WE HAVE ALL AGREED ON.

Whether you like it or not, we have decided to NOT allow only admins to edit comments. Another RfC may in the future change that decision, but right now that decision has been made. So WHY DOES THE MAIN WEB PAGE THAT THE WMF USES TO COMMUNICATE WITH WIKIPEDIA ABOUT FLOW NOT REFLECT THIS?

You asked for input. We gave it. There is no technical reason why WP:FLOW does not say that anyone will be able to edit other people's comments. Why wasn't it updated? And more importantly, if we on the Wikipedia side can make a decision that is within our purview and yet not have it show up in the documentation, how many decisions have been made on the Wikimedia side that have not shown up in the documentation?

What good is Agile methodology if, when customer requirements are discovered and agreed upon, nobody puts them in the documentation that the customer reads? Has anyone at the WMF documented this decision anywhere?

This really is a minor issue, but I fear that it is a symptom of a far deeper problem. Wikimedia foundation, please give me a reason to believe that once we agree upon a customer requirement that it will be documented and that we can move on to the next issue. --Guy Macon (talk) 11:39, 16 August 2013 (UTC)

Here's the confusion (on the editing comments thing, anyway). Right now, when people say they want to edit other people's comments, they mean a number of things, including:

• correcting typos
• fixing broken links
• fixing broken formatting
• removing personal attacks
• oversighting sensitive personal information

Because talk pages are created with unstructured data, doing any one of these things requires making an edit to a page or section of a page. A Flow discussion will be created with structured data, meaning some of these things (fixing broken formatting) become moot, while others (removing personal attacks) can be done in completely new ways. Once the data is structured, there's no particular reason to force a user to open up a comment containing a personal attack, physically edit out the personal attack, and save the comment; why not just make it easy for anyone to hide the comment? That's what every other discussion system on the Internet does (well, that or flagging as inappropriate).

Of course when you poll a group of Wikipedians right now about how they want to deal with all of the bullet points above, they will say they want anyone to be able to edit a talk page comment. That's how they currently deal with those things – just like if you'd asked Wikipedians in 2001 how they want to create internal links in Wikipedia, they would have said "CamelCase!" There's nothing intrinsically wrong with editing talk page comments, just as there was nothing intrinsically wrong with camel-case links, but there are pretty obvious practical limitations, and it would be pretty silly for us to spend a lot of time and money building a structured data discussion system and then just ignore the obvious advantages and new ways of doing things it affords us.

I think perhaps the confusion on the documentation front is that there's a mismatch in expectations between staffers and community members about what it means to put something on a wiki. This portal was many things (early brainstorming space, research dump, conversation starter), but it was certainly never meant to serve as an authoritative feature document or customer contract this early on in the development process. Maybe it would help if we took out all the very specific language around implementation and reoriented it more toward research, rationale, and user stories? I'm perfectly happy to slash and burn if it'll help to foster clarity and put your troubled spirits at ease. Maryana (WMF) (talk) 16:35, 16 August 2013 (UTC)

Your changes should be in the opposite direction. Please make your documentation sufficiently specific that we can react and comment on it in a meaningful way. Right now, we get vague promises with some very frightening sounding caveats. Tell us precisely what you plan to do, let us wreak havoc upon it, and then, when there's an agreeable specification on something to do, implement it.—Kww(talk) 16:40, 16 August 2013 (UTC)

I just updated the "Timeline" section; have a look. Instead of making people read a long list of requirements, I'd much rather get a basic Flow instance running on a test wiki, invite users to try it out for themselves, and get feedback on what's missing or broken. Walls of text are open to (mis)interpretation; real features aren't :) Maryana (WMF) (talk) 17:30, 16 August 2013 (UTC)

That's neither Agile nor Scrum, that's just writing code and crossing your fingers that somebody likes some part of it. I'd much rather that no one coded a thing until there's agreeement on some basic set of requirements.—Kww(talk) 19:13, 16 August 2013 (UTC)

In other words, you simply want us to trust you that your product will be great, without having any idea how it is going to look like. The problem is that it does not reassure anyone who does not trust you already...

You are once more taking a list of use cases and assuming that they exhaust all possibilities. They are very unlikely to do so.

Also: "A Flow discussion will be created with structured data" - structured how..? If we knew, how, we could at least check if you can actually do with it what your listed use cases demand. Now you listed five use cases and explained how two (or three) of them are covered. What about the other two? For example, "fixing broken links"..?

Furthermore, "unstructured data" does end up looking more flexible. Someone wants to remove the personal attack while leaving the rest of the post, can do so with the current system. Will it be possible with the new one..? Yes, such things also happen in the forums.

Oh, and "just like if you'd asked Wikipedians in 2001 how they want to create internal links in Wikipedia, they would have said "CamelCase!"" sure does read like an insult... It is equivalent to "Eh! Who cares about your opinion!". And things like that are not what builds trust...

So, in the end you got feedback and found some excuses to ignore it. What makes you think that you will not do just that with feedback after the first "Agile" deployment..? --Martynas Patasius (talk) 00:49, 17 August 2013 (UTC)

Err, just in case, are you familiar with Wikipedia:CamelCase and Wikipedia? There is no chance that was intended as an insult - it was referring to actual history. –Quiddity (talk) 01:38, 17 August 2013 (UTC)

Yes, I know that Wikipedia once used the "CamelCase" for internal links. And I know that it was not meant to be an insult. But perceptions matter. Yes, even wrong perceptions. And it was still offered as an excuse to ignore the arguments and opinions of everyone who disagrees with WMF. That might not be a "real" insult, but it is suspiciously close to argumentum ad hominem... And not exactly a way to win friends...

In other words, the "insult" I referred to was an attitude which, if exaggerated (yes, much exaggerated), would read as "You narrow-minded peasants just have no imagination to see how great this new product will be!". You do understand why that exaggeration would be perceived as an insult, right..? The actual words are obviously not nearly as bad, but er, they still do not exactly feel like praise... --Martynas Patasius (talk) 02:02, 17 August 2013 (UTC)

Am I the only one who feels like I was just told that my RfC above was a huge waste of time and that it would be futile to create any future RfCs? That nobody from WMF will participate in any RfC or present logical arguments for a particular RfC outcome, but they have no problem with waiting until the RfC closes and presenting arguments for rejecting the unanimous RfC outcome in a followup talk page discussion?

Anecdotes are interesting things. They can provide insight, but they can also inadvertently mislead. Take the CamelCase anecdote above. It is an anecdote about someone rejecting something new and being proven wrong. The thing is, I can come up with a bunch of anecdotes about someone rejecting something new and being proven right.

Our article on Paternalism may provide some insight. --Guy Macon (talk) 09:23, 17 August 2013 (UTC)

Jorm has an unfortunate habit of saying things in ways that can easily be interpreted as dismissive. I believe what he's actually saying is that the userright functionality is necessary to allow those wikis that want to restrict such behaviour to do so, but that it can be turned on by default for all users on en-wiki, satisfying en-wiki consensus. This is, after all, not just for en-wiki, and possibly not even just for Wikimedia sites, so removing the functionality completely would be counterproductive. As even IP editors can be given default userrights, there shouldn't be any issue with setting up en-wiki appropriately. Adam Cuerden ^(talk) 09:41, 17 August 2013 (UTC)

And thus the cycle repeats:

Guy: Who can edit comments?"

WMF: Admins only. Letting anyone edit comments is stupid.

HEW: (Helpful English Wikipedian) I think what they are saying is that It's configurable, and the English Wikipedia can decide.

Guy: RfC time...

RfC: Unanimous consensus: anyone can edit comments.

Guy: Well. WMF?

WMF: It's configurable. The English Wikipedia can decide.

Guy: Great! We are done.

Guy: New topic: why hasn't the flow page been changed to reflect the above?

WMF: Letting anyone edit comments is stupid. Flow does it differently.

Guy: Why are we just finding this out? What about our previous discussion?

HEW: (Helpful English Wikipedian) I think what they are saying is that It's configurable, and the English Wikipedia can decide.

Guy: Look, can we just forget about who decides and fix the page?

WMF: Edit the page to say that anyone can edit comments? Letting anyone edit comments is stupid. But It is configurable. The English Wikipedia can decide. Also, Flow does things differently, so the question is meaningless.

Guy (gives up) --Guy Macon (talk) 10:27, 17 August 2013 (UTC)

I don't know whether or not this makes me an HEW, but I'd like to call WP:BEBOLD up from the deep. There's no valid reason for Guy or for an HEW not to just go ahead and change this page. It's reasonable to infer that the configuration is, indeed, configurable, so let's just plan on configuring it here, and letting the other projects do whatever they end up doing. (By the way, I loved reading the mini-screenplay above!) --Tryptofish (talk) 14:59, 17 August 2013 (UTC)

I was sort of hoping that Wikipedia:Flow would document the evolving understanding that WMF has of the user requirements. If I turn it into me communicating my understanding of the user requirements to to the WMF, I would just be calling spirits from the vasty deep. I can call spirits from the vasty deep, but will they come when I call them? I can dictate requirements to to the WMF, but will they obey me? I am guessing No and Hell No. --Guy Macon (talk) 20:20, 17 August 2013 (UTC)

Well, nobody reverted my edit yet. Don't worry about whether they will obey your dictates, or mine. They are smart enough to, eventually, take seriously the dictates of the community. --Tryptofish (talk) 20:46, 17 August 2013 (UTC)

Point well taken. Despite my disagreements on a few things, In general I am quite impressed with the job the WMF and in particular the WMF developers are doing. --Guy Macon (talk) 02:46, 18 August 2013 (UTC)

"Jorm has an unfortunate habit of saying things in ways that can easily be interpreted as dismissive." - perhaps, but the words we are replying to ([10]) were not said by User:Jorm (WMF) ("Brandon Harris, Senior Designer, Wikimedia Foundation"), but by User:Maryana (WMF) ("Maryana Pinchuk, Product Manager, Wikimedia Foundation"). "Jorm" has said similar things too ([11], [12], [13]), but when we have two different people saying the same thing, perhaps it is not correct to assume that we are dealing with mere linguistical incompetence of one man... It is far more likely that WMF as a whole is dismissive of our concerns. It would be even more obvious if we add the "proclamations" of other WMF employees (for example, User:Whatamidoing (WMF) - "Community Liaison (Product Development), Wikimedia Foundation"... Speaking of which, shouldn't WMF employees publish their real names..?). Let's just say that if they see themselves as our servants, they are really good at hiding it... --Martynas Patasius (talk) 14:21, 17 August 2013 (UTC)

I think this is missing a critical part of the point. Agile methodology is fine. I've used it, and I found it to work well. But a critical part of agile is listening to your users after your initial test-the-waters release. There were several cases in which I released something, only to have users come back and say "This is confusing." Or "This doesn't do what I need it to." Or "This isn't useful at all." The reason our agile development worked is because I then spoke to those users, and said "I hear you. How can I make this better suit your needs?". After asking that, I got a lot of valuable feedback, and upon the next release, inevitably got "This is much better, I love it!". You can't please everyone, but when most everyone is telling you you're wrong, you stop and listen. If you're doing agile development, you must be listening to feedback from your users, not ignoring it. Otherwise the whole thing breaks down. We've spoken clearly here. Listen to us, and make sure the software can do what we asked you to do. It doesn't matter if you, Maryana, or you, Jorm, think editing comments for all is necessary under the new system. We, your users, do, so it needs to be part of the software or the software needs to not be deployed here. Period. Seraphimblade ^{Talk to me} 15:15, 17 August 2013 (UTC)