Wikipedia talk:Flow/Archive 12

Archive 5

←

Archive 10

Archive 11

Archive 12

Archive 13

Archive 14

Archive 15

Killer features

User:Erik Moeller (WMF) presents what he believe are or will be three killer features of Flow: [1] (for his full text, please read this link, the below is just a selection)

1) Fast interactions. The process of responding on a talk page is ridiculously slow (edit section, find place, indent comment, write comment, sign comment, preview, save, worry about edit conflict ..).

Problems: most of the problems given for old style talk pages are only applicable to the high-speed talk pages, for which Flow is particularly ill-suited (not enough indentation, no subsections, no indication of which post you are replying to, not enough flexibility and possibilities, much harder to keep track of pages on e.g. a daily basis, ...). Finding the right section is often harder with Flow than with normal talk pages. For most low-traffic talk pages, you don't get problems with find place or edit conflicts and so on.

2) Centralized conversation spaces. Flow's architecture is already cross-wiki; its UI is not. As pointed out, there are multiple cross-wiki discussions as well as mailing list discussions about this very topic. Wil suggested "Pick a conversation space and stick to it!". Well, wouldn't that be nice - if it worked in our universe. Except that we know it rarely does. People want to have discussions in their "home wiki", and we use mailing list threads like this for good reasons as well.

Cross-wiki discussions are the exception and are rarely needed. They also have their own set of problems, e.g. who are the admins on such a discussion, what with users blocked on one participating wiki but not the other, and so on. I have the feeling that it is not just the UI that isn't ready for this... A cross-wiki watchlist would solve most of the need for cross-wiki discussion spaces anyway.

3) Tags. The team hasn't decided if/how to implement tags yet. My own bet is that they could be a killer feature. Let people add/edit those right below the thread title with one click and see if they start using them.

No obvious reason why they can't be introduced in existing talk pages, if they are wanted. The suggested use seems to duplicate much of what certain templates already do. Has lots of potential problems though.

In any case, after more than 6 months of being live, only one of these has materialized, and its success seems to be limited: yes it's fast and easy (when you have found it, and it doesn't crash, and you don't want to add e.g. any wikimarkup), but in real life, it turns out to be way too limited and simple (in the negative sense). And it is extremely poorly integrated in the existing wikipedia structures (namespaces, history, contributions, administration, ...) So why would we have any confidence that the much more complex cross-wiki would be workable? We can't even do something simple as rename a Flow page, and it takes days to find someone to delete a Flow-enabled page... Fram (talk) 12:38, 9 September 2014 (UTC)

Fram, to be fair, there's a very obvious technical reason why those features can't be developed on top of current talk pages in an equivalent way - wiki text is not structured, so it's next to impossible to identify individual comments in a reliable way so as to copy them or associate tags to them. I agree that the Flow technology is poorly integrated with the existing mediawiki, though I hope that can be solved with enough time and effort. I'm waiting for a technical reply from Erik that would clarify to what degree Flow can be made to collaborate with existing wiki technology instead of completely taking its place. Diego (talk) 13:41, 9 September 2014 (UTC)

But Erik Moeller isn't suggesting hanging threads to individual posts either, he wants them "right below the thread title", which would be "right below the section header" in the current system. The system has no problem identifying sections (TOC, edit section), so it should be able to find all tags between a section header and the next header. Fram (talk) 13:47, 9 September 2014 (UTC)

Right, but that would make the possible functionalities more limited than what can be achieved with Flow. For example, a watchlist/stream that showed "all comments that newbies have tagged with the word 'help'" can't be achieved with templates. Diego (talk) 14:01, 9 September 2014 (UTC)

Cross-wiki discussions have additional problems not mentioned above:

• If a discussion on "wiki 1" also appears somewhere on "wiki 2", then you might accidentally reveal your IP address if your third-party cookie settings prevent "wiki 1" cookies from being accessed on "wiki 2". As an example, my third-party cookie settings prevent "wikipedia.org" projects from accessing "wikimedia.org" cookies, and vice versa.
• If "User:X" refers to one person on "wiki 1" but to a different person on "wiki 2", then participants in the discussion might find it unclear which "User:X" they are talking with. If mw:SUL finalisation ever happens, this problem will automatically go away. --Stefan2 (talk) 14:28, 9 September 2014 (UTC)

If it isn't going to be clear who you are replying to I can imagine there could be all sorts of problems. Is that really going to be the case? Dougweller (talk) 18:48, 9 September 2014 (UTC)

See mw:SUL finalisation#Status for their latest status. They're aiming for completion of the required tools, by the end of September. Actually unifying/renaming all the conflicting accounts will take a while longer, as it has to be done slow&surely with human oversight and attempts to contact all conflicting accounts. (I think they're roughly estimating Q3, so early-to-mid 2015, but it will take as long as it takes). Quiddity (WMF) (talk) 21:57, 9 September 2014 (UTC)

The real killer feature is genuine permanent links. Right now, links break when pages are archived. Oiyarbepsy (talk) 17:38, 11 September 2014 (UTC)

The real killer feature is that Article space = Talk space. This makes Talk pages a fully functional work zone rather than a crippled chat page. Alsee (talk) 13:38, 12 September 2014 (UTC)

Yes. --Pi zero (talk) 14:02, 12 September 2014 (UTC)

I don't see it a good thing that pages with completely different purposes work identically. For example, the "fully functional work zone" doesn't even have the basic function of permanent links. Not to mention that, once fully operational, wiki markup will work in post, so not sure what the advantage of the old way is in that case. Oiyarbepsy (talk) 14:48, 12 September 2014 (UTC)

I assume you don't perform a lot of maintenance tasks and keep track of large numbers of pages? When working on a huge amount of unrelated content, having a homogeneous set of tools that you can rely upon to be always available is essential to achieve efficiency. When all pages are based on a wiki model, you can always check for recent updates by comparing diffs between revisions, organize them with categories and templates, and create new complex workflows by combining those atomic tools in novel ways. All that will disappear with the current discussion-based model on which Flow is based.

They may or may not rebuild a subset of those tools that now are in frequent use (and given their very limited approach to storing diffs, it's most likely that they won't), but even if they do those tools will definitely work in a different way and such homogeneity will be lost. Diego (talk) 15:06, 12 September 2014 (UTC)

It's also fundamentally preferable to discuss technical issues with an article on a page where one can, routinely and without having to think about it, reproduce exactly the effect of any article markup under consideration for the article, and copy-and-paste between the two. --Pi zero (talk) 16:03, 12 September 2014 (UTC)

Well, we'll always have Draft space, I guess. In other wikis, it's a common technique to mix commentary with the knowledge that is being compiled in the page. Diego (talk) 19:21, 12 September 2014 (UTC)

Interesting software

And an interesting commentary [2] about the roadmap: This is a process of discovery, learning and growth. That's how interesting software gets built. Considering that Flow is going to be imposed on us all, whether we like it or not, and we are going to have to use it to build an encyclopaedia and numerous other projects, I'm not sure that being "interesting" is high on my agenda. Could we have well-built, effective and efficient, please?

However, one concrete question. Decisions are based on a lot of factors, including active work with community partners and stakeholders, feedback from community members Who are these partners and how are you engaging with them? Deltahedron (talk) 21:25, 12 September 2014 (UTC)

Some use cases for non-linear navigation

Here are some workflows that I typically perform at talk pages and which are not well suited for infinite scrolling, though relatively easy with numbered pages. Let's see if Flow design can be made to support them well.

• Find the period of time when a talk page was most active throughout its history (for example, to track a time of fast article development and/or a controversial discussion). I often do this with a manual binary search through the archives.
• Get a random sample of topics that were discussed throughout the whole life of the page.
• Read the archives from oldest to newest (a simple reversal of the current ordering would allow this, but it seems developers didn't think it would be necessary - they even listed this requirement as a problem!).
• Read in order all the threads that were visible at the talk page on 31 Aug 2010 (i.e. those that were not archived at that particular time). This is useful when there is a period of large activity and you want to find out the most important discussions that took place around that time, without being distracted by those that were manually archived. Also, reading them in order is important because many discussions span several threads in sequence. Flow design, with their detached topics (that are automatically reordered) and no subsections, does not take this into account. (Although, thinking about it, something similar could be achieved by allowing threads to be displayed by chronological order, jumping to a particular date, and skipping discussions that were closed and summarized).

The infinite scrolling is clearly simpler than the current one, but for those needs it has been made too simple - those workflows are impossible to achieve through scrolling or simple search. Diego (talk) 15:27, 12 September 2014 (UTC)

Related question: will we have pagination for really long TOCs, like we do have paginated archives now? Or do we get the same problems of infinite scrolling and no random access withing the TOC? Diego (talk) 15:55, 12 September 2014 (UTC)

Simply a view from a Flow page at one specific point in time would be a basic requirement. As far as I can tell, one can't see how Wikipedia talk:Flow/Developer test page looked 4 days ago or 3 months ago. That's not even asking for "compare two diffs", the difference between the page at time A and time B. Fram (talk) 17:14, 12 September 2014 (UTC)

I have no hope that requirement can be ever achieved, as there's no such thing as a Flow "page" - as far as I can tell, the way they've built flow is by creating a new wiki page for each comment. However, finding out what comments have appeared in a board since the last time you visited any of its topics should be achievable, and showing just those comments while hiding the rest (the closest possible thing to a diff on a Board); after all, they need to detect those comments in order to update the Echo notification. Diego (talk) 19:38, 12 September 2014 (UTC)

@Fram: This should be fairly easy to implement, since all we need to do is hide all posts after a given date. -- Ypnypn (talk) 19:47, 12 September 2014 (UTC)

• I think this raises the interesting question of the balance between the extent to which Flow is intended to duplicate existing talk page structures and systems and the extent to which it aspires to control them. Is it a design principle that every workflow in existence will continue to be possible under Flow, with only minor technical modifications -- or will the Flow team take the opportunity to radically simplify, prune, remove, merge or otherwise rewrite existing workflows? In other words, how often are we going to see an exchange along the lines of "I'd like to be able to do X for purpose Y" "No, we've decided you don't need to do that"? Deltahedron (talk) 20:06, 12 September 2014 (UTC)

During development we'll see a lot of "I'd like to be able to do X for purpose Y" (with varying Yes and No answers), but if it reaches "final deployment" that's pretty much the end of that. No one is going to initiate an impossible effort to get developers to rewrite the code every time someone get an idea to experiment with something new. Our current methods are organically grown out of clay. Our fundamental workflow is to build articles out of Wiki, to build discussions out of wiki, to build workflows out of wiki. Flow takes away our clay home and attempts to impose metal hallways that resemble our current workflows. But the fundamental workflow of building and reshaping things out of Wiki is broken. Alsee (talk) 21:18, 12 September 2014 (UTC)

This comment [3] suggests that design, development and deployment are being taken in an order different to the one I would have employed. Deltahedron (talk) 21:28, 12 September 2014 (UTC)

I guess this highlights the power of the wiki-model. The software does very little: a page of text with markup stored as successive revisions. With this model the use-cases are determined by conventions of the users of the software. Its relatively easy to implement a new use-case all it takes is a new page of policy. While some tasks may take a little longer to perform most tasks as possible. This offer great freedom for the users, and shows the simple idea which has made wikis successful. I'm a little worried that we are forgetting the the spirit of wikis and the freedom it allows.--Salix alba (talk): 22:02, 12 September 2014 (UTC)

You might want to strike out "we" and replace it with WMF. Alsee (talk) 01:25, 13 September 2014 (UTC)

Bots

Just a question, does this mean that message-leaving bots (antivandalism bots, bracketbot, message-delivery bots) will all need to be rewritten to use flow as well? And how will this be in the intermediate time, when some users use flow and others still the old talkpages? --Dirk Beetstra ^{T C} 09:10, 11 September 2014 (UTC)

In the long term, yes, as the WMF expects that the new software will replace current talk pages. In the meantime, bots will need to detect if a talk page is created as a Flow page or a Mediawiki page and use different APIs to change them. Diego (talk) 10:59, 11 September 2014 (UTC)

Facepalm . And detecting earlier warnings to editors (do we still have a 'history' to retrieve)? {{nobots}}? ... --Dirk Beetstra ^{T C} 11:03, 11 September 2014 (UTC)

The last I've heard is someone suggesting to keep a separate "meta" page with wiki format, for keeping track of all such content that needs to be archived for attribution and tracking of milestones; the proposal seemed to be well received by the development team. Which is an advance, since at the beginning of the project one developer in particular was adamant that editors would be forbidden from using the old style talk pages. Diego (talk) 11:31, 11 September 2014 (UTC)

... was adamant that editors would be forbidden from using the old style talk pages. I would like to see the link for that if you have it please, Diego. BethNaught (talk) 11:54, 11 September 2014 (UTC)

Thanks for asking that, I am also curious. Is (was?) that an argument similar to deployment of the MediaViewer? --Dirk Beetstra ^{T C} 12:11, 11 September 2014 (UTC)

Name the sin, but not the sinner. The scuffle happened in the context of a discussion where a couple of experienced editors commented that they always would have the option to ignore Flow and keep creating talk pages for discussion instead, and this developer implied that this shouldn't happen, ever. I have to correct myself though; I had misremember the exact strength at which the developer defended the replacement (he considered using both systems a bad, unfeasible idea, but didn't ever threaten to forbid it), but he made it absolutely positive that Flow was clearly intended as the only option for discussions in the long term.

