Talk:Structured Discussions/2013a

Strengths of existing system

I would like to see a section on the main page outlining the strengths of the existing system, and what will be done to preserve them, build on them; or if they will be abandoned, why that is necessary or valuable. (I of course do not deny the major drawbacks, as described.)

One thing that comes to mind is the "talk page stalker" dynamic that so often leads to unexpected spontaneous collaboration. I'm sure there are others, but this one especially comes to mind. Under Flow, will there be an easy way to eavesdrop on, and jump into, conversations involving the people with whom you work closely, admire, etc.? If not, is there a solid reason for thinking that will be OK? Pete F (talk) 21:07, 1 February 2013 (UTC)

Every discussion that someone else is involved in would be tagged with their username, as I see it (just as logs are, if you want to search logs by user). So yes, you could visit the stream of just those interactions. Right now, you can in theory search an individual user's contribs by namespace and see all of their edits to [user talk] pages. In this setup, as I understand it, you would be able to search for all interactions between users involving that user. (effectively the same thing). Sj (talk) 03:13, 3 February 2013 (UTC)

Yes but what's not totally clear is whether you can "subscribe" to the conversations of a user (messages to/from) i.e. "watch the user" (using the bugzilla term): this should be clarified.

In theory it would be even easier with this proposed system, because – as you said – they're all tracked and they wouldn't rely on the fact that they happen on the user talk you're watching.

A requirement for this is that no such a thing as private messages/"notifications" exist. This is very important, and another thing that should be highlighted in the document.

Kaldari said that only non-persistent messages are going to be private notifications, for instance "page A has been linked from page B" which adds nothing to page B's history; but this is not very clear/well defined in the document. Nemo 09:12, 3 February 2013 (UTC)

I'd like to clarify the things I'm interested in here. The order of these is significant, it goes from most general to most specific:

1. The people undertaking a project to replace/upgrade a major software feature should carefully think through (among other things) the strengths of the existing feature, and whether or not they can be preserved.
2. The people undertaking the project should put that analysis on display in a clear way (i.e., it should not be necessary for the reader/community member to dig through various wiki pages to learn about the fundamental design goals and the fundamental design challenges).
3. Talk page stalking: probably too specific for this discussion; it was meant only as an example. (However, it may be worth noting that even after these explanations, I'm having a hard time picturing how, as an end user, information about my friends' edits and notes left for my friends would be presented to me.) Pete F (talk) 15:53, 4 February 2013 (UTC)

Pete, the monthly status says «Mid-month saw Kim Schoonover begin user research regarding how user-to-user talk pages are handled», so maybe by digging wikis, google docs, etherpads and mailing lists enough you may find the "strengths of existing system" documented somewhere. Nemo 14:46, 4 February 2013 (UTC)

Yes, you will be able to "talk page stalk" as it were. Even better, actually.

And I'd argue that there are no strengths of the existing system, only interesting work arounds for its flaws. Jorm (WMF) (talk) 19:43, 6 February 2013 (UTC)

What is interesting or valuable about the workarounds? What do they reveal about how people prefer to collaborate? Knowing the way you work, I am sure you've asked questions like this, but I think your thinking on this needs to be on prominent display if community buy-in is desired. I'm not looking for answers here in discussion -- my point is that the description of the project needs to put this stuff on display, or nobody outside the core group working on the feature will understand or fully buy into its value, nobody outside a core group will be in a position to offer useful input along the way. I am pretty sure this kind of communication is the key to getting genuine community buy-in in the long run.

An example of the kind of overview/conversation-starter that works: http://lists.wikimedia.org/pipermail/wikimediaannounce-l/2011-September/000238.html and a helpful evaluation of what came before: meta:Talk:Terms_of_use#Reasons_for_the_New_Terms_of_Use Pete F (talk) 17:53, 9 February 2013 (UTC)

One of the things from the bare-wiki discussion method that I miss in LQT is the ability to fully edit other's posts, specifically signatures* and dates. I do this quite a bit when organizing old talk pages, with threads in incorrect pages, incorrect order, unsigned, unmerged, etc. Forgery needs not be a concern since the whole edit history is available, and small marks can be added to make it clear the date or signature have been edited, just like LQT currently marks that the content of a post has been edited.

* In LQT, a user can edit their own signature if they edit the post after it's first saved, but editing others' sigs would be a potentially useful feature, as described above. Dates can't be edited by anyone, apparently. Waldir (talk) 20:36, 17 February 2013 (UTC)

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

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

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

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

