Wikipedia talk:Flow

Main article: MW:talk:Flow

Smaller and offsite announcements/mentions

Continued from Wikipedia:Flow#Announcements

• Wikipedia:Wikipedia Signpost/2013-03-11/Technology report - Article Feedback tool made opt-in only (brief)
• Wikipedia:Wikipedia Signpost/2013-01-21/Technology report - First Quarterly Review makes for interesting reading (brief)
• Wikipedia:Wikipedia Signpost/2012-12-31/Interview - Interview with Brion Vibber, the WMF's first employee (brief)
• Wikipedia:Wikipedia Signpost/2012-09-10/Technology report - August engineering report published (brief)
• Wikipedia:Requests for comment/Article feedback - January 2013 (numerous brief mentions)
• http://blog.wikimedia.org/2013/05/02/wikimedia-engineering-april-2013-report/#Editor_engagement_features
• http://blog.wikimedia.org/2013/04/12/wikimedia-foundation-report-march-2013/#Editor_engagement
• http://blog.wikimedia.org/2013/03/13/wikimedia-foundation-report-february-2013/#Editor_engagement
• http://blog.wikimedia.org/2013/03/12/engineering-february-2013-report/#Editor_engagement_features
• http://blog.wikimedia.org/2013/02/17/wikimedia-foundation-report-january-2013/#Editor_engagement
• http://blog.wikimedia.org/2013/02/07/engineering-january-2013-report/#Editor_engagement_features
• http://blog.wikimedia.org/2012/12/06/engineering-november-2012-report/#Architecture_.26_Platform_support
• http://blog.wikimedia.org/2012/10/03/engineering-september-2012-report/#MediaWiki_infrastructure
• http://blog.wikimedia.org/2012/09/04/engineering-august-2012-report/#MediaWiki_infrastructure
• WMF Editor Engagement mailing list (most of May 2013)
• Wikimedia tech ambassadors mailing list, 16 May 2013

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

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

The result of this discussion was an overwhelming consensus: 28 users supported letting anyone edit another person's talk page comments, 9 users supported letting any autoconfirmed user edit another person's talk page comments, and 0 users supported limiting this to reviewers, rollbackers or administrators. In addition, one user made a proposal that concerned user talk pages; this RfC applies to article talk pages only. --Guy Macon (talk) 18:46, 10 August 2013 (UTC)

---

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

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

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

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

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

Header

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

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

Support all users

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

---

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

Support autoconfirmed users

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

---

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

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

5. Support. I've fixed (and seen fixed) many old instances, of IP-users deleting/mangling/altering the comments of other editors (Similar to WhatamIdoing's examples above. Or this example from yesterday, where I had to search through a lot of diffs, to determine who had deleted what, and when.). It's rare that an IP-user fixes the comments of another editor (It definitely occurs, but it's rare proportionally). –Quiddity (talk) 22:39, 30 June 2013 (UTC)
6. Support. With this new system in place, I think a minor restriction like this just naturally comes with the territory. In particular with its user-friendliness and similarity to other web forums it can be argued that unhelpful IP editing and trolling of other users' comments would actually increase once they notice that they "can actually do that here". -- œ^™ 02:10, 1 July 2013 (UTC)
7. Support I've seen too much mangling of talk page comments by IP users. If something needs prompt action on a talk page, one of the 100,000 plus active autoconfirmed users can handle it. Edison (talk) 19:51, 11 July 2013 (UTC)
8. Support as long as everyone has the right to edit comments left on their own talk pages. I think this will eliminate most editing of others comments and allow tracking of what remains. The exception for your own user talk page is so that everybody can remove any harrasment, etc. from their own talk page in the way they currently can. Thryduulf (talk) 11:14, 15 July 2013 (UTC)
9. Support Autoconfirmed only. These are people who have shown enough interest in improving Wikipedia so they've taken the step of truly "joining the community." GeorgeLouis (talk) 07:21, 22 July 2013 (UTC)

Support reviewers

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

---

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

---

Support rollbackers

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

---

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

---

Support administrators

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

---

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

---

Support another user group not listed

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

---

1. If a user group other than "all users" is selected, then I propose that everybody be allowed to edit others comments on their own user talk page. There are reasons to restrict editing of others comments on article talk, etc, but everyone should have the ability to remove hurtful/insulting/trolling/etc comments from their own user talk page as they currently can. The only exception is blocked editors who have been blocked from editing their talk page, who should obviously not be ale to alter others' comments on it. Support as proposer Thryduulf (talk) 11:20, 15 July 2013 (UTC)

---

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Threaded discussion

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Arbitrary Section Break 1

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

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

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

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

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

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

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

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

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

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)

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)

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. [8], [9], [10], [11], [12], [13], 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)

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)

Supported Wikitext

What wikitext will and will not be supported is a difficult question for me because there is an inherent problem with any answer, and that is "I can only speak to what Parsoid is capable of today" and not what it will be capable of in six months or even a year. I don't want to say things like "sure, this will work" and then later be wrong so I've been hemming and hawing here and there and that kind of sucks. However, I've had several conversations over the past couple days (my time has been compressed this past week due to several all-day engagements), but I've got some answers.

First, it's probably easier to ask "what will not be supported" rather than "what will be supported." And it turns out, there's a whole page about the limitations of Parsoid. As you can see, much of that is broken wikitext - stuff you shouldn't be doing anyway. Some of it (using templates to define table structure) is listed as "tricky, but solvable", and I'm informed that most of those issues will be solved within the next six months or so.