As for bots, reviewing the archives I've seen a comment implying that bots should be able to handle Flow through the same existing API for editing comments; I don't know to what extent bots will need to be adapted, but if it supports the same interface, the change should not be as radical as I thought. Diego (talk) 12:38, 11 September 2014 (UTC)

From the current WP:Flow page: "At some point in the future, once the software is stable and a significant portion of active Wikimedians have had a chance to trial it and offer their feedback, we may mandate Flow on all discussion pages, but we have a lot of work ahead of us before that happens." (emphasis mine) So it looks like they hope that mandatory Flow will happen, but realise that stating that in such terms may not be universally welcomed... Fram (talk) 13:40, 11 September 2014 (UTC)

I'm disappointed you didn't provide the link; however, this different thread WT:Flow/Archive 2#WMF intends for Only VisualEditor to be usable on Talk pages under Flow; representative states he would "dearly love to kill off Wikitext". is instructive. Apparently we are supposed to have "Zen acceptance" that change is being forced upon us when we don't necessarily want it. That statement is offensive. BethNaught (talk) 13:47, 11 September 2014 (UTC)

@BethNaught: Wow, I'm pretty sure we'd all dearly want to kill off wikitext, for it is utter garbage, and replace it with a sane markup system that was designed (in the good way) and thought-out, rather than grown on top of its older incarnations like mold – but it is also clear to everyone that we can't do that without a massive effort and pain that makes it very much not worth it. That looks like an offhand remark and it sounds like really bad faith to treat it as "offensive statement". (For a technical correction, both possible Flow backends – wikitext and HTML – support templates as we know them and can be seamlessly converted to each other; I'm not going to dig down deep enough to find out if Jorm was wrong or if his words were misinterpreted, but such a conclusion is clearly incorrect.) Matma Rex talk 17:59, 11 September 2014 (UTC)

@Matma Rex: I was talking about the part where he told us to have "Zen acceptance", because I find it offensive to be told by someone who is supposed to work for us to suck it up when we're given something nobody has even asked us if we wanted. In any case, I disagree that wikitext is garbage – the only hard parts are tables and template syntax (as in parser functions and the like). BethNaught (talk) 18:11, 11 September 2014 (UTC)

When compared to other statements made by that particular contributor, it does not seem like an "offhand remark". Instead, it seems to reflect his attitude towards the rest of the community:

::And there you're wrong, and this may be why you seem to have difficulty communicating. Let me disabuse you of a notion: We are ''not'' your servants and never have been. --[[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 01:09, 15 October 2013 (UTC)

172.56.38.251 (talk) 18:32, 11 September 2014 (UTC)

Brandon is quite right: the WMF staff are not our servants. They do, however, work for us, the users who share and create knowledge [4]. Deltahedron (talk) 11:14, 14 September 2014 (UTC)

It is not a problem, as long as it does not override old functionality: XLinkBot (one of the bots I operate) loads the last # diffs of a page, and parses the edits to find the 'highest' level spam-related-warning left and when (either by the bot or by humans - if a human left a {{uw-spam4im}} or the bot a {{uw-spam}} in the last hours and the editor continues, then WP:AIV is alerted and no warning is left; if there are none, the bot will be more friendly with the 'spammer'). Parsing the text of a page is useless - editors regularly remove warnings (their full right, it means they noticed the warning at least, the more reason to use a higher level warning). As long as the flow (no pun intended) can be parsed by a bot it is fine with me (well, sigh, I have to figure out HOW to parse it). Also, having a possibility to have a personal 'template' at the top would resolve the {{nobots}} issue. --Dirk Beetstra ^{T C} 11:52, 11 September 2014 (UTC)

Actually, the task you describe above would probably be a lot simpler since user would no longer be able to delete the warnings, as I understand it, so you probably wouldn't need to check the history at all. Oiyarbepsy (talk) 14:44, 11 September 2014 (UTC)

Easier .. the bot needs to check page histories on pages itself, it is hence built in, easier would be to leave it as is so I do not have to 'write' two different mechanisms for the two different namespaces. So it is not 'easier'. --Dirk Beetstra ^{T C} 03:31, 14 September 2014 (UTC)

• Flow was originally intended to be not just a talk page system, but a workflow management system (hence the name). A year or so ago, there was discussion here and a summary "in terms of loosely-structured workflows, breaking them down to their components, and optimizing for the best possible outcome with software... and actually writing a workflow engine for every non-article page on Wikipedia. The former is what we're currently doing with Flow. The latter is where I don't want us to go; at least, not yet" [5]. So Flow is intended to cater for all the common components of work at a discussion page, which would currently implemented by bots, templates and so forth. Under Flow, all these ad hoc mechanisms devised over the years by the various communities will be replaced by components within Flow. The need for research into what these workflows might actually be was due to start a year ago. I see no evidence that it has actually been carried out: no substance has been added to m:Research:Wikipedia Workflows for two and a half years and mw:Requests for comment/Workflow was last updated eight months ago. The conclusion is that for the last year the Flow team have known they would need this information to design and implement Flow as a workable platform for discussion pages, and yet have done nothing to gather it. The result is that they simply cannot know what it is they are designing for. I have to say that this is merely what I can see as an outsider looking in, so would be happy to see that the research is finished, documented and ready to show to the community for review and acceptance. I would assess that even to document and redesign the workflow processes on one sort of Egnlish-language Wikipedia talk page will take some weeks of effort, and there are hundreds of languages and a dozen projects to follow. This seems ... ambitious. Deltahedron (talk) 18:48, 11 September 2014 (UTC)

Workflow research 2

There are a number of workflows, standardised actions, messages and so forth that are currently handled on various kinds of talk page by a variety of templates, bots, social conventions and so forth. Flow is going to have to make it possible to perform all those actions, although not perhaps in the same way. Given the desire to roll Flow out to a variety of production wikis by the end of December (Q2 in WMF-speak), it must surely be the case that the Flow team are confident that all the major workflows on those pages will have been incorporated. It would be interesting to see the working list of what those workflows are, what the dependencies are, and what actions will be required of the participants, bot maintainers, template authors and so on. The reason I suggest this exposure is that contributors here and in other locations may be able to help if, as is within the bounds of possibility, the list is not quite complete, accurate or up-to-date. Deltahedron (talk) 19:43, 12 September 2014 (UTC)

Note: Discussed further at #Use cases and #Workflow_research above. (This section retitled to fix duplicate). Quiddity (WMF) (talk) 20:57, 15 September 2014 (UTC)

Snapshots

This comments on two threads above, so I thought I would start a new one.

On Wikipedia, it's relatively easy to see what a talk page looked like at a given time (although changes in templates may change appearance).

In Flow, it's relatively easy to see what a message looked like at a given time (although whether it was hidden or no at the time may require a separate search); in the present configuration, the "template" problem.

An approximate look as to what a thread looked like at a given time would be to "remove" all messages after that time (ignoring actual message editing, which the Foundation seems to be doing), but, determining which of the remaining messages were hidden is difficult. [On the other hand, if messages were hidden for good reason, there could be a problem.]

Determining what the entire talk page-equivalent looked like at a given time is, because of the additional level of complexity, would be almost impossible.

But that last is what would be required to determine whether the article reflected the consensus at the time. — Arthur Rubin (talk) 19:40, 13 September 2014 (UTC)

Tag this one as a bug We need history links for every page, including talk page. The links in the page history don't actually link to the page version, but to the topic namespace, which is completely against expectations and against how every other wiki page history works and not as it should be. Oiyarbepsy (talk) 01:02, 16 September 2014 (UTC)

I am making a prediction.

This so-called "feature" is what is going to make the fork happen. I am predicting it. I don't want this on my talk page, or the talk pages of any articles I edit, as it is ugly, I can't see the source, it has this infinite scroll crap, I'm unable to customize my archives, I can't search the flow archives, if I want to demo complex wikicode on the talk pages, I am unable to. This just takes away so many features, and for what? So new editors can participate better? It's not that hard, you just type in your heading, and what you want to write. You don't even need to sign anymore, as Sinebot does that! {{ping}} is very helpful to use, yet this goes too far. This will be the straw the breaks the camel's back. Grognard 123chess456 (talk) 14:06, 10 September 2014 (UTC)

Actually, one of the key benefits of flow is that it will eliminate archives, so you'll have no need to customize them at all. You can create a link to a topic on a discussion like this (Can I opt-in at my talk page?), and unlike archiving current talk pages, the link won't break. As far as wikicode, I'm not sure why you need talk pages for that when you have sandboxes and user pages, and with flow, you generally won't need complex templates on talk pages. As far as eliminating signing, don't forget that the current system makes it very easy to impersonate other editors, something that will be essentially eliminated with flow. On the other hand you might be right - Spanish Wikipedia forked over the mere rumor of advertising, so I wouldn't put it past English Wikipedia to do something just as stupid. Oiyarbepsy (talk) 14:37, 11 September 2014 (UTC)

"As far as wikicode, I'm not sure why you need talk pages for that". This was explained at mw:Thread:Talk:Flow_Portal/Maths#Maths_32131 a year ago. It's because Flow is a device to, among other things, help people collaborate on writing encyclopaedia articles. Deltahedron (talk) 20:39, 11 September 2014 (UTC)

And how are you supposed to browse old discussions? Searching, yes, but that can't take you to a particular time (or, if it would, we don't know that because the WMF hasn't built the damn thing yet). You can't get a sense of the discussion history. At the very least, pagination of Flow boards with a functional TOC is the minimum required for past thread navigation.

As to forking – who'll host it? At any rate though, many users will boycott it. I already don't donate to the WMF because I don't want my money to be spent on this monstrosity. Then again, as we all know, kind old Jan-Bart doesn't care if people leave over Flow. BethNaught (talk) 14:44, 11 September 2014 (UTC)

I'm inclined to agree Flow will likely finish the sisterhood under the auspices of the WMF. If they play their cards cleverly (not that they've been clever about it so far), perhaps they can demoralize the community in small stages, and thus avoid a fork until the spirit of the movement withers and dies (like the urban legend about boiling a frog). There are imaginable scenarios in which, sooner or later, they effectively abandon Flow, but while imaginable, those scenarios don't look likely atm. --Pi zero (talk) 15:17, 11 September 2014 (UTC)

You browse old discussions same way as any news comment board - keep scrolling down and older posts load as you go. Pages don't "archive" as they do now, so if you need to refer to a discussion, you can use the topic wikilinks and they will remain valid forever (while current talk page section links break as soon as the page is archived). There is still a history tab if you're looking for a particular date but you're not sure what discussion it is. Oiyarbepsy (talk) 18:29, 11 September 2014 (UTC)