Absolutely valid point. With the current system I leave a message on someones talk page and add it to my watchlist to see if he responds. Often the initial question is solved but a very similar follow-up question by another editor is posted (but in a new section). If I had not watched the whole talk page (and I probably won't do this with the possibilities of the new system) I'd never know about this new question, which may be enlightening for me or easy for me to answer. Patrick87 (talk) 19:15, 16 May 2013 (UTC)

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

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

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

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

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

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

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

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

Migration

On some places Flow is advertised as following LQT. So I would expect that there will be some kind of migration from LQT to Flow? DaSch (talk) 13:50, 6 February 2013 (UTC)

We are hoping that this will be able to be done but at this point in time we have not scoped work regarding a migration path.

I can't guarantee this, but I assume that a migration path will exist. Jorm (WMF) (talk) 19:42, 6 February 2013 (UTC)

Migrating from the current (bare-wikitext) system should also be possible. I've outlined the rationale and use cases in another post. Waldir (talk) 20:39, 17 February 2013 (UTC)

Is anyone in the process of responding?

It is occasionally useful to know if anyone is in the process of typing out a response to a comment. Also, it could sometimes be helpful to be able to read what has been typed so far, although many users would probably not want to have public what they haven't sent/saved yet. Perhaps it could be an available option to make both of these things public in Flow. Yair rand (talk) 16:41, 7 February 2013 (UTC)

You mean to avoid edit conflicts? Yeah, I agree that would be useful. ShoeMaker   ( Contributions • Message )   23:48, 16 March 2013 (UTC)

There won't be an issue with edit conflicts. This is a structured messaging system, not a flat file. Edit conflicts disappear. Jorm (WMF) (talk) 23:58, 16 March 2013 (UTC)

Actually, edit conflicts do not disappear; they merely no longer lock, as I noted in the en.Wikipedia discussion.

If comment A is edited while comment B (to comment A) is written, there is a conceptual edit conflict; under FLOW, it won't lock, but comment B will no longer be responding to the current comment A. Arthur Rubin ^en.Wiki (talk^en.Wiki) 03:35, 2 July 2013 (UTC)

Of course, if comment A is edited after comment B is written, we have the same disconnect under FLOW as at present. It's considered "bad form" to edit comments with replies, I was just saying above that we will still have edit conflicts; they just won't block. Arthur Rubin ^en.Wiki (talk^en.Wiki) 06:25, 4 July 2013 (UTC)

Response to Quora question

User:Jorm (WMF) asked on Quora: What do you find confusing about Wikipedia's discussion systems? I'm moving my answer here so it's available on the open web.

Since perspective is important on this, here's where I'm coming from: I'm a long time (8 year) heavy user of MediaWiki (many different sites), most notably English Wikipedia; and I do a great deal of work with first-time and developing wiki contributors. So, my comments reflect both my own needs, and my perception of the needs of the people I teach.

Things that don't get discussed much, but are big opportunities for improvement:

• Links (to talk pages, to section headers of talk pages) do not persist through through archiving. Asynchronous, eventualist communication is one of the core strengths of wiki software; this is a major exception. (e.g., I link today to a conversation -- from Twitter, say -- but next month, that link goes nowhere useful.)
• It's difficult to provide context. Outside Wikipedia, most of my collaborative writing is in Google Docs; and the "comment" feature, where you highlight exactly the chunk of text you are talking about, is incredibly useful. I find myself missing the ability to easily point others to exactly what I'm talking about frustrating.
• There's no easy way to "search ahead" when typing somebody's username or other internal link. The HotCat extension has this capability; on Twitter and Facebook, when I type "@" followed by the first few letters of a friend's name, it starts to guess what I mean. A feature like this in MediaWiki would be hugely helpful.
• No "ping" notification. If somebody tags me in Facebook, I am notified; if somebody links my name in a Wikipedia discussion, there's no notification capability.
• Posting diffs can be a really important element of descriptive or persuasive discussion. A quicker and/or more intuitive way to find and paste a diff would be a big help.

Obvious/well-known issues with perceiving what is going on:

• When somebody comments on my user talk, do I reply on my own page or on theirs? There are pros and cons to both.
• When somebody replies to me, I'd like to be notified. "Watch list" is too general, expecting them to tell me on my own user talk is too onerous.
• Same as #2, but cross-wiki: multiple languages, multiple projects.
• Too-specific time stamps result in a whole lot of clutter. It's very, very rare that information about what precise time a comment was left is important to the discussion; if that information is preserved a click away (e.g. in edit history), it could be left out of the display in the context of discussion. Perhaps dynamically: for instance, anything more than 3 hours old suppresses the minutes and seconds, anything than two days old suppresses the time of day.

Obvious/well known issues with adding comments:

• I shouldn't have to think about whether/how much I am indenting…much less need to use markup to do so.
• I shouldn't have to remember to sign.

… I will try to come back and add to this. Thanks for asking! Pete F (talk) 00:45, 15 February 2013 (UTC)

This post is great. Thanks for putting it here, I would've never seen it on Quora. :-) MZMcBride (talk) 07:25, 17 February 2013 (UTC)

The great thing is, that Extension:LiquidThreads already has most of this features and works mostly great, even if some WMF developer think it's experimental, I'm using it almost stable since years! DaSch (talk) 19:39, 17 February 2013 (UTC)

This includes most of the points that annoy me about the current discussion "system" in mediawiki. There are a few things that I would add, though:

• Thread-independent management. Have each thread be a single entity would allow watchlisting only the topics you care about, moving threads to more appropriate pages, and archiving without losing edit history, or, if archival is done via moving the page to preserve the edit history, without having to split the page at unnatural places (e.g. if organizing archives by year, the first posts of a still active thread near the end of the year will have to be copy-pasted back to the current page, losing history; if organizing archives by number of threads, reactivating a prematurely archived thread would require manual copy-paste and loss of history)
• Native support for quoting. This is especially relevant for long messages, since inserting replies below parts of the original post break its flow and make it unclear who is writing what, and quoting templates are a hack that can't, for instance, link reliably to the original post being quoted.
• Features for consensus-making. Wikipedia discussions can get quite big and it would be great to have a way to provide summaries for threads, and voting for individual posts, so people who come across a long discussion don't have to read the whole thing to make sure they're not repeating a point already made (and potentially addressed/resolved), or overlooking important points that should be taken into account. Voting would also make it easier to ignore low-vote posts if one's short on time, and allowing the best posts to be highlighted would even allow some form of summarizing to the thread.
• Automatic signatures. Not only the tildes markup is unintuitive, it's also very easy to forget to sign, even for experienced editors. Waldir (talk) 20:24, 17 February 2013 (UTC)

Some questions

1. What exactly is Flow? Just a quick one-sentence thing 'Flow is ______.' would be quite handy.
2. Why is this here instead of just replacing Flow? Old content would still be in the history and such that way, but where it is now people aren't going to find it, and even if it is a draft, or perhaps especially, more eyes should be good good since the feedback can be rather useful.
3. Who all are the target audience(s) of this page?

Thanks. -— Isarra ༆ 20:41, 31 March 2013 (UTC)

User subscription and permissions

User subscription and permissions says: "Since subscribing to other users can be problematic when taken from a "stalker" perspective, it is recommended that subscribing to another user require permission to be granted." And then a lot of extra features related to this are described.

Nowadays anybody can see the user contributions of anybody without requesting any permission. Why is this different? Is there a problem with stalkers because of this? This feature could be as simple as Twitter's Follow.

If someone misbehaves it's not because of following but because of posting inappropriate content in your user page or the discussions where you participate. After all this years of Wikipedia I guess we have precedents on this and ways to deal with this situation? Qgil-WMF (talk) 23:31, 6 April 2013 (UTC)

Yes, there are social issues related to "Wikistalking". The "request permission" feature was a request from the Ombudsmen committee after they were shown the thinking about Flow earlier in the year.

The "private conversation" part of the feature has gone away. Jorm (WMF) (talk) 03:22, 8 April 2013 (UTC)

Ok, understood. Well, let's see how this works in practice. With or without Flow, stalkers always had and will have all the data to stalk. Qgil (talk) 03:55, 8 April 2013 (UTC)

I am concerned that this can be used by editors to conceal what they are doing or what they are saying, with poeple setting up "walled gardens" where only like minded editors can see what is being said, while stopping oversight from others. This has great potential for abuse by vandals or POV/COI merchants Nigel Ish (talk) 19:09, 24 May 2013 (UTC)

Denying someone permission to follow you doesn't prevent you from reading their conversations, or even subscribing to individual elements on their board (given the model described).

This is a very complex topic and one that isn't finalized by any stretch of the imagination. Jorm (WMF) (talk) 21:26, 25 May 2013 (UTC)

Jorm, I get the impression here that you're writing software based on some horror stories you've heard from English Wikipedians, with perhaps a soupcon of European "privacy" paranoia. You should know better. Subscription approval by itself might be enough to kill acceptance of this tool on English Wikipedia, where we still take openness seriously - I like the general idea of this software but even I would oppose its imposition with subscription approval. It's a bad idea on English Wikipedia, and a ten-times-worse idea on smaller projects with a smaller number of users who really do need to know what each other is doing. Please rethink. Risker (talk) 15:42, 29 June 2013 (UTC)

As Jorm said in April, that feature-concept is a request from the Ombudsmen..

Also, keep in mind that mediawiki is designed to be adaptable (i.e. with options/toggles throughout, with different defaults at any given wiki based on their own needs), and is designed so that it can be used by thousands of wikis, both WMF projects and others. Quiddity (talk) 01:33, 30 June 2013 (UTC)

Yes, I know - which pretty much informed my first sentence. I suppose it depends on what a "subscription" would include - if it includes one's entire feed including all the discussions on all the talk pages one watches whether or not one actually participates, frankly nobody in their right mind would approve any subscription requests. It's another matter when it comes to places where a user actually posts. That discussion absolutely must be publicly available, but I'm not seeing anywhere that describes where that information is available on something comparable to a user contribution page. Risker (talk) 02:01, 30 June 2013 (UTC)

The user subscription example is just that: an example. I wrote it up by request from the Ombudsmen. The version that's out there is bizarrely more transparent than the initial one (which had all sorts of weird privacy-related events).

All discussions are public. Subscribing to a user just makes it easier to track them in a single place (instead of going to watchlist/contribs/etc.). The request was an exploration into the feasibility of openness regarding "followers". It clearly doesn't work when one is tracking a vandal, though, which is why I think it's doomed (I don't know if I wrote about that or not).

Either way: an exploration, nothing more. Jorm (WMF) (talk) 02:24, 1 July 2013 (UTC)

TimeFrame

I'm really excited about this project however I haven't been able to find any dates mentioned anywhere, is there a rough idea of a development timeline yet? redekopmark (talk) 05:12, 16 April 2013 (UTC)

Numbered lists

Often, ad hoc polls are constructed when each user types # Support - ~~~~ or # Oppose - ~~~~ in the appropriate sections, resulting in numbered lists of all the supporters and opposers. Would this (or something similar) be possible in Flow? Ypnypn (talk) 17:08, 2 May 2013 (UTC)

Agreed. I think this is covered under Flow/Use cases. Steven Walling (WMF) • talk 20:22, 2 May 2013 (UTC)

Are you sure? I couldn't find anything like this. Ypnypn (talk) 20:38, 2 May 2013 (UTC)

See all the references to "voting" in that use case page. I know that we don't officially use the v-word for support/oppose discussion, but that's what it's referring to. Steven Walling (WMF) • talk 22:05, 2 May 2013 (UTC)

I see. I don't know why I didn't notice it before. :-) Ypnypn (talk) 00:01, 3 May 2013 (UTC)

Yeah. I use the term "!vote" pretty often. The word "vote" is easier to understand than "enumerated option comment", which is the technical term for what we're talking about. Jorm (WMF) (talk) 18:47, 15 May 2013 (UTC)

A poll widget, with a way to specify default choices for quick submission, would be incredibly useful.

E.g.:

"Create poll" → "Set options" → you type "support" and "oppose", or "keep" and "delete", or other common selections, "comment" could be included as standard → People get a drop-down menu with the options and a text box for reasoning.

The end result looks like any other vote has done in the past, but saves people having to type "* '''Support'''" (etc) all the time. Maybe also an option to set an optional expiry time after which no further posts would be accepted. — Scott • talk 15:38, 28 June 2013 (UTC)

This would not be adapted for discussions with a wide and dynamic range of !voting options such as XfDs (keep, merge, userfy, delete, incubate, redirect, comment, keep and rename, delete and salt, etc), where furthermore users often switch positions, making neat separations undesirable. Even in discussions with clear, stable and desirable separations (support/oppose/neutral for example, as in RFA - indeed perhaps the most stable and delineated process on en.wp, but its uniqueness makes of it a poor case study - and it's considered broken by most commentators so this is telling), many users make a point to qualify their !vote, such as weak oppose, provisional support, etc. There may also be resistance to changes that would seem to emphasize the numerical aspects. Cenarium (talk) 12:38, 29 June 2013 (UTC)

It doesn't have to be a single poll widget. We could have restrictive-widgets that limit options, and open-ended workflow-widgets that allow user-entered values.

And/Or we could adapt the way we write, by placing our qualifications after the keyword, e.g.

• "Support - provisionally as long as squirrels are included..." Quiddity (talk) 01:39, 30 June 2013 (UTC)

As in other aspects, we need to maintain the fullest extent of on-wiki customizability possible. For RFA/RFBs and some RFCs, a fixed format separating !votes along choices with the possibility of entering an optional bolded opening statement (weak support, etc) different from the default may indeed make the trick. However, for others, an all-!votes together approach (no separation) would be preferable, with selection of bolded opening comment (which may be aided by a drop down menu if needs be).

So as you suggest, we'd need two types of poll workflows: one with separation (and default votes) and one without separation, both with customizable bolded opening statements. Workflow admins should be able to tweak workflows as needed for the various ever-changing processes. Cenarium (talk) 16:34, 1 July 2013 (UTC)

Absolutely. Possibly more than 2, or meta-poll-workflows that can be adapted into numerous subtypes. Whatever we decide we need; as malleable as legoblocks. (Hmm, possibly more like the Universal adapter set...?!)

I've added an {anchor} to Jorm's comment at en:Wikipedia_talk:Flow/Archive_1#What_Flow_actually_is as I think it covers a lot of useful ground. Quiddity (talk) 21:07, 1 July 2013 (UTC)

I'm not sure that RFA/RFB actually require separate sections. We do that now solely because that's the only way to count the votes automatically. If Flow can keep a tally (and that seems to be planned), then there's no reason why we would need to have !votes be out of chronological order. WhatamIdoing (talk) 07:52, 2 July 2013 (UTC)

There are advantages to separate sections. If the candidate wants to respond to all the objections, having the Opposes in one place is useful. So too if someone wants to see, "Why did the RfX succeed/fail?" And so on.

Of course, this is a post-facto justification, not the actual reason. But the same applies to most complaints against Flow, VisualEditor, etc, etc, etc... Ypnypn (talk) 04:17, 16 October 2013 (UTC)

You are describing one of the "workflow" tools that we'll be implementing. Jorm (WMF) (talk) 02:17, 1 July 2013 (UTC)

IP editors

Will this be enabled for "anonymous" users? (I just don't want a repeat of the disaster that happened with Echo when no one even thought about IPs.) Ypnypn (talk) 01:03, 3 May 2013 (UTC)

Yes, absolutely. They probably will not get feeds, however - just local boards. Jorm (WMF) (talk) 01:05, 3 May 2013 (UTC)

I'm curious, how will notifying suspected IP vandals work? Will it remain the same, or will there be some changes needed? If there are changes that will need to be made, I figure we should discuss them now, rather than later. Sophus Bie ^(talk) 13:14, 19 May 2013 (UTC)

The same as it works now. A warning is given to the IP user (on their board), they get an Echo notification, and can then go to the board and see it. It is not far removed from the current workflow with User Talk pages. Jorm (WMF) (talk) 19:37, 19 May 2013 (UTC)

Okay, that's good! (I assume you mean "orange bar notification", since IPs don't have Echo.) Sophus Bie ^(talk) 19:48, 19 May 2013 (UTC)

I didn't want to say "Orange Bar" because I'm not sure what the Echo team has planned for a long-term solution. Re-inserting the orange bar for IP users was (as far as I know) a temporary fix. Jorm (WMF) (talk) 19:50, 19 May 2013 (UTC)

I'm still curious why Echo can't word for IP users. Ypnypn (talk) 20:02, 22 May 2013 (UTC)

You'll have to ask the e2 team, I'm afraid. Jorm (WMF) (talk) 21:11, 22 May 2013 (UTC)

Ugh, change

It looks like this more replaces existing talk pages than building on them, which I don't like. It seems as though it ought to be simple enough to build the GUI into a wikitext-based page that we experienced users could edit more comfortably, but evidently it is not.

Will wikitext still work in replies, or will we have to learn a completely different markup to use on talk pages? Is this still italic? TortoiseWrath (talk) 00:42, 5 May 2013 (UTC)

Oh crap, it's not necessary to sign my post with four tildes, it says. *hyperventilating* TortoiseWrath (talk) 00:42, 5 May 2013 (UTC)

...reverse chronological order? Why? I took to Echo from the first minute; this will take a while. TortoiseWrath (talk) 00:43, 5 May 2013 (UTC)

It's reverse chronological order by "last update" time. So the "hot" conversations float to the top. This is actually more natural than having to scroll to the bottom to see a conversation that you're involved in.

There's another reason why this is so: Flow boards and feeds are infinite scrolling. There is no pagination. So if we do a "most recent at the bottom", you'll never see it. Jorm (WMF) (talk) 18:49, 15 May 2013 (UTC)

They use infinite scrolling? That is an interesting design decision. What was the basis? -— Isarra ༆ 23:08, 18 May 2013 (UTC)

Auto-archiving of topics and the ability to localize searches within the corpus of a single board, plus the expected behavior of re-structuring the topic stack based on last-modified timestamps. These things lend themselves to infinite scrolling architectures.

This is actually a very old decision. Jorm (WMF) (talk) 19:36, 19 May 2013 (UTC)

But then you have to scroll to the bottom of that conversation (but not too far, or else then you’re in the middle of the next conversation). Frungi (talk) 03:54, 24 May 2013 (UTC)

…which is more or less completely mitigated by auto-collapsing already-read posts, I see now that I’ve looked at the prototype. So unless there’s an option to never do that, I guess my point is invalid. Frungi (talk) 04:00, 24 May 2013 (UTC)

Note that we are using LiquidThreads here, not Flow. πr² (t • c) 01:09, 3 June 2013 (UTC)

Oh, are you talking about the prototype? Sorry. πr² (t • c) 01:10, 3 June 2013 (UTC)

EN.Wikipedia's use of talk pages and this new FLOW

This doesn't seem compatible with the way that En.Wiki uses talk pages. I noticed this from something posted at enwiki's WhatamIdoing's user talk page.

How does this affect how WikiProjects are tagged onto talk pages, and how history attribution is also tagged onto talk pages? These wouldn't be discussions, but metadata for the article itself (like previous deletion nominations). If this were implemented, then it seems that each page should also have a metadata page for containing such information.

-- 65.94.76.126 22:21, 7 May 2013 (UTC)

Or talk page notices (circular discussion notices, off topic warnings, etc) 65.94.76.126 22:40, 7 May 2013 (UTC)

The demo seems to have a place for an introduction, which can hold this kind of stuff. Ypnypn (talk) 19:48, 9 May 2013 (UTC)

Yes, there will be a "header" section that will be editable and allow for tags and categories. Jorm (WMF) (talk) 18:45, 15 May 2013 (UTC)

The whole concept seems to be based on wrong assumptions

When I came to Flow Portal I wondered. When reading the first two of the eye-catching headlines I was literally shaking my head and was just thinking "No! What's going wrong here?".

"Users expect a modern and intuitive discussion interface."

No they don't! I (as a user) always loved Wikipedias concept of talk pages which is unique and unbeatable in it's simplicity. You write what you mean and it just works. No need for a blown-up messaging interface, just pure Wikitext. For their purpose the ucrrent talk pages are a perfect match.

"Users are surprised by the cultural norms of the community."

Oh yes, they are! And it might be even a bit confusing in the beginning. But the longer one is contributing to Wikipedia the more one appreciates them. The "cultural norms" are a fundamental aspect of the Community. The fact that you can call it cultural norms should be enough to know that we have something great going. Who else ("normal" discussion forums, etc.) can claim to have an own subculture?

Talk pages made Wikipedia what it is today. The whole threaded mess you're planning will ruin it for everybody. Patrick87 (talk) 23:14, 15 May 2013 (UTC)

So, in order:

• "No they don't! I (as a user) always loved Wikipedias concept of talk pages which is unique and unbeatable in it's simplicity. You write what you mean and it just works. No need for a blown-up messaging interface, just pure Wikitext. For their purpose the ucrrent talk pages are a perfect match."

  I totally appreciate this; I enjoy the customisable elements of wikimarkup, and of talkpages as they stand at the moment. But it's worth appreciating that what a single user needs, be it me or you, is not a good predictor for what is needed overall: this is particularly the case when we're having the conversation in quasi-wikimarkup, on a wiki, between community members. By definition, we've limited the conversation to people who can handle and enjoy handling wikimarkup (or enjoy the things that come with it, anyway). For a look at how non-Wikimedians handle and approach wikimarkup and talkpages as they stand at the moment, check out the user tests we ran.

• "The "cultural norms" are a fundamental aspect of the Community. The fact that you can call it cultural norms should be enough to know that we have something great going. Who else ("normal" discussion forums, etc.) can claim to have an own subculture?"

  Also agreed, on the first point; cultural norms are a fundamental aspect. And they're fantastic, most of the time - but as you say, they're confusing at the beginning. It's challenging to get to grips with a site that has 10+ years worth of rules, norms and conventions. What we should be doing is going "okay, this is something people need to get to grips with" and helping them do so, not by reducing the complexity of the community, necessarily, but by reducing the number of other things they have to care about. Complexities around messaging - a communications mechanism for getting help with cultural norms, and understanding them - is an "other thing". It's something else that they have to handle while also getting to grips with policy, our internal slang or conventions, etc, etc. I don't think anyone is saying our culture needs correction: we're saying that we can help people best get to grips with that culture by reducing complexity elsewhere. Less complexity means less time spent figuring out messaging means more time to dedicate to culture, and having conversations about it, and understanding your way around the projects.

  As an aside, actually a lot of discussion venues and communities on the internet have a distinct subculture. Culture is, largely, a distinct way of representing and classifying experiences and elements through symbols, be those symbols slang, internal terminology, or attitudes. A lot of places on the net have this; just from the ones I'm involved in I can point you to b3ta and reddit, for example, which definitely demonstrate features of subcultures. It's not something specific to Wikipedia - and it's not something our talkpages have enabled. Our talkpages and their limitations have just been a vector for some elements of it to develop. Okeyes (WMF) (talk) 23:29, 15 May 2013 (UTC)

I don't know if you are right. Our talk pages are not necessary for a subculture to emerge – but I'm quite sure that they were an important factor in how our subculture actually looks.

Assume threaded discussion like they are on this page: They are boring. Only text, hard to read in my opinion, absolutely impersonal. Is this what you want a discussion on your talk page to be? Impersonal? It might be efficient for pure discussion (however I'm not even sure about that) but besides that it's even worse than classical forums where you have smileys and avatars to add something personal to your posts (but I don't thing this would be suitable to Wikipedia either).

If you're talking about user tests: Did you run tests on the new system you want to implement? I'd volunteer as a test candidate ;). To already share some of my frustration on threaded discussion (this is basically the first time I get in touch with LiquidThreads):

• I feel like a dumb beginner that is surfing the internet for the first time right now. I don't find the new posts (they are always hidden because they are too deeply nested).
• After reading new posts via the "you have new messages" link I still seem to have new messages, which I don't find though. Actually I forgot to click "mark read" so it probably still were the old messages (although I read them already twice: once on the new messages tab and once in the thread after somehow finding the correct thread again andclicking the "show N messages" link a few times).
• At the same time I'm not quite sure on which thread I'm actually replying (the new messages tab is just too confusing). Where is the direct link with the content just plain in front of me? Right now I'm missing my watchlist sadly.
• Just a few seconds ago I did a very bad error: I scrolled the page. I needed propaply 30 seconds to find the edit field again. It was somewhere "arbitrarily" hidden between a flood of posts.

Edit: It's ridiculous – I'm adding a reply but I don't see it. The replied message is still marked as new however. Where is this anywhere near user friendly? I'm considering myself very skilled regarding anything technical but I'm totally struggling with this LiquidThreads-thing. Patrick87 (talk) 00:19, 16 May 2013 (UTC)

Extension:LiquidThreads version 2.0 is a circa 2010 extension, which has ben discontinued. Its usage on the talkpage here (Talk:Flow Portal), is painful, and confusing, and you should pay no attention to it. Flow is a completely different code-base/project, that takes into account the lessons learned whilst creating LiquidThreads.

See Flow Portal/Interactive Prototype (IMPORTANT: Read the first introductory sentences, before clicking the "Open ..." link) for a demonstration of the rough draft of how Flow might work. Note that there's a specific subpage for feedback about that prototype, so don't just append your feedback to this thread ;) Quiddity (talk) 00:57, 16 May 2013 (UTC)

As opposed to...the images that characterise so many discussions on AN/I and talkpages?

And, user tests on LiquidThreads are unlikely to be helpful because LiquidThreads is not what we're implementing. Okeyes (WMF) (talk) 18:45, 6 June 2013 (UTC)

I assume you were responding to me (after three whole weeks!)?

Yes, I think talk pages are much more colorful right now. It's the simple things that make the community worthwhile: Welcome messages, customized signatures, smileys, barnstars, a huge amount of templates to choose from for all imaginable use cases, etc, etc. Even a deletion notice template adds something to a talk pages uniqueness.

Threaded discussion as proposed by FLOW strips out most of the personality of talk pages, making every comment look exactly like the previous. This might actually increase efficiency of discussions (in theory) but could be detrimental for the community needs, resulting in people being bored by discussions, therefore even reducing efficiency (in practice).

As to the LiquidThreads part: Yes, this was already made clear three weeks ago. Three weeks ago was also the time when Brandon first visibly announced FLOW yelling out: There will be FLOW, the threaded discussion system of the future!

Back then it was much more unclear how it will look, therefore I posted my impressions with the other threaded discussion system I knew by then, namely LiquidThreads, to voice my concerns with threaded discussion in general. I'm sure if you think of it you will realize that most of my points are also valid for FLOW. Patrick87 (talk) 20:17, 6 June 2013 (UTC)

It's still unclear what Flow will look like. For all we know, every post will have a different color so you can tell them apart, and every post will have the option of adding a dozen pictures and setting every other word to blink automatically. You're making a lot of completely unwarranted assumptions about what will happen.

Even your assumption that templates won't work is just an assumption. There are limitations in the server set up (which Flow doesn't have any control over) that might make templates impossible. But that's not actually a definite problem at this stage; it's just a possible concern. Even if it's a problem, there's no rule that we can't create a substitute that will achieve the same end but not technically be "a template". The only thing that's been decided about templates is that they will not be supported in signatures, which you might have noticed is already banned by policy, so this represents no change in practice. WhatamIdoing (talk) 19:36, 7 June 2013 (UTC)

Read the discussions more closely (also those on en:WP:VP) and you'll notice that most of my "assumptions" are actually based on design considerations already made by WMF. They are not put into stone yet but are likely to be implemented this way.

If we're not allowed to talk about the things supposed to happen as you propose, we'd have to wait for the final product to be ready and discuss then. I think you agree that this is nonsense. Patrick87 (talk) 20:00, 7 June 2013 (UTC)

The fact that the WMF has a concern about templates does not mean that colorful welcoming messages will be impossible. If you want colorful welcoming messages, then say so: someone will figure out a way to make it happen. That method may not involve what we currently call "a template", but there has never been any assumption that these sorts of communication will stop.

In fact, if you look at Flow Portal/Use cases#User talk namespace, you will see that a large proportion of the things that Flow will support are things done currently with templates. Supporting these kinds of messages is in the official plan. The specific method of support might not be exactly what you're used to, but there will be a way to make these things (e.g., a welcoming message, a block notice, a newsletter) happen. WhatamIdoing (talk) 22:27, 8 June 2013 (UTC)

You seem to be of the "relax, everything will be fine"-fraction. That's fine. I can live with that.

But please also accept, that I'm used to be a little more discerning regarding such fundamental changes. I don't question the fact that many things will be possible one way or another. But I want to make sure that development is going into the right direction so there won't be a bad awakening when FLOW is deployed.

The link you gave is an analysis of current talk pages. It's not a feature list of FLOW! It's not sure what will get into the final FLOW and how it will look. Patrick87 (talk) 23:09, 8 June 2013 (UTC)

If you interpret "Flow will have to support [this]" and "This is a primary use-case for Flow" and "They have to be handled through Flow" as meaning "Eh, I think we can ignore these things, because nobody needs them", then I don't think that we're speaking the same language. WhatamIdoing (talk) 15:34, 9 June 2013 (UTC)

Patrick, speaking as the person who wrote that document: it's a set of use cases. Things that users do that we have to support. By definition it exists so we can have a list of things that the new software has to include, either directly or by finding a new way to address the underlying user need. Okeyes (WMF) (talk) 17:38, 10 June 2013 (UTC)

What about the use cases that could pop up in the future? Wikitext, in its simplicity, is extremly flexible. This thing seems instead to lock people in a predetermined structure. It's terrible. Cyclopia (talk) 20:37, 15 July 2013 (UTC)

We will be designing all the workflows, using the features that the devs create (including features that we request). They're just making the lego-blocks, and it will be up to us to create the structures from those blocks. See Flow Portal/Architecture#Big Ideas (old and informal, but gets to the point), and Flow Portal/Workflow Description Module, and also the comments at Talk:Structured Discussions/2013a#c-Quiddity-2013-07-15T05:32:00.000Z-Risker-2013-07-15T05:13:00.000Z, and Jorm's comment at en.wiki (which I added an anchor to) w:Wikipedia talk:Flow#What Flow actually is, which gives a few more details. Quiddity (talk) 01:56, 16 July 2013 (UTC)

Accessibility: JavaScript, screen readers, slow connections, etc.

I have a couple of accessibility concerns.

First: Users, for myriad reasons, such as ancient hardware or non first-world connections, often disable JavaScript. (Looking at the discussion at en:Wikipedia_talk:Notifications/New_message_indicator#The_bigger_issue_here:_Javascript, I can count at least six frequent editors whom this will affect.) I can say that, while this page is not impossible to use with JavaScript disabled, it is nearly unreadable. Every section displays as one undifferentiated blob of text. Nevermind, this is LiquidThreads, not Flow.

Furthermore, I worry about blind users with screen readers; from what I've seen, they have had challenges using some of the recently rolled-out changes, and it would be depressing if Flow didn't work properly for them.

Lastly, I worry that this will affect users with slow connections. Wikipedia is used throughout the world, but it is my understanding that broadband connections are only generally available in non-rural parts of North America, Europe, and Asia. Sophus Bie ^(talk) 13:42, 19 May 2013 (UTC)

By "this page" do you mean this talk page, Talk:Flow Portal? This page is using Extension:LiquidThreads, not Flow. (I don't think a deployable version of Flow exists yet.) Your concerns are good ones, though – I too worry about how usable Flow will be without JS.

I had some fun a while back putting together CSS to make LiquidThreads look nice without the use of JavaScript; see w:User:PartTimeGnome/lqt.css. The format is of my own design – it doesn't look anything like the format you get with JavaScript enabled. This is only for people who keep JavaScript disabled; if JS is enabled my formatting will conflict with the normal formatting added by JavaScript and look thoroughly wrong.

Standard disclaimer: I've only tested this CSS in single browser; it might not work for you. I'm pretty sure some bits will look different in Internet Explorer, though I hope the appearance would still be better than it would be without it. PartTimeGnome (talk | contribs) 17:11, 19 May 2013 (UTC)

I tried out that CSS; it looks great! ( Using en:Iceweasel under en:Debian, if you're curious.) Suddenly, I can read everything without straining! :D Sophus Bie ^(talk) 19:53, 19 May 2013 (UTC)

Hi everyone, I have some questions :)

1. will there be a fallback skin for users who do not have Javascript enabled? I know a lot of them who complained about new features because they are more and more depending on scripts - and I loved Wikipedia for the utmost waiver of Javascript.
2. I did not understand the project pages exactly - is there the possibility to subscribe only a user's board without receiving his contributions on other pages? I just want to follow the activities on his board (= talk page) just as watching it at present.
3. A big problem will be the rights management. I'm sure there will be massive protest because users can not edit posts of other users. It is possible that an user only wants to do a spelling correction in another post, or an user wants to remove a personal attack. Also, there is a problem with "work lists" started in discussions, for example if somebody wants to mark a task another one started as done.

Please excuse my English :) IW (talk) 18:36, 19 May 2013 (UTC)

1) There will almost certainly be a fallback (though it probably won't be a skin - in mediawiki parlance, a "skin" is a very specific kind of thing). I cannot promise that the experience of interacting with the system will not be painful if you don't have javascript enabled - and it may very well be that you will not be able to edit or add comments without it (given our dependance on the VisualEditor). However, the best effort will be made.

2) That is the "minimal" case for subscribing to a user, perhaps. If we look at the maximal case of subscribing to a user, the following things could be important:

1. New topics started on their board
2. New topics that they start on other boards
3. Topics they respond to in other boards
4. Edits they make to articles
5. Workflow discussions they start or get involved in (AFD, RFA, etc.)

As we go forward, we'll probably have to create a system whereby you, as a user, can have more fine-grained control over your subscriptions like this.

3) Rights management is an on-going discussion. We knew that restricting comment edit would be a Thing. But there are several routes to achieving solutions that are acceptable to the use cases we've identified.

One thing I can tell you is that we are planning for the idea of a "collaborative" post flag, which would allow for multiple people to edit it. Jorm (WMF) (talk) 19:34, 19 May 2013 (UTC)

That is the most terrifying thing I have heard this week. Being unable to "edit or add comments" is tantamount to being forcibly en:WP:retired. I don't want to leave the project, but that would force me to, since I'd be unable to participate in the community at large.

I hope no one minds that I merged these two threads. They seemed to belong together, but I couldn’t find any documented etiquette for merging. Sophus Bie ^(talk) 20:06, 19 May 2013 (UTC)

Yeah. I wish I could comment more about the non-javascript comment-adding part. This is really tied up in our VisualEditor functionality (which is Javascript only). I can see a case where we allow some commenting in "standard" edit modes but with a significantly restricted list of available wikitext (this is also dependent upon the parse). Honestly, it is too early for me to make realistic predictions about this.