If you're curious, there is a sandbox that you can play with and test arbitrary wikitext in form to see output modes (also how it gets saved, but that shouldn't be a concern).

Hope this helps.--Jorm (WMF) (talk) 19:47, 24 July 2013 (UTC)

Oh, yeah: the question about SUBST'ing things vs. non-SUBST'ing is actually not finalized yet; I don't have an answer for that.--Jorm (WMF) (talk) 19:48, 24 July 2013 (UTC)

Thanks, that's very helpful in understanding (at least for me). Given that (as far as I understand) we are concerned here with what could loosely be called discussion pages, as opposed to article space itself, I do not see these limitations as presenting an impediment to worthwhile communications amongst editors. --Tryptofish (talk) 20:20, 24 July 2013 (UTC)

Could you please acknowledge that you understand how partial wikitext support (i.e. any form of wikitext processing that is redirected through Parsoid) would disrupt current community practices? So far I've not seen you acknowledge that disruption, and given that you'll be designing the new cooperation platform, it would be great to know that you at least know exactly what you're "taking away from Peter". Diego (talk) 21:09, 24 July 2013 (UTC)

No it does not help. Because you still have it upside down. We need full rendering - of everything, including the ugliest css-hacks or misappropriation of templates. Your job is to provide it. Period. I don't care how difficult it is, your code won't be rolled out until it can deliver. rgds --h-stt !? 13:01, 25 July 2013 (UTC)

Right. So, as said before, "full rendering" in comments and posts with Flow is not likely to happen. If you'd like to help out with the project, that's great, but this kind of comment doesn't get us anywhere.--Jorm (WMF) (talk) 16:30, 25 July 2013 (UTC)

Jorm, if the user base say that the software is completely unsuitable for them unless X, then your choices are 1. Deliver X, 2. Do tests to see if they really miss X, 3. Stop development, or 4. Spend a lot of time creating something that will never be used. Adam Cuerden ^(talk) 16:50, 25 July 2013 (UTC)

I agree with H-stt and Adam that full rendering of arbitrary (correct) Wikicode (not limited to that allowed by Parsoid, but any Wikimarkup which generates valid HTML) is required in talk pages; but it doesn't have to be part of Flow. It would be adequate that any Flow message allow the inclusion (not link to, but include) an "article" in a scratch space. And ... talk page messages should be subst'd; talk page copies of proposed article text should not be. As long as page can be rendered in article-space, it must be able to be discussed in the user-talk-page equivalent. — Arthur Rubin (talk) 17:26, 25 July 2013 (UTC)

Agreed with Arthur. As long as some method of delivering the functionality is there, and it doesn't cause undue disruption, it should be fine.

In all honesty, I think we're dealing a little too much in abstract here. Flow doesn't need the ability to deliver perfect Wikimarkup all the time; it just needs a method of gracefully handling the few situations where that ability is vital, which is not quite the same thing. There's a thousand different acceptable ways to make this work, from some equivalent of <nowiki> tage - <noflow>, say, to incorporating a wikitext markup interpreter box as a type of workflow meant for that purpose. You might even find that people are amenable to using subpages for that purpose if they can make those subpages have "sticky links", if you're familiar with forum terminology. Perhaps transcluding subpages is an option: if they look a little funny in Flow, people can still jump over to the subpage and see the full functionality.

Any of those methods and many more would probably be perfectly fine. Adam Cuerden ^(talk) 19:19, 25 July 2013 (UTC)

Instead of arguing about abstracts (which is going nowhere), we need specific examples.

(This has been discussed in a large variety of locations, partially due to multi-posting by some editors. I'll try to summarize the fragmented discussion so far...)

The core issues are summarizable as:

• We, the editors who continue to primarily "Edit source", need a way to copy-and-paste content from the edit-window into a Flow-discussion. We also want to continue to type the markup that we're accustomed to, that effortlessly flows from our fingers.
• Article-content is often discussed in usertalk, therefore it needs to be considered even before the beta/opt-in stage.
• The content we post, needs to display the same way as it does in an article, because we're frequently discussing the visual-aspect of formatting and layout, and diagnosing errors or glitches.

Here are some specific examples, one for each type of content. The descriptions I added are abstract, not diff-specific.

• [14] Demonstrating new templates.
• [15] Discussing IPA technicalities, with IPA templates and examples probably copied from an edit-window.
• [16] Various {{User}} type templates, often used in multiples.
• [17] Numerous {{tl}} templates.
• [18] Copying example code (and embedding it in a < nowiki > or < code >), to explain something.
• [19] Table-Code excerpt from article.
• [20] Template:Gi/Tq used to highlight quoted remarks that are being replied to.
• [21] Magic word {{NUMBEROFACTIVEUSERS}}

I went through about 40 usertalk pages, and those were the clearest and most diverse examples I saw.

If Flow's still hypothetical (therefor hard to predict features of) fallback-editor, or even the VE-editor-after-months-more-development, supports all of these instances, without us changing our typing-habits drastically (or at all), I believe that will satisfy all the confusion and concern. At the very least, it gets a brief & clear set of examples in front of the devs' eyes (for them to keep in mind over the coming months), rather than abstract requests for "everything". –Quiddity (talk) 20:19, 25 July 2013 (UTC)

Perhaps I could add one more example, from my own talk page:

• [22] Copying mathematics text from an article to ask a question about the notation employed.

Will it continue to be possible to do that? Spectral sequence (talk) 21:18, 10 August 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)

Deletion