Have you ever tried doing such a thing while on a slow connection? Let's just say, I'm not a big fan of infinite scroll. This has been discussed several times by now, so I'm not going to repeat it all. Pagination and a table of contents do have some advantages and for some use cases a search engine alone will probably have some difficulty providing help. AFAIK pagination will have to be in place as a fallback for non-javascript environments anyway, so, why not at least offer it as an option to everyone (I'd be interested in seeing what will be used more)? --HHill (talk) 20:23, 11 September 2014 (UTC)

Good point. I personally have no problem with splitting into pages for people who want that option, as long as it's automated. Oiyarbepsy (talk) 20:34, 11 September 2014 (UTC)

Talk pages are not news boards, and many times I don't browse them as such. I rely heavily on the table of contents to skip all about subjects that don't catch my attention, and often jump randomly throughout the archives of an old long talk page to get a sample of the kind of discussions that are typical for such article. Sequential access is awful for those use cases.

Having permanent links that work from day one and don't break is certainly a nice addition. There's no drawbacks to that. Diego (talk) 15:16, 12 September 2014 (UTC)

Don't know much about programming, but I bet that this can be solved pretty easily by having a bot update any broken links. We don't need Flow for that. (Far as I can see, we don't need Flow for anything). --Randykitty (talk) 16:02, 12 September 2014 (UTC)

It appears that User:ClueBot III might do just that when it archives. But most of archivebots don't, and as far as I know, nothing is dealing with the thousands of broken archive links already around. Besides, bots are a hack, and something like this should be part of the software. Oiyarbepsy (talk) 02:57, 16 September 2014 (UTC)

@all: Pagination is already available for non-JS users (it's not beautiful yet, but it does allow loading 10 topics at a time).

The infinite-scroll default is going to be re-examined, but it ties deeply into a number of things such as archiving and topic-sorting, so Danny wants to get the upcoming ToC and Search into place, before looking at it again.

There is a ToC coming, in some form or another.

There are plans to examine the various ways we currently archive things (beyond my 2 sets of notes), as well as ways we might want to add to that ability. (Eg. the currentkly hackish {{DNAU}} for "sticky posts" and User:ClueBot III/ArchiveNow for "insta-archiving")

Everything marked "Experimental" in Wikipedia:Flow/FAQ#Components of the discussion system (and more!) is still completely up for discussion, and a few of them will be changing for sure. There's good news coming soon, on some of these other long-running questions. Quiddity (WMF) (talk) 01:04, 12 September 2014 (UTC)

@Quiddity (WMF): I've added a few navigation use cases that aren't well served by infinite scrolling+autoarchiving+search, see below. Diego (talk) 15:31, 12 September 2014 (UTC)

A different direction

Suppose, just for a moment, that Flow, rather than being an alternative mode for a page, were something that could be embedded on a page. That is, one would have an ordinary wiki page, and somewhere on it one could have some markup (for example, perhaps a magic word) to embed a Flow discussion forum. Each community would then have the option of deciding whether, where, and how to embed such things.

This, hypothetically, could be a win–win: For the wiki communities, it could transform Flow from a straightjacket that would prevent the community from functioning, into an additional degree of flexibility that the community could explore using to enhance its functions. For the Foundation, it could transform the Foundation–community interaction on Flow development from adversarial to mutually supportive, with both sides looking for ways to make Flow more useful. If Flow isn't made sufficiently useful, it doesn't get used, and that wouldn't be fatal for the communities or for the wikis or for the Flow project itself: it would just mean looking for ways to make Flow more useful, a process in which communities and developers would be on the same side.

Issues that immediately leap to mind:

• How to arrange that a flow forum would look natural both when it was the only thing on a page and when it shared the page with other material.
• How to arrange for a TOC on a wiki page to include content from a flow forum. Likewise for something akin to an archive menu.
• Whether it should be possible to have more than one Flow forum embedded on a page.

--Pi zero (talk) 13:32, 13 September 2014 (UTC)

This would be tricky to get right, but may be viable. Certainly better than what they're planning now (a dangerously misdirected chat board with a crippled undefined "scratchpad" to be bolted on.) It also reminds me of the various requests that Media Viewer be changed into something that can be embedded into a page, perhaps with an image gallery attached. Alsee (talk) 03:22, 14 September 2014 (UTC)

(edit conflicted!) Pi zero this is one of the most sensible ideas I've seen on this page. As soon as the "Discussions cannot be embedded yet." condition goes away, should be trivial for a page to have a Talk: and perhaps a Flow: page, and just embed the Flow page on the talk page in a frame if you wanted it. — xaosflux ^Talk 03:27, 14 September 2014 (UTC)

Very good idea. Various embedded discussion tools (Flow as a structured discussion, or maybe a poll tool) could be used in addition to what we have now. That way, Flow would not have to destroy the flexibility our current talk page system has, while still making some discussions easier. (In my mind, flexibility is more important than structure, but I understand that some people disagree with that). —Kusma (t·c) 06:53, 14 September 2014 (UTC)

What use would the Flow page, or part of the page, be likely to be put to? If Flow hinders or makes impossible the various modes of working that are required to collaboratively write and edit articles, then all that work would remain at the wikitext part of the page, and the Flow page would become a sort of chat room for people to discuss the article topic at large. I believe that this is exactly how Wikinews works, but not Wikipedia, where this is explicitly not what the article talk page is for. Is augmenting an encyclopaedia article with a chat room likely to make it easier to write the encyclopaedia, or to assist in the goal of retaining old editors and attracting new ones? Deltahedron (talk) 09:18, 14 September 2014 (UTC)

I don't know. But it is certainly better than replacing the current discussion pages with a chat room. To be useful for anything other than chatting, Flow would need to offer features that make it a superior tool for things like RfCs. I can't imagine something like a Requested Move discussion (which has "votes" and "comments" that belong to each other in some way) in the current Flow software. —Kusma (t·c) 09:32, 14 September 2014 (UTC)

That we can agree on. By the way, the use cases are at mw:Flow/Use cases: Requested Move do not seem to be listed. Deltahedron (talk) 11:02, 14 September 2014 (UTC)

(edit conflict) In principle, Flow shouldn't need to work as a chat room; this is just the way the development team has decided to build their discussion application on top of the platform. Technically, at its core Flow is a collection of individual comments, each one with its own individual history of edits. The way these comments are related to each other is called a definition; they're thinking of building definitions for polls, RfCs, and other discussion workflows, but not for collaborative editing of the page as a whole.

We have to convince developers that we really need a "wiki definition" that allows us to work with content they way we're used to, with a common history for edits from all editors, as the functions of a wiki are essential to the existing methods by which we build and maintain the encyclopedia. Diego (talk) 11:13, 14 September 2014 (UTC)

What the Flow team need as a matter of urgency is a workable description of some of the major wiki ways of working on en.wp. The Use cases page I pointed to is woefully underpopulated. Perhaps contributions from here would be helpful. Deltahedron (talk) 11:19, 14 September 2014 (UTC)

If the developers do not already know that, then the best-case scenario for Flow is that it is a huge waste of time and money that will never be widely rolled out. —Kusma (t·c) 15:46, 14 September 2014 (UTC)

In practice, Flow's current incarnation will make the pages more like a chat room then anything else, and maybe there is use for it; by having the talk space support BOTH flow and traditional talk (perhaps side-by side layout style, especially with Flow wanting to limit its pixel width) - slow moving discussions, notices, tags, etc could stay in a prominent location while also allowing the chat style flow---and in my opinion a page should default to not having the flow at all, but having an easy way to 'start a flow' alongside the general talk would be a better introduction to any of the benefits of flow that are not being considered right now. — xaosflux ^Talk 14:08, 14 September 2014 (UTC)

Why don't we use talk pages for most of Wikipedia and flow for those pages meant to be a chat room... oh wait, no part of Wikipedia is supposed to be a chat room. How about we just stick with the talk pages that have worked great for the last decade? Chillum Need help? Type {{ping|Chillum}} 15:58, 14 September 2014 (UTC)

I tend to agree with you, but if Flow is inevitable I'd rather see if be a bolt on instead of a complete replacement for what works so well. — xaosflux ^Talk 16:03, 14 September 2014 (UTC)

• DannyH (WMF) and/or Quiddity (WMF) any feedback on this section? Would this type of use even be entertained (as opposed to "Flow or Fork")? — xaosflux ^Talk 04:17, 15 September 2014 (UTC)

We definitely need a way for Flow to exist alongside other page elements. Right now, I'm thinking about approaching it the opposite way -- to have editable wiki areas as elements within a Flow topic page. But it's early days on that concept, it's still just speculation at the moment.

Flow also needs to have a way to support votes, as Kusma mentioned. The RfC-style use case is one of the harder ones to approach, and there's still fairly basic elements to build, like a table of contents. So it'll take a while before we get close to the RfC functionality.

As I wrote in the thread just above, I totally understand why people are afraid that the current version of Flow will suddenly be deployed on RfC pages, and why you're asking me to respond to the threat of forking. There's lots of work still to come before it would be ready to go anywhere outside the test pages. DannyH (WMF) (talk) 18:57, 15 September 2014 (UTC)

Hi, DannyH (WMF). Some thoughts on flow-embedded-in-wiki versus wiki-embedded-in-flow. (Where I'm coming from: I'm a CS PhD with one foot in hacking and the other in theory, dissertation in programming language design, who's spent the past several years approaching the problem of wiki-enhancing software design by immersing myself in the wiki I want to enhance. What I came up with as a concept, which I see as potentially invaluable to all the wikis (not just my home wiki) once the i's are dotted and the t's crossed, is described at n:Help:Dialog.)

There are two ways to approach flexibility, the general road and the specific road.

Wiki markup takes the general road. One of the key reasons it's so successful (sic: wiki markup isn't the cause of any of the modern flaws of the movement) is that it's pretty much infinitely maleable. Someone else here has been comparing it to clay, which imho is apt. What you can do with it is limited mainly by your imagination. And that includes what you can do in a discussion on the talk page of an article; I'll come back to that point in a moment. When you add feastures to the system, your purpose is to add power, withoug bolixing up the flexibilty of the whole.

From what I understand of Flow, it takes the specific road. A system like that tends to start out powerful in some particular way, but inflexible. When you add features to it, they're typically meant to add flexibility as much as power. And you'll never get to the sort of flexibility that the general road starts out with. No matter how many "use cases" you come up with, there's always something else left out; you're stuck perpetually playing catch-up, trying to add parts of the intrinsic flexibilty of a general system. When using wiki-markup talk pages, any time an unusual case comes up, you simply use the natural maleability of wiki markup to achieve whatever is needful — and there's no way to anticipate everything that might come up. A specific-road system can't duplicate the sponaneous flexibility of a general-road system.

Particular features within a general system, such as wiki markup, are —well— particular. But a successful particular feature within such a system preserves-and-enhances the flexibility and versatility of the whole. It tends to require deep insight to fashion a new feature so that it will synergize that way with the whole; it's easier to just tack things on for particular purposes, which has too-often happened in the past of wiki markup; but that's at least as likely to happen, perhaps more so, when features are added to a specific-road system. And the system on the specific road has a starting handicap on flexibility that it could never fully compensate for even if all its added features were wonders of elegant design.

Hence, I reckon Flow can't get to where it needs to be by replacing the wiki structure and then trying to add stuff back in; it needs to find a way to fit itself into the wiki structure — and then really work on making itself fit smoothly within that structure. So to me, Flow-embedded-in-wiki is the option that has the potential to lead somewhere good (though nobody's claiming this will be easy). --Pi zero (talk) 22:06, 15 September 2014 (UTC)

@DannyH (WMF): This talk page has laid out some well-founded arguments of why Flow, even when it reaches its feature-complete status and fulfills the vision that the development team has presented, will still not be an adequate match for our needs. Some editors participating in the discussion have solid professional knowledge of software development and the principles of groupware, and we can analyze and evaluate the possibilities not just of the current tool but of what it can become. Your words are well meaning, but do little to dispel our worries. The fact remains that you misunderstand our concerns as mere evaluations of the current status of the tool (which are not) and you haven't acknowledged the reasons why we prefer a different approach to Flow, instead of the one that has been laid out so far.

I have a background in information architecture and knowledge capture, and I completely subscribe to Pi zero's analysis of the benefits of a flexible tool that follows the "general" approach, and the advantages of a true wiki as the basis for such platform; certainly, n:Help:Dialog looks much more promising than Flow from a philosophical point of view. Yes, that approach may look like heresy to a developer well-versed in industry standards, but then those standards evolved to satisfy the needs of corporate applications with a few predefined business workflows, not world-class collaboration platforms trying to capture the world's knowledge. ;-) Let me add that a tool which allows representation of unstructured an semi-structured content will always be a better match for knowledge capture in its early stages than a fully structured tool: having to match the structure imposes a burden on users that can leave some knowledge outside of the system, because of the friction entailed in adjusting to the expected format. Wikis, as friction-less tools for capturing knowledge, are the most advanced systems that humanity has devised for knowledge and content capture (only on par with the empty page and ink), as the structure of information can be built incrementally instead of imposed by the software.