(As far as merging threads goes, this is MediaWiki.org. It's like the wild west up in here, and BOLDness is appreciated.) Jorm (WMF) (talk) 20:30, 19 May 2013 (UTC)

I still don't get why your're clinging to the VisualEditor when it's clear it comes with a huge amount of compatibility problems on it's back.

Why not sticking to the "good old" Wikitext or something compatible as a base and fix the Visual Editor to support all features? Then one could always offer both: The nice-and-shiny VisualEditor for all people with JavaScript and/or a reluctance towards source code; the lightweight WikiEditor for people without JavaScript and/or a preference towards markup. Patrick87 (talk) 20:47, 19 May 2013 (UTC)

The answer, as I've said before, is that it may not be technically feasible for us to do so. Since this is a fairly large design constraint, we have to account for it in the design (and assume the worst case).

Regardless, I highly doubt that the comment editor will support any more than the most rudimentary of wikitext. Jorm (WMF) (talk) 20:59, 19 May 2013 (UTC)

I’m not sure if I’m understanding everything right here and I must say that I’m worried that there will be no way for taking part in discussions in the future anymore, just because it shall not be "technically feasible" that every user can take part like it is up to now. If it is not feasible that every user can take part on the projects and with new features, then it is better that the new features will never get live because then they make things worse. I really don’t understand that. You wrote also that there will be a fallback, but I don’t understand how it’s supposed to be, if it could be not possible to edit talk pages anymore (if I understood that right).

Now to VisualEditor: It’s AFAIK a feature that is supposed to be added optionally to the now-being system, but not replacing it in any way. So, the standard will be wikitext like now and if you want you can enable VE. Is that right? Because I can’t imagine in any way a new feature that is only accessible with JS to replace a system like normal wikitext, as the wikitext is compatible and accessible to everyone, and the new system isn’t. I think that I will not be around anymore, if it will come to that there will be no way to edit anything anymore (because VisualEditor will surely affect every page and not only talk pages). Is it that the foundation aims to get people out that haven’t the right technology for editing or am I understanding everything wrong here? It’s really hard to understand for me what is happening here and why.

All I want is that every new feature that is being developped and that has already been developped and put live, will be and will get accessible to everyone. I don’t know why, but it seems to me that there is not enough energy or drive within the foundation or developers or whatever to put that aim forward (despite the fact that this is not a commercial company who tries to make as much as money with their products but is claims to be a non-profit which I nearly can’t even believe anymore). It is or it should be the most important thing at all for every new developped feature to be accessible and compatible to everyone in a way that doesn’t affect too much, and that it doesn’t produce new errors or problems that wouldn’t be there without it. Everything else shouldn’t be as much important as that. If it doesn’t fulfil this then it should never get implemented. Cause you shouldn’t change a running system that isn’t out of order to make it out of order for a lot of people. Geitost ^diskusjon 16:49, 20 May 2013 (UTC)

I agree with everything Geitost said.

I take Jorm's "may not be technically feasible" comment to mean not technically feasible with the current design. If your design cannot meet the requirements that the current system fulfils, it is a poor design. I know it feels horrible to throw away something you've poured weeks of effort into, but it's better to start afresh on something good than to keep putting effort into a poor design. And your previous effort won't be entirely wasted – you will have learnt valuable lessons that will help make the next design better.

I speak from experience here. A few years ago, my company decided to "modernise" its flagship product. (It used 80×25 text screens and was becoming unsaleable because managers who make purchasing decisions don't like the retro look. Strangely, the people actually using the software liked it!) We spent two years working on a replacement system, which was widely disliked by customers and we found it was "not technically feasible" to make the changes they wanted. So we scrapped two years of work and started again. At the time I thought this was madness; I now think this was one of the best decisions we made. Having learnt from the previous attempt we were able to produce a much better system that can do some really cool things neither of the previous systems could ever have done.

I have no objection to you using JavaScript in ways that make life easier for some editors (like the Visual Editor will), but JavaScript should never be required for any core function. If you use JavaScript for a core function, also provide a non-JS fallback mechanism (even if it is a little clunkier to use).

Like Sophus Bie, if you make the ability to edit or participate in discussions dependent on JavaScript, you will have forcibly retired me. Though perhaps a better word would be blocked – i.e. a technical restriction preventing a user from editing. PartTimeGnome (talk | contribs) 23:24, 20 May 2013 (UTC)

Thanks for your answers. If the system is customizable, it it much better than a rigid one and will perhaps receive more recognition.

I think there are some really good approaches in this new software. For newer editors there are some nice new features like the "Welcome" mode. But I am sure that there will be massive discussions about the things Geitost mentioned above. I can imagine, and that's partially also my optinion, that users will refuse the new system because it is to "Facebook-like".

For minor fixes in articles, I can imagine using the VisualEditor, but I can't imagine writing long articles with this tool. Sometimes, I want to save a written text offline for finishing it later, and sometimes I do the same with discussion posts. The VE will probably not support that. And there are some other points mentioned in the discussions already, so please keep normal wikitext for everyone. Editors who ever used wikitext will be faster and better in using it instead of the VE. I can understand your technical concerns, I know how difficult backward compatibility can be. But wikitext is a feature that is essential for Wikipedia, you will offend everyone if you are removing it.

Regards, IW 17:55, 20 May 2013 (UTC)

I agree, wikitext in discussions is a feature, not a bug. Leucosticte (talk) 08:46, 24 October 2013 (UTC)

Agreed. See the recently-updated FAQ for where we're at currently: Flow Portal/FAQ#Will Flow support wikitext or the VisualEditor? Note that the default on the prototype is wikitext, but if you create an account there, there is the option to use VisualEditor instead. Quiddity (WMF) (talk) 19:23, 24 October 2013 (UTC)

I would say... If you cannot enable making new comments or make it so painful to use discussions without JS that everyone without that leaves, you must not implement Flow. It would seriously harm Wikipedia. I strongly advise you to make the development of a non-JS version that enables discussing the highest priority in the Flow project. If you cannot, you must stop development of Flow. If you cannot, and try to implement the expansion, the Board will most likely stop you anyways. Müdigkeit (talk) 14:33, 5 July 2013 (UTC)

If they are unaware of or willingly ignoring w:en:Unobtrusive JavaScript we can expect the worst. Many many people have already now problems with the extent of JS already used in Wikipedia. My home desktop PC gets JS timeouts every time I am editing a wikidata page f.ex. so am using the company laptop instead. I also believe, that the developpers are unaware and/or are ignoring that even in grown up countries like Germany still today telecom companies offer 192 kps internet and that German Telekom has announced to scale down in future even DSL heavily after 75 GB per month has used up. It's funny how for a couple of years we have heard any promises concerning a bigger involvement of the global south but atm the WMF does anything to close out the global south. I am sure with the VE and with flow we the number of active editors will drop dramatically. --Matthiasb (talk) 21:06, 24 July 2013 (UTC)

And when we are talking about less grown up countries... the impact is even more severe. And now a question directed at the WMF staff responsible for this: Will you do something to make it accessible to everyone without JS or with not very good internet connection, and if you cant, stop development of Flow? Müdigkeit (talk) 22:02, 27 July 2013 (UTC)

Yup, they are definitely planning ways to support editors who don't have javascript, or who use screen-readers, etc. See w:Wikipedia:Flow/FAQ#Will_Flow_support_wikitext_or_use_the_VisualEditor.3F, and other comments that specifically mention "without javascript".

One of the most productive admins at en.wiki is completely blind - they have to support editors like him, or editors with slow connections/computers. The aim is always to support maximum diversity - both people, and their hardware. Quiddity (talk) 08:10, 28 July 2013 (UTC)

Discussion about Flow on EN Wikipedia

Copied from [1] and placed here for notification.

From Flow Portal:

"At first glance, Flow is a next generation discussion system - but that is only one part of it. Flow is actually a rethinking of how we do collaborative work in the projects."

This whole thing worries me. Granted: The current talkpages with complex wiki-markup are very different from many other such systems on the web. However it is also something that I think is a deep-rooted part of Wikipedia culture. Yes, it has it's flaws, but editors in most cases find ways to work around those flaws. I fear that this change will alter the Wikipedia experience completely. I can only hope that the ultimate goal isn't to turn Wikipedia into Facebook. But, well, maybe that's just me and I already got too used to it and imagine an all too dark scenario.... Toshio Yamaguchi (talk) 22:54, 20 May 2013 (UTC)

Flow is too tall

My biggest concern with the interactive prototype (a concern I share with LQT) is that the individual posts/replies are way too tall. The current colon-based wiki discussion system is well suited to a high volume of short posts, which is what usually occurs on wiki talk pages. Flow looks as if it will be more oriented towards fewer but longer posts, more like an online forum.

Facebook handles this quite well, using a compact style for comments which allows many to be seen at once (although the font size is too small for our purposes).

I am worried there will be a large community backlash if discussions will take twice the screen real estate. It is already hard enough to skim posts on very-high-volume discussion pages like w:WP:ANI, and it would become quite frustrating with the proposed Flow layout. This, that and the other (talk) 08:14, 21 May 2013 (UTC)

I agree, having a more compact format is a must. In my opinion, the reason is that the font is too large. If thes were reduced to current ones, it would be much more compact. Also, I proposed deleting the second row for user details, so that saves a bit more space. Bye! NaBUru38 (talk) 13:16, 22 May 2013 (UTC)

+1 for providing some compact format. Helder 20:25, 25 May 2013 (UTC)

I agree as well. For me, ideally, Flow should look almost identically to current talk pages. I think their layout is the only good part about them. Keφr 15:33, 4 June 2013 (UTC)

Compare the original with a modified version. (The arrow, if clicked, would reveal a menu with "Mark abusive", "Delete" (for admins), "Move" (maybe), etc - similar to the [More] of LQT.) Ypnypn (talk) 15:40, 5 June 2013 (UTC)

Better, but I would compact it even further. Something akin to how discussions look like with a script I developed. The "reply" button would be put somewhere where signature links are in this screenshot. Keφr 15:44, 22 June 2013 (UTC)

I think the Prototypes, just like the earlier static-mockup-illustrations, are more for demonstrating the concepts and features and possibilities, rather than for the aesthetics. Software devs tend to make clear and simple models initially, and leave the aesthetic-fine-tuning until later...

Also, CSS means we could potentially have a newcomer-friendly version, with oodles of whitespace and big friendly buttons; versus a compact-power-user-version with dense-as-current-layout (or like reddit, etc) with additional links and features that would overwhelm newcomers (or non-geeks).

UI always has to tread the balance between too-simple and overwhelming-options. (E.g. Firefox's options menu, versus its [about:config]) But web UI has more flexibility... Quiddity (talk) 22:05, 23 June 2013 (UTC)

There are other ways of solving the too-much-scrolling problem. For example, if comments you've previously read are partially collapsed (perhaps like Gmail's threaded messages), then the height of individual unread messages won't be as big of a deal. You won't need a design that crams 1,000 words onto a screen, because you'll only need to see the 50 words that you haven't read yet and enough of the others to see which ones you want to re-read. WhatamIdoing (talk) 06:35, 26 June 2013 (UTC)

Thread layout

Hi, folks! I'm testing the interface at unicorn.wmflabs.org/flow. I think that layout of each each post in a thread is too cluttered. I think that the extra information should be included in pop-ups. But these should be activated on click, not on mouse over. Under the mouse over system, the screen blinks a lot when you move the cursor around, which stressess me. Or at least wait 2-3 seconds with the cursor still before showing the pop-up.

First of all, I dislike the "232206 edits since 7 April 2005 · autoconfirmed" message. It reduces people to those facts, which I really dislike. I'd prefer it to be a pop-up, and it should include the links to the board and contributions as well.

I like that the date is displayed as "7 hours ago" and "4 days ago". But posts older than a week (or two) should be labelled by their actual date. I agree that the Please don't display seconds or time zone, it's unnecessary and make more difficult to read it.

I don't like reading "mark abusing" on each post. I'm sure that it helps newbies, but to me it's depressing. Use an inverted red triangle, an exclammation, or hide it under an "extra options" button. Thanks for the work! NaBUru38 (talk) 13:02, 22 May 2013 (UTC)

This was raised several times already. Yet, there was no official statement ragarding the issue, though. Patrick87 (talk) 15:58, 22 May 2013 (UTC)

There should be a way to undo marking as abusive as I did by accident. Gilderien (talk) 00:09, 2 June 2013 (UTC)

There will be. The whole "abusive" workflow needs deep looking at; I regret including it in the prototype. Jorm (WMF) (talk) 04:21, 2 June 2013 (UTC)

Thread tags

Hi, folks! I think that it's interesting that threads get custom tags. I think that using hashtags like #ThisTag is a bad idea, because it doesn't allow spaces. I think that tags should be separated by commas, for example "one tag, another tag". These tags are private to the user, right?

In my board, there's a "Archived talk" link. What's the criteria for an archived talk? Is it a fixed number of days? I'd prefer a button "archive this thread", so in my board I only see new or pending threads.

Finally, I'd love to configure tags and archiving automatically. There should be a Gmail-like system that allows the user to configure which threads get which tags or which get archived. Thabks! --NaBUru38 (talk) 13:07, 22 May 2013 (UTC)

First, the "Archived talk" link: the purpose of that is to point to your old talk page. The existing User_Talk page would have to go somewhere, right? We don't want to lose that forever. So we archive it off and keep a copy.

Tags are intended to be short and mnemonic. Adding spaces to them feels like, well, another implementation of categories, I think.

The entire tagging infrastructure is definitely still under design. We know that they are essential in order to manage information velocity, but we don't know the exact form they'll take. It's possible that there will be both private and public tags, or maybe the "public tag" concept remains with categories, or one of many other solutions.

Your idea about "automatic tagging" is an interesting one. Let's put that on the pot to simmer. Jorm (WMF) (talk) 21:15, 22 May 2013 (UTC)

As in other areas, I hope that tagging will profit from widespread conventions. FB has just adopted Twitterian hashtags. It behooves WP to do the same. In fact, IWBG if WP if search engines would find tags from all three sources. Lfstevens (talk) 17:52, 25 June 2013 (UTC)

That's the plan, but it probably won't make it into the first iteration of the product. Jorm (WMF) (talk) 02:41, 26 June 2013 (UTC)

Subpage scratchpads?

Will this affect all pages in talk namespaces if it is rolled out Wiki-wide on one of the wikis, or can this be selectively (de-)activated? I know that on English Wikipedia, some people use the talknamespaces to store scratchpad information in subpages, while developing drafts on the subjectspace subpages. -- 65.94.76.126 12:08, 24 May 2013 (UTC)

This is an interesting question. I really can't answer with any authority until we get deeper into development.

I can't imagine that we'd think it a good idea to eliminate scratchpad places. We may actually create special scratchpad places to avoid namespace confusion. Jorm (WMF) (talk) 21:04, 25 May 2013 (UTC)

Would every page acquire a scratch: namespace, as they currently have a talkpagespace and subjectpagespace? scratchpagespace. (this would then create a namespace location to store Template workpages that on English Wikipedia currently reside as subpages) ? 65.94.76.126 22:14, 25 May 2013 (UTC)

I rather like the idea of a Scratch: namespace. I think maybe we'll talk about it.

The problem, though, lies in that we might end up creating a "shadow" discussion zone. Some people who hate Flow (for whatever reason) may decide to only communicate on the Scratchpads. That would be an unfortunate turn of events. Jorm (WMF) (talk) 18:51, 29 May 2013 (UTC)

Should I start laughing? Are you actually aware of what you just said?

If people see the need to avoid Flow, this will be because of limitations of this new discussion system. If flow is thought through properly it will fulfill the needs of all editors, therefore making such workarounds unnecessary.

When you already start mistrusting editors at this point (and it's the editors you're writing Flow for, right?) you probably should stop development of Flow immediately. Patrick87 (talk) 20:22, 29 May 2013 (UTC)

Patrick: are you telling me that every piece of software we work on should serve every possible use case of every possible editor?

Jorm is not saying "a majority of users will ignore Flow". He is not saying "A plurality of users will ignore Flow". He is saying "even if fifty people resort to scratchpads, we have a problem because discussion has now fragmented". I'm finding the lack of good faith you're continuing to show here frankly disappointing. Ironholds (talk) 02:15, 10 June 2013 (UTC)

No, but for most editors. And as the comments on FLOW show, most editors are concerned with the way FLOW might constrain editing.

I see your point that it might not be a "majority" of users resorting to scratchpads. But if Jorm is considering not implementing scratchpads at all because of those who do, he is afraid it could be a notable amount of editors (not just "fifty people" he would probably not be worried about).

Now explain to me: If Jorm is afraid a notable amount of editors could resort to scratchpad discussion — why is this amount of editors not notable enough to redesign FLOW to fit their needs? Patrick87 (talk) 02:55, 10 June 2013 (UTC)

I rather think that something along the lines of English Wikipedia's "talk in article" warning template can be used to warn users of improper use of scratch space. People do that in articles now, and are handled by informing them of the talk page and how to use it. 65.94.76.126 14:53, 31 May 2013 (UTC)

I can't see that happening. People will leave rather than be told how to work together. Personally I think all the problems listed on the main page could be solved much easily; we already have notifications, make a notification if there is a reply in a section you've commented in. Simple. It can't be that hard to make talk pages autosigning, although what about Project pages, where posts may or may not need to be signed? At least now if you want to add a signature you learn how to do so once and then it's sorted. New users are just going to get more confused. Reply button. The en.wiki teahouse already has one which seems to work fine. Sorted. I could honestly see a consensus, at least on enwiki, to oppose this change and if it is forced upon us, people will leave. Gilderien (talk) 23:03, 1 June 2013 (UTC)

People always threaten to leave. They almost never do. In fact, if you wait a couple of months and go back to the loudest complainers, they often can't even tell you what the differences are.

As for the difficulty of autosigning, you've exactly identified the problem: it is hard to make talk pages autosigning because there's currently no way for the software to know whether your change is one of those that needs to be signed or not. Flow will provide that distinction, and autosign all the ones that ought to be signed. WhatamIdoing (talk) 21:11, 5 June 2013 (UTC)

Well, It basically achieves this by prohibiting changes that wouldn't need to be signed at all, so you can hardly call this a feature.

Oh, and when you start comparing Wikipedia to Facebook (see link) I'll leave immediately... No, actually I won't, but Facebook and Flow are (should be) completely different:

• Facebook wants people to be involved in endless, and pointless discussions as long as possible. Quantity but quality!
• Wikipedia needs an efficient discussion system, so basically the opposite. Patrick87 (talk) 21:20, 5 June 2013 (UTC)

Why do you believe that we won't be able to add things that are unsigned? Please go read Flow Portal/Use cases, and pay attention to all that talk about the importance of unsigned stuff like WikiProject banners. Search for the keyword "metadata" on that page: a method of accommodating this need has been planned from the beginning. WhatamIdoing (talk) 15:45, 6 June 2013 (UTC)

I neither said nor implied that we wouldn't be able to add things that are unsigned.

But a default comment will be signed with Flow, and there is nothing to change this behavior. Everything else must go into the unstructured section you are talking about.

So there is no "magic" auto-sign algorithm involved in Flow, just restrictions installed to remove any need of such an algorithm. Patrick87 (talk) 15:52, 6 June 2013 (UTC)

Perhaps you would like to explain what "prohibiting changes that wouldn't need to be signed" means, if it doesn't mean "we wouldn't be able to add things that are unsigned." WhatamIdoing (talk) 19:25, 7 June 2013 (UTC)

I don't understand the difference (since one implies the other), but what I was saying is, that we can't edit the posts of others (e.g. to re-indent, fix some link, etc.) so every edit we can make is posting a comment which automatically gets signed.

Everything else we might post goes into the unstructured edit section where signing isn't necessary. Patrick87 (talk) 19:54, 7 June 2013 (UTC)

You seem to be assuming a lot here. You're assuming that Flow will have an unintuitive, segmented, and restrictive interface. Seeing as Flow doesn't exist yet, it's difficult to say what it will look like and how it will function, but I doubt it will be as you think.

If you wish to make suggestions to the development team, it makes their job a lot easier if you do not work from your assumptions about what the software might end up looking like, but instead explain to them exactly what you want the software to be able and unable to do, in broad general terms. This, that and the other (talk) 01:19, 8 June 2013 (UTC)

The difference is that you will be able to add unsigned material on a talk page—in the unstructured section. You have already been promised the ability to add unsigned material.

There will be much less need to edit other people's comments (e.g., re-indenting), but it is currently planned for at least admins and perhaps other trusted users to be fix problems with comments (although this will be noted, just like it's noted now in the talk page's history). I'm sure that people whose comments have been vandalized (e.g., removing the word not) or wrongly blanked will appreciate this limitation. WhatamIdoing (talk) 22:20, 8 June 2013 (UTC)

I hope that the ability to edit others' comments will be a separate userright that can be given to different usergroups on a per-wiki basis. Ypnypn (talk) 14:11, 10 June 2013 (UTC)

Per the discussion at English Wikipedia, it seems that a scratchspacepage for every talkspacepage/subjectspacepage will be required, since FLOW will not render wikicode the same as the subjectspacepage will, so showing examples of sample revisions to the subjectspacepage will need to be placed onto the scratchspacepage as a FLOW based talkspacepage will just not support such things. 76.65.128.222 08:31, 17 July 2013 (UTC)

That's part of what I was trying to say about Flow. Flow will, at least in Jorm's concept, not be suitable for discussion of article Wikimarkup, and hence not be suitable for article talk pages. Arthur Rubin ^en.Wiki (talk^en.Wiki) 20:40, 19 July 2013 (UTC)

That's not what I've said at all. Please do not spread mis-information while attributing it to me. Jorm (WMF) (talk) 20:51, 19 July 2013 (UTC)

I didn't quote you. I said that your concept of Flow (not allowing editing of Wikimarkup and rendering of all Wikimarkup suitable for articles, including templates) would not be suitable for discussion of Wikimarkup.

Do disagree with the statement that your concept of Flow does not allow editing and rendering of all Wikimarkup, including templates? Arthur Rubin ^en.Wiki (talk^en.Wiki) 22:40, 19 July 2013 (UTC)

I'm sorry, but I'm not going to get into discussions wherein the spirit of my words is corrupted to serve a point which I am not making. Jorm (WMF) (talk) 07:49, 20 July 2013 (UTC)

It's true that you're not making the point that Flow will not be suitable for article talk pages; nor I think that Arthur wanted to attribute that point to you. We are making that point, based on the words you've used to explain what Flow will and won't be able to do. Diego Moya (talk) 09:40, 20 July 2013 (UTC)

I've tried to summarize this issue, over at the end of the w:Wikipedia talk:Flow/Archive 3#Supported Wikitext thread, with a handful of clear examples. Quiddity (talk) 08:13, 28 July 2013 (UTC)

For what it's worth, when the current Flow code "occupies" a talk namespace, /subpages are unaffected. Subject to change, early days, etc. S Page (WMF) (talk) 02:30, 11 October 2013 (UTC)

Existing pages and FLOW

How does this affect existing talk pages, were this to be rolled out? (Talk, talk archives, etc) 65.94.76.126 12:10, 24 May 2013 (UTC)

They will be archived and saved. They will not be parsed into Flow topics and boards (this would be exceptionally difficult to do). Jorm (WMF) (talk) 21:03, 25 May 2013 (UTC)

This will be disruptive. The vast majority of talk pages is very low volume. The few comments they assembled over the years represent a substantial knowledge base. This will effectively archived wholesale. 130.75.103.104 16:18, 16 July 2013 (UTC) 16:06, 16 July 2013 (UTC)

KaiMartin (talk) 16:17, 16 July 2013 (UTC)

How is that any different from the substantial knowledge base already archived in higher-volume pages?

As always, if you're interested in something in the archives, you could re-post it. All you would need to do is say something like "I think this person made a good point eight years ago:" and copy it over. WhatamIdoing (talk) 19:59, 27 July 2013 (UTC)

I don't think "higher-volume pages" were what the IP editor had in mind.

Considering article talk pages, they are one of the most important sources to verify validity of articles for me. If there were any controversial statements in the past, talk pages allow me to quickly identify those and be cautious about those parts of the article.

Talk pages of articles are also a quick way to get an overview of an articles history. What was changed for what reasons? What was missing and what was left out on purpose?

Archiving is actually bad in that this information is more or less lost (or would you dig into archives when quickly scanning an article?). Splitting the old and the new talk page is some sort of history split.

I admit that I can't think of a workable solution of this problem though with the current design of Flow you're intending. And I doubt you liked the design proposals I could think of which would not exhibit these problems... Patrick87 (talk) 21:49, 27 July 2013 (UTC)

Each archived conversation could be stored in a Flow page under the "metadata" or scratchpad section, with and empty "new-storage" Flow threads section. Diego Moya (talk) 17:23, 29 July 2013 (UTC)

> All you would need to do is say something like "I think this person made a good point eight years ago:" and copy it over.

That would be quite difficult in cases where the old discussion used some form of wikitext that is not supported by Flow... Diego Moya (talk) 17:20, 29 July 2013 (UTC)

Ack. In addition it does not address the problem, that archived discussions are out of sight. There is a reason why old low volume talk pages are not automatically archived. KaiMartin (talk) 21:51, 10 August 2013 (UTC)

Talkpagespace using administrative processes

How will this affect talkpagespace using administrative processes? On English Wikipedia, polls/consensus discussions frequently take place on talk pages. These need to be marked closed when a conclusion is reached. (processes such as suggested moves, splits, mergers; or other less regimented discussions, like RFCs)

Also on English Wikipedia, there is something called Articles for Creation, a process that uses the talkpage to store a draft version of an article, which multiple people edit, and isn't a talk thread. And other people outside of AFC also use talkspace to store draft articles, which multiple people edit (there's even a template for marking such things on English Wikipedia), will this still be possible with a FLOW rollout? 65.94.76.126 22:20, 25 May 2013 (UTC)

As well, some of these processes have malformed structure, which other editors then go about to correct, and use templates as part of the structure. Since other editors need to fix the templates, it would mean editing someone else's contribution. (as well as remove them to close marked discussions)

Is this still possible in FLOW, or does a separate second talkspace need to be added for these? 65.94.76.126 22:25, 25 May 2013 (UTC)

First off, I want to re-iterate that phase one of Flow is only concerned with "User talk" and user-to-user communication. Process discussions like you've described - "!vote procedures" (pronounced "bang vote", or "not a vote") - they are being thought about but we want to learn what we can about how Flow is used in the real world before we begin thinking very deeply about those kinds of discussions.

That said, we have been thinking about how to handle these discussion types (even though we're not there yet, we have to avoid "painting ourselves into a corner", as it were), so our designs today account for future growth.

Now, what I'm about to say may get too technical, and if so, feel free to ask me to be clearer.

What you're talking about is actually wrapped up heavily in what we are calling the "Workflow Description Language Module". This is a going to be a kind of "scripting" language that will allow local wikis to define workflow processes for themselves (the reason being that the Foundation cannot possibly hope to account for all the myriad workflows that exist on all wikis, and forcing everyone to follow a singular workflow is crazy).

Let's take the example of a "Request for Deletion". Such requests follow a workflow, even if it isn't apparent. Let's say it goes like this (we'll ignore the actual technical events that happen, like "posting templates", as we want to focus on what happens, not how it happens):

1. User finds a page they want deleted
2. User adds the page to the list of "Article Deletion Discussions"
3. The page is marked as being under discussion for deletion
4. A discussion is opened about the page
5. Several editors engage in the discussion, leaving "votes" and/or comments
6. An administrator closes the discussion and makes a decision about to keep or delete.

That's actually a fairly straightforward workflow.

Where people trip up is thinking that the way this workflow is currently handled (with templates and star-indentation and twinkle and so forth) is the only way it could be handled. The current system exists in the way it does simply because there were no better ways to do it.

So let's create one.

With "user to user" talk, we describe a single type of "Flow Object" - a "Discussion Topic". Let's say that Discussion Topics have the following elements:

• A title
• A creator
• Where it was created
• When it was created
• A summary (maybe)
• A "lock state"
• 1 or more Discussion Post objects, which have
  • An author
  • Post text
  • Create date
  • In reply to designator

(Discussions are also workflows, mind you.)

Let's say we want to describe a "Request For Deletion" object, instead. With a different workflow. A Request for Deletion object may have:

• A title
• A creator
• A pointer to the page being discussed
• A reason for the deletion (text, added by the creator)
• A closing summary (at the end)
• A closing admin (at the end)
• A closing state (at the end)
• 0 or more Enumerated Vote Comments, which have:
  • A "vote state" (say, a pulldown that you can select: keep, delete, strong keep, strong delete, merge, comment, etc.)
  • A comment author
  • A short comment (say, 500 characters)

This defines a very simply workflow object for an RFD. Obviously, my example here isn't fully fleshed out and doesn't account for all situations, but I hope I've been illustrative. Local admins will be able to define any number of automatic workflows that will just. . . flow. . . through your feed.

The short answer to your question is "Yes, these things are totally possible with Flow." The long answer is "We're going to make them so much better". Jorm (WMF) (talk) 18:48, 29 May 2013 (UTC)

First of all (please don't take that personal):

I want to re-iterate that phase one of Flow is only concerned with "User talk" and user-to-user communication. — Stop that silly sentence! Everybody knows that there is no point in maintaining different concepts of talk pages for user-to-user discussion in contrast to article discussion or project pages, etc. If you're talking about implementing Flow in user-talk pages, we're talking about Flow being implemented on all talk pages eventually. It doesn't matter in which time frames this will happen, it will happen at some point (unless Flow ends in a disaster and is abolished).

To prevent the disaster from happening we have to discuss usability of Flow for general discussion, independently of the user-talk pages example that you try to keep in mind. And we have to discuss general usability now, before starting with any "phase" at all. The whole "phase" partitioning is eyewash that is detrimental for the goal of a working future discussion system.

Regarding your Workflow concept:

It sounds interesting, but at the same time it sounds as if it was an unnecessary specialization. You're always assuming that we're currently doing things with the old system the way we do them because "there were no better ways to do it". Actually we're able to do all these things because our current system is not specialized at all! When introducing any form of specialization, even if it is thought through very well as you're suggesting, you're removing certain degrees of freedom from the system, since that's the definition of specialization after all. It might simplify certain workflows, but I'm almost sure we'll find certain workflows that will be limited by the new system. Therefore we'll need to develop new workarounds to meet our needs again or adapt the system further. A vicious circle... Patrick87 (talk) 20:15, 29 May 2013 (UTC)

I'm not going to stop using that sentence because that's exactly what is going on here. We are looking at user-to-user discussion in the first set of deployments because user talk pages are the simplest workflows we can encounter. We are planning to develop for that, and then take what we learn from that process - what's good and bad - and apply it to other areas going forward.

I'm not going to lie to you or sugar coat it: You should achieve zen acceptance that talk pages, as they currently exist, are going to disappear. I don't have a time frame for when that is going to happen. I can't tell you what phase 2 (what we focus on next) will be. I have nothing to say other than "user talk is the first phase." It's not eyewash. It's practical planning.

Because of the way this has to be scaffolded, it simply isn't possible to trot out a complete package, covering all bases (which seems to be what you're asking for). The problem is very big and very complex and it has to be broken down into segments in order to be understood. We focus on one part and get the processes and experiences correct for that, while also allowing for future growth, and then move on to the next part.

I'm going to point you to the way that "Unblock requests" are handled on the English Wikipedia for an example of a totally, completely broken workflow that exists in the way it does simply because there are no better tools. Wikitext and templates are rarely the "best" answer to these problems; they're just the tools that are currently available. I'm unsure why you would object to having additional, better tools at your disposal. Jorm (WMF) (talk) 20:33, 29 May 2013 (UTC)

I don't meant that planning in phases was eyewash. I said your so beloved "don't care for that now, that's not part of phase 1" sentence is eyewash. The phases are of no interest to the editors, they are a purely internal thing with importance to only developers.

If you have no idea how to solve certain problems today, that will maybe not matter in phase 1 tomorrow, but will probably be a design issue the day after tomorrow. And I already hear the crying that will happen then: "We can't make it work satisfactory because we didn't thought it through at the beginning, but we are too far in the process to revert the changes so we have to live with it". Don't make that error! Patrick87 (talk) 20:57, 29 May 2013 (UTC)

The two extremes that you need to avoid are:

Ready, Fire!, Aim.

Ready, Aim, Aim, Aim, Aim, Aim, Aim, Aim, Aim... Guy Macon (talk) 01:14, 31 May 2013 (UTC)

One problem is, that user talk pages cannot be dealt with as an isolated problem. The decisions that you make now will foreclose options when it comes to deal with later phases of what you are saying is an inevitable process that all us poor users must simply lie down and accept. We need a system that can deal with the hard things like admin boards or article talk pages, where users have to be able do do the same things that they can do in articles, not something that may work at first but cannot be expanded later on, or is only going to work by removing large amounts of functionality. Nigel Ish (talk) 19:26, 2 June 2013 (UTC)

Clearly this is true, and clearly we're thinking about it. The back end structure as is being designed (there's an architecture document) accounts for this. Jorm (WMF) (talk) 22:11, 2 June 2013 (UTC)