Jorm comments above that it is currently planned that deleted posts and topics will remain on the board, just noting that the topic was deleted and by whom. So you won't have to check the history to see that this has happened. This is problematic. Being on the receiving end of abuse is an all too common occurrence on talk pages, and there absolutely must be a way for a non-privileged user to eradicate text to the same degree that it's currently possible to do so. — Scott • talk 20:51, 8 August 2013 (UTC)

I don't think he means that the entire message will be left on the board, but rather that the fact the thread existed will remain. So instead of seeing the original message:

I accuse you of edit warring on this article that you've never even touched! Your existence is a blight upon humanity, and you should be ashamed to breathe! User:Example 21:47, 8 August 2013 (UTC)

—This post has been deleted by WhatamIdoing (talk) at 21:47, 8 August 2013 (UTC), so pretend you didn't read it, okay?

you would likely see something more like

This post was deleted by WhatamIdoing (talk) at 21:47, 8 August 2013 (UTC). Undelete (authorized accounts only)

If the post simply disappeared, then I'm not sure how you would find it again, in the event that you ever wanted to undelete it (e.g., because you clicked on the wrong post when you were deleting things). WhatamIdoing (talk) 21:47, 8 August 2013 (UTC)

Have you ever seen harassment at Wikipedia? It's surprisingly rare, but it does happen and it's totally destructive. It's destructive not just for the person being harassed, but for any decent person who notices because no decent person likes to be part of a community that has no tools for dealing with such obvious exploitation of anyone can edit. As Scott explained, there must be a way for rubbish to be removed totally because WP:DENY is our only tool—any attempt at blocks of wide IP ranges is met with howls at ANI. The abuser would regard the fact that they can get half a dozen "This post was deleted..." messages on a talk page as a win for their side, and everyone watching would think, "oh—that's X saying Y again". Complete removal is necessary not just for harassment but for other kinds of ratbaggery, for example, from zealots pushing their cause on article talk pages where again they would regard a wall of "This post was deleted..." as flags marking their progress towards campaign victory. Johnuniq (talk) 03:07, 9 August 2013 (UTC)

In your opinion, does the example I gave above indicate who's post it was? How would anyone know whether it was his post or someone else's? How would this be any different from regarding the talk-page history as a trophy? WhatamIdoing (talk) 15:33, 9 August 2013 (UTC)

How is it different? A history page is not in the face of everyone reading the conversation. Diego Moya (talk) 16:46, 9 August 2013 (UTC)

If the post simply disappeared, then I'm not sure how you would find it again... - that's why I said to the same degree that it's currently possible to do so. In other words, page history currently provides a mechanism for locating removed text. As it stands, the current proposal loses this functionality and gains the problematic scenario that John describes. — Scott • talk 12:15, 9 August 2013 (UTC)

Each post is its own page. There is no unified page history. Imagine that I have a thousand subpages with names like User talk:WhatamIdoing/39582-03-20358920952. None of the are linked on a visible page, and someone has deleted a dozen entire pages, possibly without my knowledge or permission. How would you find the deleted pages? WhatamIdoing (talk) 15:33, 9 August 2013 (UTC)

• What!!!???!!!!???? That is terribly non-functional. There has to be a way to see all edits to the same page, otherwise the result is not a wiki, and you've broken the number 1 functionality that people depends upon since 10 years ago. The problem you mention is only the tip of the ice-berg of everything that can be wrong without a common edit history. A single history for the whole page is the mechanism that the community uses to perform all kind of supervision. You eliminate that feature, and there's no way to review what other people is doing with the content. Diego Moya (talk) 16:01, 9 August 2013 (UTC)

• Each comment is its own "whole page". You will be able to see the page history for each comment/page—but, just like now, you can only see that page history if you know the exact name of the page. WhatamIdoing (talk) 20:46, 10 August 2013 (UTC)

• I understand that, and that's exactly what's problematic. But it doesn't need to be that way; if you have a logical concept of "thread" that includes more than one comment, there has to be a way to find which comments belong to it (even if a comment belongs to several threads, that's a separate concern to this concept). Diego Moya (talk) 21:25, 10 August 2013 (UTC)

Er, I'm reporting a bug in your design. Solving it isn't my job, and especially not inventing solutions to problems created by a complex new infrastructure I have absolutely no knowledge of. — Scott • talk 16:14, 9 August 2013 (UTC)

In any case, there's no sense in saying that there can't be a unified history page. There is a way to find all posts that belong to a thread, otherwise you couldn't show them and notify people subscribed to it. It should be possible to use that same mechanism to find all posts' histories and merge them on a single page. Maybe it wouldn't be terribly efficient, but accessing history is also not the most common operation. Diego Moya (talk) 16:58, 9 August 2013 (UTC)

It might be possible, but you're still thinking about "a comment" happening exclusively on "a page". That's not the idea here. The idea here is more like "a comment" is made, and it (if wanted) simultaneously appears on multiple pages. Your "unified history page" would be the equivalent of every single edit to every single AFD and every single subpage of AFD appearing at WP:AFD's history. That's probably not what you really want. WhatamIdoing (talk) 20:46, 10 August 2013 (UTC)

Multiple post is no excuse. If you have a concept of a "page" or a "thread" or a "tag", it should be possible to find all comments that belong to that one page and find their history; it's no different to what we have now, if I post the same comment to several pages with the current system (by copy-pasting it) it will show at the history of each page, and it doesn't mean that all those pages have their histories merged; there's no need for the new system to behave differently. Your analysis of the problem (that this somehow would mean merging all the histories of all possible threads) makes no logical sense to me. Diego Moya (talk) 21:23, 10 August 2013 (UTC)