We have suggested ways in which Flow could be made to conform to our expectations as users experienced in the usage of the tool for collaboration and coordination; unfortunately it seems impossible to reach you and make you recognize and value these suggestions, as you provide no feedback that these have been heard; and everything suggests that the decision on how to build Flow was made long ago, without input from the community and before initiating the project to understand the particular ways that we use talk pages, and that there's no way that early decision can be influenced by what you find along the way.

You ask us to trust you that you'll be able to develop a capable tool, yet give very little on what to base such trust. Please, address at least the concerns about the communication between the community and the development team, and improve the channels we use to follow track of the project, as we have repeatedly asked. Start by designating a single centralized official forum on which all decisions are communicated and all doubts can be asked (which are now scattered between this page, mediawiki, the mailing lists and the bug tracker), and update it thoroughly with your current understanding of the requirements and the existing community processes. Make a priority to improve your understanding of the existing flows for both new and experienced editors, above any development of new features, and make all decisions subordinated to gathering data that can support those decisions - maybe using some partial development as a prototype to gather some new knowledge, but not as a final feature. This is the only process I foresee that can followed so that we gain your trust. Diego (talk) 23:11, 15 September 2014 (UTC)

I totally understand what you're saying, and I wish that I had time to fully engage with this discussion. Unfortunately, right now I've got limited time for large-scale philosophical discussions. We're a very small team, working on a very large and complicated project. Quiddity and I are fielding feedback at multiple wikis and mailing lists, as well as triaging bugs, testing code-updates and getting some more features designed, built and out the door. We're reading everything, but we can't scale to reply to every comment.

A lot of the philosophy and architecture for Flow was hashed out with Jorm and others over the last couple years. My job at the moment is to take the current philosophy and architecture, and turn it into a working feature. I think the way that I can be most helpful to this project right now is to actually do more work on the feature, so that we have more to talk about. DannyH (WMF) (talk) 00:33, 16 September 2014 (UTC)

Thanks, Danny, that's the kind of honest answer that we needed. At least we now know that our concerns were heard, although there's little that can be done about then. With this confirmation of what we suspected, it's clear there is little use in trying to push Flow to meet our expectations in the medium term. I hope there will be a later revision, after the current minimum viable product is rolled out according to the original, limited plan, and that there will be time in the future to embrace this talk about the possibilities of the software, that is meant to completely replace the tools we have now but which was never debated as such. Diego (talk) 06:26, 16 September 2014 (UTC)