One question regarding the new backend:

You said before, that content will be converted to something similar to HTML when it enters the system. How can we solve things like maintenance categories and the like? Things that can change after the document got first created.

Right now we have the wonderful possibility to change templates afterwards and pages will update to reflect those changes. I assume this will be hard to impossible with the new system? Patrick87 (talk) 22:51, 2 June 2013 (UTC)

Why would you apply a maintenance category to a discussion topic? You can't do that now, with the current technology, so why is this a concern?

As I've said multiple times, there will be an "unstructured" section on each board where things like maintenance templates and categories go. Jorm (WMF) (talk) 00:42, 3 June 2013 (UTC)

Well there are some maintenance templates, that go into a discussion (e.g. edit requests). But I assume most of the cases could actually be solved with the "unstructured" section.

I'm unsure however if this will not add again complexity you're trying to avoid, since an "unstructured" section will be unstructured by definition (the opposite of what you want Flow to be).

Would it be an option to have an unstructured section per topic, that can be easily referenced from within the comments on the thread (I have some sort of "see figure 1" in mind)? Patrick87 (talk) 00:57, 3 June 2013 (UTC)

Some of these workflows happen on talk pages attached to the object for which they are being applied to, unlike deletion requests, in the current usage at any rate. And users keep screwing them up. With a specialized workflow implementation as you suggest using the example of a page deletion process, we'd need to make sure that users actually use these tools, instead of how they currently act, by randomly starting a poll on the talk page, and then someone comes along later, and corrects it by properly registering it into the various processes (such as Requested Moves). If the specialized workflow is not started at the beginning of the discussion, then all that came before is effectively lost. As well, the originating nominator's name will not be attached to the new workflow unless we allow users to attach other user's identities as the "creator", or create a new set of workloads for our administrators (who I assume would have such a right, if the general user does not) 65.94.76.126 14:50, 31 May 2013 (UTC)

Is there a list of the (short- and long-term) targeted workflows? Lfstevens (talk) 17:53, 25 June 2013 (UTC)

There's Flow Portal/Use cases which might be what you are looking for. I don't believe there is a detailed roadmap/timeline, at the moment. There are other interesting/insightful pages linked in the sidebar, though.

(Bear in mind that all the docs are brainstorming-notes, and many are more than a few months old, so they are not definitive at all.) Quiddity (talk) 00:41, 26 June 2013 (UTC)

Unstructured section vs. Unstructured sections (plural!)

I posted a comment regarding this already here but I'm afraid it was overlooked. However I think this could be a very important design decision, so I think it deserves it's own thread.

I was asking if there will be only one unstructured edit section per talk page or if there will be multiple (e.g. per thread). Actually I think it would be useful to have

1. one large unstructured edit section on the top of the page for design purposes (e.g. to put inproject page headers or to customize user talk pages)
2. one unstructured section per thread into which thread specific examples go that require Wikitext and templates to be working.

I'd even go further and not have a completely unstructured design of 2), but allow some sort form of dividing the edit section into distinct "test cases" that can easily be reference from within the discussion and a common section. For example:

• The common section can contain an example of what is discussed in the section, e.g. an existing template, some images, whatever.
• User 1 creates "test case 1" in the unstructured section (that gets a nice border around it, and a label, e.g. "Figure 1" beneath it)
• User 1 writes something like "see [[fig:1]]" (I'm still thinking in Wikitext here, it should be easy to implement something similar in the VisualEditor) in a comment, which get's rendered as a section link with the testcases name as link text.
• User 2 can create a second testcase, independently of what user 1 created, which will get a nice box and label in the not-so -unstructured section, too, which he can easily link to and explain to user 1 why his design might be better.
• Those sections should still be editable by everyone, but I'm quite sure It will be necessary to reference different examples and distinguish between them when there is no possibility to put Wikitext directly into comments. Patrick87 (talk) 16:56, 6 June 2013 (UTC)

I only read this after making my comment above. This is a good way of presenting feedback, and I like the idea.

Maybe it would be simple enough to just use subpages of the talk page (on which Flow is not enabled), which could then be linked to from the main talk page. This, that and the other (talk) 01:22, 8 June 2013 (UTC)

It would be a good thing for each thread to have a "community area" , which structured discussions is anchored to. 76.65.128.222 08:33, 17 July 2013 (UTC)

Your #1 is already planned; see all the stuff about "metadata" in the use cases.

Approximately three ideas have been seriously considered for #2:

1. One anyone-can-edit-just-like-an-article kind of unstructured space per thread.
2. One per comment.
3. A separate 'scratchpad' area, which might not be truly part of the thread (but could be associated with it).

I don't believe that a decision has been made, but since these are the ideas that keep coming up, I assume that it will end up looking like these ideas, or like some combination of these ideas. WhatamIdoing (talk) 23:37, 27 July 2013 (UTC)

I only gave #1 for the sake of completeness, I already knew it was planned.

It was #2 that I actually wanted to point out.

1. Sounds like a good idea in terms of clarity (Wikitext samples neatly arranged at one place in the thread). It would definitely need some sort of sophisticated referencing system, though as I proposed in my initial post (which could easily get too complex in the end, I'm afraid). Otherwise it probably gets impossible to keep track of which Wikitext sample was posted by which editor.
   Completely separating comments and Wikitext samples isn't a good idea for sure.
2. Could quickly get crowded when many Wikitext samples are posted and would therefore need some very well thought-out integration into the thread structure. However this is what gets closest to the current discussion system and might fit our needs best. At the very end I'd prefer Wikitext directly in comments anyway (as many other authors do) but from the statements by Brandon and others I'm afraid that will not happen, so this is possibly our best opportunity.
3. Sounds like a very bad idea. Wikitext samples are needed directly alongside the comments. Further scattering contents of a talk page should be avoided at all cost.

What about offering both, #1 and #2? There would be nice usage scenarios for both of them! Patrick87 (talk) 00:11, 28 July 2013 (UTC)

I support #2. It looks like the most flexible in terms of reusing existing Wikipedia content in order to discuss it, given the constraints of the architecture that was already decided by Brandon. Diego Moya (talk) 17:17, 29 July 2013 (UTC)

The most flexible is probably the scratchpad system, which could be a plain old page rather than anything "inside" Flow. WhatamIdoing (talk) 00:24, 5 August 2013 (UTC)

Sorry, but how is having to visit another page every time I want to look at a Wikitext sample flexible? I hope this is not the way it will be implemented.

Just to make sure: I'm not against scratch-pads. They might have their uses (although I'm not sure if a simple subpage did not do the job as good as dedicated "scratch-pad"). But a discussion needs Wikitext examples directly (or at least nearly directly) in the comment that is referring to them! And on the same page for sure... Patrick87 (talk) 00:43, 5 August 2013 (UTC)

The best solution would be "one scratchpad per comment", shown right above or below it. That model would be the one that best suits our needs, and definitely the most flexible (it subsumes everything that can be done with #3 above, since a separate scratchpad can be created as a separate thread with only one comment).

Of course, if you create one scratchpad per comment, there's no real need to have one comment at all; everything could be done by placing each comment directly at one the nested scratchpads. For some reason, I don't think this is what they have in mind, although it is exactly what we need. Diego Moya (talk) 16:49, 5 August 2013 (UTC)

As long as the list of examples I added at the bottom of the w:Wikipedia_talk:Flow#Supported_Wikitext thread, are supported in either the VisualEditor or the fallback editor, then the whole notion of requiring-scratchpads will be vastly less important. Hopefully a dev (from either VE or Flow) will reply to that listing, after Wikimania. Quiddity (talk) 17:46, 5 August 2013 (UTC)

Who said that you'd have to "visit another page every time I want to look at a Wikitext sample"? It could be displayed on the same page, right there with the comments that it's connected to. WhatamIdoing (talk) 18:54, 10 August 2013 (UTC)

Sorry, maybe we're talking past each other, but in your comment above you mentioned a scratchpad (#3) as a separate thing which "could be associated" (whatever that means, I imagined a link). This would not be a workable solution in my opinion, see my immediate answer on this comment.

As soon as you show the scratchpad directly in the thread this would basically be (#1) from my understanding (e.g. one scratchpad per thread). This would be a possibility, although limited (again see my answer on your original post).

I don't think multiple scratchpads per thread could be shown directly, as this would quickly get very unclear.

Edit: The fact that we're again discussing the exact same things than at the start of the thread is the reason I think the threaded style that is currently intended for Flow (and which will be similar to what Liquid Threads offers us here) is not working well for our discussions. If we had this conversation on a conventional talk page, we'd have all the information in view and I would not have to repeat myself over and over again! Patrick87 (talk) 13:19, 11 August 2013 (UTC)

1. You could associate multiple scratchpads with a single conversation. I was thinking about using the tag structure, but there are probably other ways to do it. Imagine not "we are limited to one scratchpad, and it will always be in this fixed position" but "hey, I just added a scratchpad between these two comments".
2. I have to repeat myself over and over in the existing talk-page structure, too, and information isn't always visible on screen. In fact, this conversation, pasted into my sandbox, is three screenfuls of moderately small type for me. WhatamIdoing (talk) 22:48, 12 August 2013 (UTC)

1. So basically we'd reach (#2) of your comment above (up to one scratchpad "per comment"). Do you think "scratchpads" are really helpful then?
   • I mean, how probable will it be that a single sctatchpad is shared between multiple comments (e.g. the tagging feature)? Will this even be possible technically with reasonable effort?
   • How should those scratchpads be stored in a way to be able to ever find them again to even be able to reuse them? They can't be saved as simple subpages as on current talk pages I assume? Therefore the only place those are accessible will probably be the comment they were posted on?
   • Would it not be much more convenient to have an "add Wikitext area to comment" action directly choosable from the file menu that adds something similar to a scratchpad which is automatically associated with the corresponding comment (but not necessarily reusable)?
2. I better do not ask how much space this thread is taking up for you in Liquid threads then (e.g. this page) and how many pages it would use in the current Flow prototype (which wastes even more space then LQT)...
   Plus I don't know your settings of LQT, but it tends to hide comments, making it even harder to follow the discussion. Something Flow might suffer from, too. Patrick87 (talk) 23:17, 12 August 2013 (UTC)

Actually, "up to one scratchpad per comment" was not what I said. I see no particular reason why you couldn't have a dozen scratchpads associated with a single comment, if that's what you wanted.

Database storage is not something I'd want to speculate on, but the primary difference between a Flow comment and a scratchpad is the storage difference: one is written directly in HTML5, and the other is written in exactly the same wikitext markup that articles are currently stored in. So even if the wikitext area is "inside" the comment, it seems to me that you would still have the Flow comment and the "wikitext area" stored separately, with exactly the same limitations that you hypothesize about being able to find it later (or even greater ones, because if you can tag it separately, then you ought to be able to view it, and therefore to see the URL just for it). WhatamIdoing (talk) 21:00, 16 August 2013 (UTC)

"Actually, "up to one scratchpad per comment" was not what I said. I see no particular reason why you couldn't have a dozen scratchpads associated with a single comment, if that's what you wanted."

Well, then add it to the list of things I said! I don't think this would be a good idea. In fact i think this would be a hell of a mess! I can't imagine a single reason one would need more than (at most) one scratchpad per comment (many comments might need none at all). It will definitely increase clutter to have separate scratchpads in the first place, instead of typing Wikitext directly into the comment. Having even multiple scratchpads will increase clutter exponentially (and render the whole idea of not having Wikitext inside comments useless).

For the second part: You're exactly right (and that's what I said): It will be hard to find a scratchpad for reuse. Therefore I think this is an unnecessarily complicated "feature" that will only be useful in some very rare edge cases.

Therefore my suggestion: Don't add such a tagging feature. Irrevocably attach scratchpads to the comments they were created for. This will a) simplify the user experience; b) won't seriously limit functionality; c) will almost certainly simplify the implementation in the backend.

I'm wondering a little bit what you try to achieve with such a tagging feature for scratchpads in the first place? First you state that Wikitext won't be available inside Flow comments as a design constraint. Then you try to implement some incredibly complicated tagging for some "mysterious" scratchpads, nobody asked for and even I (whom I'm one of the most enthusiastic advocates of the need for Wikitext inside Flow) would not now a single really useful usage scenario for.

Why don't go the simple way and simply allow one Wikitext area at a fixed place per page, thread, and comment? Patrick87 (talk) 22:51, 16 August 2013 (UTC)

I agree with Patrick87. There are potential reasons why one might want more than one wikitext area per comment, but it would only be important if the wikitext was flawed (unclosed tags), so it shouldn't be rendered, anyway. One wikitext area per page (board?), thread, and comment seems the way to go. Arthur Rubin ^en.Wiki (talk^en.Wiki) 16:28, 17 August 2013 (UTC)

RfC on editing other user's article talk page comments with Flow

On the English Wikipedia, Wikipedia:Flow is a page discussing Flow, the planned improvement to the way MediaWiki software handles article talk pages. There is an RfC about how to configure Flow regarding editing other people's article talk page comments. Your input would be welcome. The RfC is at Wikipedia talk:Flow#Request for Comment on editing other user's comments with Flow. Guy Macon (talk) 13:55, 28 June 2013 (UTC)

Wikiformat in threads

I don't know about other fora, but en.Wikipedia _requires_ use of Wikiformat in talk comments, even if a WYSIWYG editor is normally used, so we can discuss which modifications of the format will display properly. This may not apply to user talk pages (although I've found it helpful, at times, to show users on their own talk pages what their edits might look like), but it does apply to article talk pages, and definitely to template talk pages.

Any ideas as to implementation? Arthur Rubin (talk) 04:08, 29 June 2013 (UTC)

Templates are frequently used in discussions indeed, and images also, for example when discussing whether such or such image is appropriate for the article. Cenarium (talk) 04:57, 29 June 2013 (UTC)

Thinking about it, I don't exactly mean "Wikiformat". I mean exactly the same format as used in Wikipedia articles, whether in a WYSIWYG editor (now beta or possibly gamma on en.Wikipedia) or in raw Wikiformat. Arthur Rubin^en (talk^en) 05:02, 29 June 2013 (UTC)

Arthur & Cenarium: Check out the 4th item at Flow Portal/Use cases#Talk namespace, and see the example-edit link. The thread that example-edit is in, en:Talk:GlaxoSmithKline#Sidebar, is a discussion of template content & design!

I agree that the current-documentation isn't describing things perfectly (and the confusing discussions so far on en.wiki made it worse), but the devs definitely understand that this particular workflow is prominent/frequent/important.

There's a lot of brainstorming in the docs, and a lot of the docs contents haven't been updated in months (or were written by non-developers who were helping to brainstorm/document), so the exact wording is often... inexact... If that makes sense. :) Quiddity (talk) 05:51, 29 June 2013 (UTC)