Mathematics under Flow

I am disturbed by the comment features like math editing are planned for VE, but are not guaranteed to arrive by the time Flow does. It seems extraordinary that editors of mathematics articles will be required to use VE for discussions about mathematics and yet be unable to write the formulae they want to discuss. Is that really intended? Is that not equivalent to telling mathematics editors that their discussions are less worthy of support than others? Is it not a contradiction of this commitment by User:Jimbo Wales that The source editor will remain available so nothing about mathematical editing needs to change at all? Spectral sequence (talk) 19:39, 9 August 2013 (UTC)

I had not thought of that before, but it's a very good point. Discussions about mathematics need to be able to include mathematical markup. --Tryptofish (talk) 00:17, 10 August 2013 (UTC)

Hi. I am πr², or $\pi r^{2}$ if you would like to use the math syntax. I added that row to the features table following a discussion above, especially this comment, where math is used as an example. Basically, Jorm said that he doesn't want to promise features in Flow, because it's up to the VE team. The same could apply to the music scores extension for music-editors, or syntax highlighting for programming and CS editors. It's definitely planned, and an important feature, but it seems there's no guarantee. πr² (t • c) 04:35, 10 August 2013 (UTC)

For a group of editors to be able to discuss the material that might be added to the encyclopaedia is not a "feature", it is a requirement: indeed, effective discussion of how to build the encyclopaedia is the primary purpose of any workflow system. Suggesting that you don't want to promise, or can't guarantee, that we'll be able to discuss our work effectively seems less than adequate, especially since we can with the current system. Why is it proposed to force us to work for some indefinite period without that essential ability? Spectral sequence (talk) 06:23, 10 August 2013 (UTC)

Right now I have the option of using VE or editing the source directly. I was given to understand that nothing about Flow will change this.

This gets back to the basic principle that I have been advocating; It is not the place of the Wikimedia software developers to arbitrarily change any user restrictions or capabilities on Wikipedia without the consensus of the community. An obvious exception is cases where such changes are required by the nature of the software change. Even in those cases, if there are any choices about what new restrictions/capabilities would replace the old, the Wikipedia community should be allowed to make that decision. --Guy Macon (talk) 19:23, 10 August 2013 (UTC)

My question is really rather simple. Is there a design criterion and commitment to implementation of the requirement that editors such as myself, who need to use mathematics for discussion on article and user talk pages, will continue to be able to do so without interruption on the introduction of Flow? Whatever the answer to that question, I would like to see it explicitly stated. Spectral sequence (talk) 19:53, 10 August 2013 (UTC)

In this pdf, Equation support (LaTeX/mw:Extension:Math-based, probably) is listed as "Coming soon". (was mw:User:Jiabao_wu/OPW_Round_6_Application accepted?) @Spectral sequence: The feature request has existed since late 2012, and is "High enhancement" priority. πr² (t • c) 02:25, 11 August 2013 (UTC)

Thanks for that, but it doesn't really answer my question. The answer to "Is there a commitment to do X at a certain time" is of the form "Yes" or "No", not "There is an aspiration to do X at some time". It is possible to guess from the items you quote that the answer to my question is probably No, but what I'm asking for is that someone in a position to give an authoritative answer do so, and take responsibility for it. Spectral sequence (talk) 06:24, 11 August 2013 (UTC)

I had a helpful discussion with User:Whatamidoing (WMF) at her talk page which addressed some of these issues. Interestingly, she stated that Flow isn't technically my job, or indeed anyone's in any community-facing role. That seems a mistake, given the nature and extent of the concerns articulated here. However, arising from that was what seemed like an important comment.

Technical question. The only thing that has been firmly decided about this issue is that Flow will store its material directly as HTML5+RDFa rather than as (exclusively) wikitext that has to be transformed into HTML every time someone wants to read the page. How will mathematics markup be stored internally, since it is an extension to HTML? It seems necessary to store it in markup form, in order to make it possible to transfer segment of text containing mathematics from articles into discussions and back into articles. What is planned here? Spectral sequence (talk) 17:21, 12 August 2013 (UTC)

I have to admit I find some of the things being said here alarming, although I don't know how seriously to take them. If it becomes impossible to write mathematical notation on talk pages, I would support a blackout of all Wikipedia pages bearing math category tags (maybe 30,000 articles?) until that crime is rectified. Is there some way to bring that about? If not, then maybe simply shutting down Wikipedia until the problem is fixed could be done. I would also feel a moral duty to make the lives of those responsible unpleasant until they fixed the problem. Michael Hardy (talk) 17:43, 18 August 2013 (UTC)

There is a relevant discussion at mw:Thread:Talk:Flow_Portal/Maths where Jorm (WMF) has stated "I cannot promise that there will be mathematics markeup in normal discussion comments. I can promise that there will be collaborative authoring areas in Topics that will accept and store mathematics output." Spectral sequence (talk) 21:26, 18 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)

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., [23]) --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 [24]. 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 ([25]) 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 ([26], [27], [28]), 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)

Javascript? No way.

Please tell me this isn't Javascript based. I hate javascript pages—they're so slow and clunky, even on a fast computer.—Love, Kelvinsong talk 01:21, 13 August 2013 (UTC)