@Pi zero: Thanks for this analysis, it's a very interesting read and I agree with most of it, though not with the final conclusion: I don't see a principal difference between flow-embedded-in-wiki and wiki-embedded-in-flow in terms of the practical functioning of a page. There are technical limitations at the moment (we don't have scratchpads in Flow yet and the ones in the making are limited by parsoid), but that's a problem with the currently existing code, not with the general idea.

Plus, IIRC the plan for Flow is not only to develop additional workflows besides the simple conversation module we see now, but also to implement a way to modify and add workflows on-wiki, without need for software upgrades (@DannyH (WMF): correct me if I'm wrong). So at that stage Flow could do everything our current talk pages can do (by having each topic a wiki-scratchpad), plus it could do more, plus it would have additional flexibility for teaching it even more.

That said, once Flow is in reality developed enough, such that flow-embedded-in-wiki and wiki-embedded-in-flow makes no difference from a user's point of view, then it doesn't matter which one we use, so I don't oppose either model. But I realize that's the far future we're talking about here. I don't know which variant would be easier to implement and/or more useful as a mid-term solution. — HHHIPPO 07:29, 16 September 2014 (UTC)

@Hhhippo: Well, there's a clear practical difference between wiki-inside-Flow and Flow-inside-wiki that makes the former more limited, which should be easy to understand and doesn't depend on philosophical lucubrations: a wiki scratchpad embedded within a Flow board will not enjoy any of the purported benefits of the structured platform - no content ownership, no clear separation of individual contributions, no avoidance of edit conflicts, no notifications and subscription to just a part of the updates, no automated or semi-automated reordering, filtering and classification. The idea of the scratchpad as it has been suggested amounts to exactly what we have already, with the same reliance on old unadorned wikitext, just presented within a new context surrounded by forum-like threads. If there are no improvements to the collaborative writing experience, why should we care about it? It's clear that this option is easier to implement by developers and that they will favor it along the way, but it's not the best fit for our needs; a structured board where each comment is a wiki scratchpad does not allow for all the possibilities of current talk pages.

On the other hand, the capability to embed Flow comments and threads within a wiki page would open a large range of possibilities for a groupware tool: real time collaboration, review comments embedded alongside article content, those are options that have been suggested as welcome applications that would provide a real enhancement to current talk pages (or even article and draft space!), but they require that Flow content is subordinate to a free-form whiteboard structure, not that it imposes its own.

With respect to the planned workflow-building module, everything points toward it being oriented to communication and community-building workflows (the points of pain of our current wiki talk pages), but there are well-founded doubts that it will be flexible enough to support the other types of current workflows, as Pi zero has explained well. Diego (talk) 10:34, 16 September 2014 (UTC)

@Diego Moya: I wasn't thinking of one wiki scratchpad per Flow comment, that would indeed combine the worst of both worlds. I thought of one wiki scratchpad per topic and/or per board. Of course these scratchpads would have to have the full functionality of wiki pages, with all markup possible, full page width, categories etc., so more than the current Flow board headers can do. If we have this on one hand, and magic words for embedding a Flow board in a wiki page on the other hand, then the difference between the two scenarios more or less comes down to which software generates the section headers. I don't know which one is easier to implement, my feeling would be Flow-within-wikitext, but that's for the devs to comment on.

Regarding the workflow-building module: well, if what's planned now is not good enough, then something better has to be planned. I know many people here doubt that the WMF can be convinced to put all the features we need into Flow, but that's the same problem for the workflow-building feature and for the Flow-embedded-in-wikitext feature. If it turns out to be easier to get the latter, we can use that until the former is ready. — HHHIPPO 18:44, 16 September 2014 (UTC)

More MVP (minimal viable product)

In addition to complete board and topic diffs, the watchlist and raw watchlist must be understandable. In other words, the watchlist and/or echo notifications must read something like:

User (Username) added a message to Topic:TopicId (Topic header name) on board (Boardname).

not

User (Username) made a post on board (Boardname)

or

User (Username) added a message to Topic (TopicID).

As I mentioned before in regard granularity, we also need the ability to separately watch

New topic creation (as a watch level of the board)

New message creation (as a watch level of the topic)

Topic split or combine (if any topic in a split/combine is watched, all must be watched afterward)

Message editing (could be at the topic level, rather than needing to be granular to the message level).

Protection levels should also be settable on a board, topic, or message level, and the individual scratchpads/header sections must separately have protection levels. If you can hide/delete/suppress threads or messages, it is logical that someone can set protection levels for editing at the same granularity. This last is not a requirement, but it would certainly be a detriment to Flow if an entire board needs to be semi-protected, rather than just certain threads. A minimum requirement is that boards can be protected or semi-protected, and moved retaining the protection.

As I said earlier, if Flow is to be used for an actual discussion of articles, each topic, if not each message, needs to have a visible header or scratch area, which renders as it would in article-space (including screen width). — Arthur Rubin (talk) 16:42, 18 September 2014 (UTC)

Window Usage

Maybe it's me, but I dislike how Flow only goes halfway across the page. The usual rage page format goes all the way across, so I have two and a half inches left over on a laptop with Safari. Origamite^{\(·_·\)(/·_·)/} 16:17, 11 September 2014 (UTC)

See WP:Flow#Design FAQ. I know, I don't like it either. What would be good is if the WMF allowed it to be customised with user CSS. BethNaught (talk) 16:21, 11 September 2014 (UTC)

Also, I think that the "Watch page" star should be near the view history again, instead of at the top of the topic. I had to look for it. However, if the majority finds that preferable, okay. Origamite^{\(·_·\)(/·_·)/} 17:02, 11 September 2014 (UTC)

That is a fun read. I like best that the annoying whitespace is not only deliberate, but also an attempt to reduce my stress level. Maybe we can get pictures of cute puppies instead of whitespace to reduce our stress levels even further. —Kusma (t·c) 18:47, 11 September 2014 (UTC)

No! No! That's a horrible idea!! It should be kittens!! --Randykitty (talk) 19:30, 11 September 2014 (UTC)

Sheep would be more appropriate. --NE2 19:39, 11 September 2014 (UTC)

Lemmings (yes, I know, it's a misconception, which makes it doubly appropriate :-) ) Fram (talk) 20:37, 11 September 2014 (UTC)

The WMF could just set the default system font to Comic Sans. It's an extremely popular font, and should help with New User Retention. Alsee (talk) 22:53, 11 September 2014 (UTC)

@BethNaught: nothing should be stopping you from customizing it with your own CSS...

.flow-board, .flow-board-header { max-width: 1800px;}

worked for me, but it might need some tweaking. Legoktm (talk) 22:24, 11 September 2014 (UTC)

Well, then, if that's how easy it really is, seems to me the sensible thing to do would be to build in the adjustment as a simple, on the page "option", where a user may set a percentage width. or an actual width, or have where he drags a "width setting bar" to remembered between sessions. I think the default is wrong, too, but at least this way, there'd be a simple answer/solution when folks like me say that. Give people options... This kind of approach, across the board, would be very valuable. Modern computer users expect their environment to be easily customisable for their disparate needs, and dislike the feeling of being told "we've decided this is best for you". A little extra thought and effort to leave the user in control of his experience goes a long way. Many of us are comfortable fiddling with css, and will do so - but many are not, or may be confused by it, or resent needing to do it, especially, I would expect, newer users. Begoon ^talk 08:52, 18 September 2014 (UTC)

It might make sense for a feature that "pops out" a Flow discussion from the talk page in to its own separate, modal window in a similarish way to what can be done separate gmail mails. This is a good way to compare text side by side and maximize screen real estate. -wʃʃʍ- 07:47, 19 September 2014 (UTC)

Possibly. However, my suggestion was an option that could reduce, or mitigate, the widely expressed dislike for the width as offered by the base software. I think addressing that, before adding new bells and whistles, would be preferable. That's not to say they aren't good thoughts for the future, but if the basic flaws and objections never get fixed, Flow might not have much of that. Begoon ^talk 10:29, 19 September 2014 (UTC)

Watchlist acting starnge for Flow topics

The watchlist is acting very strange for Flow. Often, it simply doesn't work, but for topics I have replied to, it often shows the last post before mine (which is unwanted behaviour), or now even the two most recent posts:

(diff | hist) Requested change: print the topic link in the header of each post on Wikipedia talk:Flow/Developer test page; 14:26 . . (+65)‎ . . Oiyarbepsy (talk | contribs | block) (diff | hist) Requested change: print the topic link in the header of each post on Wikipedia talk:Flow/Developer test page; 14:26 . . (+400)‎ . . Oiyarbepsy (talk | contribs | block)

These are two changes to [6] where my post is the most recent. One is the creation, the other is the first post (which are always simultaneous anyway), but the wtachlist doesn't make that difference clear. I don't want to see this topic, as I'm the most recent contributor, and I certainly don't want to see it twice. That's even ignoring the whole page vs. topic discussion of course... Fram (talk) 14:35, 19 September 2014 (UTC)

Can we really fix wikitalk pages?

I have had a horrible experience on the long section a couple notches above this one. It's not the other commentators that are the problem, but the wiki-talk that has made it horrible. Today my watchlist tells me that Alsee added a comment to the section. Of course, clicking on my watchlist doesn't even take me to the correct section - I have to click on the TOC link to get there. But I still haven't found the post - now I have to skim the entire section to find the comment that is actually new. Then I want to respond - I'm taken to wikitext where I have to find the comment yet again, and this time it's not formatted for easy reading. But the huge amount of idents without any subheadings doesn't make it easy to read anyway.
In short, as an experienced editor who knows all this shit, using these boards still fucking sucks. With flow, the link in my watchlist points exactly to Alsee's post, and a response it a single click away, no searching required.
Fixing the wikitalk system to fix the above problems and get the behavior that every other discussion board on the internet is capable of, is a gargantuan task. The fact that none of these have been done over all these years, and I know several have been requested repeatedly, shows this. In fact, I suspect that making the wikitalk system actually work properly would be an even bigger task than flow itself. So that's the question - which is a bigger task, a new talk page system, or bandaiding the one we have? Oiyarbepsy (talk) 04:00, 18 September 2014 (UTC)

To see his comment, use a diff. For many comments, use the cur link in the history. To add a comment, use the find function using a memorable quote from the previous post.

It's not as bad as you make it sound. BethNaught (talk) 06:45, 18 September 2014 (UTC)

The "cur" is what I use most of the time, but I agree it is less than ideal. Better would be to have an adapted diff view for talk pages. Imagine seeing everything that is new on the page since your last visit with a green background, and everything in paragraphs that have changed with a red background (insert your own better colour suggestions here or via CSS). Again, there are ways to make talk pages better without abandoning the standard wiki model. —Kusma (t·c) 08:20, 18 September 2014 (UTC)

Well, that's a stupid way to do it. Really, hit the "current diff" button, are you kidding me? Is that seriously supposed to be a solution? And how does it solve having to find the post a second time, unformatted, when I want to respond? And, yes, it is bad as I make it sound, that original post was an accurate description of the process. Why not posting that at Reddit or Discus or YouTube and convincing them that our system isn't terribly broken? Oiyarbepsy (talk) 14:30, 18 September 2014 (UTC)

Did you read my post (the one directly above yours)? It contains suggestions how to improve the current system and alleviate your problems. I also have pointed out (in a different section) how one could add a simple "reply" button that makes it easy to find where to insert text. To answer your last question: As I have never seen a single comment on YouTube that was worth reading, I am sure absolutely certain that our talk page system is much better for our purpose than their discussion system. —Kusma (t·c) 15:52, 18 September 2014 (UTC)

With Flow, if a discussion gets somewhat longer you can't even see any more who is responding to what. Wikitak has problems, but yuor view of Flow seems to be based on whta it might eventually perhaps become, not on what it really is at the moment. But I'm glad you have lived a rather happy life, if you can call the problems you encountered a "horrible experience" with a straight face. With Flow, if you get back after a couple of days and want to see what has changed since, you get an equally "horrible" experience, having to check every timestamp to see what has been added.

And of course, this page actually appears in my watchlist, something like Wikipedia talk:Flow/Developer test page, despite being on my watchlist (the main page is on my watchlist, and the green star on the Flow board is checked), and despite having changes less than one hour ago, does not appear on my watchlist. At all. So please, yur support for Flow is admirable, but stay real. At the moment, Flow sucks big time and is much less user-friendly than wikitext for most slightly complicated and even many easy things. Fram (talk) 07:06, 18 September 2014 (UTC)

Actually, the endless indenting is part of the problem - it encourages conversations to split off into off-topic tangents. So, "who's responding to what" is part of the problem, when people respond instead of starting new topics like they should. Look two sections above and how many topics are covered in a single section. I'm not sure what's happening with your watchlist, I see the posts on mine. And, yes, even the current state of Flow is better than wikitalk, even though it isn't ready for primetime yet. Oiyarbepsy (talk) 14:27, 18 September 2014 (UTC)

I think people respond instead of starting new topics like they should neatly encapsulates the ideological debate behind Flow. If people find it beneficial to the discussion to behave in a certain way, then who is to say that they "should" do something else? Under Flow, editors will be constrained to behave in ways the Flow designers think "they should". This is probably where much of the angst underlying the whole debate lies. As it happens, I don't that the designers have even started to appreciate the complexity of existing behaviours, let alone being in a position to replicate them, but then perhaps that's the point. Deltahedron (talk) 07:53, 20 September 2014 (UTC)

When you start a new topic, I won't get a note, as I would only follow the topic I have posted in (at least, that's what the Flow team has as vision). You would have to ping everyone in the previous topic to alert them that the conversation (or part thereof) continues in the new topic you created, because you can't indent any further or start subsections. And that is better how exactly? Fram (talk) 14:39, 18 September 2014 (UTC)

Fram, in theory, if a topic were split, and you were watching it, you would end up watching both. I'm not saying it would work that way. As Flow is certainly not yet even up to beta, it's hard to say whether a workflow would be implemented, whether or not documentation says it will be. — Arthur Rubin (talk) 16:24, 18 September 2014 (UTC)

Good point. Noted at https://trello.com/c/oJHPeRvq/9-split-topic along with some other possibilities. (Should everyone from the original topic watch the new topic by default? or should only the person whose comment was split out, be watching the new topic by default? Perhaps something like gmail or bugzilla, where we're given a line of "currently CC'd" names, and can delete or add names as needed?) It'll get discussed in more detail, before they start developing the feature. (There'll be increasing attempts at coordination of discussion about singular features, over the coming months; though the multi-wiki nature makes it very challenging). Quiddity (WMF) (talk) 00:30, 20 September 2014 (UTC)

To add to the above - Alsee claimed that Flow would lead to more revert wars. I think the opposite. I large number of editors have that above experience and give up talk pages entirely, and revert war instead. A revert war is a lot easier for new users. And a revert war on articles is a lot more damaging than on talk pages. Oiyarbepsy (talk) 14:31, 18 September 2014 (UTC)

I disagree. I don't think Flow can be made into a model for a discussion forum. Hence, if implemented, the editors interested in discussion will go elsewhere, and the ones interesting in improving the article will have nothing to do other than revert war. — Arthur Rubin (talk) 16:24, 18 September 2014 (UTC)

There was some discussion about small fixes/upgrades/tweaks/scripts for standard talkpages, at [7] and [8]. I believe there are a couple of staff developers who are going to be working on it - more details when I know for sure. Quiddity (WMF) (talk) 00:30, 20 September 2014 (UTC)

BOLD edit to main page. Flow does not encourage meaningful conversations that support collaboration.

The main goals for the Flow project are:

• to make the wiki discussion system more accessible for new users

 Confirmed

• to make the wiki discussion system more efficient for experienced users

 Inconclusive /  Unlikely

• to encourage meaningful conversations that support collaboration

 Not possible

• It appears the Community and WMF employees generally agree that putting a chatboard on articles will draw a large volume of unconstructive posts.
• Every proposal to deal with this issue involves some method to suppress voices you consider unhelpful.
• Opposing sides routinely consider each other unhelpful.
• If opposed sides stop listening to each other then collaboration and consensus building become impossible.

• Result: Endless edit warring, or majority POV dominance with wild POV flipflops whenever the balance shifts.

Does my edit draw any support? Does anyone feel a need to revert and discuss? Alsee (talk) 21:28, 15 September 2014 (UTC)

Just pointing out the message box at the top of the page is now incorrect... BethNaught (talk) 21:41, 15 September 2014 (UTC)

Good point, I missed that. If anyone restores my edit, or otherwise edits the page, the infobox should be updated. Alsee (talk) 22:18, 15 September 2014 (UTC)

I do, and did. WP:Flow is a WMF page, basically; its purpose is for the WMF to describe their goals, progress, etc. with Flow. It's not for the community to voice their displeasure with or objections to it. There are lots of other pages for that; this one, for example. Writ Keeper ⚇♔ 21:52, 15 September 2014 (UTC)

First, I note that you did not disagree with the content of my edit. Second, if the WMF does not wish to engage in collaboration and consensus seeking, then perhaps they shouldn't be posting on Wikis. Third, if this page is "owned" by the WMF then you had no more business editing it than I did. As far as I'm aware ENWikipedia has no policy nor mechanism to give WMF employees an exclusive lock over any page. I am not going to revert war with you, but perhaps someone who considers my edit productive will restore it. Alsee (talk) 22:12, 15 September 2014 (UTC)

I didn't say it was owned by the WMF, I said that its purpose is to provide the WMF a place to say things about Flow. Mixing community opinions into it dilutes that purpose. There is value in allowing the WMF a place to provide to us their official party line, for us to better critique it. Writ Keeper ⚇♔ 22:19, 15 September 2014 (UTC)

BRD is a proven method for breaking logjams and trying to develop a consensus. There are a significant number of editors who agree with the general content of my edit. Having someone outside the WMF revert the edit utterly defeats the process. Alsee (talk) 22:30, 15 September 2014 (UTC)

Huh? That doesn't defeat the process, that is the process. You boldly edited, I reverted, and now we're discussing it. That is how BRD works, is it not? Writ Keeper ⚇♔ 22:39, 15 September 2014 (UTC)

No, our conversation is clogging the page discussing process. It is not productive towards the underlying issue. Alsee (talk) 22:58, 15 September 2014 (UTC)

If you wanted to start a discussion on whether Flow is a good solution for those goals, maybe you should have, y'know, just started a discussion about it, instead of inserting your assertions into a page that's not set up for discussion. Writ Keeper ⚇♔ 23:16, 15 September 2014 (UTC)

((edit conflict)x3) I would suggest that the second point (that you've marked as "Inclusive/Unlikely") should instead be marked as "Too early to tell" - There's a hell of a lot of work to do, before we'll all know if the modular workflow plan will bear fruit. See mw:Flow/Release planning for many of the planned features, and various ongoing mailing list threads at wikimedia-l (particularly "Let's fix templates", "To Flow or not to Flow", "To Flow or not to Flow -> it does not flow", and "To Flow: on featured article discussions"). If we're just talking about 'who can edit a post', that's likely to change as soon as there are designs/code available for better transparency in the post, of who exactly edited the content (ie. original author, or someone else - like LQT does but better. Which will be better than the current impossibility of knowing whether something has been edited, from the talkpage itself.).

For the third point, I'm not sure what exactly you're concerned about, though I would guess it is to do with the hide-button; please elaborate? (I'll add that they plan to insert "Hide" links in the same place in History pages as "Undo" would be, and to make the content actually disappear from the page, as "undo" does. Danny explained some of this above at #Wiki misconceptions in the Hiding/refactoring section, with updates to that plan at https://trello.com/c/V8Flrczl/)

I also join in encouraging discussion here, rather than inserting commentary directly into the documentation page. Please and thank you! Quiddity (WMF) (talk) 22:31, 15 September 2014 (UTC)

We are getting close to WP:POINT here. The edit look a lot like trying to prove/illustrate a point. You could, uncharitably, characterise it disrupting the purpose of the page. As the software is still very much in development reviewing where it has met its goal is premature, fine to have this discussion on the talk page, but not yet on the project page. A review section on the main page or a subpage like the Wikipedia:VisualEditor/Known problems page might be appropriate.--Salix alba (talk): 22:56, 15 September 2014 (UTC)

I understand your concern, but positive constructive intent is not WP:POINTy. It is an is an ineffectual mess for WMF employees to try to engage in endless 1-on-1 chats. I sincerely believe it would be productive if chaotic talkpage discussions generated clear concise consensus-based engagement. I believe the substance of my edit had significant support. If it had been reverted because someone (community or WMF) thought it was wrong, fine, the talk page can sort that out. Alsee (talk) 13:33, 16 September 2014 (UTC)

@Quiddity (WMF), I had already read almost all the links you provided, and did just check the two new ones. No help. Try putting a Flow chat page next to the Democratic Party page, or Republican Party page, or Obama's page, or the Fox News page, or Evolution. You will rapidly get hundreds or thousands of unproductive or inflammatory posts per day. People arguing the topic, or merely wanting the page to present a totally one sided partisan view. Put a Flow page next to a page like Expelled:No Intelligence Allowed when it was a fresh release and you'll get THOUSANDS of rabid posts per day. The only proposal you have is to hide/mute/whatever posts that look like crap. Aside from the impossible labor needed to sort through and hide all the crap, editors will be hitting other editors they consider unhelpful, and newbies will get hit, and everyone who gets hit will be enraged for being "censored". Unless you have some NEW idea, replacing Talk pages with Flow appears to be incompatible with a collaborative place to develop pages. Alsee (talk) 23:29, 15 September 2014 (UTC)

Everyone keeps asserting this without evidence. I don't think it's the case. First and foremost, everything I've seen says that talk pages will remain explicitly separate from article pages, flow or not. So, the flow page will not be "next to" any of these articles. We're not placing them at the bottom of the page like news sites do, we're keeping it separate. Inappropriate posts are rare now, and in flow, we would deal with them the same way as now - either delete outright or just hide, or some other possibility might be developed. Finally, most people can see the tone of a discussion board and choose what they post accordingly, which is why Slate and YouTube's discussions are so radically different - here, hiding will set the tone, and users seeing nothing but productive posts will mostly follow suit. I just don't see your nightmare situation happening. Oiyarbepsy (talk) 00:55, 16 September 2014 (UTC)

The problems with the article feedback tool reinforce the above statement, rather than undermining it. The article feedback tool was placed at the bottom of the article, which invites those who just finished reading to spout whatever garbage is in their brain. Scrolling back to the top requires extra effort and deters the morons. Oiyarbepsy (talk) 00:57, 16 September 2014 (UTC)

Oiyarbepsy I now notice that some things were removed in the latest edit to the Roadmap, before it was copied here. I have spend extensive time using Flow and studying all available Flow information over on the wikimedia and mediawiki websites, and I have spoken with staff there. In my discussions with staff they never said I was wrong when I discussed convertsion of Talk pages to Flow. They universally expressed a lack of understanding or lack of concern that this might be a problem. Note the WMF replies here - there is no disagreement on intent to ultimately replace Talk pages with Flow. The desired endpoint is "Broad project/article page rollout". The WMF's motivation for VisulEditor and Flow is to address the Wikitext problem. Specifically, the number of people who click EDIT or TALK and see wikitext and just close the page. If I recall correctly, the WMF director herself said she found it "very scary" that so many people didn't edit because of wikitext. The second big concern is that display-limited mobile devices have a problem displaying Talk and Edit pages. The dual purpose of Flow are (1) give an easy TALK PAGE on-ramp for new editors, and (2) create a tightly constrained Talk page format that limited-display mobile devices can handle. I have other significant concerns, but I don't want to defocus this section. Alsee (talk) 12:45, 16 September 2014 (UTC)

@Alsee: I think the confusion above is regarding your phrasing in "Try putting a Flow chat page next to the [...]" - I agree that would work about as well as AFT did. (Although the way VE surfaces <!-- comments --> now is quite nice, and could potentially be extrapolated for occasional links to Flow topics)

Regarding the overall aims of Flow, they're much more along the lines of (in no particular order) :

• Fixing the problem of separating the content from the history when we cut&paste archives,
• Fixing the problem of having to count the number of *:::: indents;
• Fixing edit-conflicts for a simple reply.
• Automating (part of) some of the processes that currently take a copious number of manual steps (which some people use scripts/gadgets for),
• Fixing the difficulty of porting the vast majority of these useful tools into other languages and sister projects. (I.e. the hundreds of interdependent bots/templates/categories are an adhoc system, that work Ok at Enwiki and a few of the other large wikis with volunteer developers, but they don't scale well to the hundreds of smaller wikis that want to use the same tools. E.g. I spent a few minutes trying to explain "Wikiprojects" to a group of editors from Kazakhstan at Wikimania, and kept coming back to the long list of things they'd need to implement and maintain themselves to get equivalent workflows going there);
• Fixing the difficulty of transcluding a single discussion between multiple places (and potentially between multiple wikis, so that we can discuss global concerns on global pages). We currently do this to a limited extent via subpages e.g. AfD but not very clearly or consistently especially to newccomers and it requires (Talk:Selfie_Slam should surely contain the topic Wikipedia:Articles for deletion/Selfie Slam as well as the daily AfD page and Wikipedia:WikiProject Deletion sorting/Video games ?);
• Fixing the WP:INDENTGAP issues (where we mis-use HTML Definition lists to create :::these indents) which makes it troublesome to add paragraph breaks;
• Fixing the issues of not-knowing whether someone's post is how they originally wrote it, or a tweaked version, or a vandalized version (unless we check the entire subsequent page history manually);
• Adding additional abilities for watchlisting single topics on busy pages;

and more! E.g. The list given by Erik at #To Flow or not to Flow, and his related post at https://lists.wikimedia.org/pipermail/wikimedia-l/2014-September/074433.html Plus the feature list at mw:Flow/Release_planning.

Regarding mobile: I believe the efforts towards making talkpages (and all pages) more accessible to mobile-users, is more of a concern for the Global South and non-Western projects, where mobile devices tend to outnumber desktop/laptop devices. But as I've said elsewhere, I'm unfamiliar with most aspects of mobile.

Hope that helps. I've got to dash, else I'd keep going (or edit this into more coherence..). Quiddity (WMF) (talk) 00:02, 17 September 2014 (UTC)

@Quiddity (WMF): No, that was zero help. We have essentially 100% communication failure here. As best I can make out you are maybe agreeing that replacing article Talk pages with Flow would be Total Fail, and then proceeding to copy-paste a wall of bad reasons why the WMF has decided it wants to railroad us into Total Fail anyway. I had already read the unhelpul mw:Flow/Release_planning and mailing list. Alsee (talk) 01:09, 17 September 2014 (UTC)

Clarification on bad reasons: most can be improvements to Talk, and none justify unusable Fail. Alsee (talk) 01:18, 17 September 2014 (UTC)

"Fixing the problem of separating the content from the history when we cut&paste archives" - how can we accomplish this with improvements to current talk?

"Fixing the problem of having to count the number of *:::: indents" - how?

"Fixing edit-conflicts for a simple reply" - how?

"Automating (part of) some of the processes that currently take a copious number of manual steps (which some people use scripts/gadgets for)" - how? Do you endorse our hacky bot system?

"Fixing the difficulty of porting the vast majority of these useful tools into other languages and sister projects" - how?

"Fixing the difficulty of transcluding a single discussion between multiple places" - how?

"Fixing the issues of not-knowing whether someone's post is how they originally wrote it, or a tweaked version, or a vandalized version" - how?

"Adding additional abilities for watchlisting single topics on busy pages" - how?

I don't think it is feasible to fix a single one of these issues while still maintaining wikitext talk pages (I didn't chime in on the purely technical ones that I don't understand). I don't think any of these can be improvements to talk. Oiyarbepsy (talk) 14:31, 17 September 2014 (UTC)

Sorry, why not? Here are some not too difficult ones:

• "Fixing the problem of having to count the number of *:::: indents" - how? Imagine a "reply" button in VisualEditor that automatically indents to the right level. Being software, it should be easier for VisualEditor than for a human to count the number of indents.
• "Fixing edit-conflicts for a simple reply" - how? I don't think this needs to be significantly more difficult than when MediaWiki was rewritten to no longer edit conflict on edits to different sections on the same page. Indented lines could be treated like sections.
• "Fixing the difficulty of transcluding a single discussion between multiple places" - how? The software already perfectly supports transcluding one talk page on multiple others. We do not usually do that, but it is not impossible.

Other issues may require more creativity, but may still be possible in wikitext. —Kusma (t·c) 14:50, 17 September 2014 (UTC)

Transcluding is difficult. For example, some edit section links no longer appear, and after editing, your sent to the transcluded page, not the overall page - if you then hit the back button to the full page, your new post isn't there until you hit reload. These are all serious issues, so Quiddity was right to use the word difficulty. Oiyarbepsy (talk) 15:07, 17 September 2014 (UTC)

You shouldn't have to hit the back button. Instead, a transcluded discussion should have links at the top taking you back to the pages the discussion is transcluded on. With, say, "action=purge" or something if necessary. It is not super pretty, but my point is, all of these things are possible. Talk pages could be a lot better if some effort went into these things, without giving up the flexibility of wikitext. —Kusma (t·c) 15:21, 17 September 2014 (UTC)

1. Archives: Improve the archive system? And/or re-write existing links into archived sections as links into the archive? And/or check the archives when a section-link fails to resolve?
2. having to count the number of *:::: indents: Put the cursor on the comment you want to reply to and hit reply - the software can do the right thing in the large majority of cases, and it can be canceled and edited as normal if needed. Once most comments are made that way the success rate of the Reply button will vastly increase.
3. edit-conflicts for a simple reply: In most cases treating indented text as a section solves this, and the interface for solving simple edit conflicts could be improved. Most comment edit conflicts can be resolved with a simple append-after-last-edit.
4. Automating processes that take a number of steps: Easily solvable by allowing a template to trigger the next step. Requires care to avoid abuse or ill-behaved results, but definitely doable.
5. difficulty of porting: I'm not familiar with the issues here, and how Flow chat boards are supposed to be an improvment. Isn't this mostly translation issues? And won't the Automating solution above help here?
6. difficulty of transcluding a single discussion: I'm certain it would be easier to upgrade this than to invent Flow.
7. issues of (modified or vandalized) comments": This has not been an issue. Malicious edits are excellent for nailing and sanctioning/banning problem individuals. They're a valuable feature, not a flaw.
8. watchlisting single topics: How about watchlisting edits affecting existing sections?

Surely SEVERAL of those things can be improved for far less than the cost of building Flow. And this entire discussion is irrelevant and completely offtopic. The topic of this section is that there is a Critical Block. Flow is incapable of meeting the design goals. Specifically Flow is incapable of hosting "meaningful conversations that support collaboration" if it is deployed next to Article pages. If you can't address that then there's nothing to argue, Flow is a dead-on-arrival zombie project. Alsee (talk) 20:00, 17 September 2014 (UTC)

When you say "deployed next to Article pages", what do you mean? It sounds like you think that, when Flow is deployed, it's going to display on the same page as the article, but I'm pretty sure that's not the case. Flow is going to go on the talk page (as a separate page) in the same way that talk pages are currently separate; it won't get displayed at the same time as the article itself. As for the rest of your points, well, several of those things you mention cannot be solved without a rewrite of MediaWiki on a scale similar to Flow's: watchlisting sections or treating each comment as its own section come to mind. Writ Keeper ⚇♔ 20:17, 17 September 2014 (UTC)

I mean eventually converting Talk pages to Flow. If they put Talk pages PLUS Flow, that would be a mostly harmless annoyance.... we'd just wind up doing what Wikinews currently does with their Liquid pages. Wikinews calls Liquid pages "Trollspace", and the only way they can get any work done is by ignoring the Liquid chatboards and keeping their work strictly on Talk pages. But that would achieve exactly zero of Flow's goals. All of the development work on Flow would be completely wasted. If they replace Talk pages with Flow that leaves us no place we can get productive collaborative work done. Alsee (talk) 21:16, 17 September 2014 (UTC)

That's not how I understand how Wikinews works. My understanding is that Wikinews has talk pages for improving articles, like any wiki does, and a separate liquid-threads board for opinion comments, like any news site does. They are two separate things serving two separate purposes, and no one there pretends that the liquid threads is for improving the article. Placing the liquid commenting at the bottom communicates to everyone who uses the internet that it's space for personal opinions about the article. Having a separate page, wiki or flow, communicates that it is solely for improving the article. The technical implementation doesn't create this distinction, it is the user action required to comment. Here on Wikipedia, naturally, we won't ever have an opinion space, no matter what happens to our discussion systems. Oiyarbepsy (talk) 03:45, 18 September 2014 (UTC)

Having a separate page, wiki or flow, communicates that it is solely for improving the article - People believe Truth is an improvement.

In case that wasn't clear enough, Wikipedia works because most editors are general-purpose Encyclopedia-builder accounts. Contrast that with Single Purpose Account: editing (which) is not compatible with the goals of this project. It won't take long for general internet commenters with an ax to grind to want to improve Wikipedia with Truth. God forbid some leftwing or rightwing site links to a Flow page wanting to improve Wikipedia with Truth. Encyclopedia-builders on the page would instantly be outnumbered 1000-to-1. Any page related to Evolution will be obliterated by the most glorious most passionate unending stream of TheTruth. <Note different link. Alsee (talk) 22:22, 18 September 2014 (UTC)

@Quiddity (WMF): Thank you for your candid statements. I'd like to talk about what you said here:There's a hell of a lot of work to do, before we'll all know if the modular workflow plan will bear fruit. If it doesn't, Flow is sunk as as it stands it can never support RfCs, RfAs, the proposed warning/blocking interface, and all the other workflows which need easy customisation, refactoring, sectioning etc. Should that be the case, there would be no point in rolling it out because at some point every talk page may need a non-chat workflow. This is why I think production wiki rollouts are premature – we don't even know if Flow is viable yet. BethNaught (talk) 07:40, 16 September 2014 (UTC)

I agree: failure here is simply not an option. Yes, it's ambitious; yes, it's hard. But that is what the Flow team have set out to do. Deltahedron (talk) 07:56, 20 September 2014 (UTC)

• I have disliked the concept of flow from the moment I laid eyes on it and still do not understand how it is beneficial to wiki. Do the good outweigh the bad? If so how? - Knowledgekid87 (talk) 02:30, 16 September 2014 (UTC)

Browser Warning when replying to a topic

When replying to a topic, I'm getting a browser warning that I'm trying to leave the page without committing data. Using Firefox 32.0.2; monobook skin. — Preceding unsigned comment added by Xaosflux (talk • contribs) 16:11, 19 September 2014

Yes, there is a major bug in the new Flow release (which also seems to have altered, but not improved the way the Echo lists and buttons work, and what is displayed in the watchlist). No idea how that got here undetected. Not a good start after everything that happened the last few weeks, but a good argument against further rollouts of course. Every cloud... :-) Fram (talk) 18:15, 19 September 2014 (UTC)

Perhaps related to this section above? Risker (talk) 20:17, 19 September 2014 (UTC)

Yup, the bug Xaosflux is experiencing is the same as that which Risker and 2 others have run into, bugzilla:70586, which we're having a hard time consistently reproducing.

(Unless it was related to the other bug that started yesterday, with replying on Topic pages, which is now fixed).

If you're still experiencing this "leaving page warning", and can consistently reproduce it, please give me details either here or bugzilla. Thanks Quiddity (WMF) (talk) 22:09, 19 September 2014 (UTC)

I can't reproduce it now, but I remember the one time I had it yesterday I was surprised that after confirming to leave the page I ended up on the topic page, while had I typed my message on the board page (possibly reached via one of the special URLs generated by Echo). So the browser was actually right: it did leave the board page without submitting the form, it instead submitted the form to the topic page, which did the job. — HHHIPPO 09:28, 20 September 2014 (UTC)

Please test before and after deploying

As you can see at the interestingly named Topic:S1q7oxlwwt9r7rh0, some of us are now unable to use "return" in their replies, as that triggers the "post" button, effectively restricting them to single-paragraph comments. Furthermore, they can't see them effectively, as they only get one line in the input box.

However, they shouldn't complain, they are the lucky ones. I can't even respond any more. When I use "reply", I get a single-line (infinite scrolling!) box, but no buttons whatsoever" (cancel, preview, post), and if I hit return, I get the "are you sure you want to leave this page?" message. I'm working with Vector, FF32, W7, so pretty standard stuff.

Can you please make sure that the very, very basic functionality (posting things is the bare minimum for a talk page, no?) is tested before and after any rollout? At least now no one can claim that Flow is in any way better than wikitalk, unless you simply want to abandon all talk :-)

Note: this seems to happen only when you are in topic view (also with other topics like [9], not when you are in full page view. But as far as I can follow the devs' philosophy, topic view is supposed to be the default... Fram (talk) 06:35, 19 September 2014 (UTC)

The current problem with replying to anything on a Topic page, has been patched and the patch is being applied as I type this. IIUC, the error snuck in with one of the backported patches, hence it wasn't caught in automated-testing, or in the usual week of time that all versions spend at mediawikiwiki/test/test2 before coming to the content wikis. I'll nudge the testing processes, particularly for backports. Quiddity (WMF) (talk) 21:51, 19 September 2014 (UTC)

Then it has to be said that the testing process is inadequate. Please bear in mind that this is a production wiki: it's the wiki where we are bulding an encyclopaedia. People here are using notifications, watchlists, contribution lists and so forth as tools to help them do that. Bugs that impede that process are not acceptable. Please improve the pre-rollout testing to reduce the frequency with which this sort of thing happens -- which is currently unacceptably high -- or, if for some reason that is actually impossible, give a full clear and reasoned explanation to the contributors and editors here why you are choosing to disrupt the editing process. Deltahedron (talk) 20:40, 20 September 2014 (UTC)

I agree in principle, but this particular bug was only affecting WT:Flow/Developer test page. At that page, we're not writing an encyclopedia, we're testing Flow. Other bugs, like sending mass notifications to people not participating in the testing, are of course a different story. — HHHIPPO 20:56, 20 September 2014 (UTC)

But the notification system is used across the wiki. If that gets messed up, even if it only for people posting to the test page, it is disruptive. The purpose of rolling out to the production systems is for users to test the features and comment on their design. It is not for them to help look for bugs, which should already have been done on the test systems; not is it for them to have their other work put at risk by bugs. Deltahedron (talk) 21:06, 20 September 2014 (UTC)

Yes, that's why I wrote that notification bugs are a different story, they can be disruptive. But the topic here is a malfunctioning edit box, which only affects people trying to post at the test page. — HHHIPPO 21:27, 20 September 2014 (UTC)

Thank you for that explanation: I withdraw my comment. Deltahedron (talk) 21:42, 20 September 2014 (UTC)

Roadmap update

I updated the documentation page with a more realistic version of a roadmap that gives a more accurate expression of how building a project like this works. I know that people on this page (and in discussions elsewhere) want more honesty from me as a PM. That's actually how I want to live, being more natural and real about the work that we're doing. I've gotten more distant and "professional" over the last couple weeks, because that's what happens when people are angry at you, like, all the time about everything.

I'm sick of the way these conversations have been going lately; I'm sure everyone here is. It's boring and awful, and we don't get anywhere. So I'm doing a bit of a reboot in my communication style, and I'll see how it works.

So, the roadmap. Like I said, this version is more realistic, and actually reflects the current state of play. I've been a product manager working on ambitious user-facing features on a MediaWiki platform for about five years, and I've built big crazy features like this. The roadmap is more of a discovery process than a strict plan. I can talk intelligently about what we're working on for the next couple months. Beyond that, I know the general direction that we want to go, but the actual details get fuzzier the further out you go. This isn't a trick. This is actually how it works.

I want to talk more with the people who are posting on this page, for several reasons. For one thing, it's just fun, and it's a part of my job that I really like. Also -- you guys have good questions and ideas, and you challenge me, and that's productive and cool and it makes everything better. But I can't do that if I'm just going to get yelled at, and if everything I say is picked apart. It just doesn't work. I'm not feeling sorry for myself here, or expecting anybody else to feel sorry for me. This is my job; I choose to do it, and this is part of the job. I'm just saying that I can be as honest and real and receptive as the conversation allows for. I'm going to hit save right now, before I talk myself out of it. DannyH (WMF) (talk) 21:32, 12 September 2014 (UTC)

Hi, DannyH (WMF).

I've thus far taken the academic route to Computer Science, myself, but a friend who went into industry advised me if I wanted to know what it's like, read Dilbert, that's exactly what it's like. Of course, that's industry, with its authority-drive hiearchy; wikis are a bit different, with a bottom-up structure (recalling the old Cold War-era saying, that in capitalism man exploits man, whereas in Communism it's the other way around). And you have the fun of working for an authority-driven hierarchy that sees itself as in charge of a collection of wikis whose communities consider themselves to be in charge, which presumably means you get to enjoy the disadvantages of both, at point blank range.

I do notice you claimed, in your 'roadmap' edit, that there isn't a "plan". That's probably how it looks from inside. Indeed, speaking for myself, I'm skeptical that there'd be a "plan" in the sense of an Evil Plot spearheaded, no doubt, by Dr. Evil; that sort of "plan" is close kin to the kind of supposed conspiracy that usually can't work in real life. However, there's another kind of conspiracy-like phenomenon that's pretty common: organizational machinery moving in a direction that gets going and then has legs, resulting in something being imposed despite nobody specifically wanting it; surely there'd be a Dilbert about that.

I know of one, pretty ironic, context within the wikimedian sisterhood where Flow would —if sufficiently improved— possibly be an improvement. On English Wikinews, each article has two associated auxilliary pages: a "collaboration" page and an "opinions" page. The collaboration page is an ordinary wiki page, used for discussion in the construction of an article, and we've got a strong consensus that it should be an ordinary wiki page; that's internally the Talk: page. The opinions page is for readers of the article to discuss the issues raised by it; and that uses LQT. We all hate LQT with a passion, except that it really is a great improvement for the opinions page. Before LQT, the opinions pages were ordinary wiki pages and Wikinewsies had to pour a lot of time and effort into cleaning up the mess created by readers who, for the most part, had no idea how to use wiki markup and had neither time nor motivation to learn how; why should anyone have to learn how to use wiki markup simply in order to discuss the issues raised by an article? If they want to contribute to the wiki, then and only then is there a reason for them to learn wiki markup.

We've discussed Flow, and whether or not it would actually be an improvement for our opinions pages to use Flow instead of LQT. The current sense seems to be that we're better off with LQT than with Flow; but with improvements to Flow, who knows. And this is ironic because the Foundation is notorious amongst the non-Wikipedian sister projects for not giving those sisters software support. (Wikinews does techically demanding stuff that relies heavily on all the customized semi-automation we've got, and badly wants more; for my part, I've put three years and counting into developing the sort of tools I reckon we, and the rest of the sisters, need.) --Pi zero (talk) 23:08, 12 September 2014 (UTC)

Pi zero, I don't have any experience with Wikinews and having an extra Opinion board next to our Talk pages. Could you please give your opinion on what would happen if the current Flow roadmap proceeds? Specifically, if the Talk page and Opinion page were merged into a single Flow page and placed next to the articles for Republican Party and Democratic Party? My guess is that work on those pages would become impossible. Alsee (talk) 02:21, 13 September 2014 (UTC)

I believe there's a solid consensus at en.wn that using Flow for collaboration would be a disaster. I'm inclined to agree with your assessment that it would make it impossible to collaborate. And yes, those two pages do look like pretty good examples of why. --Pi zero (talk)

A lot of people think you're on the wrong track, and it's not something that can be fixed with some tweak the current Flow project. Here on Wiki we're creators and builders. We want flexible tools. We need a collaborative environment. Wiki is the clay we use to build articles, to build discussions, to build workflows. We build it and reshape it. It's like you see that we built a car and house out of legos, so you come along and take away the legos and try to give us a cast-metal car and a cast-metal house. Instead of trying to take away Wiki work&discussion areas, how about offering us interesting new tools, and letting us figure out how (and if) we want to use them. Alsee (talk) 01:57, 13 September 2014 (UTC)

Alsee, do you think this might be an interesting direction for tool development? --Pi zero (talk) 02:52, 13 September 2014 (UTC)

Pi zero, Yep. Anyone with the skills/interest can build or modify something, and if it's good, everyone else can copy/use it. Pure Wiki. Alsee (talk) 03:08, 13 September 2014 (UTC)

DannyH, first, thanks for engaging. Like your Biblical namesake, walking into the lion's den takes courage.

You say "Beyond that, I know the general direction that we want to go." The crux of the biscuit is, What does "we" mean?

This is the only question that really matters. The rest is mundane technical detail. Short Brigade Harvester Boris (talk) 03:45, 13 September 2014 (UTC)

This^. The "we" being used is a few WMF managers. The community-we see fatal problems in YOUR direction, WMF. Your direction is not our direction. Alsee (talk) 03:14, 14 September 2014 (UTC)

• Speaking for myself, I have no problems with plans: they have served me well. A plan is a framework to hang the engagement wth the community on. Naturally much of the discussion takes place round the WMF water-coller in San Francisco, or IRC chat rooms. If that is the planning process, then the vast majority of the stakeholders are going to be, and feel, disenfranchised. Collaborating together on the plan is the very expression and instantiation of stakeholder engagement. A plan also holds the team to account. If the plan is simply to deliver whatever the team feels able to deliver, then they can't fail -- which is another way of saying they can't succeed either.

I was struck by the comment Anybody who tells you that there's a hard and fast plan for a project like this is probably trying to sell you something. Well, the team is trying to sell us something -- it's trying to sell us Flow. In one sense we have no option: WMF have decreed Flow and when it's implemented we will have no choice but to use it, so selling isn't necessary. Or is it? Because, you see, we do have a choice: the choice to leave (and Jan-Bart has made it clear that he's happy for us to do so). If the team fails to sell Flow to the users, and the users leave, then they may succeed in delivering the product but fail at the goal that the product is there to achieve, which is editor retention. Deltahedron (talk) 07:02, 13 September 2014 (UTC)

I think Flow will succeed or fail based on the quality of the feature, and the feature has a lot of work ahead. It is absolutely true that the feature as it currently exists today is not good enough to deploy much further than test pages. But the feature will get better, and people will see that as it happens.

I completely understand the fear that WMF will deploy a devastatingly insufficient version of Flow, too far and too fast. That's a perfectly reasonable reading of what happened with the VE and Media Viewer releases, and it makes sense that people are looking at Flow with the same kind of dread.

If the question is, "What are you going to do when you impose a broken feature that ruins everything, and the encyclopedia collapses?" -- then there's not really a way that I can respond to that. I understand where it's coming from. I can't fix that right now. All I can do is be honest about the work that my team is doing, and work on improving the feature. DannyH (WMF) (talk) 18:15, 15 September 2014 (UTC)

No, MORE dread, because whereas VE created a fixable mess and MV was a minor pain in the ass, we face the likelihood that the mass archiving of pages and lack of convertability will make "switching off" Flow and translation of subsequently created talk page content to the old system in the event of that floundering piece of crap's seemingly inevitable failure will be difficult to impossible. There is a realistic chance that WMF engineers are gonna "break the wiki" here. That's not just rhetoric, talk to Wllm (Wil Sinclair) about how easy it was to turn off and convert from LiquidTreads back to WikiText after he unilaterally imposed the former at his OffWiki site. This software is unwelcome at En-WP and doubtlessly elsewhere. Carrite (talk) 14:37, 18 September 2014 (UTC)

Actually, I never tried to convert the LT text, because it was mostly undistilled transient stuff like bickering that simply wasn't worth moving to a new version of the site. In fact, it's a case in point for what you said on wikimedia-l a few days ago. Discussion is clearly not the only thing that happens on talk pages. Some more persistent information is better captured by far in a document-oriented workflow. This would include stuff like decisions made, FAQs, notices, and WikiProject templates. However, this distilled and more or less structured data doesn't do much good if it gets lost in the poorly structured, lengthy discussions that are far better conducted in a discussion-oriented workflow. The WMF needs to listen to you like you're goddamned EF Hutton unless it wants a disaster 10 times larger than VE to the power of MV on its hands. If your mail or this discussion don't catch their attention and open a dialog, we've got to figure out what will. I'll do whatever I can to help; bringing attention to stuff is one of the few things I don't suck at. ;)

On a side note, it's a tiny concern in relation to what you brought up, but I wasn't won over by your suggestion of adding another tab. I've had a few ideas since then about how to keep the meta-document and discussion UIs linked and simultaneously viewable to support stuff like referencing one from the other and easily comparing text. I'll start a new discussion on these brainfarts below.

One minor correction: the decision to impose LiquidThreads would be better described as a-lateral. I installed the extension and enabled it on what I thought was a single sandboxed page for testing. What I didn't know and should have more diligently look in to was that it automatically enables itself in all talk namespaces. By the time I figured out what was going on, several LT discussions had already been created + a page-level directive to disable it was making the rounds. Since I was kept busy trying to keep a few people off each other's throats at the time, I decided to leave it installed. It's worth noting that some people who didn't see any value in LT whatsoever at first were won over by some features with the caveat that it still couldn't do everything a normal talk page could. Sound familiar? :) -wʃʃʍ- 07:32, 19 September 2014 (UTC)

@Wllm: Yup, the words "document-oriented workflow" neatly capture what's missing from the original design vision for Flow, so let's keep it around as a shorthand for what should be built. After the initial feedback they incorporated the underdeveloped Scratchpad idea, but as you say that won't do any good if the scratchpad document gets "lost within the flow" of scrolling discussion.

Recently the development team seems to be more receptive to the idea of embedding Flow comments within the wiki, and not just the other way around, which would allow for document workflows to become viable in the new platform; but they have set other priorities in the short term, so this subject should be brought back in the mid-term. Diego (talk) 10:32, 19 September 2014 (UTC)

The decision about discussion within document or vice versa is about as fundamental as it gets when it comes to the technologies at hand. Part of delivering great software on time is risk management, which often involves deferring decisions. One has to look at the dependency graph among the software subcomponents to make those decisions. I can pretty much guarantee you that the decision about whether the doc workflow is embedded in the discussion workflow or the other way around will be quickly pushed forward to one of the first decisions to make, if risk is being managed properly. I've seen this scenario play out all too many times. It looks like you're getting away with not making a fundamental decision for a while, instead working on less intimidating (in my experience with open source projects, community controversy or possibly disagreement within the core team is usually the source) features instead. The primary, uncomplicated use cases work OK. And then reality comes and screws everything up. Every corner case breaks the software because it wasn't developed with all the safe assumptions that the big decisions, once made, provide. Usually at this point, the development team is in too deep, so developers start hacking to support corner cases as they come up. This is where things get really ugly. Hacks fixing corner cases have a tendency to spawn even more corner cases themselves. The software behavior becomes extremely unpredictable. The code looks like the dog's breakfast. And any semblance of true risk management is thrown out in a panic to deliver something by the deadline. And, because a lot of the corner cases will involve templates and customizations that are deployed on the wiki and used in many different ways across different pages and projects in Wikipedia's case, a lot of corner cases won't be discovered until the software is pushed out.

Maybe that's not what's going on here. Maybe there is some architectural magic that makes fundamental decisions like this deferrable; for Zend Framework a lot of what we built allowed our users to defer certain decisions, in addition to lowering the cost of decisions. But this kind of advanced risk management is very deliberate and involves it's own tough decisions. If the Flow team has not made that design decision or some decisions to manage risk that might be introduced by deferring it, their best move is to stop and figure this out before committing another line of code.

Fortunately for us, even if the engineering leadership at the WMF doesn't know how to manage risk, Lila does. Now that she's gotten a first-hand look at a rough release- regardless of whether it was under her leadership or not- it would be extremely out of character for her to let something like that happen again under her watch. She would hardly be learning this stuff on the job, tho I imagine she might have some teaching to do. :)

My recommendation is to provide workarounds and strictly add- not replace- functionality in the first release. Basically, the Flow team shouldn't make this any harder for themselves than it already is thanks to the size and complexity of the production environment. And the community should understand that this is a very tricky project due to the complexity of the rollout. And we should all be nice to each other no matter what, cause ultimately people are simply more important than software. -wʃʃʍ- 12:27, 19 September 2014 (UTC)

From all I've seen regarding this project, that decision (between embedding Flow within the wiki or the other way around) was made more than one year ago, way before the day this page was put up for the community to evaluate. Or better said, the decision was never made, as the original design was already settled on wiki within Flow; as that design was the personal "vision" ;-) of Erik Möller for building online communities through software (which is a good thing to consider, as software shapes online communication), who a la Steve Jobs simply knew the way to solve all the problems of talk pages, even though he never asked the community how they wanted to have them. This is just my personal impression of how the project originated, of course, but I don't think I'm too far from reality.

As you say, there's hope that the planned flexibility will include enough magic to reshape the architecture into a document-centric platform, but I wouldn't place our hopes in that; all the talk about such flexibility has always been directed towards building conversation workflows, not collaborative editing ones, so there's a high chance that the design decisions taken so far already have some constraint that precludes such steep turn in purpose. Not knowing the low-level details, I've asked Erik Moeller (WMF) if he could confirm the viability of repurposing the software in that different direction and he somehow promised to address it, so I'm hoping this will surface in time (though that was the last time I've heard of him) ;-) Diego (talk) 13:13, 19 September 2014 (UTC)