Yet I'm under the impression from the "Avatars" thread and others (see Talk:Structured Discussions/2012#c-Jorm_(WMF)-2013-05-31T16:09:00.000Z-Kephir-2013-05-31T14:45:00.000Z) that templates wouldn't be parsed, at least as planed (even though old LQT can), and that if we want some particular template-like functionality within threads, we'd need to make a specific feature request. It's just impossible, considering the time it takes for bugs to be addressed, and the constant need to tweak, deprecate and renew those templates on short notice. Not including demonstrations, on en.wp there are literally thousands of templates in active use on talk pages in-threads (tens of thousands if we include templates that are little used or deprecated), so even the possibility of putting templates in the header of threads would not work. Just to give a few examples: the series: edit protected, w:Template:EP, ESP, UAA, AIV, RFPP, w:Category:Image with comment templates (291 there), w:Template:User and numerous variants (136 at least, see w:Category:Username internal link templates), plenty of linking templates as well (w:template:bug for an ironic one) and the multitude of citation templates (thousands, often used in comments), of course the thousands of user message templates - see w:Category:User namespace templates and subcategories (warnings, blocking, welcoming, awards, etc), various hiding templates to hide some of the message(s), miscellaneous formatting, workaround and shortcut templates, etc. And it's just thinking about it for a few minutes, the search on wp is down again so I can't refresh my memory.

Not supporting template transclusion is definitely a blocker that even in user talk namespace would fatally disrupt critical user interaction processes, scripts and bots, and the need for flexibility and reactivity excludes a 'just ask over at bugzilla' strategy, which wouldn't work for the varied inline/linking templates anyway. It would monumentally increase the workload for experienced users, mechanically many of them would reduce their involvement, and consequently, it would very badly affect inexperienced users since experienced users would have less time for being helpful to them. It's without a doubt something the community could not accept at any time for any duration (that is, even with the assurance that transclusion might potentially be eventually tentatively supported in some unspecified projected future release). And when I'm talking about the community, I don't mean just the en.wp community, but the whole wikimedia community. Other wikipedias and other projects intensively use templates in-threads as well (to the extent that this has led to 'wars' on commons and meta between competing discussion templates...). Cenarium (talk) 08:40, 29 June 2013 (UTC)

For the sake of clarity, since this has confused some commentators, the template support mentioned at Flow Portal/Use cases is only for the 'metadata' of the thread, i.e. what I called the header of the thread. There is no support for in-threads templates, that is within comments, which is why the example of the unblock template is given as something that would have to be requested as a special feature over at bugzilla. Which in real life is totally unworkable. Cenarium (talk) 09:13, 29 June 2013 (UTC)

Not supporting template transclusion won't actually cause as many problems. For example: DPL bot currently subst's a template that amounts to a typed-out message saying that you linked to a dab page.

Okay, we need those messages. But do we really need that message to be "a template"? Don't we think that we could just have DPL bot leave a message for you without technically using "a template" (directly) to get those words onto your talk page? It would require tweaking the bots, but this seems totally achievable to me.

The unblock template is perhaps more complicated, since it adds a category and some instructions rather than just a message. But I still think that it might be feasible to find a non-template solution for this. For example, what if all block messages had both a "Reply" and a "Request unblock" button, with the latter providing all the support that the template currently does (except without expecting newbies to be able to use a transcluded template properly, since we know that some of them can't)? WhatamIdoing (talk) 10:01, 29 June 2013 (UTC)

I wasn't talking about those templates (many of which should be substituted, and the block template might be redesigned, and would probably need to be redesigned as it needs to add a category to the user talk page, which would end up being added to the thread in any reasonable implementation of threaded comments.) I'm referring to templates which represent what the user may be trying to get into an article.

Basically, any template which might be placed in an article needs to be able to be placed in a comment. Something with scratch spaces might partially solve the problem, but it would significantly reduce usability of Wikipedia. Arthur Rubin^en (talk^en) 10:52, 29 June 2013 (UTC)

Some bots and scripts may possibly be adapted (it would have to be technically feasible, and that script/bot developers be sufficiently motivated). But then how could we (wikipedians) edit the message if it's not in an editable page on wikipedia but hidden in some bot or scipt code ? User message templates are changed quite frequently. And then again, users without the appropriate scripts would have to do everything manually. This would represent a significant disenfranchisement of those, which includes all unregistered users (and also many experienced users who don't find it useful to have plenty of scripts and prefer manually adding the templates). They would either have to do their best to write manually those complicated messages or good alternatives (which often require fetching diffs, article titles, dates, external links, etc), or they would add brief messages inferior in terms of editor guidance, or altogether stop notifying users, which according to wikipedia policy is necessary in various occasions. Even if some specific situations could eventually, at some point in the not too distant future, get covered by feature requests at bugzilla, that would never be reactive enough. We would seriously loose an enormous amount of functionality, even in user talk only.

And for the huge number of manually added inline templates, some of them I mentioned above, the only way to adapt would be to reverse to full manual, which would be a monumental increase in workload. Having to write down the wide variety of linking templates (citations, article, user, template links, helper templates at noticeboards, etc) would be excruciating, users would be discouraged. Let's not imagine what would become of AIV without AIV templates, RFPP without the RFPP templates, RFCs without inline links, TfDs without w:template:t1 and co - all of those templates require regular changes which excludes a bugzilla-mediated update process.

We would no longer be able to easily cite references on talk pages, which is crucial for verifiability discussions. So that we can take into perspective the extent of the loss, let me give as example one single citation template (one of the most used): cite web is transcluded almost 10,000 times in main talk namespace and a bit more than 2000 times in user talk namespace, excluding some sandbox pages. This isn't even the most used inline template on main talk pages, and on user talk pages, User has tens of thousands of transclusions.

And then as Arthur Rubin mentions, we could no longer give in-comment examples of templates when discussing them directly, which happens every day in all talk namespaces, just check out w:Help talk:Citation Style 1 or the thousands of transclusions in talk namespace of the template families infobox, navobox and co. And unlike for some talk page messages where the ability to subst: alone may be sufficient, try to subst one those templates, and then well :) Cenarium (talk) 15:00, 29 June 2013 (UTC)

For the bot question, why not have the bot's message reside in an editable page on Wikipedia? The bot's command then only needs to be changed from "subst this template" to "copy and paste this page". WhatamIdoing (talk) 15:15, 29 June 2013 (UTC)

Then that page could simply be a template. The problem is that it's not simply "copy and paste", the relevant information must be retrieved (username, page, revision, edit, external link, date, log, etc), integrated within the template and ultimately converted in plain wikitext. Mediawiki knows how to convert by subst:ing, bots don't naturally. The bot would have to make the correct replacements, it may be possible, only bot operators would know if this can be done properly - I'm not, but I don't think it's trivial. In theory it is at least for subst:able templates by editing on any page where you can subst then retrieve the wikitext then make the edit, but it looks like a unusable hack to me. Maybe you suggest using another language than mediawiki, but this would require substantial community resources to pull together and relatively few users would have the knowledge for editing those pages.

Still, I would expect that subst: at least be usable in comments. Even so, currently many messages transclude templates, and most often those templates can't be subst:ed (at least without leaving a giant wall of wikitext and likely a few errors), it would be unpractical to translate them in another language, so it's out of question for bots to add them on their own. But it's just for bots, real users would still be left adrift in space, with bugzilla far, far away... Cenarium (talk) 18:08, 29 June 2013 (UTC)

Ironically, I think the trend is to get away from the mediawiki language for simplification purposes, but in the same time this results in loss of function: too complicated things can't be done anymore, even though they remain essential. I think the general approach of Visual Editor of having both the simplified interface and the advanced interface, while noting that not everything can be done with the simplified interface but there's always the advanced interface for that purpose, is best. Ideally Flow should follow the same principles : simplifying without incurring loss of essential function, even if there is an additional desired change in appearance. Outsourcing all complex functionality to developers is just impossible, they already have enough on their plate, we need reactivity and specificity, and it's just not the wiki way. Cenarium (talk) 18:28, 29 June 2013 (UTC)

The unblock template should be done as a Flow workflow:

1. "Initiate Block Workflow"
   1. Provide reason, expiry
   2. User is blocked
2. User gets block notice via Flow
3. Block notice has "Request Unblock" button
4. Clicking that initiates "unblock request" workflow
5. etc. Jorm (WMF) (talk) 02:16, 1 July 2013 (UTC)

en.Wikipedia special considerations

1. The ability of an admin to delete a comment and all child comments with a few clicks.
2. The ability of an admin (or possibly bureaucrat) to rename the "author" of comments when the account is renamed or "vanished" (currently implemented by a rename to Vanished User nnnnnn).

I'm sure I'll think of others. Arthur Rubin^en (talk^en) 05:07, 29 June 2013 (UTC)

Admins should also be able to move threads to other pages in batch (when a talk page is no longer being used). Cenarium (talk) 05:12, 29 June 2013 (UTC)

These are good ideas. WhatamIdoing (talk) 10:02, 29 June 2013 (UTC)

The first point (deleting comments and child comments) falls under "moderation". I'm sad to say that I haven't had a great deal of time to focus on this lately but I've been asking for other things to be deprioritized so that I can.

The second point - renames - is going to have to be remanded to the Stewards once the Great Username Unification occurs. The nice thing here is that once a user is renamed, all their Flow postings will report the rename, and not the name at comment creation (which is what happens now).

As far as moving threads, that's kind of a weird thing. Threads aren't really "owned" by a page - they are "associated" with it. But threads can be associated with several pages, not just the one they were created on. You're really talking about batch association and de-association, which I don't think is a bad idea. Jorm (WMF) (talk) 02:21, 1 July 2013 (UTC)

So the rename user problem is being redone completely, anyway.

We would seriously lose functionality to protect editors if "RevDel" (suppress) wasn't available for the IP (if an editor accidentally edits while logged out).

Although it might lead to some attribution problems, the ability of Admins to change an IP to an editor name would be helpful. Arthur Rubin ^en.Wiki (talk^en.Wiki) 01:00, 2 July 2013 (UTC)

Ideally, the system will warn you before you post anonymously. Jorm (WMF) (talk) 04:31, 2 July 2013 (UTC)

Ideally, it already does. In practice.... Arthur Rubin ^en.Wiki (talk^en.Wiki) 06:20, 4 July 2013 (UTC)

Since there is a header for talk pages, I guess that talk pages would still have an existence as an editable page and could therefore be moved - which would happen mainly when moving the associated page itself. Is this correct ? Then threads would need to be moved/reassociated automatically when the talk page itself is moved. In addition, when deprecating a talk page we would need a way indeed to reassociate threads to another talk page without actually moving the talk page. In that case the talk page would be redirected as well. For coherence, the software should not propose the possibility to create threads when the talk page is redirected and put the talk page in a tracking special page or category if there are threads associated to a redirected talk page. Is this how it is envisaged or in a different way altogether ? This at least is compatible with the current system which would make transition smoother. Cenarium (talk) 22:31, 5 July 2013 (UTC)

You are pretty much spot on here and in your other comment about transclusion. Moving threads from one page to another is simply a matter of creating a new board association.

A page is associated to a board. If the page is moved, it is still associated until the association is broken. But multiple pages can be associated to the same board. So people could read the board from multiple places. Jorm (WMF) (talk) 23:45, 5 July 2013 (UTC)

Warning levels detection

I'd like to let you know, if you don't already, of a system that would necessarily need to be adapted. In order to heed warning levels on user talk pages, all standard warning messages contain hidden text indicating the warning level, that bots and scripts can read from the source talk page. This is critical to wikipedia's anti-vandalism efforts. No detection of last warning level means no escalation of warnings means vandals aren't reported to w:WP:AIV means vandals are not blocked. Cenarium (talk) 17:37, 29 June 2013 (UTC)

So, this is a perfect example of something that Flow will handle and make better. You're describing a "warning" workflow. In this scenario (and I'm throwing cheese around; pseudo-code), a user would initiate a "Vandal" workflow on the user. That workflow would then remain active until manually closed by a privileged user (or maybe expired via time, depending on the level).

Once that workflow was enabled, it wouldn't be able to be "deleted". Bots or other users wouldn't have to search histories or hidden text; they could just query the user's Board for specific workflows (tags) and they'd appear. Additional attempts to initiate the same workflow would bring the existing, working one to the front, and automatically escalate it.

We could even do things like require that the user acknowledge the warnings before they are permitted to continue editing (though that could lead to denial of service attacks). Jorm (WMF) (talk) 02:14, 1 July 2013 (UTC)

What would be a privileged user? The person who posted the warning, or just administrators? And on English Wikipedia, many people who post incorrect warnings never bother to remove them instead they currently say, "sorry, remove it yourself". So, then, wouldn't this flood the administrator's notice board with requests to remove incorrect warnings? 76.65.128.222 02:33, 10 July 2013 (UTC)

Usually, when you design something like this, you make it configurable by the sys admins who are setting it up. "Who gets this privilege?" is a policy question, not a software question. Policies are set by the people who run and use each individual wiki. The software developer is not setting the policy for every single Flow installation in the world.

This isn't "Flow for the English Wikipedia". This isn't even "Flow for WMF projects only". This is "Flow for thousands of wikis". So a business running this might let anyone have this particular privilege. A school might let anyone except students have this privilege. And similarly, each of the WMF projects could choose to have a different system. One might make this function available to admins only; another might make all warnings expire automatically based on time; a third might allow any admin plus the individual user remove warnings; a fourth might allow any autoconfirmed user to have the warning-removal privilege; a fifth might allow anyone at all to remove a warning. WhatamIdoing (talk) 22:26, 10 July 2013 (UTC)

Okay, I'm going to stop you right there, because this theme that the WMF should be creating software intended to be used on "thousands of wikis" keeps cropping up. I thought we all just went through this narrowing focus exercise, didn't we? Where it was determined that the WMF would support the WMF movement? Why are we spending our donor dollars creating software that is being genericized instead of customized for our projects?

I hold Jorm in the highest respect, but this is fancy software for the high-speed Western world. Visually, it looks like a cross between LiquidThreads and Facebook, the former being unscaleable and widely disliked software, and the latter now slowly morphing into Myspace. I do not understand how the driving rationales have brought us to the point where users are supposed to sort through a pile of mixed threads on their "board" rather than selectively reviewing things through their watchlist. I can see lots of features here that would be useful, but I'm really not seeing any rationale for creating this mélange of topics in one place. I don't think anyone asked for that as a design principle, did they? Risker (talk) 02:53, 15 July 2013 (UTC)

Risker, in this instance, at least, making it "generic" is the simplest and most obvious way to make sure that each project has the ability to customize it. WhatamIdoing (talk) 04:52, 15 July 2013 (UTC)

We have no indication that customization is possible or even considered an option, WhatamIdoing; in fact, at this point, it seems that the key issues that a project would want to customize aren't even under consideration or, alternately, are not options. Templates? no, unacceptable. Usable by the visually handicapped? Maybe sometime, but not a priority. No Javascript? No communication. The absence of a method by which to communicate with other users that does not require javascript means that this project is actively working against its own objectives. At this point, I'm ready to spend donor dollars to send our engineering team to the Philippines for two weeks and require that they use computers built before 2010 and dial-up, and accept only code that works effectively and pulls up pages in a reasonable time. This won't.

The more time I have spent looking at this, the less I find it a worthwhile replacement for talk pages; in fact, the more I dig, the less persuaded I am that this is going to improve communication and collaboration. Facebook doesn't improve communication and collaboration. LiquidThreads didn't either. Collaboration has never really been that much of a problem, comparatively speaking. I'm hard-pressed to understand why this is a big focus. Risker (talk) 05:12, 15 July 2013 (UTC)

Jorm said months ago that there would be a fallback for users who don't have Javascript. The exact features were unknown, of course, as was just about everything else at that time. Am I really the only person who saw those messages?

As for sending them off to the Philippines: perhaps they would all enjoy it. WhatamIdoing (talk) 05:33, 15 July 2013 (UTC)

In answer to your question, what Jorm said months ago is kind of moot when he's said just this weekend that he doesn't really know how it will be done, or whether or not anyone will be able to respond absent javascript. His comment below Risker (talk) 05:53, 15 July 2013 (UTC)

Reply to Risker, quoting in places:

Okay, I'm going to stop you right there, because this theme that the WMF should be creating software intended to be used on "thousands of wikis" keeps cropping up. I thought we all just went through this narrowing focus exercise, didn't we?