I don't have any inside knowledge, and Flow is still at an early stage, but everything I have seen so far indicates that the developers working on this are competent and follow best practices. Best practices for web pages include the concept of graceful degradation. See http://james.padolsey.com/javascript/graceful-degradation-still-matters/ and http://www.w3.org/TR/WAI-WEBCONTENT/#gl-new-technologies (checkpoint 6.3) for more details. --Guy Macon (talk) 21:05, 13 August 2013 (UTC)

No, what I mean is that Javascript works for me, and I like to have it in small quantities. However, an infinite scrolling list of Javascript boxes (even a short one) is a recipe for low frame rates, seconds of lag, and a general atmosphere of frustration, even on a fast Linux computer. I'm not enthusiastic about Flow, but if you're going to do it, please keep it at plain HTML and CSS.—Love, Kelvinsong talk 04:06, 14 August 2013 (UTC)

I don't think any of that will happen. the WMF is very much aware that there are still a huge number of users in third-world countries that are still using Pentium II or III processors, 256 or 512 MB of RAM, and 56K modems. Not to mention low-end cellphones or even satellite phones. I fully expect that we will end up with a system that takes full advantage of high-end hardware and fast connections, but will also do all the basics just fine on low-end hardware and slow connections. See http://analytics.blogspot.com/2012/04/global-site-speed-overview-how-fast-are.html --Guy Macon (talk) 06:56, 14 August 2013 (UTC)

I think you'll be pleasantly surprised by the speed we expect Flow to have. Currently, talk pages are monolithic things that must be parsed from wikitext into HTML on every load. Flow doesn't have that problem; Flow discussions will be read (as html) directly out of the cache, and topics will be lazy-loaded as the user scrolls.--Jorm (WMF) (talk) 22:35, 15 August 2013 (UTC)

Perhaps I might repeat my question of 17:21, 12 August 2013 (UTC) which went unanswered at the time. It appears that the only thing that has been firmly decided about Flow is that it will store its material directly as HTML5+RDFa rather than as wikitext that has to be transformed into HTML every time someone wants to read the page. How will mathematics markup be stored internally, since it is not HTML? It seems necessary to store it in markup form, in order to make it possible to transfer segment of text containing mathematics from articles into discussions and back into articles. What is planned here? Spectral sequence (talk) 06:13, 16 August 2013 (UTC)

If Parsoid can figure out how to handle mathematics work in HTML 5, then that's what will happen. The VisualEditor and Parsoid team have their own priorities and I cannot give an estimate as to that timeframe. If Parsoid cannot do this, then mathematics work will have to be done in the scratchpad areas (which will be parsed by the PHP parser).--Jorm (WMF) (talk) 06:43, 16 August 2013 (UTC)

If Flow cannot use mathematical formulas in messages, en.Wikipedia will refuse to use it on article talk pages. (This doesn't prevent implementation, but it does prevent implementation as long as you use the consensual model you've said you are going to use.) — Arthur Rubin (talk) 09:17, 16 August 2013 (UTC)

Thanks to Jorm (WMF) for such a prompt and frank response. It would be interesting to know whether mathematics was simply overlooked in taking that decision, or consciously relegated to the status you describe, but that's not so important right now. What is important is that, as far as I can determine, the requirement to collaborate by copying mathematics over to discussion pages and back into articles is unlikely to be met directly in the near future, and the proposal is to relegate such discussion to a "sandbox". That seems ... sub-optimal. I wonder how mathematics editors are expected to feel about that? Spectral sequence (talk) 16:53, 16 August 2013 (UTC)

Nono, not a "sandbox", he really did mean a "scratchpad", by which he refers to discussions at mw:Subpage scratchpads? and elsewhere. It's a completely different beast from a sandbox - it will hypothetically be embedded in a discussion thread, somewhat like a post-it-note at the side, if that helps clarify it for you. It will be integral to the discussion, and edited in the same place, just using a different subsystem to parse it. (or something). –Quiddity (talk) 18:23, 16 August 2013 (UTC)

I see. So will it (hypothetically) support copy-and-paste or some other equally convenient way of transferring mathematics from articles to discussions and back? And will we (hypothetically) be able to edit the mathematics markup directly? If so, then the new system will be only marginally less convenient (for this purpose) than what we have already. Spectral sequence (talk) 18:30, 16 August 2013 (UTC)