I am unwatching this page for the time being. It takes me a lot of time to follow it, and, frankly, with zero output. People are discussing minor issues here, but WMF refuses to discuss the bigger picture, saying "we are going to switch FLOW does not matter what". Great, once you switch flow does not matter what, I am going to stop editing the English Wikipedia does not matter what, and we are going to look how FLOW is going to attract an editor with 50K editcount to replace me.--Ymblanter (talk) 10:52, 21 September 2014 (UTC)

Flow talk pages as transcluded topics

I'm wondering if it might be possible for flow talk pages to be structured as transcluded topics. What I mean is that flow talk pages would have an edit source button, like all other pages, and the source could look like this:

{{talkheader}}
{{oldafd-full|blahblahblah}}
<!-- end of header -->
{{newtopic}}
{{Topic:S2n8v8tnlfrk509z}} <!-- Of course, the topic links need to be changed to something human readable -->
{{Topic:S2n4acq720znw1xf}}
{{Topic:S2mtqnqvnkubl0g1}}
<!-- and so on -->

The {{newtopic}} transclusion would be the box where users enter a heading and their post, and established the talk page as a flow page. Upon submittal, the software would create the topic and transclude it to the talk page under the {{newtopic}} template call (the source is there but new users don't have to see it). This also means that editors could put a flow discussion on any page, whether converted to flow or not, and it would be very easy to put the same discussion on multiple pages. It also allows the transition without disrupting existing talk pages, especially if the {{newtopic}} template has an option to transclude the topic to the bottom, for old talk pages. The newtopic template could have extra options for specific pages, for example

{{newtopic|heading=Deletion discussion of Wikipedia talk:Flow/Developer test page|prompt=Please explain why you feel this page should be deleted|transcludeon=Wikipedia talk:Flow/Developer test page|transcludeon=Wikipedia:Miscellany for Deletion/Wikipedia talk:Flow/Developer test page}}

could be used to start new deletion discussions, appearing both on MfD and the talk page. What does everyone think of this idea? Oiyarbepsy (talk) 21:29, 19 September 2014 (UTC)

I don't believe it's possible to mix Flow content with normal wikipage content, because they use different "content models", much like wikidata pages (eg. wikidata:Q42 cannot be edited as a wikitext page). However, see my second comment here, and the 2nd paragraph in this comment, for some related ideas. HTH. Quiddity (WMF) (talk) 03:23, 27 September 2014 (UTC)