There are still around 800+ wikis underneath the Foundation's umbrella. It is not "thousands" but it's still quite a large number, and I do not believe that our "narrowing focus" exercise does not absolve us from supporting them. It is actually easier to make the software customizable for every wiki than to build for 800 disparate instances.

Why are we spending our donor dollars creating software that is being genericized instead of customized for our projects?

That's the point: we are spending donor dollars to ensure that the software is customizable for our projects.

I hold Jorm in the highest respect

Thanks!

, but this is fancy software for the high-speed Western world. Visually, it looks like a cross between LiquidThreads and Facebook, the former being unscaleable and widely disliked software, and the latter now slowly morphing into Myspace.

I do not understand how the driving rationales have brought us to the point where users are supposed to sort through a pile of mixed threads on their "board" rather than selectively reviewing things through their watchlist.

I've heard you say something like this before and I thought I had cleared it up, but the fact is that what I think you are afraid of simply isn't true. In fact, in the first planned rev of the feature, it is assumed that you will continue to utilize your watchlist to follow topics and pages.

The inclusion of a "feed" view is an additional feature - it's simply a way for you to view all discussion activity in situ without resorting to the watchlist and being forced to open a gazillion tabs to keep up with things. Jorm (WMF) (talk) 00:39, 17 July 2013 (UTC)

Assuming Flow feeds will be anywhere close to what LiquidThreads offers as "New Messages" (all watched and updated threads collected in one feed) I'm a little skeptical about that feature, too.

Actually it encourages to discuss – but one often looses overview about what one was actually discussing (was it Flow in general? Or the prototype? Or was it some completely different discussion regarding VE?). Doesn't matter! Just write what you think! The Flow will go on – and sometimes steer the discussion into a dead end where much was said but little gained.

Threads are not closely enough bound to pages for my taste. One gets discussions everywhere and I'm afraid it could lead to users contribute to whatever pops up in their feed. While producing more "Flow" this probably won't increase the quality of contributions but will hide the useful contributions between the many "say something" answers.

Edit:

Actually I just did it myself!: The thread was about warning levels. Now I'm talking about feeds in a discussion that is already nested in seven layers! I have serious concerns if threaded discussion will actually aid the type of discussions we have going on Wikipedia... Patrick87 (talk) 00:50, 17 July 2013 (UTC)

Wikipedia discussions are threaded discussions. I'm not sure how adding structure to those threads is a bad thing. Jorm (WMF) (talk) 00:59, 17 July 2013 (UTC)

Sorry, I intended another meaning.

The current talk pages are self contained with all text on one page.

Flow will be split in threads and comments that will be "wildly" distributed across pages, will get included in feeds of all sorts, etc.

I don't know if this really adds structure. Personally I think to keep threads exclusively to one page already adds a huge amount of structure – which Flow will just give up. Patrick87 (talk) 01:06, 17 July 2013 (UTC)

If you like seeing all of the discussions about [Page X] in one place, then why wouldn't you just go look at them? Flow offers you a feed. You are not required to use it. WhatamIdoing (talk) 19:54, 27 July 2013 (UTC)

Sorry, but this reply wasn't too thoughtful, was it?

I assume we're discussing to improve Flow for everybody to get a discussion system fit for it's job. I don't think the way how I personally use Flow will influence the problems beginners might face. This might become a serious problem and you'd rather think about solutions then to fob me off with "if you don't like it don't use it". Patrick87 (talk) 21:33, 27 July 2013 (UTC)

What Risker above hinted is that you're generalizing over a wrong axis, because you have created and already committed to a design solution based on wrong assumptions (like "Wikipedia discussions are threaded discussions" - that's only one of the many use cases). This happened because you created your solution before gathering requirements, and thus you're solving a wrong problem -or rather, only a sub-problem of the whole thing.

By forcing the tool upon the community, you're going to eliminate all the possibilities of the tool that you didn't take into account from the beginning. Editors who care about the project are trying to warn you about this outcome, and so far it seems that we have failed to convey this message in a way you can understand. Diego Moya (talk) 12:21, 17 July 2013 (UTC)

Can you give an example of a non-threaded discussion at the English Wikipedia?

Threaded discussions are the normal approach. Sometimes this takes the form of you post, I reply, you reply, I reply again. Sometimes this takes the form of you post, and a dozen people reply (e.g., !votes), sometimes with replies to those replies (e.g., when the original poster wants to argue with the people who !voted the wrong way). But I don't think I've seen a non-threaded discussion, unless you count the occasional newbie who creates a new section/new discussion for every single reply, and they stop that as soon as someone explains how to reply properly. WhatamIdoing (talk) 19:52, 27 July 2013 (UTC)

> Can you give an example of a non-threaded discussion at the English Wikipedia?

Why should I do that? The problem with Flow is that English Wikipedia talk pages are used for collaborative tasks that are not "discussions" at all, threaded or otherwise, and the current proposed design includes little or no support for them.