The VE math extension is being worked on at mw:User:Jiabao wu/GSoC 2013 Project Work, and it was testable a few weeks ago at mw:VisualEditor:TestMath (although it seems to be hanging, at the moment). But mw:User:Jiabao wu/GSoC 2013 Project Work/Math Node User Interface seems to be appreciating your comments. So, I would guess that VE will directly support math examples in the near future, and if it doesn't, then the devs know that the fallback editor will need to handle it, well before Flow is deployed to any pages that ever see users needing it (See the moments-ago Timeline update). I'd assume (based on everything I've read) that there is a 0% chance that Flow will arrive at usertalkpages or wikiproject mathematics pages, until <math> is handled in a comparably easy way to how it is currently used. –Quiddity (talk) 19:38, 16 August 2013 (UTC)

How VE handles mathematics and how mathematics is stored in the Flow database are different issues. I would like to believe that you are correct, but to be honest, I would rather we did not "guess" or "assume" things here. Spectral sequence (talk) 20:08, 16 August 2013 (UTC)

Additional. I have been told "The fact is that no decision has actually been made with regard to data storage yet. I know this for a fact because I'm the one whose job it is to decide those things. There is a strong leaning toward HTML5+RDFa from folks in the design and development team, and right now they're prototyping features on a local mediawiki instance with the assumption that we'll have HTML5+RDFa storage, but that doesn't mean things can't change before we write any production code – which nobody has done yet." [29] It would be good to have that promulgated here, so that engagement between contributors and developers (on this board or at some other venue?) could be about what are the possible modes of storing and rendering text with specialist markup, such as mathematics, and what is the best choice to make. I suggest that the ability to transfer material from articles to discussions and back is essential, that it is very important that the transfer be as easy as possible, and that it is highly desirable that it should render the same on all pages (there are regular discussions about how to mark up a tricky piece of mathematics so that it renders well on a variety of browsers and platforms). Presumably there is some date by which that decisions will need to be taken and knowing that would help to structure the engagement. Spectral sequence (talk) 08:04, 17 August 2013 (UTC)

So, I just had a conversation with the lead developer of Parsoid, and he says that support for savinga and rendering <math> via Parsoid (as HTML5/RDF) is already done - there's just no VisualEditor hook for it, which doesn't impact Flow at all. So maybe we can stop worrying about this.--Jorm (WMF) (talk) 18:31, 19 August 2013 (UTC)

Scrolling and lazy-loading

Sorry, Jorm, you said things are Lazy-loaded as the user scrolls. Doesn't that screw over any attempts to use browser-based find tools (usually Ctrl-F)? Will there be an alternate functionality if you can't just wait for the page to load? Adam Cuerden ^(talk) 05:48, 17 August 2013 (UTC)

There's a bigger generic question: how will I be able to search Flow pages at all? If I want to search for an individual statement by an individual editor, but don't know precisely what page it was made on, how can I find it?—Kww(talk) 06:04, 17 August 2013 (UTC)

Well, first, to Kww, you may want to actually spend some time with the prototype, as your answer lies with the search tool that's there.

To Adam, the answer is "yes and no". Lazy-loading of content is done with loading-by-page in what is called a "promise". The first set of items (page) - say 20 Topics - are loaded immediately, and the next 20 are loaded after the user scrolls to, say, item 10. Browser-local search functions (Ctrl-F) will only work for the items that are loaded into the browser (as is the case with all sites that have this functionality) (so yes, that gets broken).

However, Flow gets around that by having a persistent, always available search tool. I think (hope) that you'll be pleased with the way it behaves and how it functions.--Jorm (WMF) (talk) 06:11, 17 August 2013 (UTC)

Is there any way to make Flow's tool override Ctrl-F? Because, if so, the issue becomes minimal. Adam Cuerden ^(talk) 06:13, 17 August 2013 (UTC)

Interesting idea. I'm not sure if we can program accelerator keys that will override browser defaults. I'll see if that's possible.--Jorm (WMF) (talk) 06:14, 17 August 2013 (UTC)

I wouldn't like a script at any one website overriding the default behavior of my browser, which is expected to work in a consistent way every time. I don't think it can be done, but if it can, please don't do it; it's a bad idea (sorry Adam). Find a different accelerator key and put a visible widget on screen for the different search behavior. Diego Moya (talk) 06:59, 17 August 2013 (UTC)

Jorm, the search box on the prototype doesn't do anything, and it isn't clear from its location whether it searches all boards or just the one I am currently looking at. Is there a way to specify a range of boards to do the search on, similar to the prefix based search that's available for talk pages today?—Kww(talk) 06:23, 17 August 2013 (UTC)

That's. . . odd. The search is actually fully functional; are you using Chrome or Firefox?--Jorm (WMF) (talk) 06:26, 17 August 2013 (UTC)

OK, I can see what had happened. I was on a page, and searched for a piece of text that occurred only on that page. You displayed searching graphic, and then displayed the page. You didn't highlight the searched-for text in any way, so I didn't realize that anything had happened at all. When I back out and do a search that occurs in multiple pages, you do display the messages the string occurs in, but once again with no highlighting of the searched-for text. So, how do I do the equivalent of a prefix search? And would you please highlight the searched-for text in the results?—Kww(talk) 06:36, 17 August 2013 (UTC)

Yeah, we should be doing search highlighting. However, the prototype doesn't support it because it's a prototype. I spent about half an hour trying to fake it up and gave up. Search will be context-local (you'll be searching the local Board or Feed, not all Boards. For global search you'll have to use the main search system, but that may not be something that is a launch feature (as goofing with the global search is a pretty tall order and requires resources from outside of the E2 team.)--Jorm (WMF) (talk) 06:51, 17 August 2013 (UTC)

I think you should consider this a must-have feature for anything outside of a sandbox-style test.—Kww(talk) 06:55, 17 August 2013 (UTC)

Hmm. That brings a slightly awkward problem: if the page has, say, 200 posts, we're going to need a way to scroll the page directly to the first instance, then second instance, etc; otherwise, large talk pages will become unusable. Adam Cuerden ^(talk) 06:44, 17 August 2013 (UTC)

Well, the "search" is actually more like a "filter". If a Board has 2000 items, and the search term returns 200 hits, only those 200 items appear on the page while the filter is active. This is actually how the prototype works (I managed to get that part working).--Jorm (WMF) (talk) 06:51, 17 August 2013 (UTC)

By "item" here, do you mean a single post or a whole thread? I'm searching for "regards" and only two posts contain the word, but six posts are displayed. Is this the expected behavior? Diego Moya (talk) 07:09, 17 August 2013 (UTC)

By "item" I mean whole Topic. There's no point in showing you singular comments without context.--Jorm (WMF) (talk) 07:14, 17 August 2013 (UTC)

Well, the problem is that doesn't solve the ctrl-F problem. If a thread has 200 posts, and you want to find one in it, the lazy loading will prevent you from doing so unless there's a method coded. I don't imagine it'd be particularly hard coding, just something to make sure to do. =) Adam Cuerden ^(talk) 07:16, 17 August 2013 (UTC)

Can your software show just the comments containing the searched content, and provide a "parent" link that will expand the topic on demand? This way users can find what they're looking for, and context is still available but only when needed. This is how common forum software implements search, so there's a chance that it's not a bad solution. (Totally unrelated question: do you have an interaction designer -someone related to UX-, or are the inmates running the asylum?) Diego Moya (talk) 07:51, 17 August 2013 (UTC)

Prototype. Not final product. Unlikely to be further expanded, as development has begun. Not easy to do rapid iteration of interaction design in code. I've got 20 years as a designer; I know where the interaction is buttered.--Jorm (WMF) (talk) 07:58, 17 August 2013 (UTC)

As I said, it's something to keep in mind; it may not be first priority, but it'll be needed when it's fully launched. Adam Cuerden ^(talk) 08:46, 17 August 2013 (UTC)

(edit conflict)Ok, glad to hear that. I didn't mean to implement that on the prototype, but as the model for the final product. If you'll do iteration with users where interaction is buttered, that should fix interactions that are problematic. Diego Moya (talk) 08:48, 17 August 2013 (UTC)

You may be interested in this, which is a work in progress but hopes to address some things brought up here.--Jorm (WMF) (talk) 00:33, 19 August 2013 (UTC)

Blocked users

What will blocked users be allowed to do? Appealing blocks is a special workflow, but, if posts are on multiple boards, and the blocked user should be allowed to comment on his own board, if he replies to an existing thread, should his comments be propagated to the other boards that thread is on? Sorry if this is convoluted, but I don't know if it's being considered. — Arthur Rubin (talk) 02:10, 16 August 2013 (UTC)

Arthur Rubin:Funny you should ask this, as I am literally writing up a functional requirements document that discusses this very topic right now (and similar topics). What you're describing is absolutely being considered. To understand the complexities here, the following must be known:

• Topics have an "owner" Board (the Board it was started on)
• Topics can be attached to multiple Boards
• Flow is inter-wiki, and users may be blocked on some projects but not others

The current thinking is this: Blocked users will not be able to interact with Topics that are not started on their own Board. If a Topic on their Board is attached to another Board, their replies will show up there. I think this is okay (and probably a good thing, for reasons I'll explain in a moment) because the blocked user is not "forcing" their comments into other Boards; those Boards have, in a way, invited the user to speak there.

As to why this is a good thing, consider the following (theoretical) "unblock request" scenario:

1. Ankit blocks Barbara. The block notice workflow Topic is started on Barbara's board.
2. Barbara requests an unblock. The block notice workflow Topic advances its stage, and the Topic becomes attached to a second board, one called, say, "Unblock Requests"
3. Admins who subscribe the "Unblock Request" board can now interact with Barbara (asking her questions, etc.) without having to visit her Board directly.

This clearly gets more complicated when you're dealing with inter-wiki conversations. Barbara is blocked on enwiki but not on commons, and can continue to be involved in discussions on commons. Users who read commons-owned Topics on enwiki will continue to see her posts - but Barbara is not interacting on enwiki; she is interacting on commons.

I'm not sure if that makes sense. Please let me know.--Jorm (WMF) (talk) 02:35, 16 August 2013 (UTC)

Multiproject discussions probably aren't worth implementing. There's no reasonable way to manage the interactions of different user-rights on different projects with different rules that span multiple projects. I'd just rip that feature out right now and stop worrying about the problems it causes. We are different projects today, and there's no reason to expect that to stop.—Kww(talk) 03:15, 16 August 2013 (UTC)

I follow Jorm's statement; I'm not sure it's a good policy. It depends on how a thread becomes attached to multiple boards. — Arthur Rubin (talk) 04:26, 16 August 2013 (UTC)

Kww, before you reject the idea as not worth it, I want you to think about an RFC that asked editors here a question like, "Commons frequently deletes images without notifying anybody here, where the image is used and where the editor who uploaded it is active, that the image is even being considered for deletion. The WMF says that it is technologically possible to let all interested editors here see and participate in these deletion discussions, without even needing to go over to Commons and login there. Similarly, discussions that happen over at Meta about the WMF's terms of use or privacy policy could be fed straight to users here. Would you like this feature?"

I'd bet that the response would be very strongly positive to this proposal, even if it means that there are occasional awkward issues with which project's policies apply to which discussion for rarely taken actions (like deletion) . WhatamIdoing (talk) 16:19, 16 August 2013 (UTC)

I'm sure you could come up with proposals that would be embraced by people that didn't think the issue through. Think through the whole damn mess, though: if English Wikipedia and Commons have two different policies over who can edit comments and an editor active on both Commons and English Wikipedia edits comments in a joint discussion, can he be blocked on English Wikipedia? If there's an interaction ban in place between two editors on English Wikipedia but not on Commons, can they both participate in a joint discussion? Whose policies on personal attacks will apply? We are separate communities with separate policies. This is a feature that is an absolute quagmire with no benefit that couldn't be handled by a simple cross-notification bot. It's also the kind of feature that gets in the way of every design decision because it makes it difficult design the configuration flags necessary to adapt the feature to each individual and unique environment. Flow pages should be restricted to single environments.—Kww(talk) 16:31, 16 August 2013 (UTC)

I don't believe it's impossible to do this: As Jorm says, the topic is "owned" by a project. The "owning" project's policies should apply to it. So if the topic is "owned" by Commons, then you participate under Commons' policies, which means that if you're blocked or have a topic-ban at Commons, then you don't participate, but if you've got a topic ban from en.wp, then you're free to participate. This is, in other words, exactly like the rules work right now, only with a technological feature that allows you to read Commons' pages without "physically" going over to Commons to do so. It's still a discussion "at" Commons as far as any policy is concerned. WhatamIdoing (talk) 18:00, 16 August 2013 (UTC)

So if someone wants to evade their restrictions on English Wikipedia, they create the page with Commons ownership and then link English Wikipedia to it? Rendering them immune to sanctions for violating their restrictions on English Wikipedia? No, thanks. It's a bad idea, and should be eliminated from design consideration now.—Kww(talk) 19:45, 16 August 2013 (UTC)

Unless there were some reason why the discussion needed to involve multiple projects (e.g., deletion of images located at Commons but used elsewhere), then I think that we would legitimately consider that to be a violation of the en.wp ban. Furthermore, I can't imagine why any project would tolerate someone creating off-topic or out-of-scope discussions this way. We'd likely handle that just like we handle the steady stream of people asking the English Wikipedia to punish the admins at some other Wikipedia, i.e., by refusing to have the unrelated project involved in it, and backing up that refusal with blocks and bans when necessary. WhatamIdoing (talk) 20:37, 16 August 2013 (UTC)

My one thought about this is that this might almost be too much functionality - too many options and it could easily get confusing. It might be worth prioritising core functionalities, and adding functionalities that should, ideally, be minimally used later, after the problems with the core functionalities are worked out.

If nothing else, a lot of the secondary functionalities probably aren't worth discussing in detail until Flow's core is finished. Once that's done and a few user feedback loops happen, it'll be a lot clearer how such secondary functionalities will be implemented, if they're still on the table (because it's likely some features will later prove to be impractical, or be superseded by some other solution). Adam Cuerden ^(talk) 08:59, 17 August 2013 (UTC)

Thinking it over, the idea that the "home board" of a thread determines whether a user (blocked, unconfirmed, etc.) can contribute is a reasonable approach for a prototype. Until the details of how threads get attached to boards is determined, the question of whether it would be workable remains open. — Arthur Rubin (talk) 17:18, 17 August 2013 (UTC)

Feature requests

I asked at mw:Talk:Flow Portal for details of a couple of features that are missing from the prototype. I was pointed to repeat the questions here after developers came back from Wikimania, so here they are.

• What will be the equivalent of the Table of Contents for all comments in the same "owner Board", showing only the titles of each thread and subthread? Will there be arbitrary (up to five) levels of nested subthreads? Will it be possible to filter threads so that only threads up to sub-level X are visible in the overview? All these features are available and quite handy at current talk pages.
• How will you implement page history? i.e. the log of all changes made to posts in the same owner Board. (This is used among other things to be notified of changes to any post, to search for specific changes made to the conversation by a particular user, and to build diffs of changes as evidence for arbitration). As I understand what I have heard of the proposed system architecture, you're not relying on the current Mediawiki history since each Flow post will count as a separate page. So how do you plan to merge those separate change histories, and is there a way to cache them so that recovering them is efficient? Diego Moya (talk) 06:35, 17 August 2013 (UTC)

• I would like to add the request that the diffs be really, really easy to create and to understand, and of course unforgable. I volunteer at WP:DRN and we really like diffs so that we know exactly who wrote what and when they wrote it. It is really hard for a new editor to figure out how to create diffs, and even when I do it for them, the often have trouble understanding what they are reading. --Guy Macon (talk) 20:31, 17 August 2013 (UTC)

"Is it time for mathematicians to leave Wikipedia?"

This discussion at Wikipedia talk:WikiProject Mathematics is about "Flow". That is the liveliest and most successful of all subject-matter-defined WikiProjects. Michael Hardy (talk) 17:45, 18 August 2013 (UTC)

I hope that no one is going to leave. And I truly believe that everyone at WMF sincerely hopes the same thing that I do. --Tryptofish (talk) 17:53, 18 August 2013 (UTC)

I started that discussion, and it's wider than just Flow, it's about what the editing process will look like after both VE and Flow, and the associated changes, arrive. We are now at a point where for certain groups of contributors, merely "hoping" that things will turn out well are simply not enough. We as contributors need to decide whether or not it is worth engaging with the design and build processes. And to make that decision we need WMF to articulate clear plans, clear priorities and a clear and effective process for user engagement. Spectral sequence (talk) 18:11, 18 August 2013 (UTC)

CamelCase and Paternalism

RecentlyTheFollowingArgumentWasMadeOfCourseWhenYou... Oops. Too much time spent reading about CamelCase. Let me try again. :)

Recently,[30] the following argument was made:

"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!'"

This got me to thinking; that was a real decision made by real people. It should be possible to see whether anyone wanted to retain the bad CamelCase and reject the then-new square brackets. So I asked at Wikipedia:Help desk#WikiArcheology. I suggest that you stop now and read that discussion.

(Checks email, reads latest on FARK.COM...)_{Actual Waiting Simulated. Do Not Attempt.}

Ah, I see that you are back. Interesting, wasn't it? Perhaps Wikipedians are better at deciding what is best for themselves than we thought... :) --Guy Macon (talk) 03:42, 19 August 2013 (UTC)