I'm talking about user-created classification silos and review backlogs such as those typically created by Wikiprojects (tables of discussions requiring attention, various newsletters and other tools that get posted to talk pages, or tools like the AfD voting statistics), that typically depend on transcluding tables and other rich formatted data that don't fit a "threaded discussion" model. (P.S. there's also everything [2] by Quiddity).

There is some talk about allowing sticky shared notes and an "unstructured" section, but those are poorly defined lacking use cases and features; and given the amount of features from wikitext that are being dropped in Flow, it's likely that the current tools will cease working, and it's not at all clear that they can be adapted to the new paradigm that is not designed to support them.

All this wouldn't be a problem if Flow was not intended as a complete replacement for talk pages, and therefore imposing a design that only supports threaded discussions for a collaboration tool that is used for other communication models. Solving it would be as easy as associating each talk page or thread with a free-form sandbox supporting the same content that can be displayed at articles.

P.S. Watching this thread below it looks like some options are being considered to support this kind of free-form collaboration tools that are not threaded. Diego Moya (talk) 17:05, 29 July 2013 (UTC)

2 quick notes:

Newsletters and other Bot-messages are included in the Flow Portal/Use cases page. The newsletters shouldn't be using tables for columns/formatting, so hopefully that will be fixed as part of the transition. Edwardsbot already uses css/divs for formatting some newsletters, eg.

The pages created by ScottyWong's tools (w:User:Snotbot/AfD's requiring attention, and w:User:Snotbot/Current AfD's, and AfD stats) and all the other bots, need to be kept in mind for the future, but don't impact usertalk pages (afaik). Quiddity (talk) 19:04, 30 July 2013 (UTC)

I'm a little surprised that everyone is so worried about ScottyWong's tools. So at the risk of repeating myself, what Snotbot is doing will get easier under Flow. Instead of needing to "transclude" AFDs, it will just need to "tag" them, and everything else will happen automatically. You won't lose any functionality here. There is also nothing inherent in a "discussion" system that will prevent ScottyWong from tallying up !votes in AFDs. Again, this might even get easier with a Flow system that is tailored specifically for AFDs rather than free-form text that he has to carefully parse. The same tasks can be achieved in Flow, even though the exact mechanism for doing them will be different. WhatamIdoing (talk) 00:20, 5 August 2013 (UTC)

"Workflow"? Can you please use English, instead of MBA-speak? And "they could just query the user's Board for specific workflows" is doubly incomprehensible. It's rather amusing that wiki-markup takes only seconds to figure out, but the explanation of the new system reads like something that was run through a machine translator a couple times. Guettarda (talk) 04:10, 15 July 2013 (UTC)

I'm not sure that there really is a plain English word. It's a kind of technical concept. "A workflow" is "one kind of thing you do".

So if you're washing laundry, you have "a workflow" that involves several steps: sort the laundry, put the laundry in the washing machine, add soap, run the machine, remove the clothes, and dry them. That's your "workflow".

That workflow is similar to, but differs from, washing the dishes in an automatic dishwasher: You probably add scraping the plates, but skip sorting the items. You still put things in the machine, add soap, run the machine, and remove the dishes, but drying might have been done by the machine.

I can't think of another word that describes the abstract concept of an orderly process of things you do to accomplish a particular goal. Can you? WhatamIdoing (talk) 04:58, 15 July 2013 (UTC)

Yes I can. Procedure. Course of action. Method. Process. System. Practice. Technique. Risker (talk) 05:13, 15 July 2013 (UTC)

A.k.a Workflow! (Also, many of the words you listed have ambiguous meanings, or do not primarily/precisely describe an ordered-sequence-of-steps.) Quiddity (talk) 05:32, 15 July 2013 (UTC)

Well, what I am seeing is the term "workflow" to describe multiple things, and it is not actually being used correctly. Workflows have rigid ordering of steps that must be done in a specific order or the end result is not correct. Much of what we do on our projects that is being described as a workflow isn't really. For example, when we block a user, we complete the block form, we may or may not leave a notice on the page (either personally written or using a template), we may or may not revert edits, we may or may not ask for revision deletion or suppression, and none of these has to be done in a specific order, or within a specific timeframe. Yet, this would be described as a workflow. There is no sequence, the only step that is mandatory is the actual completion of the block form (whose fields can be completed in any order), and the end result is the same whether or not any of the non-mandatory steps are taken. Risker (talk) 05:48, 15 July 2013 (UTC)

I added an anchor to a comment Jorm made at w:Wikipedia talk:Flow#What Flow actually is, which might help.

I don't think the conceptual workflow modules are intended to be rigid procedures; they're intended to streamline the bits that can be streamlined (that currently require multiple disjointed steps and large pages of instructions to remind us exactly what order we're meant to do things in, like AfD), whilst still allowing whatever nuanced customizations each process often requires.

And more than that, the workflows will have hooks for alerting anyone who wants to be alerted about [an afd in the medical field / an afc request that needs copyediting / an rfc that is related to MOS:QUOTE / etc], hence increasing our awareness of what's going on, but without adding to anyone's workload.

We're going to be building the workflow modules, and requesting whatever features we need. The devs are just building the lego-blocks of features, that we'll put together in whatever ways we need/desire. Quiddity (talk) 07:51, 15 July 2013 (UTC)

Transclusion-like implementation for displaying associated threads ?

As I understand it, the end goal is to provide a system that works not only for talk pages but also pages that contain "discussion components and non-discussion components". Would it then be implemented in a way quite similar to transclusion ?

If as described threads can be associated to a page (not necessarily unique), say Foo, then we should be able by a magic word such as {{#Threads:Foo}} to have a transclusion of threads associated to Foo, with various rendering options.

A talk page could be hardcoded in a manner equivalent to show the editable wiki talk page itself, that is the header, followed by {{#Threads:Talk:Foo}}, with the desired rendering (in preferences). It wouldn't do to have {{#Threads:Foo}} because we would need in numerous cases such as processes or noticeboards a threads flow for the page (for the process itself) and the talk page (for meta discussion). (This is still assuming that talk pages have an existence as a wiki page themselves.)

Then we could have complex processes where we would put {{#Threads:Wikipedia:Foo}} where we need to have it, and we could have different ones transcluded on a same page, such as {{#Threads:Wikipedia:Foo/A}}, {{#Threads:Wikipedia:Foo/B}}, etc (effectively associated to a subpage, but this isn't important, an alternative would be options). We could ask only for threads from a given date or the last n days, e.g. {{#Threads:Wikipedia:Articles for deletion|date=7 July 2013}}. Cenarium (talk) 23:24, 5 July 2013 (UTC)

This is exactly what is planned for thread and board transclusion. Well, something similar; it'll be more like pages are attached to boards (and possibly multiple boards). But yes. Jorm (WMF) (talk) 23:42, 5 July 2013 (UTC)

The problem as I see it is that if threads are attached to boards in a manner that is too rigid, difficult to customize, this isn't going to be worth implementation compared to just transcluding subpages (especially if templates are not supported). On the other hand, a magic word such as {{#workflow:Type|Foo|options...}} which transcludes the workflow topics as specified and could be inserted in source text would be flexible enough for all intent and purposes, if templates are supported as well.

For talk pages, this would be hard coded instead. But for adaptable non-talk boards, I don't see how else it could be made. Cenarium (talk) 07:14, 6 July 2013 (UTC)

Black Magick

I have been told that Black Magick is supposed to be funny, but I don't understand what it means, or why it should be funny. New MediaWiki features, such as Flow, should be explained so that most anyone would understand. A Google search for Black Magick did not help me. I am new to MediaWiki, but I assumed the same formal style would be required as in the Wikipedia article space. I will watch this page, if any should decide to reply. Wmdv (talk) 01:54, 9 July 2013 (UTC)

The phrase "Black Magick and Other Trickery" is probably used here to imply the way non-technical people can sometimes view wikicode (ie. "we have to use colons to indent on talkpages, and 4-tildes to sign our posts) as being complex or "arcane". I'd suggest it's potentially related to the phrase "Any sufficiently advanced technology is indistinguishable from magic." (Clarke's three laws).

Documentation and brainstorming pages, frequently contain informal phrases, metaphors, analogies, and even attempts at humor, that wouldn't belong in an encyclopedia article. Partially because developers are human, and would go crazy if they had to express everything in either code or in formal documentation. Partially because developers are creative souls and often like to indulge in creative writing. Partially for other reasons that I haven't thought of. Quiddity (talk) 03:54, 9 July 2013 (UTC)

But why the unusual spelling and capitalization? When I saw "Black Magick and Other Trickery," I wondered if there was some other trickery in Wikiland that I still did not know about, but should. Wmdv (talk) 16:54, 9 July 2013 (UTC)

"Unusual" capitalization and punctuation is a way of indicating that a phrase has a meaning or emphasis beyond its normal meaning or emphasis.

For example, "I do not like that" means something much weaker than "I. Do. Not. Like. That."

In this case, the capitalization indicates that this is a joke. People aren't really sacrificing chickens during a full moon, or whatever kind of black magic you prefer, to find out what's new on a page.

As for the spelling, "magick" is preferred by true believers. According to them, "magic" is the fake stuff you see in show at the theater, and "magick" is the true spiritual thing. WhatamIdoing (talk) 17:22, 9 July 2013 (UTC)

Interesting. Is there any evidence that Flow will work better in reading changes than the current unstructured format (i.e., diff to determine changes, especially with the colored dot indicator as to what has been read.) LT (here) certainly requires "Black Magick" and some memory of information not stored in the threads to determine what the changes are, and doesn't appear to report any edits to read comments.

(As the current Flow simulator doesn't allow editing of comments, it's hard to tell whether there would be any way to determine changes in existing comments.) Arthur Rubin ^en.Wiki (talk^en.Wiki) 04:40, 9 July 2013 (UTC)

That's a good point. I'd summarize as "A visual-indicator that text has been added/edited in a discussion post".

I don't recall seeing anything in the docs about this (I guess it would/should be mentioned at Flow Portal/User to User Discussions#Activity notification? Perhaps it would re-trigger this, and mark the post as "un-read").

It seems like it would be an easy thing to add, software-wise, as Flow just needs to check whether the original post was changed or not, and add a message to the meta-data & the display if it was. (Either a text-line saying "Last edited ...", or a colored asterisk next to the time (like reddit but better), or something more complicated).

(I thought we did have a "Last edited at ....." message somewhere in LQT or the Flow prototype, but I must be thinking of a different site.) Quiddity (talk) 09:10, 12 July 2013 (UTC)

This functionality exists in the new version of the prototype. Just edit a comment and you can see what happens. Jorm (WMF) (talk) 22:08, 14 July 2013 (UTC)

Maths

Also mentioned at mailarchive:wikimedia-l/2014-September/074206.html.

And what about maths? Are we going to be able to discuss how to format a particular mathematical equation and give examples of its use? The problems here is that VE maths editor project bug 43058 has only just started. A bigger problem is that there is a WONTFIX on the rollout of the mathjax renderer bug 36496, without that anysort of interactive mathematical editing is imposible. Salix alba (talk) 13:29, 14 July 2013 (UTC)

+1 Helder 19:56, 14 July 2013 (UTC)

There is a functional <math> VisualEditor plug-in that lets you edit the LaTeX directly already in master (it's currently marked as "experimental" and so isn't available on the wiki unless the wiki is set to use that setting). Longer-term this will indeed be a graphical editor, almost certainly using MathJax, yes.

You can play with the code on this test page; we're evaluating what more it needs (beyond an icon!) before it's stable enough to switch on in production. Expect things soon. :-) Jdforrester (WMF) (talk) 22:41, 14 July 2013 (UTC)

Nice, but the input box needs to be much bigger. We sometimes have very large multi-line equations say

$\mathrm{atan2}(y,x)=::\{\begin{array}{cc}::\arctan (\frac{y}{x})& \text{if }x>0\\ ::\arctan (\frac{y}{x})+\pi & \text{if }x<0\text{ and }y\ge 0\\ ::\arctan (\frac{y}{x})-\pi & \text{if }x<0\text{ and }y<0\\ ::\frac{\pi }{2}& \text{if }x=0\text{ and }y>0\\ ::-\frac{\pi }{2}& \text{if }x=0\text{ and }y<0\\ ::\text{undefined}& \text{if }x=0\text{ and }y=0::\end{array}$

I also get wierd interface errors if I have my preference set to math_png and try to edit the large equations.

Is this related to Jiabao Wu work or something different? Salix alba (talk) 04:26, 15 July 2013 (UTC)

Yes, this is Jiabao Wu's work. I agree that there are some improvements for this before it's really ready, but I think it's close. Jdforrester (WMF) (talk) 15:44, 18 July 2013 (UTC)

I understand that it is proposed, if not decided, that the Flow database will contain HTML5+RDFa only, and in that case it would not be able to store mathematics markup. The workaround proposed for that would be to put mathematics markup into some kind of scratchpad.

This seems less than optimal. There is an obvious necessity for transferring mathematics between articles and boards for discussion and back. We shall almost certainly need source-level editing of the raw markup in both article space and discussion space.

Please can we have some kind of confirmation that this is going to be possible and preferably no less convenient than the current system. Spectral sequence (talk) 20:51, 17 August 2013 (UTC)

I don't think that anyone has said that HTML5+RDF storage precludes storage for mathematics work; that's something that the Parsoid team is working on.

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. Jorm (WMF) (talk) 23:42, 17 August 2013 (UTC)

As had been said, if you can promise wikitext authoring areas embedded in each message, it would be satisfactory. Otherwise, many articles would still be using a "conventional" talk page, although we might have to add additional namespaces. Arthur Rubin ^en.Wiki (talk^en.Wiki) 02:50, 18 August 2013 (UTC)

Thanks for that update. Spectral sequence (talk) 19:12, 18 August 2013 (UTC)

Thanks for that extra information. The need expressed is to be able to transfer text, including mathematics from an article to a discussion area, discuss it, possibly modify it, and transfer it back into an article. At present this is possible using cut-and-paste on wiki and LaTeX markup. Can you promise that the new system will support something equally convenient? Spectral sequence (talk) 19:16, 18 August 2013 (UTC)

You will be able to cut-and-paste into the collaborative authoring areas. I feel it is reasonable to assume that this will include LaTeX markup. I expect this will be more convenient but some people are masochists and like to do things the hard way.

I'd like people to stop asking for "promises". It's very difficult to promise anything when code hasn't been written. Jorm (WMF) (talk) 19:22, 18 August 2013 (UTC)

Thanks for that assurance. Rather than the word "promise" (which you introduced into this discussion), would you rather say that you have "clear plans" to deliver the capability we require? The precise terminology is not so important, provided that we had a good reason to believe that the need is well understood and reasonably likely to be delivered. The point is that we as editors need a certain amount of clarity about the developers' plans in order to engage effectively and constructively with them, and in particular to warn when the development process seems to us to have gone seriously astray. Spectral sequence (talk) 19:57, 18 August 2013 (UTC)

That won't solve the problem. If Jorm says something like "At this point in time, I'm tentatively expecting to eat a cheese sandwich sometime next week, subject to availability of time and materials, and assuming an absence of unforeseen contraindications as well as the absence of potentially better alternatives", and he doesn't post a video of himself eating that sandwich along with testimony of people who saw him do it in person, then people come back and complain that he's broken his promise to eat a cheese sandwich.

"Clear plan" means promise to these people. "Plan" means promise. "Expect" means promise. "Hope" means promise. By the time you get through the rumor mill, even "might be possible" means promise. After months of this, I think you can imagine why Jorm is a bit wary about saying anything that could be misinterpreted by other people as meaning that any particular outcome will happen. WhatamIdoing (talk) 21:06, 21 August 2013 (UTC)

What we could get from the WMF (probably not Jorm) is that Flow will not be rolled out, even for beta testing, without certain features working (at least, in alpha test conditions). I would say the minimum feature would be

• Copy/paste between VE, Wikitext, and Flow messages (although, in some cases, it might have to be in Flow as an embedded Wikitext object.) This should include (in theory) anything which generates valid HTML; in practice, it should include < math>, anything tested which generates valid HTML (which includes templates with unclosed tags if they get properly closed by other templates, regardless of Parsoid), and anything you consider a valid Flow message without special workflows.

But I've already said what I expect as a minimum for a functional Flow system Arthur Rubin ^en.Wiki (talk^en.Wiki) 01:51, 22 August 2013 (UTC)

I doubt you'd be able to get any promises along those lines from any employee of the Foundation, actually. Jorm (WMF) (talk) 01:58, 22 August 2013 (UTC)

Editors wouldn't be so eager to request such promises if the dev team kept a public, updated list of all features that they're taking into account in their design, where all requests made by the community and acknowledged by the developers could be traced.

You're expected to have that with Agile methods. When you don't have an upfront design, communicating the current status of development at all times is vital, but the dev team has a serious problem of miscommunication with their final users.

If you shift focus from "I promise that final product will have X" to "I acknowledge that you need X", that could solve the problem without the need to make promises. Diego Moya (talk) 07:42, 22 August 2013 (UTC)

Even Agile methods should have a closure criterion; acknowledgement that if certain things cannot be done, then the product should be shelved. But "I acknowledge that you need X" would be helpful. So far, on VE, there are at least one "won't fix" and a number of bugs listed as low priority enhancements which fall under the minimum required for (at least, me) to consider using VE for major edits. Flow isn't yet to the point where bugs can be reported, or even feature requests be made. Arthur Rubin ^en.Wiki (talk^en.Wiki) 09:49, 22 August 2013 (UTC)

The people here and there shouts: math-math-math, but nobody clarifies about what precisely do they speak. What is your “math”, indeed? The <math> tag really present a special problem. But articles on many technical (and not only) topics use tens of special templates (I mean: formatting templates, not navboxes), and mathematical articles use them as well and are not exceptional in this sense. Will wiki templates be expanded in Flow or no? Will we have a possibility to use an actual formatting code whether is it mathematical or no? Incnis Mrsi (talk) 15:39, 19 August 2013 (UTC)

still waiting for an answer... KaiMartin (talk) 04:15, 19 October 2013 (UTC)

The discussion here is relevant. Spectral sequence (talk) 17:30, 19 October 2013 (UTC)

More minimal functionality

A minimal functionality for Flow (and VE) is the ability to copy/paste paragraphs or sections between articles and "talk page messages", whether in Flow, LT, or Wikitext. If that will not be available, there is no reason to proceed with Flow. I mentioned that over in w:Mediwiki talk:Flow, but it needs to be said, here, as well. Arthur Rubin ^en.Wiki (talk^en.Wiki) 18:36, 15 July 2013 (UTC)

I agree that this should be minimal functionality. However, that's functionality that exists within the VisualEditor, and is independent of Flow. This is a gating requirement, probably, but it's one that the VE team has to work on, not the Flow team. Jorm (WMF) (talk) 00:15, 17 July 2013 (UTC)

Well, no. We need to be able to copy material, that VE doesn't edit correctly, between article sections and Flow messages.

And, there's still a component for Flow: The message has to be rendered the same way as it would be in an article. As you have said you don't want to use Wikimarkup internally, that means Flow needs to convert between Wikimarkup (which will still be the internal representation of Wikipedia articles) and Flowmarkup, and the conversion must have fidelity(noun, 3). Arthur Rubin ^en.Wiki (talk^en.Wiki) 01:47, 17 July 2013 (UTC)

+50 to this, Arthur. Jorm, you don't seem to understand why wikimarkup is the major asset of the Mediawiki software, and you think of it as a liability (likely from legitimate performance concerns, that need to be solved - but not at the cost of getting rid of all the semantic possibilities of the platform).

I'm worried about the design that you can create starting from the assumption that Wikimarkup is something from the past, when it's the world's first and successful example of a semantic platform, and the way all computer systems will work in the future (with more friendly editors, of course, but certainly with a semantic platform beneath them). Now if you were talking of building FLOW on top of Wikidata in order to make Wikimarkup obsolete, that I would understand; but that doesn't seem to be what you're buidling here. Diego Moya (talk) 12:07, 17 July 2013 (UTC)

Why the reordering of topic discussions?

Looking at the "board and feed" model in Flow Portal/User to User Discussions, I wonder if the decision to "bubble" active topics to the top of the board is a sound one.

Reordering conversations misses a feature of the old talk pages, which is stability. If topics are ordered according to their creation time (just like a blog) instead of their activity, it's easy to know where a particular conversation is located with respect to all others, and use spatial reasoning and "muscle memory" to remind what you have read and what is on your pending list. You don't need to bubble up the entire topic in order to find updates; the feed takes care of that, providing quick access to any active conversation. With the board-and-feed model, reordering the board is redundant, and even harmful.

You also miss any possibility to have a Table of Contents with a summary of not-archived conversations, a really useful feature that is not present in the Flow prototype (see "substantial knowledge base" comment below). Flow seems to assume that conversations that are not active are not important and can be archived, but that's simply not true of Wikipedia talk pages; inactive conversations can contain knowledge and suggestions that can be acted upon, so they should be stored for reference, in an easy-to-retrieve way that doesn't require searching but mere browsing.

I understand the appeal of "infinite scroll" metaphor for boards, but that can be achieved with static boards ordered by creation time. Instead of modelling Flow boards after bulletin boards at internet forums, I find the blog model a better fit for the way conversations are handled at Wikipedia. Diego Moya (talk) 09:43, 19 July 2013 (UTC)

That was what I wanted to point out in Talk:Structured Discussions/2013a#c-Patrick87-2013-07-17T00:50:00.000Z-Jorm_(WMF)-2013-07-17T00:39:00.000Z and Talk:Structured Discussions/2012#c-Patrick87-2013-07-17T01:01:00.000Z-Jorm_(WMF)-2013-07-17T00:48:00.000Z. Brandon told me I was dead set against anything and everything; And that he thought it may be better for him to disengage with me.

Maybe he realizes that I'm not the only one with these concerns... Patrick87 (talk) 09:57, 19 July 2013 (UTC)

The funny thing is that having these particular two features should be relatively simple to program - they're just a query on topic names to show the topics index (LiquidTrheads have it!) and a database index to keep them ordered by date. It's all a matter of design, and providing a clear metaphor for conversations.

I find the "filtered topics" model in both LiquidThreads and Flow quite confusing; the focus on laser-guiding users to the conversation they're interested make it difficult to assess where a conversation is located, as they are devoid of context. This could be fixed by simply providing a more prominent, always visible link to the board name where the topic is stored, and a board index when the user navigates to the main view (which is ordered by creation time by default in order to provide the required spacial grounding - otherwise Flow_Portal/User_to_User_Discussions#Collaborative_Posts would be quite difficult to grasp).

Surely auto-signing, auto-tracking of conversations and a "reply" button to posts instead of editing the whole thread are needed features, and an improvement in presentation of talk pages. But these are not incompatible with the current main page metaphor. The personal feed is enough to guide users to the conversations they're interested in and keeping them updated. Diego Moya (talk) 10:28, 19 July 2013 (UTC)

Agreed. ImperfectlyInformed (talk) 21:26, 21 July 2013 (UTC)

Aye, these are good points. -— Isarra ༆ 18:26, 18 August 2013 (UTC)

Sticky posts

Sometimes you need to leave a notice of some kind at the top of your talk page for people to read before commenting. In fora, this is usually provided by a "sticky" or "pin" feature to attach a specific post/thread to the top of the page. Is this feature planned? If not, I'd like to request it. Thanks. — Scott • talk 17:49, 24 July 2013 (UTC)

It's already planned. WhatamIdoing (talk) 19:41, 27 July 2013 (UTC)

Design of Flow Portal

Hi, when i came across this page, i was quite astonished. I think, project pages should be characterized by proven facts. But the second half is only a PR text consisting of opinions and assertions. For example it is claimed, wikitext was a "user hostile" system. If it was indeed, experienced users would have started a revolt. You should not only concentrate more and more on unexperienced newbies and ignore the needs of power users. Andy king50 (talk) 15:28, 27 July 2013 (UTC)

Actually, although he's been proven wrong, it is possible for a protocol to be expert-friendly and novice-hostile. The operating system(s) UNIX comes to mind. Wikitext, though, appears to be less novice-hostile than VisualEditor. Arthur Rubin ^en.Wiki (talk^en.Wiki) 17:08, 27 July 2013 (UTC)

Community consent?

Sorry, but the search offered only Create the page "Community consent ondiscussionpage:Talk:Flow Portal" on this wiki!.

• Is there a community consent, that a change like this is wanted?
• The claims on the portal page (e.g. "Users expect a modern and intuitive discussion interface.") are backed by what? Or is this just someones opinion?
• "We believe that a modern user-to-user discussion system will improve the projects." Who is "we"? And what if, believe it or not, just being "modern" (whatever that may mean) is not strong enough to justify imposing such a change on a user community?
• "Talk pages—as a discussion technology—are antiquated and user-hostile." Antiquated in relation to what? Existing tools, which are inadequate for the task (otherwise, the implementation a new tool would lack justification)? Or a figment of imagination called "Flow"?

These are just some minor points, but I think you will get my drift: If this is again a solution looking for a problem, which is implemented and delivered without seeking broadest community consent, the next shitstorm after VE is already scheduled.

And, as an aside, be advised that, in case the Flow-tool should be lacking performance on deployment day, what will it be called by the community? Hint: It rhymes. WolfgangRieger (talk) 23:37, 6 August 2013 (UTC)

Hi, here are a few replies:

Yes, we (the editors and the WMF) have long wanted newcomers to be less-confused or put-off by:

• Colon-Indenting in discussion threads
• Manually added signatures
• The problem of where to reply, when someone leaves a message on their usertalkpage
• Having to watchlist all userpages/articles/etc when they leave a comment at the associated talkpage.
• the difficulty in determining whether a comment has ever been edited by someone other than the original author
• etc

The En.wiki w:Wikipedia:Flow portal has a few more details than the one here, which you might find useful. Also, all the subpages in the {{Flow Navigation }} navbox, contain a lot more details (many of which are old, or on a pure "brainstorming" level, but are still useful reading).

Regarding the comparison to the VE rollout - Jorm has recently clarified here that the Flow rollout will be a lot slower.

Hope that helps. Quiddity (talk) 19:20, 8 August 2013 (UTC)

Even though the roll-out as envisioned by Jorm will be a lot slower, it still follows essentially the same route as the VE. Specifically, Jorm does not mention any intention to seek broad community consent beforehand. Failure to do so was arguably the reason for the VE crash. You may read the comments editors gave in RFCs in Dutch, German and English Wikipedia. KaiMartin (talk) 21:43, 10 August 2013 (UTC)

Do you believe that it is possible for normal, non-programmer people to give informed consent to try out unfinished software they have no experience with, no knowledge of, and no true ability to judge whether it meets their needs? How do you see that working? Have you ever seen it work at any Wikipedia? WhatamIdoing (talk) 22:51, 12 August 2013 (UTC)

Of course it's possible for normal, non-programmer people to test unfinished software, it's even the recommended approach to achieve usability. It's never seen at Wikipedia because WP software roll-outs rarely follow best practices, but it works really well for big companies like Google (who gets usability fairly well). The way it's done at other places is with an iterative process for gathering feedback:

1. You develop surveys and interviews with users from your target audience, or perform a similar field study to ask for ways that a tools like yours would be used. In a place like Wikipedia, where users form a huge world-wide community, you publish a well-publicized survey and analyze what respondents have to say about the tool's purpose.
2. You select a really small set of users (three to five is enough) and present them with the first, non-functional interface (preferably offline, in the same room). Without telling them anything of how to use the tool (this part is important), you ask them whether they can make sense of the proposed interface, and how they would use it to achieve whatever goal is in their minds.
3. You annotate all the proposed ways the users intended to use the application, and where they didn't understand something. You fix anything that didn't make sense, and try to change the design to accommodate as many new proposals as possible, before showing the tool again to the next five users. Iterate steps 2 and 3 until no more major problems are found.
4. You implement a prototype with the design that emerged from the initial stage. You randomly select an average-sized and diverse group of people and repeat steps 2 and 3 with the functional prototype. You register any proposal of new ways to use the tool, and annotate the places where the initial software architecture wouldn't accommodate those ways of use.
5. You throw away the prototype (that step is also important), and design a new architecture that is adequate for all the new usages that were originally unexpected and for which the prototype architecture was a bad fit. At this point you have a software design that suits the needs for a moderately large set of users and that can be expanded with small functional increments.
6. Now comes the step that Google does particularly well. You announce worldwide the roll out of a new beta service or interface, explaining that it will be made available in the near future at incremental stages. At each stage you increase the number of users exposed to the new tool, either by providing an invite-only system or by randomly providing opt-ins to larger and larger groups each time. Any user that doesn't want to use the beta software should be allowed to easily revert back to the old system until the end of the beta.
7. During the beta phase you add polish, polish and more polish, fix abolutely all workflow-stopper bugs, and include those new functions that are frequently requested by users during the beta stages.
8. Finally, you should be confident that your tool is polished, almost bug-free and that it accommodates the needs of the majority of your user base (as compiled from user feedback during the whole process); only the most obscure use cases should be not supported by the tool at this point. This, and no earlier, is when you can do a final roll-out for all users. If you did a proper work, there should be no backlash, because the tool really provides an improved workflow, and nobody complains when they're given a better tool (provided that it is really better for them, not just better for the developer). If there's widespread backlash anyway, it means that you failed somewhere at the previous steps; you then keep track of that failure, so that the next time you don't repeat the same mistakes.

It's a lot of work, and it requires that developers are willing to re-design the whole product according to users specifications; if you instead start from an almost-finished design and architecture, and only try to accommodate the few features that make sense for developers, the end result does not satisfy user needs. As far as I can tell the VE design completely missed steps 1 and 5, and was coerced by the community to implement step 6 (the initial roll-out was nowhere like this best practice, but it's somewhat there now). This means that there's hope for a final release that won't be rejected in full, but that the current editor is not based on a complete understanding of all user needs, and that it stood in the prototype stage - so the current architecture will not be able to accommodate all the expectations from the community without a major redesign.

...and no true ability to judge whether it meets their needs. WhatamIdoing, I find that comment is incredibly dismissive of non-programmer people, for someone who claims to represent the interests of newcomers. Nobody better than the final user can judge whether a software meets their needs; if you assume what should be the needs of users, and later claim that users don't understand those assumed needs, you'd be doing everything backwards. Diego Moya (talk) 13:39, 13 August 2013 (UTC)

I appreciate the well-constructed and thoughtful answer, but I don't think that your response answers my question. My question was this: "Do you believe that it is possible for normal, non-programmer people to give informed consent to try out unfinished software that they have no experience with, no knowledge of, and no true ability to judge whether it meets their needs?"

The question you seem to have answered was, "Do you believe people are capable of trying out unfinished software?" The question I actually asked was more like, "Do you believe that it's possible to give en:informed consent to try out unfinished software, given these serious limitations, i.e., that your allegedly informed consent is not what most people would call 'informed' about the subject matter?"

There are well-respected ethicists on both sides of this question, so I can't claim that there is a "right" answer and a "wrong" one. However, I'd like to know your answer.

It may be easier to understand with an example. Consider this case:

The user is an average 20-year-old. He has no experience with software stuff except everyday normal-user things, like sending e-mail and listening to music. Being an approximately median active Wikipedia editor, he makes about five or ten edits a month, most of them trivial changes like typos or adding the name of the latest album released by a band he likes. He receives a message on his talk page from someone he doesn't know, who says, "Hey, go to Special:Preferences and try the new experimental Thing! I really like Thing, and I hope you choose to test it, too!"

At this point in time, given the information he has, is this user capable of giving informed consent to use Thing? Also, is this user capable of giving informed consent to refuse to use Thing? WhatamIdoing (talk) 21:23, 16 August 2013 (UTC)

The reason why I started my post with "of course" and "it's even the recommended approach to achieve usability" it's because it can be done, and it really is the recommended and standard approach to achieve usability. There are several professional fields (user-centered design, user experience, information architecture, interaction design, and anything with an UX in its description) which are all based around processes that depend on it being true.

The tl;dr version of the long post below is that users can give informed consent if you don't expect them to achieve anything useful with the broken/unfinished software; the consent should be given to provide feedback about what is actually built at any given time, not what is in the head of the production team as future possibilities. (And again, the "no true ability to judge whether it meets their needs" is a false assumption - the user can always judge whether the unfinished product meets their needs, and that is exactly the question that must be asked). The good thing about asking about the current version, and not your planned fixes, is that you don't just keep talking about the great design that you think will solve all the user's problems - you have to actually test whether it solves them or not. This is the scientific process at its best.

Of course if all the information you provide is "Hey, go to this page to test this really cool new thing" you're not gaining anything. But you originally asked me if the user could give informed consent to "try out" the software, and now you've shifted to ask whether they can "use" it. Those are very different things, and by conflating them you're asking the wrong question and thus making a serious mistake in the way you approach end-user involvement. The message to the user as well as the way to test the software should be "Do you want participate in an experiment to help us build a better version of Thing? The experiment consists in that you try out this Thing, we see how you try to use it, and you tell us what you think of it".

The goal of these early interactions must not be to assess whether the user can use the software, which means that they could successfully complete tasks that meet their goals with it. Of course they can't do that with an early version; it's unfinished, and it has been designed with only a cursory understanding of their needs, based only on early field research (and that if there's luck; most software is created just from developers' gut feelings).

No, the purpose of early testing is to let users try out the software with the only goal to get feedback from people using the software, watching exactly where they have problems with the design, and asking them if they can make sense of the interface.

If your only goal is to get this feedback so that the product can be later improved, of course users can give informed consent for this kind of sessions. See this example of the process required to ask for this consent. When users are guided through a session like this to use the software, they are perfectly capable to assess whether they're willing to proceed and to answer whether it's useful to them; an answer that for these early sessions should always be "no, I can't use it ([which is expected at this time]), because of reasons X, Y, Z ([which is the valuable thing to learn]). A technician performing the sessions that is experienced in the field can make the most of this feedback so that few users need to be tested. The most important part of the test is not only what users say, but what they do - i.e. whether their use of the software corresponds to how developers thought it would be used.

Of course for a site the size of Wikipedia you need more than a few in-place user tests; the kind of unsupervised feedback you talked about is what I described as step 6, for which users can also give informed consent of the exact kind you asked, provided you've built a system that reasonably fulfill their major needs through steps 1-5; and, much earlier, a lot of research must be done even before design begins (that was step 1, creating surveys to compile user needs from the wide user base). But you'll need actual users testing the unfinished product through steps 2 to 4 to be sure that the software makes sense and that there aren't any obvious gaps in your understanding of the problem, which is something much more common than what software developers are willing to admit.

The link to the usability test script above comes from Don't Make Me Think, a short and very useful introduction to the methods of Usability, and its sequel Rocket Surgery Made Easy (I have no relation with the author, I just think they're very good introductory texts). Although they deal primarily with web pages, the test methods they describe are valid for any kind of software development, and they answer your questions much better than I ever could. Diego Moya (talk) 21:55, 18 August 2013 (UTC)

Interesting question. That the WMF seems not to be capable of correctly deciding whether software is usable makes the question moot, doesn't it? Arthur Rubin ^en.Wiki (talk^en.Wiki) 16:31, 17 August 2013 (UTC)

Modify a pre-built system

Does there no pre-built system exist wich could be modfied for covering the use cases within the wikipedia? Such a system would be in my opinion cheaper and more stable. --Arcy (talk) 06:56, 10 July 2013 (UTC)

This was lost on another talk page WhatamIdoing (talk) 00:00, 13 August 2013 (UTC)

The answer appears to be "no", at least not if the requirements include using open source software and being able to handle the volume of discussions at the English Wikipedia. WhatamIdoing (talk) 00:01, 13 August 2013 (UTC)

Workflows

I have a question about Flow "workflows". From what I understood, a "workflow" is some facility which eases conducting a specific type of discussion, hardcoded into Flow for each specific use case. Which strikes me as inflexible and impractical. Say we have a deletion workflow. If for some reason the deletion process needs to be changed, this would entail a need to change in software. And we all know that changes to software are slow and painful. The same would apply if for some reason we needed to have a new workflow created.

Meanwhile, on Wikia, I see there are "forums" with a really neat feature: threads attached to ordinary pages. I would do something like that: each Flow thread would have a list of one or more pages it relates to. A "User" discussion would be nothing more than a discussion attached to a user page. A "deletion discussion" would be nothing more than a discussion attached to the page under consideration and a deletion policy page in the project namespace, or even some specially designated page to which deletion discussions are attached. A "newbie asks for help" discussion would be simply attached to both the user's page and the "active newbie requests" page. There would be no need to distinguish "User talk" from other types of discussions at all. Simple, flexible, and integrates neatly with wiki structure.

[Edit: I read a reply below indicating this is pretty much exactly what is planned. Never mind. But then, what are workflows, actually?]

Some time ago on w:WP:VPT I also proposed a "page tagging" feature, for tags like "unreferenced". Talk page banners could be integrated into that. If we wrote such a thing, it could eliminate the need for an "unstructured heading" space too, further simplifying things. Keφr 09:36, 19 September 2013 (UTC)

We've been using the term "workflow" rather loosely to refer to any discussion or process on Wikipedia that includes a set of steps that are more or less regular. Examples include the AfD process on English and other Wikipedias (step one: an article is nominated for deletion; step two: users comment with keep or delete; step three: the discussion is closed and summarized, and the appropriate action is taken on the article), or user blocking (step one: user is warned; step two: user gets a block template on their talk page, with the option to request unblock; step three: user requests unblock, which goes into a category for admins to review; step four: user is either unblocked or his/her request is denied).

Some of these processes can be automated with software, and we've done a bit of brainstorming on how this might actually work – check out this doc for an example. But in the first release, we've decided to focus more on the unstructured user-to-user discussion side of things. There are benefits to automation (it can make some processes work faster and more smoothly), but there are also drawbacks – we want to ensure that any automation we create is maximally flexible, configurable by the community, and can evolve alongside the policies and practices that it's meant to serve. That's why we're holding off on the workflow piece of Flow until we can devote our full time and energy to it. Maryana (WMF) (talk) 17:13, 20 September 2013 (UTC)

Okay. I have seen the word "workflow" thrown around a lot in discussions regarding this. I assumed it has a technical meaning.

Still, the descriptions I find around there, and in the above reply sound rather complicated. To reiterate, the core, universally-needed features here are:

• Threads and posts clearly separated from each other. [in progress]
• Threads attached to (possibly multiple) pages. [in progress]
• Enumerated options ("votes"). [early plans]
• Discussion closure and closure summary. [early plans]

(I am omitting things like notifications of replies, subscribing to discussion boards/threads separately, etc.)

If I were to support "workflows", I would base everything on these core features, and create a configurable policy (similar to protection levels) for choosing how they are supposed to be used, i.e. who is able to attach or detach a particular page to a discussion thread, and who can close threads attached to particular pages (i.e. anyone can attach a new thread to a "current deletion discussions" page, but only administrators can close and detach threads from it; blocked users cannot attach threads anywhere except the "current unblock requests" page and their own talk page, etc.). Very little of the discussion processes would need to be coded into Flow this way.

And I think there should be a feature for seeing threads attached to "all of the specified pages" (e.g. for when someone is looking for past deletion discussions for a given page: intersection of that page and "past deletion debates") and "either of the specified pages" (someone wants to have a unified view of MfD, TfD and RfD, or a unified Village Pump).

Also, did anyone think about the "page tags" feature? This could replace maintenance tags like "unreferenced", deletion or protection notices, or talk page banners. It could eliminate some problems, and would be great to integrate with Flow, e.g. we could have a tag saying "this article needs to be cleaned up, see [this discussion thread] for details". And the discussion thread would be created by the software while adding the tag, instead of requiring the tag adder to do it manually. The current system of "templates and categories" kinda works, but sometimes it just feels strained. Merges seem especially painful.

The final item on my wishlist: please keep the visuals simple. I like the ascetically compact look of talk pages, certainly more than I like LiquidThreads. I only want posts to be clearly separated from each other, and to be able to collapse threads to take even less space.

And a pink unicorn, please. Need not be invisible. Keφr 17:40, 25 September 2013 (UTC)

Talk:Flow Portal/Research/Experienced User Responses

From when are the "Experienced User Responses" at Flow Portal/Research/Experienced User Responses? It makes a whole lot of difference if these are from before Echo or after (they seem to be from before Echo), since at least some complaints are solved by Echo. Fram (talk) 13:55, 8 October 2013 (UTC)

That page was initially created on March 13, and Notifications were released on Enwiki on April 30. So yup, from before, and a few of the complaints are partially solved, and a few are 99% solved. –Quiddity (talk) 17:04, 8 October 2013 (UTC)

Thanks. Fram (talk) 07:44, 9 October 2013 (UTC)

Why discussion?

The subject of this discussion refers to Flow Portal#Why discussion?, the table with "expectations" vs. "current reality". Taking the current reality point by point (and noting that it only lists the negative point, I hope that the devs are also taking into consideration all the positive points of the current reality!):

• "Conversations that thread to infinite depth": everything I have seen from Flow has the exact same functionality (but hopefully it works better than LiquidThreads, which break down after 65 or so posts in one thread!)
• "Comment authorship shown at the end of comment or not at all". But in Flow, like in the current reality, the "section header" is not signed (and can be changed by anyone), and apparently the OP is also not signed.
• "Inconsistent reply system (whose talk page hosts the conversation?)" How will this change? If I get a message on my talk page in Flow, I can still go to the user talk page of the other user to reply. Perhaps the "reply" button will increase the likelihood of conversations staying together, but it certainly isn't solved magically by Flow.
• "Wikitext/code" which will remain in Flow, according to the latest promises
• "Notifications only when the conversation happens on their own talk page" or through Echo of course. On the other hand, I have not been able to test this with Flow anywhere, but with LiquidThreads, when looking at e.g. your contributions list, your post in a thread will be the "current" post no matter how many replies there have been. If this isn't improved in Flow, then you have solved the notifications problem and created another, equally serious problem instead.

Tackling the expectations:

• "Easy to distinguish topics"; not in the current setup. What is the difference between two sections with the same title, and two discussions with the same title/subject?
• "A "reply" button" Yes, but not consistently (again, judging from the Flow sandbox), where sometimes I can top-add a reply, and sometimes I can't.
• "Obvious and consistent comment authorship" apart from the title and subject header, that is
• "Automatic "signing"" is the same as above, basically. Furthermore, what with places where you don't need to or are not wanted to sign? Starting RfCs? Adding templates to talk pages? Will there be a possibility to disable automatic signing where needed?
• "A simple comment field". A bit too simple perhaps? What if I want to present refs or other more complicated stuff? What with pages or sections that need a different format (like numbered responses in !votes? Articles for Creation pages on enwiki, like en:Wikipedia talk:Articles for creation/Graft versus tumor)?
• "Notifications of replies to all discussions" Will there be an "unwatch" possibility per discussion? And will there, on the other hand, still be a useful "watch" possibility to be notified of new discussions or changes to discussions you haven't yet participated in?

The current prototype, and what I have seen from the documentation, make it impossible to judge whatever it is that is being developed. Considering that first rollout to enwiki is expected for next month, this seems to be a problem Fram (talk) 14:32, 10 October 2013 (UTC)

FAQ

The Flow Portal/FAQ has a number of problems. Some highlights:

• "Is this replacing talk pages? Yes." Well, no. It is replacing talk page technology / look / feel.
• Is this replacing wikitext? No. [...] Note that while the prototype does not support wikitext, the final product will." Will Wikitext be supported before the first roll-out to Wikiprojects?
• "Will there be avatars? [...]The long-term answer is "possibly." Using avatars on Wikimedia projects brings up several problems, not the least of which is "using a free-use image on a project that doesn't allow free-use content."[...]" I must be misunderstanding something: since when is free-use content no longer allowed on Wikipedia / Mediawiki / ...? Which projects don't allow free-use content at all?

The page also needs information on archiving, monitoring, watchlisting, ... All the things people do to follow discussions, pages (not the same thing!), users, ... or to unfollow these. Fram (talk) 14:39, 10 October 2013 (UTC)

Yup, the FAQ is very outdated (and now marked as such). I saw your comment on enwiki, so am just replying for anyone else's benefit. :) Quiddity (WMF) (talk) 21:08, 10 October 2013 (UTC)

Dates of usability tests?

I was looking at some of the research mentioned in footnotes for this project and noticed some of the user data came from research in 2004-2008 when the site was quite different than it is now. Other research came from surveys or studies done several years ago.

So, when I'm looking over these usability tests, I'm surprised not to see any date for when the testing occurred. Was this before, during or after the VB interface was rolled out? This would be useful to know, even if it is just a date range (like Dec 2012-Jan 2013).

Thanks! Nwjerseyliz 23:10, 19 October 2013 (UTC)

The videos linked in Flow_Portal/Research/User_Test_Data#Test_Results were all made in January/February 2013. (Date is in topright of the video. :) Quiddity (WMF) (talk) 21:09, 4 November 2013 (UTC)

Talk subpages

Hello,

Based on my experience with Wikipedia in French, I have some difficulties to identify how Flow would replace the subpages in the article talk space.

In Flow Portal/Functional Specifications/Boards and Topics#Board, I read "Each MediaWiki page object may have one (and only one) Board associated with it.". What exactly is considered a MediaWiki page? How could we use Flow to replace subpages of talk pages (for which there is no corresponding subpage of the main page)? On WP:FR, we use this a lot for evaludation purposes, such as in the process towards good articles and featured content.

On that same page, I also read "If a Board's associated Page is deleted, the Board itself is deleted.". Well... One case where we use subpages of the article talk namespace on WP:FR is for the Articles for Deletion process. And we definitely need those discussions to survive the possible actual deletion of the article! Klipe (talk) 21:16, 20 October 2013 (UTC)

I missed that. It's usually the right thing to do, at least on en.Wikipedia; see w:en:WP:CSD#G8 (w:en:Wikipedia:Criteria for speedy deletion#G8. Pages dependent on a non-existent or deleted page). Arthur Rubin ^en.Wiki (talk^en.Wiki) 17:14, 21 October 2013 (UTC)

Subpages: Note that the plan is to not place Flow in any /subpages automatically, but rather to provide some sort of switch so that it can be selectively enabled where it is wanted.

Boards without associated pages: That's a good point. I've taken a look around, and these seem to be examples of what you mean:

• AfD resulting with deletion: fr:Discussion:Solvaxis/Suppression
• AfD resulting with keep: fr:Discussion:Vivre avec Camus/Suppression
• Article evaluation subpage: fr:Discussion:Calcul de la date de Pâques/Article de qualité

We used to do this at English Wikipedia, too, in various places, such as w:Talk:Steve Reich/Comments, but they've been phased out over the years (See w:Wikipedia:Discontinuation of comments subpages). I believe we still do this in various places in non-article namespaces, but I can't find any great examples at the moment.

I'll ping the developers, to let them know.

Deleting Boards: Do note however, that as it says, if a "Board" is deleted, any Topics (threads/content) within will not be deleted - the topics will still be linkable and visible, they just won't all be compiled into a single Board. Deleting those Topics would be an entirely different process. I'll have to check, to find out what would happen to the Header-material, in that circumstance. Quiddity (WMF) (talk) 20:19, 24 October 2013 (UTC)

We still do it in article namespace as well, e.g. for good article reviews like [3] or [4]. Fram (talk) 14:28, 25 October 2013 (UTC)

Sorry for popping up only seldom on the MediaWiki wiki... I just want to confirm that the examples you found indeed correspond to what I had in mind and add some info about the case of a deleted article:

• The (now non-existing) w:fr:Solvaxis page in the main namespace contains a first box listing the journal of moves and deletions, in which there is a link "(Décision PàS)" pointing to the talk subpage containing the AfD discussions and conclusions.
• From what I understood regarding the topics in Flow, we would need a board containing several topics to match the current structured content of the AfD talk subpage for one article on WP:fr. You remind us that the topics would still exist even though the board would be deleted... and I'm not sure that this would be sufficient.

Anyway, thanks (also to the dev's) for looking into this. Klipe (talk) 21:21, 9 November 2013 (UTC)

i18n review

Hallo,

I have a few questions about some user interface messages in Flow. As you probably know, we are very very interested in getting all the messages documented well as early as possible. The current documentation for some messages is not completely helpful now. Here they are:

1. What exactly is the definition of "Moderated user"? I found some documentation about moderation on the wiki, bot not so much about "moderated user".

2. The current documentation says "Used as text for the link which points to the "Edit header" page." The problem is that it's not quite clear what is this page about. Is it the header of an edit? Is it a page (a whole page?) where the header of something is edited?

3. Is there any difference between "Title" and "Header"? If they are not different, then the terminology must be made consistent. If they are different, then the difference must be documented.

3.1 What about "Topic" and "Topic title"?

4. Is there any difference between "Comment" and "Post"? If there's a difference, can you please define both? It may affect the translations quite significantly. If there synonymous, please consider dropping one of them.

5. Some messages that use PLURAL may or may not need an additional clause for 0. For example, it may be needed in the message flow-rev-message-reply-bundle: "$1 {{PLURAL:$1|comment|comments}} were added. I considered sending a patch with something like {{PLURAL:$1|$1 comment|$1 comments|0=No comments}}, but then thought that it may be irrelevant in this context. Please go over all the instances of PLURAL use and add it if necessary.

5.1 What would make this message even easier to understand is, again, better qqq documentation. Currently it says "When multiple replies have been posted, they're bundled. This is the message to describe that multiple replies were posted." This is good, but it should also say where does this string appear: Near a post? In an email? What must happen so it would appear? The same applies to all messages.

6. Some messages include parameters that will be replaced by usernames. It's not clear whether this must be a username or whether it can be an anonymous user, and if it is an anonymous user, how will this be handled. This must be made clear in the qqq documentation of every such message.

7. The message flow-rev-message-edit-title currently reads "[[User:$1|$1]] {{GENDER:$1|edited}} the topic title to [$2 $3].". I suspect that instead of "edited" it should say "changed", but please check this.

8. The message flow-post-history is very hard to understand. Why the quotation marks? What's the post? What's the comment?

9. Some messages with imperative verbs include the current user name for GENDER support, and this is very good, but some don't. For example, flow-topic-comments, flow-talk-link, flow-moderation-intro-* and others.

10. In general, can you please prepare a glossary of terms for this extension? All of the above and then some can go there - moderated, header, title, board, comment, post, delete, suppress, censor etc. If "moderate" can have different meanings with different words, for example "moderated user", "moderated post" etc., then all the meanings must appear. You can simply write it as a page in mediawiki.org and make it translatable. The Wikidata project did such a thing and it was supremely helpful, even though it changed frequently throughout the process. This helps not just the translators - it should help the developers understand and plan their own work better. Amir E. Aharoni (talk) 13:11, 6 November 2013 (UTC)

Re: 3, 4, 10, see Flow Portal/Nomenclature. It's a start. S Page (WMF) (talk) 07:49, 9 November 2013 (UTC)

Flow Portal - Why discussion? - changes

I'm going to remove this large addition from User:199.255.222.82 and paste it below, because whilst there are some good points in here, it's structured more as a series of discussion points or musings, than as documentation. (I'll ping the user's talkpage to let them know, and give them an opportunity to cut and paste it into their own comment box.)

<paste begins>

Users expect a modern and intuitive discussion interface.

Talk pages—as a discussion technology—appear antiquated and user-hostile.

Their most obvious value is to teach the use of wiki editing and social conventions - so that only one set of skills would be required to edit article pages and also talk pages.

Less obvious advantages, apparent mostly to more experienced users, are the abilities to

• easily merge similar, split multiple, or refactor topics
• quickly determine origins of any character of text in case of abuses
• manage potential problems (such as misattributions, deliberate or not, or immediate corrections by oneself) with social rather than rigid technical means
• embed wiki links or spelling corrections in both one's own, and other's comments, if socially reasonable
• let any user act as moderator, for instance, archiving or refactoring text about disputes that have been settled

When abused however these capabilities can appear as disadvantages. It is largely Wikipedia's cultural norms and sanctions that prevent same. Persons comfortable with wiki source code have a marked advantage in refactoring or name changes or other decisions, as do persons very comfortable with the social conventions and willing to enforce.

Users are surprised by the cultural norms of the community.

Many things about the culture that has grown up around talk pages (such as "talkback" templates or being able to edit other people's comments) are confusing, even disturbing. That is not to say those conventions are wrong, merely not what those users are prepared for.

New users are prone to abuse these features or misinterpret their use. For instance, one well-known user involved in a discussion might correct a spelling error or bad link in someone else's comments, by way of helping them make their point, whether the correcting user agrees or not. Abuse of the exact same ability by a bad-faith editor attempting to make the initial comment appear wrong or stupid is intolerable, but of course there is no way for technical measures to detect the effect of such a correction psychologically or socially. The choice between technical and social measures in mediawiki-based "communities" has always favored the social over the technical means of control. Accordingly, very strong cultural norms have arisen and are very rigidly enforced. Not all instruction or enforcement is polite, nor could it be made polite or exhaustive - the design choices involved are ethical, not technical. The process by which cultural norms are agreed upon is political or social, not engineering.

Accordingly there is no way to make new users familiar with more technical enforcement and less open collaborative media comfortable with the wiki paradigm, until they have actual experience with wiki. Talk pages historically have been a sort of "cold turkey" introduction. Flow has potential to more gently introduce the cultural norms and ethical positions taken by mediawiki communities, while retaining the alternative of wiki-based page editing by trusted users.

We believe that a modern user-to-user discussion system will improve the projects.

Better methods for collaboration will improve collaboration, which will improve all of the projects. Mediawiki is the most widely used groupware in the world and increasingly used "behind firewalls" for corporate and nonprofit use. Many of the cultural norms evolved for Wikimedia Foundation projects are not perfectly suited for these uses, and the ability to support a diverse range of cultural norms in user-to-user discussion, with more technical controls when required, should increase the total number of mediawiki users and possibly displace proprietary pe-wiki "groupware".

Simultaneous support of the best features of "threaded" discussion media and wiki talk pages should accordingly:

1. increase the total number of users of mediawiki, by making new users more comfortable expressing themselves and becoming involved
2. increase the diversity of users of mediawiki, including projects for which more technical controls are required - which will also increase the total number of users
3. decrease the appeal of proprietary mediawiki derivations and clones which have improved collaboration features
4. decrease the appeal of competing groupware including Drupal, Joomla, Wordpress and DokuWiki
5. make talk pages more appealing visually, inclusive, and easy to understand for those unfamiliar with mediawiki

<paste ends> Quiddity (WMF) (talk) 21:10, 13 November 2013 (UTC)

Edit metadata

Of possible interest to you: Grants:IdeaLab/Edit metadata. Thanks! --Gryllida 10:47, 9 December 2013 (UTC)

Useless

How will this "flow" have anything that we expect from talk pages? How would one fix other people's comments? Archive discussions? Revert vandalism? Hat unwanted posts? Also, this is just making WP look more and more like a social network. It's a solution in search of a problem. Newbies already know how to edit talk pages. The worst thing that happens with the current system is newbies forgetting to sign their posts, which doesn't cause too many problems what with SineBot singing posts. IMO the only useful thing coming from flow is being able to watch individual threads. King jakob c 2 (talk) 20:05, 20 December 2013 (UTC)

You may perhaps wish to actually play around with it before you react with such hostility. Jorm (WMF) (talk) 20:53, 20 December 2013 (UTC)

You may consider that a) perhaps he or she did play around with it, but didn't save his efforts (or made them as an IP), and b) if you get this kind of hostility, perhaps you may consider why he or she has that reaction instead of just ignoring it. Ignoring negative feedback, even if in part parhaps unfounded, is one of the things that caused the whole VE fiasco (being an extremely immature product was the main reason, but the way WMF handled the deployment and the feedback was a major contributing factor). Treating people who give their feedback here, in the way you just did, is just repeating the same issues. Fram (talk) 10:35, 21 December 2013 (UTC)

OK, I've looked around in Talk:Sandbox, and see that I can hat unwanted posts. However, if someone vandalizes my talkpage, I don't want to collapse the vandalism, I want to revert it. And also, I don't want an infinitely long string of messages on my page, which would happen if I couldn't archive it. Furthermore, while I personally archive messages instead of deleting them, others prefer to delete them, which seems to be impossible with flow. Finally, and rather ironically, I find the whole layout to be rather clumsy and counter-intuitive. King jakob c 2 (talk) 13:24, 21 December 2013 (UTC)

Hi King jakob c 2: Thanks for the more detailed feedback. I've added those points to my notes as:

• Want to "delete" some posts (e.g. tests/vandalism, newsletters, etc), rather than "hiding" them.
• Want to be able to "archive" topics (or somehow remove them from the main display).

Both of those have also been mentioned by other editors, and are good points.

Note: Please put further feedback about features at Talk:Flow (or en:Wikipedia talk:Flow), and more detailed comments/suggestions about the layout&design at en:Wikipedia talk:Flow/Design FAQ, so that other editors are more likely to see and be able to contribute. Much thanks! Quiddity (WMF) (talk) 20:58, 22 December 2013 (UTC)

Thank you. King jakob c 2 (talk) 15:03, 23 December 2013 (UTC)