Wikipedia talk:Flow/Archive 14

This is an archive of past discussions on Wikipedia:Flow. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 10

←

Archive 12

Archive 13

Archive 14

Archive 15

Will Flow decrease participation where it matters?

While creating a deletion request at Wikimedia Commons (it works similar to the Articles for deletion process here, with individual pages created for each request), I wondered how an implementation of Flow for talk pages would affect participation in deletion discussions. The deletion process here or at Commons is outside of talk space - so it wouldn't necessarily be directly affected by Flow, I suppose. But if regular talk would change to Flow and more casual users would only be familiar with the Flow way of commenting, couldn't that lead to even less participiation by lesser experienced users in areas such as deletion requests? On the other hand, I can hardly imagine how the AfD process should be converted to use Flow. Is this something already discussed somewhere? Gestumblindi (talk) 20:48, 26 November 2014 (UTC)

Since AfD is a discussion, Flow would work just fine. I did a test run at Topic:S437gf01r85go7bv, and aside from the templates not working, I think is would work just fine for a deletion discussion. I would think that the discussion would no longer take place on separate pages with Flow, and they might be moved to a talk namespace, just because of how Flow works differently, and because you can link to each individual topic (for deletion logs, for example). Mind you, it's alpha software, and there are a lot of details and bugs to work out. Oiyarbepsy (talk) 23:21, 26 November 2014 (UTC)

Or to put it differently, we have no idea at all if and how AfD discussions and the like would work in Flow. The current setup definitely doesn't work in Flow, but perhaps some replacement can be created, and there is even a small chance that it would be better than the current situation. Of course, considering that at the moment Flow pages can't e.g. even be added to categories, there are still some major hurdles to tackle. Fram (talk) 08:22, 27 November 2014 (UTC)

To put it in plain English: We have no idea what will work at all in Flow besides a rudimentary forumesque layout. There are a lot of marketing, i.e. meaningless, words about it by its cronies, and what could eventually someday happen, and a lot of money is wasted on this LQT2.0, but up to now it's really not useful at all.

The current pages and use-cases don't have to change for Flow, Flow has to deal with all, and I mean absolutely all, use-cases the current system is capable of, or it's to be stopped asap.

The current gut feeling is: Some folks in SF will get some bonus payment for implementing it, and so won't listen to anyone who challenges the basic concept of this enterprise. It would something like loosing their face, and so I see the next superputsch on the horizon.

--♫ Sänger - Talk - superputsch must go 16:11, 27 November 2014 (UTC)

Our current workflows are based on Templates-containing-Categories, which are often added/changed by bots. Category support is the main missing element (and is indeed a major hurdle that I hope gets tackled in the next quarter. phab:T59512 and phab:T62510). There's a workshop in January for building up documentation and code-shims for bot-wranglers, but the API is already stable, and the MassMessage extension has already tied into it (phab:T73082). There is much work to be done, and the rollout is going correspondingly slowly.

I was sent this link yesterday, with someone asking for a better talkpage system in 2004. There have been many suggestions along the same lines, since then, e.g. phab:T3234. It has taken so long, because it's a very complex problem. It's going so slowly, because there are now only 3 developers working on it (one who lives in Belgium, and another in Philadelphia), and there are a lot of systems that it needs to be tied into, and features to implement, and bugs to work on.

Re: the layout, please (please!) explain what you would change aesthetically, and how that would help you as an editor. I want various changes, too. [I want increased density/width, because I do a lot of skim-reading and table-editing. But other people like some or all of the current layout choices, which I can understand. So I'm still advocating for user-preferences, both within Flow and more widely.] Other editors have given a number of suggestions already. But the more perspectives (with clear use-cases/explanations) that we can collate together, the better. Quiddity (WMF) (talk) 02:28, 6 December 2014 (UTC)

@Gestumblindi: Whether the current pages are technically in a "Talk:" namespace or not shouldn't really matter for replacing them by Flow topics. What's important is that Flow can support the processes going on on these pages, and obviously there's still quite some development to be done. But you make a good point about having some discussion spaces with, and others without Flow: on the one hand we don't want all discussion spaces be replaced by Flow boards over night, since no matter how much testing is done on smaller wikis, there will surely be some debugging and fine tuning needed on the big ones. On the other hand are the disadvantages you describe of having two different systems running on the same wiki for too long. Some kind of reasonable compromise will be needed here. — HHHIPPO 19:24, 27 November 2014 (UTC)

This needs a lot more eyes

This will be another fiasco like Media Viewer if we don't get more eyes on it. It seems that hardly anyone has really looked at this and tried it out. Crazy idea #47815: Throw it on a very heavily used page now, to ensure that everyone sees it and uses it, for a month or so. More eyes, more comments = better results. Oiyarbepsy (talk) 05:44, 28 November 2014 (UTC)

What's Plan B for that suggestion? See how it worked for Visual Editor, and it was optional. Diego (talk) 06:58, 28 November 2014 (UTC)

Which noticeboard do you suggest we break? BethNaught (talk) 07:29, 28 November 2014 (UTC)

I think this is generally a good idea, but it's too early right now. There's a lot missing in the current Flow, and the devs know that and are working on it. So at the moment there's little to gain from more testers. There's a lot to lose though: rolling it out on a heavily used page will give people the wrong impression that the devs think Flow is finished, and that this version is what they will roll out all over Wikipedia soon. Plus, indeed, we might break a process by putting Flow on the wrong page. I think overall this would mean a lot of drama for little gain. — HHHIPPO 07:44, 28 November 2014 (UTC)

Thanks for proposing an idea that will get Flow sunk immediately, instead of giving it a fair chance. We have had two projects where it would be used "temporarily", as a testing ground for a few weeks. Flow creates real problems despite the very infrequent use of it on enwiki (see Wikipedia:Miscellany for deletion/Topic:Rojlc5xnvwolwrkg), the latest discussion on Wikipedia talk:WikiProject Breakfast is "Do we want to go back to normal talk page format?" from 3 months ago.

One of the problems is that you "can't" go back to the standard format, there is no way to change flow posts into standard talk page posts. Couple this with the fact that you can't properly delete Flow pages, that the history isn't available (after the first few hundred entries), that substitution and the like doesn't work, that you can't have categories, that people can't see the wikitext you use, and tons of other problems which are already known before you start on any high-volume testing. First remove all the major bugs which we are already aware of, then test it again on some low-level or dedicated test pages (like now), and only if that doesn't produce major problems can you consider a test rollout to some more high-profile page or other usecase. If they run out of major problems with Flow, you can raise crazy ideas like the above. At the moment though, it would be pure disruption. Oiyarbepsy, you are a fan of Flow (one of the few around here), but rushing things in this way will only diminish the chances of Flow ever getting accepted, not improve it. Fram (talk) 07:59, 28 November 2014 (UTC)

Your idea is being tested on the French, at fr:Wikipédia:Forum des nouveaux/Flow. Looking at the history, it is clear that a lot of it is simply not visible. The page looks more like a vandal magnet than anything else. Looking there, I note other problems apart from thos eI listed above, like: the "what links here" page doesn't work (and the reverse, something that is linked on a Flow page, shows up as "Sujet:S6uomx6azjq9rtvw", not as "Wikipédia:Forum des nouveaux/Flow", making it impossible to find some discussion in this way when there are quite a few links); the relative timestamps don't change to absolute ones if you change the sorting of the table (from newest to most recently active). And infinite scrolling sucks badly. Trying to get to the end of the page takes ages and lots of clicks. And search doesn't work: not the internal search engine (not at all), and obviously browser-search only works on the visible part of the Flow page, not on the hidden older topics. There is a discussion on "lagomorphe" on that Flow page, but you can't find it.

All these things have been known for ages, and are serious problems. No idea why they still insist on rolling this out, but at least they are bothering other wikipedia versions for a change. Rolling the current version out here, even if it has the support of some WMF employees, some people who have received grants from the WMF, and a few seslect uninvolved editors, will with near-certainty lead to another enwiki-WMF clash, and that is one thing both can do without. Fram (talk) 08:29, 28 November 2014 (UTC)

(ec) Turning on Flow anywhere but on test pages would IMO be disruption to make a point. I'm not completely opposed to that in principle, but I'm getting the feeling the point has finally been driven home. That would make it disruption to make a redundant point, and I can't get behind that. Martijn Hoekstra (talk) 08:37, 28 November 2014 (UTC)

Ok, a bad way to get more testers (I did call my own idea crazy, you know). That said, I don't want to see a repeat of the Media Viewer fiasco. I think once the developers reach a certain point, they should maybe run an RfC simply asking "Should the Wikimedia Foundation continue to develop this software?" That way, if everyone's gonna hate it, they stop earlier in the process, not waste development time and dollars, and not piss of the editing communities. Oiyarbepsy (talk) 15:34, 28 November 2014 (UTC)

Something like that appears to be in preparation. And I too recommend looking for more testers elsewhere (i. e. not on en.wikipedia). Exposing this software early on to other experiences, conventions and practices can only help in the long run. And at this point dedicated test pages should probably suffice. --HHill (talk) 09:34, 29 November 2014 (UTC)

I fully support this sort of test, but I support putting it on the page for Gamergate, or Global Warming, or any major religion, or the latest article on white-cop-kills-unarmed-black-youth, or something resembling Expelled:_No_Intelligence_Allowed when it was a fresh release. I want the WMF to see the complete obliteration of article development when mobs of non-editors are on-ramped into our work areas. Alsee (talk) 01:51, 7 December 2014 (UTC)

Combining wikitext and Flow

So, I'm doing more brainstorming here, and this is the result this time: User:Oiyarbepsy/Wikitalk and Flow:The Best of Both Worlds. Oiyarbepsy (talk) 05:38, 6 December 2014 (UTC)

Oiyarbepsy, That's backwards. You're keeping every single objection to Flow and breaking several of the justifications for Flow. It creates the worst of both worlds. As many people have mentioned, to try to do a "best of both worlds" thing it's necessary to embed Flow as some sort of object in wikipages. Alsee (talk) 01:21, 7 December 2014 (UTC)

Flow wouldn't be embedded anywhere (well, eventually it could be). Quite the opposite, wikitalk would be embedded in Flow, but it would still function normally outside Flow. Flow would just display and organize the wikitext pages. Oiyarbepsy (talk) 02:12, 7 December 2014 (UTC)

Oiyarbepsy There seems to be a communication problem here. You're telling me exactly the same thing I just said. I said your suggestion was backwards of the "Best of both worlds" suggestions of embedding a flow object in Wikipages. You're keeping every single problem with Flow and breaking several of the justifications for Flow. It actually manages to create an even worse "Worst of Both Worlds" scenario. Alsee (talk) 21:43, 7 December 2014 (UTC)

One of the things I'd like to have in a discussion system is a way to go to a busy talk page and read all the posts that have been added or changed since my last visit. In the current system I can either read the diff and try to imagine how things would render, or I can look at the rendered page and hope to spot additions and changes myself. For the software to be able to show me the rendered version of the page, but with new/changed posts marked as such, it needs to be aware of the full structure of the discussion, down to the post-level. I think this can only work reliably if the underlying data model is post-based, not page-based as it is now, and neither topic-based as you suggest here. The flexibility lost by forcing all content into a system of posts, topic headers and board headers can in principle be recovered by allowing refactoring edits such as splitting posts and by allowing changes to the post layout. Obviously the current version of Flow is lacking quite a bit of this, but that's just a matter of writing the code. With a topic-based or page-based data model, the information I'd like to see is just not in the data base, and no amount of tweaking code on the back end or on-wiki can change that. — HHHIPPO 12:55, 7 December 2014 (UTC)

HHHIPPO: It's super-easy to do what you want, highlighting all posts that are new since your last visit. If you manually go to history and select a diff range from your last visit-to-current (like this) you get a diff-view with all new comments highlighted in blue boxes. So the software very easily identifies all the new text, and it can very easily render the page normally with that new text highlighted. That's exactly what you want. The only "problem" is that in some cases the diff gets confused and highlights too much, which which is totally a non-problem because it's still a massive benefit for finding and reading what's new. I'd also like to mention here that it would be trivially easy for the editor to add default-signing to talk page comments. People have been begging for this stuff for years. The only obstacle is that the WMF absolutely-positively refuses to do jack-squat to improve Wiki-talk... because their entire goal is to exterminate Wiki-talk. Why would they spend a singe second improving something that they want to kill? Alsee (talk) 22:31, 7 December 2014 (UTC)

I can see the changes marked in the source code (the diff), and I can see the new rendered page, but I can't see the changes marked in the rendered version. Is there a gadget I'm missing? Or do you mean that it would be easy to write such a gadget? I'm not convinced that would be so easy, but I'd be more than happy to be proven wrong here. Especially since that proof would imply actually writing the gadget, which I then could use ;-) — HHHIPPO 23:02, 7 December 2014 (UTC)

HHHIPPO Sorry I meant that such a view-mode could be developed. Chuckle. I'm a programer but I haven't looked at any Wiki-related code. I can see that all the needed elements are already available, and that it would only take a relatively small amount of new code to pull the pieces together. It would probably only work on pages you have watchlisted because watchlist is probably the only place that tracks page-last-viewed dates. (A database tracking every page you had ever viewed would be rather Orwellian, so I would *hope* it would only work on watchlisted pages. lol.) Alsee (talk) 20:25, 9 December 2014 (UTC)

Yes, "unvisited changes" is only defined for watched pages (at least considering the WMF servers, other organizations might have a different view...). But this could be a general addition to diff views, both for diffs called from the watchlist and for others. Actually also for article pages. This has been tried before, but not very successfully. I'm afraid it might be less trivial than it looks like. — HHHIPPO 22:12, 9 December 2014 (UTC)

I did bring up some of these issues here a while back, and got positive responses from wikimedians and a "gee, that sounds interesting, too bad it's above my paygrade" from a WMF employee. (Perhaps most perplexing about this is that it suggests something badly miscalculated in the WMF bylaws, because it's the sort of behavior one would expect from a big for-profit corporation, with machinery in place to insulate those whose job is to make ruthless profit-only decisions so they aren't bothered by the hoi polloi.)

Anyway, as my thinking has progressed since then, having the talk page of an article be a single text file can't be usefully analyzed as a means to an end; in effect, it is itself a fundamental desirable goal. Any information that isn't encoded as text is limited, which is why commercial software favors non-text formats, and why the open-source community has tended to coalesce around the text-oriented UNIX model. --Pi zero (talk) 14:35, 7 December 2014 (UTC)

Methinks the proper structure should be to store content in the database as separate posts with their own independent histories, but present them for edition as a single string of text where the user can freely copy/paste content between posts and change their structure. The "save" step would be more complex and this would likely require support from a special text editor a la VE, but it's certainly doable - as I've pointed out before, Microsoft OneNote works exactly like this. Diego (talk) 14:51, 7 December 2014 (UTC)

"would likely require support from a special text editor a la VE" — that sounds like evidence of a broken design: complex meta-information that's not in text form and thus poisons the accessibility of the whole. The questions being asked about summarizing what has changed are evidence of the same. To make things work better within the essential outline of the existing system is a delicate and subtle art, requiring deep insight; to do big ham-fisted projects that destroy the delicate synergy that makes wikis a successful medium is easily done using conventional corporate centralized, top-down software development. The WMF is apparently structured so that it inherently favors the second approach and, without some sort of major innovative restructuring that I can't yet visualize, may be inherently incapable of the first; but the first is what's needed, while the second is a recipe for long-term irrelevance of the sisterhood. --Pi zero (talk) 16:58, 7 December 2014 (UTC)

That meta-ínformation *can* be in text form, just not in its default presentation, as it would not be friendly for newcomers - which is the whole point of having Flow. There was talk of having a template that could keep track of Flow posts in wikitext, with each individual post having a unique ID wrapping its content, and just adding a bit of tool support.

The default text editor should just hide the template so that newbies would not break it, while still keeping track of what text belong to which post; that's not a complex feature to implement. Meanwhile, experienced editors could be trusted to edit the raw wikitext without breaking the templates. This way, classic wikitext could be merged with flow-stored comments without problem, and without losing flexibility. It would be no different to how we handle tables, except that the content of each post could be stored separately in the DB to achieve the benefits of Flow (no edit conflicts and reusability of content at several pages).

This design was mentioned to one Flow developer, who seemed opposed to it in principle, but didn't engage in a thorough discussion of its advantages vs problems. I still think it would be the best design that could bring together the best of both tools. Diego (talk) 17:44, 7 December 2014 (UTC)

Have you heard the expression "a solution in search of a problem"? That's Flow. It was a bad idea to start with, and the WMF requires it to be the right answer for something; they're willing to look as hard as necessary to find something for it to be the right answer for. And they've got us playing their game, too. This is not a "conspiracy", I don't think; there's no evil mastermind planning things this way. The intentional stance I'm assigning to WMF is not intent by an individual (necessarily), it's inherent in the organizational structure of WMF. The idea of wikimedia is innovative, but the organization of WMF has fallen by default into a form that's traditional for commercial corporations and is antithetical to an open-source volunteer undertaking. I don't claim to know yet what's needed, but after about eight years with the wikimedia projects I'm finally starting to see the problem.

Hiding wiki markup from newcomers is a way to prevent newcomers from losing their initial cluelessness; hence VE too is inherently misconceived. That's not to say the wiki interface couldn't be improved. But, compromising the underlying data structure so that its natural advantages are weakened, while completely replacing the interface so as to prevent access to the surviving natural advantages — that is not a good idea. I can't call it a "bad idea" because that doesn't begin to capture the essential ungoodness of it. Trying to "fix" these proposals is costly in time, effort, and loss of volunteers; somehow we need to throw out these proposals altogether without having them get replaced with equally bad, if not worse, ones. I don't know how to that, but I suspect we may just not be thinking far enough outside the box yet. To be clear: these technical challenges are just things that could be improved; the problem is the WMF. --Pi zero (talk) 18:28, 7 December 2014 (UTC)

Plenty of problems, actually. Links break when archiving. Clicking "talk" on a diff view doesn't show the full discussion if its been archived. It's impossible for admins or overnighters to delete inappropriate comments without deleting a lot of perfectly fine revisions. Difficult to use by inexperienced editors. Unsigned posts. Some of these could be fixed by bots. Some of these are "fixed" by building a hack using bots (signing posts and archiving are such a fundamental part of discussion that we should not have to rely on bots). Several could be potentially fixed by rethinking how we organize talk pages. Some could potentially be fixed with some kind of visual editor. But some of these are so fundamental that a significant a real software change would be required to fix them. Oiyarbepsy (talk) 21:34, 7 December 2014 (UTC)

Oiyarbepsy, you make wikitext talk pages sound like hell. But they do work. While I acknowledge some issues need to be worked around, I really do not see that the magnitude of the difficulties are so great that revolutionary changes, which will wreak havoc with our accustomed workflows, are required. BethNaught (talk) 21:41, 7 December 2014 (UTC)

Right, which is why the proposal above almost entirely maintains the wikitext and merely uses Flow as a container to organize them. All the workflows we have would continue to work (except for no-longer-required archiving) without needing to be changed, so I wouldn't call my proposal above revolutionary, and in fact, the entire point of the proposal is so it's not revolutionary. My point of the above comment was that you shouldn't argue against Flow by pretending our current systems don't have problem. You can argue that there are better solutions, as I'm doing, or argue for particular changes, as a lot of users here do, but sticking your head in the sand and pretending everything works perfectly doesn't help anyone. Oiyarbepsy (talk) 21:49, 7 December 2014 (UTC)

I never said it worked perfectly and I think you know that wasn't the point. The point was that "revolutionary changes" (to which I was under the impression the discussion was now referring) were out of proportion to the problem. Referring to your specific proposal, I reiterate that once VE is stable I would support its extension to talk pages. The rest of its content is worth exploring, but if a system like that were to be implemented it wouldn't really be Flow. Flow goes significantly beyond what I think you are proposing and I think it is unnecessary huge. Sorry to butt in. BethNaught (talk) 22:23, 7 December 2014 (UTC)

What do we mean by "Flow"?

I think one of the problems in discussions like the one above is that we don't always mean the same thing when we talk about Flow:

Some people have their own vision of their preferred discussion system, based on one or the other idea taken from Flow and a number of own ideas they'd like to see added or changed. By Flow they mean Flow as it could be if only the devs would listen to me.
Some people are strongly suspicious regarding the capability, motivation or organization of the WMF. They mean the discussion system the WMF will probably force upon us.
Others just look at the Flow version currently deployed here, see the obvious deficiencies, and assume they won't be removed. By Flow they mean Flow [f0328f0].
Finally, there's casual readers who see the extrapolation of one of the other groups and take that for granted. They mean What I heard about Flow.

I think we could have a more constructive discussion if we tried harder to make clear what we're talking about, and if we would as far as possible separate the discussion about technical points like data models and software features from the political ones like who does the programming and who decides what software is deployed where. — HHHIPPO 23:26, 7 December 2014 (UTC)

Flow is a quantum superposition of all of the above; it will only collapse to something tangible on release day. What data models and software features will be possible depend largely on the politics of the project, as the WMF developers currently aren't accountable to the online community.

For us to be able to make the distinctions you suggest, a much more detailed and updated roadmap should be put in place together with the design constraints and decisions already taken, as well as a firm statement of how the project will be handled. This is needed so that we could effectively distinguish when we are doing politics and when we're daydreaming about ideal (or even plausible) designs. In the current climate of uncertainty, our only hope is that we can convey a design so desirable that the WMF'ers will fall in love for it and decide to create that instead of following their initial, apparently unmovable stated goals. Diego (talk) 16:36, 10 December 2014 (UTC)

Move not listed in the logs?

In July, User:Quiddity (WMF) (I presume) moved Topic: The Washington & Jefferson College Review to Topic- The Washington & Jefferson College Review. However, this doesn't show up in the page history. Can this kind of thing please be avoided? Things which don't appear in the history (except real oversight issues) create mistrust and confusion.

Would it be a technical issue if the page was moved to Topic : The Washington & Jefferson College Review? This would more closely resemble the correct title.

Oh, and by the way, if you now search for the original title, you get a nice pink error: [cca66461] 2014-12-10 15:32:57: Fatal exception of type Flow\Exception\InvalidInputException. Considering that the links to the moved page were only corrected nearly two months after the page move, quite a few people mauy have encountered this... Fram (talk) 15:36, 10 December 2014 (UTC)

Also, Topic- A Journal of the Liberal Arts and Topic: A Journal of the Liberal Arts, the journal's former name. This needs to be fixed, since both of the titles with colons need to be redirects. Oiyarbepsy (talk) 16:12, 10 December 2014 (UTC)

Re: Page-move missing-log problem, I've now filed as phab:T78170. Thanks. (TL;DR: The page-moves were done at a database level. I've asked what possible ways we have to fix those 5 moves. (All are alternate-titles/redirects for the same article))

The Fatal exception for the original titles is filed as phab:T70258

"support Topic:OldPagename as a #REDIRECT" is phab:T70846, and IIUC should be possible once the blocker-bug is resolved (something database-ish).

Re: Using the title "Topic : foo" - I tested at ee-flow and it doesn't work, but hopefully T70846 will resolve this in the ideal way. Quiddity (WMF) (talk) 18:45, 10 December 2014 (UTC)

How To Get Started

Does one need to (or should one) enable the "Automatically enable all new beta features" option to begin using this? I'm hesitant to just jump in there without asking first, but I would like to be helpful in some way with regard to this project if possible, as it evolves. DonaldKronos (talk) 07:13, 29 December 2014 (UTC)

@DonaldKronos: No, Flow isn't one of the beta features (yet). Use the test page, if you want to try it out. --HHill (talk) 09:27, 29 December 2014 (UTC)

Thanks. DonaldKronos (talk) 18:45, 29 December 2014 (UTC)

Update from Lila

Lila Tretikov has made an interesting statement about Flow at her talk page. (Permalink to discussion). Diego (talk) 14:19, 7 January 2015 (UTC)

Thanks for the link which is very refreshing! Johnuniq (talk) 00:17, 8 January 2015 (UTC)

Indeed! :-) That's good news; that direction of management gives the tool a chance for the tool to be adopted by the community in places where it makes sense, if those exist. Diego (talk) 11:02, 8 January 2015 (UTC)

How come this page doesn't use flow?

This is a major discussion page about Flow, so I thought Flow would be enabled on this page. -- ^t numbermaniac ^c 05:13, 26 January 2015 (UTC)

Well, my guess is that if a user is confused on how to use it, it's better to have a complaints page they know how to use. Origamite^ⓣⓒ 05:19, 26 January 2015 (UTC)

Fair enough. But this page isn't only for complaints :) -- ^t numbermaniac ^c 08:13, 26 January 2015 (UTC)

It would be useful if someone could explain the significance of LilaTretikov's interim thoughts and this recent change to "Who is working on Flow?". Those links may suggest that Flow should not be expected here? Johnuniq (talk) 08:26, 26 January 2015 (UTC)

What are you looking for exactly that's not in the interim report, and can't wait until the next official report Johnuniq? I'm struggling to find anything other than vindication, which I very much doubt is useful at this point. Martijn Hoekstra (talk) 12:45, 30 January 2015 (UTC)

VisualEditor 2: Electric Boogaloo anyone? --DSA510 Pls No AndN 06:43, 30 January 2015 (UTC)

Dead link

@Quiddity (WMF):, you have a dead link of the WP:Flow page. It appears that it's supposed to be a link to your testwiki talk page demonstrating templates or something, but it doesn't work properly. Oiyarbepsy (talk) 04:32, 10 March 2015 (UTC)

Ah, thanks. That test-instance (server) was reset; I've created a new demo post, showing math, RTL language, template, and translated-template support. Quiddity (WMF) (talk) 19:26, 10 March 2015 (UTC)

That does seem to demonstrate a problem with Flow: "Permanent" links to threads are neither understandable nor stable. (That may not be quite fair, as test servers are often cleared, but the links certainly aren't understandable. Link pointers should have a name, as well as the current ID number.) — Arthur Rubin (talk) 01:03, 11 March 2015 (UTC)

That was a test instance that was wiped and decommissioned. The fact that the link stopped working is perfectly normal and natural, and not a comment on Flow's capabilities.--Jorm (talk) 01:17, 11 March 2015 (UTC)

If that is typical of what a permanent link to a thread would look like in the final version, it's still not understandable. A typo (say, changing a "0" to an "O"), might link to a completely different thread. Even at the expense of readability in Wikitext mode, a thread link should look something like Topic:Page name:Thread title:Th1sIsNotIntendedToBeReadable, allowing potential manual recovery if there is a typo or data loss in the topic ID. — Arthur Rubin (talk) 01:53, 11 March 2015 (UTC)

@Arthur Rubin:Known issue. See Topic:S2mti8w8pww07s5t

Tracked in Phabricator
Task T59154

Oiyarbepsy (talk) 14:52, 11 March 2015 (UTC)

Formatting tools in edit text box

The text edit box takes wikimarkup, but if your goal is a modern UI, it would be nice to have a toolbar for bold, italic, wikilink, hyperlink, special chars, insert media, and so on. SageGreenRider (talk) 02:12, 9 April 2015 (UTC)

You're about to get your wish (at least, partly). :) The first version of a simple VisualEditor toolbar in Flow entry fields should be going live to en Wikipedia later today. It's got bold, italics, links and a new tool to create mentions. -- DannyH (WMF) (talk) 16:23, 9 April 2015 (UTC)

Thanks! SageGreenRider (talk) 17:28, 9 April 2015 (UTC)

Talk:Phineas Gage

If you want an example of how complicated talk pages can become, take a look into the Total Perspective Vortex at Talk:Phineas Gage. ;-) — Preceding unsigned comment added by SageGreenRider (talk • contribs) 02:30, 9 April 2015‎ (UTC)

Yup, the various types of peer reviews are one of the more convoluted (non-controversial discussion) workflows on standard talkpages. Definitely a challenge. :-) Quiddity (WMF) (talk) 03:21, 11 April 2015 (UTC)

An excellent example of how Talk pages are powerful workplaces rather than the "chat board" model Flow is fundamentally based upon. Flow keeps trying to chase after specific workflows, but it keeps missing our fundamental workflow. Our fundamental workflow is that we create and modify workflows on the fly. A core aspect of that is that our work pages have all of the power and flexibility of article pages, our work pages are literally page-move interchangeable with article pages. That's something that Flow is unable to replicate, unless the Flow team is planning on taking Flow to the point of becoming our new and improved article pages. Alsee (talk) 20:49, 14 April 2015 (UTC)

Alsee, just hypothetically, if the Foundation were pursuing a long-term agenda of throwing out wiki markup entirely, what would do they do to pursue that agenda? I suggest they'd naturally use a three-pronged attack:

Develop alternative "structured data" tech; stuff without all that unseemly free choice of expression.
Introduce, by force if necessary, a semi-WYSIWYG editor to hide wiki markup from new contributors, so they won't learn it and thus won't come to value it and complain when it's taken away from them.
Gradually —so as not to suddenly deprive yourself of your unpaid labor force— drive away the established contributors who approve of wiki markup. Preferably by exhausting and demoralizing them, rather than enraging them, so they won't have enough energy left to interfere with your plans.

Of course the campaign would founder at numerous points and eventually come to grief (with or without permanently crippling the sisiterhood in the process) because it's based on the false premise that wiki markup isn't intrinsically better than what you'd be replacing it with; but, as a set of predictions if the Foundation were being directed by such a plan... well. --Pi zero (talk) 23:13, 14 April 2015 (UTC)

@Pi zero:I think the Foundation's trying to maximize utility for new users--after all, a lot of the people who would have joined an encyclopedia anyone can edit have already done so--but I'm not sure that they're considering the older editors. This simplification for the new users doesn't have to be malicious, just not thought out as well as it could be. I mean, I have VisualEditor turned off and would gladly disable the media viewer thingy when I click on a photo; you and to a lesser extent I are not the people these are oriented towards. I think that the main problem is that you need both new and old editors to build a wiki, and a new talk page form will turn off older editors and screw things up (especially templating user talk pages and RfA voting.) Origamite^ⓣⓒ 23:48, 14 April 2015 (UTC)

@Origamite: On the point about older editors — Established editors are conspicuously absent from the call to action, and then there's Jan-bart's statement that anyone who doesn't like what they're doing should leave. It seems less like they didn't think it through carefully enough, and more like they did think it through and decided the established editors should be ignored (so it's not unconsidered, just unwise). I agree it's not likely to be malicious, but I'm not sure that distinction actually matters in this context.

As for effects, the idea of VE making things easier for new editors presupposes (at best) a false dichotomy between VE and the status quo ante. I've watched software come and go for some decades now, and one thing that's predictable is that that the things of major long-term importance aren't WYSIWYG. It would be entirely possible to develop (with a significant effort, which VE also requires) a UI that works cleanly on mobile devices, fosters structured editing, and is based on exposing the raw wiki markup; but the politics of such things get polarized between changing everything and changing nothing, so an approach that is neither WYSYWIG nor a text box has no well-defined supporting faction. What I see as really unfortunate about VE is that it interferes with the learning path by which new editors become experienced ones with competence in wiki markup. --Pi zero (talk) 02:44, 15 April 2015 (UTC)

Back on topic, once Flow is actually a completed product (it's not), as I see it, most of Alsee's complaints would be satisfied by adding a "wikiview" button to Flow pages that would generate a wikitext version usable by bots and scripts and the like. 99.9% of our talk page functions will work problem-free with Flow simply by introducing sub-sections. But there are so many probably with using a wikimodel for discussions, that something's gotta give. Oiyarbepsy (talk) 12:45, 15 April 2015 (UTC)

Inherently unstable solutions have gotten very trendy of late; the trend was visible at least a couple of decades ago, but it's gotten progressively more pronounced. Closer to home, software projects hereabouts have tended strongly towards a philosophy of provide something that breaks important stuff now, and reassure people that eventually the functionality they've lost will be restored by a more complicated route. For example, take an inherently stable system in which wiki markup is the underlying reality and everything is derived from it by interpretation, and replace it with a system where the underlying reality is something inflexible and humanly unreadable and promise that eventually you'll create a mountain of software that will simulate wiki markup. Except eventually will never come, because, think about it, the simulation would have to be developed and then constantly maintained, and it's not plausible the devs would be willing or able to do so after developing, and in addition to maintaining, the software used to eliminate the underlying wiki markup in the first place. There is no substitute for the inherent stability of having wiki markup actually be the underlying reality. (I don't claim wiki markup couldn't in principle be improved, btw, but that's an entirely separate issue; and trying to do so would be like trying to improve the US Constitution by holding a Constitutional Convention, which would be more likely to result in degradation than improvement.) --Pi zero (talk) 14:01, 15 April 2015 (UTC)

@Pi zero:I've mentioned at this board before about improving transclusion to the point that each topic can be its own page all transcluded onto a talk page, which would bring many of Flow's benefits, such as deleting one post without deleting 10 revisions and not breaking links when archiving, etc. If keeping wikimarkup, I see this as a way of doing it. The problem with the wikimarkup is that it gives computers no possible way of knowing how the page is actually organized. That's why some type of forum would probably work better, since the software would understand that a post is a post and it could be managed accordingly. Oiyarbepsy (talk) 02:43, 16 April 2015 (UTC)

@Oiyarbepsy: I'm not entirely convinced of the bit about wiki markup giving computers "no possible way of knowing how the page is actually organized". Part of the intended functionality of the embedded lisp interpreter I'm developing (yonder) is parsing the entire content of a web page; I've already got a template that parses the transcluded content of a page, and am working on a dialog button that parses the raw markup of a page in order to selectively modify certain template calls (the button I'm starting with would submit a news article for review, but I expect eventually to set up buttons for a wide variety of page state-changes, variously-handled archiving operations, nominations, etc). I'm also hoping to thrash out a suite of templates on Wikibooks that would parse a page describing the TOC of a book and do various things with it (like formatting the TOC in different ways and generating various kinds of navigation boxes for the book pages). There are limits, no doubt, but it seems to me there ought to be lots of untapped scope for parsing pages. --Pi zero (talk) 04:02, 16 April 2015 (UTC)

Knowing how a continuous page is organized is a solved problem in computing, it's what markup languages are intended to achieve; in fact, markdown and wikitext are the most usable solutions found for that purpose, and Visual Editor and Flow are regressions in that respect - to something more complex and less flexible.

The problem with our Talk pages is that mediawiki hasn't ever had explicit tags for conversations nor interaction support for editing them, and thus editors use style tags for their posts instead of semantic ones. The day someone added an explicit conversation mechanism to mediawiki (notifications when using templates {{ping}} and {{user}}) it became a huge success, immediately adopted by the supposedly conservative user base of experienced editors. A semantic editor that enhanced interaction with markup, without hiding it, could convey the structure of pages without requiring the underlying platform to take full control (as Flow intends to do).

Transclusion is a heavyweight tool that somewhat breaks the conceptual model of markup ("all content is a decorated stream of text"); I would only use it at defining the page structure for large blocks of content (full topics may be OK) or small snippets, but not for anything in between. Diego (talk) 10:12, 16 April 2015 (UTC)

Yes, full topics is mainly what I'm advocating here. Right now, our busy talk pages archive with cut and paste moves, which is something users get trouted for if they do anywhere else. In many places, I've seen "in this post you say" with a link to a specific revision of a talk page, and I should be able to hit the talk button and see what the rest of the conversation was - cut and paste archiving breaks that, and most of the time breaks the link to the discussion entirely. Switching to a topic transclusion system would fix this problem, since archiving would simply mean removing the transclusion from the page without actually moving the real discussion. Of course, the mediawiki software doesn't handle transclusion nearly good enough for us to start now. Oiyarbepsy (talk) 12:55, 16 April 2015 (UTC)

It seems both problems of cut-and-paste archiving — misplaced content on one side, misplaced edit history on the other — might, in principle, be addressed by a device that would automatically do the simple detective work that a savvy human would do to find whichever data is misplaced-and-wanted. Taking advantage of the predictable structure of archiving (it's not arbitrary cut-and-paste, even if several different styles of archiving are provided for). Given a page, anchor, and date (humanly meaningful and therefore far more useful than internal codes like revision numbers), it should be tractable to find the right place, and given an archive section likewise to find the edit history. --Pi zero (talk) 13:42, 16 April 2015 (UTC)

New indentation & threading model

A new indentation & threading model has been deployed in today's update. Here's a detailed explanation about this from DannyH, including a comparison with the wikitext indentation habits and traditions (and how confusing those "rules" are for almost all newcomers, especially in large threads), and links to past-discussions, phabricator, and some related ideas.

The short-version (an excerpt) is:

In this new version: If you're replying to the most recent post, then your reply just lines up under the previous message. A two-person back and forth conversation just looks flat, and the visual separation is noted with the user name and timestamp.
If you're specifically replying to a previous post, then your reply creates an indented tangent. If everybody responding on that tangent replies to the last message in that subthread, then it'll stay at the same indentation level. But if someone replies to an older message within the subthread, then that creates a third indentation level. It's set to a maximum of 8 possible indentation levels, and we just stop it there because there's a point where you can't fit a lot of text in each line.
The big idea of the new system is that the indentation should actually mean something. You should be able to tell the difference between a simple conversation and a complicated conversation at a glance, and using indented tangents helps you to spot the places in a conversation where there's a disagreement or a deeper level of detail.

A few editors have said they like it, but it wasn't clear to them how it was meant to work, until they'd read this explanation. Please discuss it here and in the topic linked above, and let the team know what suggestions/requests/concerns/ideas you have. Thank you! Quiddity (WMF) (talk) 23:32, 1 April 2015 (UTC)

Well, you have said it yourself: "A few editors have said they like it, but it wasn't clear to them how it was meant to work, until they'd read this explanation.". Somehow, we do not seem to get that many questions how to read a discussion using the current system. Therefore, if you chose to describe the current system by claiming "how confusing those "rules" are for almost all newcomers", the new system is even worse.

Of course, in reality the claim that the current system is confusing is just false. Also, large and complex threads will be somewhat confusing using any possible system - that's essentially what "large and complex" means. --Martynas Patasius (talk) 17:57, 15 April 2015 (UTC)

The new threading was not confusing to newcomers, it was confusing to veterans. Diego (talk) 10:02, 16 April 2015 (UTC)

If I did understand it correctly, the new system has only been tried out with "veterans" and they found it confusing, not being able to guess (or reason out) what is supposed to end up where. I can see no reason why newbies would find it any less confusing. --Martynas Patasius (talk) 18:26, 17 April 2015 (UTC)

Have you tried it out? It's been out on various Wikipedias for the last couple weeks, and so far the conversations that I've read seem sensible and productive. When you click on a reply link or in an entry field, it opens to show you where your message will be posted.

I don't think the actual feature is confusing. The thing that Nick was referring to was that the feature changed, and it's a rather subtle change, so the people who were used to Flow working in one way were surprised to see it acting in a different way. But I've been looking out for examples where a Flow conversation is unclear because the new indentation system is ruining something. I haven't found any yet, but if you do, I'd like to see them. -- DannyH (WMF) (talk) 20:51, 17 April 2015 (UTC)

"Have you tried it out?" - if the whole point of this new system is suitability for newbies, then we should ask "Is it intuitive enough for newbies?", right? In that case I am no longer a good "Guinea pig". I have read the description.

"It's been out on various Wikipedias for the last couple weeks, and so far the conversations that I've read seem sensible and productive." - that's a pretty low bar, isn't it? Yes, it is better than just positioning posts at random. But you are supposed to show that it is better than the current system.

"When you click on a reply link or in an entry field, it opens to show you where your message will be posted." - yes, one can learn how it works. But then, one can learn to use wikitext as well. For that matter, many newbies have managed to write something in plain text - and we do find out what is going on. It is not that easy to make something easier to use than that.

"The thing that Nick was referring to was that the feature changed, and it's a rather subtle change, so the people who were used to Flow working in one way were surprised to see it acting in a different way." - it is not just that. They knew what has changed and were trying to reason out how the new system works (even after the description was published - look at the series of posts ending with [3]). And there were many guesses. Too many. That's a sign of a non-intuitive system. The proposer has effectively admitted that much ([4] - "It's sad that people find it confusing at first, at least until someone explains them how the layout is working.").

The problem is that it is "your invention". There are web sites that use something like the current system for comments. There are web sites that use "flat" system with quotes (most forums). No one uses your system. Will anyone who wouldn't have learned wikitext want to learn it? I doubt it. --Martynas Patasius (talk) 12:18, 18 April 2015 (UTC)

There's an updated proposal (originated by Hhhippo, and refined by me in this post) that would keep the same ordering and dependencies between posts that other threading system have, while retaining a mostly flat structure.

I think I've read that they tried the new threading system on unexperienced users and they didn't mind the change, though I can't find the discussion were I saw it so I can't confirm it. It would be an improvement for them in that case, as with Flow it's impossible to create badly threaded replies the way it is with wikitext. Diego (talk) 22:02, 18 April 2015 (UTC)

"There's an updated proposal (originated by Hhhippo, and refined by me in [this post]) that would keep the same ordering and dependencies between posts that other threading system have, while retaining a mostly flat structure." - unfortunately, the only thing that was clear to me was that you have to use different test cases... "A", "B", "C"... Who is supposed to be replying to what? Use longer names - "A1-answering-to-B1", or something...

"I think I've read that they tried the new threading system on unexperienced users and they didn't mind the change, though I can't find the discussion were I saw it so I can't confirm it." - yes, it is not very useful, unless one can see what actually happened. Too many things can go wrong.

"It would be an improvement for them in that case, as with Flow it's impossible to create badly threaded replies the way it is with wikitext." - actually, there is nothing wrong with "badly threaded replies" of the kind that newbies use. Nothing whatsoever. That's why such "improvement" tends to be mostly imaginary...

And anyway, it was a change of "Flow", not of wikitext. How did "New indentation & threading model" (or "Extra new indentation & threading model" you have mentioned here) compare with "Old indentation & threading model" in that same "Flow"? That's a more interesting question. --Martynas Patasius (talk) 23:06, 18 April 2015 (UTC)

Flow is a discussion system, and the most important goal is that the people who use it have interesting and productive conversations. It doesn't need to be judged based on how well it maps to another system's rules; it just needs to be good at what it does.

Martynas, you seem to be upset about this change to the feature, and I'm not sure why. Have you found it difficult to use? -- DannyH (WMF) (talk) 03:18, 20 April 2015 (UTC)

So it won't be a replacement of the talk page? Because talk pages are much, much more then just conversation pages. Conversations are the least necessary workflow, they may be nice, but not that essential for building an encyclopaedia. If this dumbed down model of a forum impersonation could go anywhere in its current state, it's at most besides real talk pages in the article name space, and probably as well most user name spaces (I for example don't want such stuff anywhere near my talk page). Thje most important workflow for talk pages is the collaborative article improvement, where sources, layouts, small votes/consensus builds are made.

The current state of Flow lets it look like some facebookisation spree (togeter with MV, Gather, UserProfile and other useles stuff) something that seems to have traction in SF, but not the communities. There is even an explicit rule against the facebookisation of the wikiverse, the WMF has to stick by the rules, they are not the bosses, just trustees.

Talk pages should behave just like any other pages in the wikiverse, any deviation would introduce confusion. They should be fully accessible via wikitext/wikisytax editors, or they are broken.

Flow forum impersonations may be a nice add-on on talk pages, but will hopefully never ever replace them. ♫ Sänger - Talk - superputsch must go 10:49, 20 April 2015 (UTC)

"It doesn't need to be judged based on how well it maps to another system's rules; it just needs to be good at what it does." - um, where in this discussion did I claim otherwise? On the contrary, I see that what has been proposed and implemented here is not "Flow" as such, but "New indentation & threading model", and I see that it is often compared with wikitext ("including a comparison with the wikitext indentation habits and traditions (and how confusing those "rules" are for almost all newcomers, especially in large threads)" etc.), instead of "Old indentation & threading model", as implemented in previous versions of "Flow". But it is that "Old indentation & threading model" that was replaced, and I wonder what is supposed to be better about the "New" one, compared with this "Old" one. I do see one obvious disadvantage of the "New model" (it is not familiar to "veterans" and it is not familiar to "newbies"). I think I see another, less obvious, disadvantage (it was not intuitive enough for participants in the discussion to find out what it actually is, thus it might be somewhat more confusing than the "Old model"). And I can see many vague claims that hint about presence of advantages ("I love it!" and the like). But I do not see any actual advantages written down, black on white. And I am asking what they are.

"Martynas, you seem to be upset about this change to the feature..." - I do?

Oh, and, since I ended up unsure what exactly did you respond to with "It doesn't need to be judged based on how well it maps to another system's rules; it just needs to be good at what it does.", even if I know what "post" you have replied to... Are there any plans to encourage (or discourage) quoting the posts being replied to? --Martynas Patasius (talk) 21:40, 20 April 2015 (UTC)

Here I've talked a little about the relative advantages and disadvantages of the new Flow indentation vs the old talk page convention (it's not really part of mediawiki, just a style guideline). In summary, the new threading model doesn't create as many deep indentation levels, and the conversation can run much longer without requiring indentation tricks; with the new model I wouldn't have needed the above {{outdent}} template to return the conversation to a sane left margin.

In fact, the threading model is independent of the software platform, and could be perfectly used on wikitext as well. I have posted here an example of this very conversation under the current Flow threading model, and here with the proposed refinement (they only differ in the order of the last three posts). Can you see how the model may be simpler to understand to a person reading Talk pages for the first time? Diego (talk) 09:41, 21 April 2015 (UTC)

P.S. Moreover, suppose now DannyH wants to make a direct reply to your latest post above (21:40, 20 April 2015). What is the expected position where he should place it? In both versions of the new model there's a definite position where such reply should be placed, and the conversation can grow almost indefinitely following a consistent set of rules; but in the current wikitext model, it's not clear how one should reply directly to a nested post and keep the conversation growing after someone uses an {{outdent}}. Diego (talk) 11:23, 21 April 2015 (UTC)

Thank you, that is exactly the explanation I was asking for.

And it's certainly a good idea to use the same real discussion to illustrate the difference between the systems. Of course, as Lithuanian saying goes, "appetite appears while eating" - if only we had a more complex example (some comment section from a big RFC, or something like that - for example, it would be interesting to compare how easy it is to spot posts that are not replies to other posts)... And (since remaking indentation style of such discussion by hand looks too hard) if only there was a way to change indentation style automatically...

Still, I am not sure I would have guessed what that horizontal line means that soon (perhaps in five minutes), if I was not a participant of the discussion...

Speaking of a correct position of a reply to a post followed by "outdent"... I guess that the proper way would be to write as if it was a "reply to the whole discussion" and start it with something like "(in reply to [something that identifies the post])". But then, an easy way to indicate the post being replied to would be useful in both wikitext and Flow, using any indentation model (after all, in all those cases discussions might grow just too much to find such posts easily). That is one reason why I have asked if there are any plans to encourage quoting: it would probably be most natural to imitate something used in forums (for example, [5] has enough posts quoting other posts - and one only needs a single click to discover, which ones). --Martynas Patasius (talk) 20:21, 21 April 2015 (UTC)

Yes, I do want to build in quoting, although I'm not sure when. We've recently added one feature that's related to quoting/replies -- a new "mentions" icon in the Flow entry fields, which helps people to directly address people who are further up in the conversation, while still continuing the chronological flow of discussion. There's an autocomplete for people who have already posted in the discussion, to make that easier. It's not quite the same thing as quoting, but it's in the same area. DannyH (WMF) (talk) 22:55, 21 April 2015 (UTC)

Still, I am not sure I would have guessed what that horizontal line means that soon (perhaps in five minutes), if I was not a participant of the discussion... Same thing could be said of the outdent line, or placing two posts one below the other at the same indentation level, which have particular meanings in the current convention that are not obvious. Any system will have edge cases which need to be explained - the test for knowing if a system is intuitive is whether you need to explain the simple, most common case before it can be understood. Diego (talk) 23:16, 21 April 2015 (UTC)

Using Flow on this page

Related to the comments above and elsewhere, this page will have Flow enabled on Wednesday (PDT afternoon). It will follow the usual rollout process, with the current contents being archived to the latest subpage archive, and the current header templates being copied across. I'll also update the header templates once Flow is enabled. Quiddity (WMF) (talk) 08:11, 28 April 2015 (UTC)

@Quiddity (WMF): May I suggest that immediately after starting the Flow page, the first topic is "for older discussion, please see the archives" with appropriate link - This way, a person scrolling through the page, seeing progressively older posts, would get a link to the pre-Flow stuff at the end of their scrolling. Oiyarbepsy (talk) 13:06, 28 April 2015 (UTC)
@Oiyarbepsy: Will do, thanks for the reminder. The task to make that idea an automated component of converting a page is phab:T87452 (see the last mockup in particular). Feedback there, welcome. :) Quiddity (WMF) (talk) 17:43, 28 April 2015 (UTC)

@Quiddity (WMF): What?!?! After many extensive discussions of Flow on the Executive Director's talk page she told us Flow was on hold and agreed with our objections.

Last month I double-checked and asked her to clarify the situation:

Hi, we have paused any but requested rollouts of Flow, but we have not resolved yet how the mission might be changed -- hence the page has not changed yet. To the guest above: great to hear your interest in helping us build wikis. You can find more info here (if you have not done so already): https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker LilaTretikov (WMF) (talk) 00:21, 18 March 2015 (UTC)

I am not aware of the Community establishing a Consensus to request Flow here. Alsee (talk) 09:06, 29 April 2015 (UTC)

Alsee, that's a good point -- we should have asked before saying we were going to change this page. I'm sorry about that.

The reason why we want to enable Flow on this page is that there have been a lot of discussions here -- like "New indentation & threading model" and "Talk: Phineas Gage" above, where it sounds like people are guessing about how Flow works, especially when it comes to recent updates.

Flow is currently in active development -- we're adding important features, and fixing a lot of old problems. So if we're talking to people who haven't looked at a Flow page since six months ago, it's hard to catch people up to the way that it works now. Suggesting that people go and try out a separate test page isn't the same thing as actually using the current feature.

There are some important use cases that Flow doesn't handle yet, like multi-editable collaboration space, and most workflows. But this page is just used for discussions between groups of people, and Flow handles that use case pretty well. I think the easiest and most efficient way to show everyone the current state of development is to actually use it on the page where people are interested in talking about Flow.

What do you think? DannyH (WMF) (talk) 19:03, 29 April 2015 (UTC)

There's enough test pages for this facebookisation gadget, that only impersonates simple forum software, but doesn't help creating an encyclopaedia, There's absolutely no need to put it anywhere else before it's able to do more than just handle simple blahblah. Or ask for a community consensus, this is not WMF property, you are just the servants of the community. ♫ Sänger - Talk - superputsch must go 19:52, 29 April 2015 (UTC)

Actually, Wikipedia pages are WMF property, and the DannyH is an employee of the WMF, not a servant of the community. -- Ypnypn (talk) 20:48, 29 April 2015 (UTC)

The WMF exists to facilitate the community which creates Wikipedia (and other projects). In any case @DannyH (WMF):, absolutely not. It has not been agreed upon, like Lila said would be necessary, and it's really off the mark for a WMF employee to casually decide to do something they shouldn't be doing without even explaining themselves or giving reasonable notice for a change which would affect an important community discussion space. Frankly, it's the WMF's fault that it's failing at explaining its engineering processes to the community, and in my opinion you are not welcome to force a half-baked and wholly-dubious "feature" on us with the excuse that you are so failing. BethNaught (talk) 21:32, 29 April 2015 (UTC)

Also, There are some important use cases that Flow doesn't handle yet, like... most workflows. -- That's more than some. 163.1.120.19 (talk) 21:38, 29 April 2015 (UTC)

Thanx DannyH (WMF). The large majority of people using this page (aside from WMF staff) are objecting to Flow. I don't think it would be a good idea to Force people to use Flow in order explain why they don't want to use Flow. It can come across as a very in-your-face disregard of (two megabyte archive filled with) objections.

The main page has a link to Wikipedia talk:Flow/Developer test page, how about adding a section to the top of this page with the link?

Regarding the latest version of Flow, maybe you can sell it as a lovely chatboard for other sites. I don't see further development being widely deployed here without a CNN-level shitstorm. Maybe I'm wrong.... you really should post an RfC at village pump asking if the project is going in a viable direction. Get some valuable input from the general community that aren't lurking this page. Alsee (talk) 21:52, 29 April 2015 (UTC)

Using Flow on this page is a great way to ensure that people who refuse to use Flow pages (such as myself) will be excluded. I already saw some notification about a Flow survey thingie on MediaWiki and didn't participate in that either for the same reason. As per the above, we don't want this here and we have enough pages to test it on. ekips39❦talk 23:30, 29 April 2015 (UTC)

Hi Danny and Quiddity, I'd like to add my name to those asking that you not activate Flow on this page. When I last checked Flow I found it harder to follow a conversation, but I would like to be able to follow this one. Also, my understanding of Lila's input about this is that nothing would be rushed or forced on the community. Now suddenly to be told that discussion about the very medium editors object to will be held in that medium doesn't seem consistent with that assurance. Sarah (SV) ^(talk) 00:58, 30 April 2015 (UTC)

Thirded. I've been testing it out, and I couldn't figure out an indent like the one used here for a while. Replying individually to the bottom post just added another "main" post, which was confusing. I'd prefer discussing Flow without having to spend time figuring out exactly how to format what I want to say. Origamite^ⓣⓒ 01:31, 30 April 2015 (UTC)
That's quite a rich statement considering how much thought we are forced to put into formatting wikitalk. Oiyarbepsy (talk) 02:12, 30 April 2015 (UTC)

Colons and asterisks don't take much thought. Origamite's issues with Flow sound more complicated than anything one would encounter on talk pages. The raw code we use now makes it easier to see exactly what one is doing. ekips39❦talk 05:29, 30 April 2015 (UTC)

Also, while for wikitalk we have to learn a very little code, it's stupid to force a new system on us which we have to relearn but which will inhibit functionality. BethNaught (talk) 07:23, 30 April 2015 (UTC)

I just looked at Wikipedia talk:Flow/Developer test page. I'm not sure whether it's been six months since I last checked in here, but that page looked basically the same as I recall it did the last time I checked. So, what's new vs. six months ago. What new features and "use cases" should we be testing out? Wbm1058 (talk) 22:40, 1 May 2015 (UTC)

@Wbm1058: The "Browse topics" table of content and the new hierarchical grouping of out-of-order replies have been added recently, as well as the option to use the visual editor (that can be exchanged with wikitext on the fly without loosing content). Diego (talk) 10:16, 4 May 2015 (UTC)

I see. I'm not sure how helpful these features are. As it seems there is no archiving to separate pages, if I want to find anything that's very old, I need to scroll through spinning gears for an hour, rather than just go directly to the oldest archive. Seems the ability to refactor content doesn't exist on Flow pages. Wbm1058 (talk) 12:00, 4 May 2015 (UTC)

I think they're adding features to solve both those problems in the next iteration. The roadmap for april-june lists "Deleting and moving Flow boards" and "Search on a Flow board" as new features; the later should provide the same functionality as the "search archives" box in current talk pages (at least if they include pagination to reach oldest threads, as I've been insisting). Diego (talk) 12:34, 4 May 2015 (UTC)

Per Sarah, it would be perverse to force discussion of something to which many are opposed into using that very thing. Bizarre, even. To do so without consensus flies in the face of the "new way forward" which Lila has said she is spearheading, central to which is community consultation and consensus. Not encouraging at all. Sad face. Begoon ^talk 23:31, 1 May 2015 (UTC)

No. People aren't interested in being alpha testers for a feature they don't particularly want. When you think it ready for global deployment let us know and we will destruction test it. Until then leave it on the test wikis where those who want to know its current state can find it.©Geni (talk) 18:35, 2 May 2015 (UTC)

Why are we using Flow anywhere on any WMF project? The software is a piece of unmitigated garbage that not a single community has asked for, or wants. The project should be immediately terminated and those involved with its development reassigned or let go. Carrite (talk) 17:43, 3 May 2015 (UTC)

Feedback heard, loud and clear. I mistakenly read the earlier thread as being open to the possibility of testing it here; I'll make sure to ask next time, per the standard Flow rollout process. For what it's worth, many other wikis are happily testing Flow, and requesting specific features and tweaks in order to deploy it to more pages at their wikis, e.g. The Catalan Wikipedia has Flow at all their Village Pumps now, and is discussing where else they'd like to try it next; and the French Wikipedia has been using Flow at a sub-page of their Newcomers Help Desk for a few months, and the devs are preparing the remaining features necessary to migrate Frwiki's main Newcomers Help Desk over to Flow. There are test pages at, and ongoing discussions with, the Portuguese, Hebrew, Russian, Chinese, Punjabi, and Telugu Wikipedias. Development is going steadily towards the use-cases that editors ask for, as well as further improvements of the backend and the feeds. Anyway, thanks to the folk who offered constructive feedback, and sorry again that I let my enthusiasm overwhelm my usual caution, before posting the original plan. Quiddity (WMF) (talk) 19:43, 8 May 2015 (UTC)

Well, we're testing it out too on a few pages. It's just that there appears to be a consensus not to have it here and now. For what it's worth, Flow is growing on me as I use it on the developer's test page; however, I cannot imagine using it in several places, including a User talk page (which can often be more templates than discussion). I feel that the main problem is that there is a fundamental incompatibility between simplifying the software for newcomers to make it somewhat more like a forum and the flexibility of current wikicode; and we prefer the wikicode option on this page. Origamite^ⓣⓒ 21:04, 8 May 2015 (UTC)

Renaming issue?

Tracked in Phabricator
Task T71883

When a thread on the Developer test page had its name changed, the notification was incorrect. As can be seen here, it showed the name which it was changed to twice, instead of the name which was changed from and the name which it was changed to once each. Origamite^ⓣⓒ 15:12, 3 May 2015 (UTC)

That bug is tracked at phab:T71883. (sorry for the delayed reply, thanks for the demonstrative screenshot :) Quiddity (WMF) (talk) 21:20, 8 May 2015 (UTC)

I can't see the board right now

The page header is completely covering the discussions, except a tiny sliver on the left. I can click in the text boxes, but everything else is hidden under the header, including the all-important post button. Upon loading the page, for a split second it shows the header on the right of the discussion board, but it almost instantly expands to cover everything up.

I'm using Chrome on Win8. I have the user script for adjusting the width of the discussion board area. Oiyarbepsy (talk) 14:24, 5 June 2015 (UTC)

Also, the close box to the right side of the header replaces the header that's covering up everything with a huge blank gray box covering up everything. Oiyarbepsy (talk) 14:25, 5 June 2015 (UTC)

That is odd. It's not broken for me but the header now goes to the side when the window is wide enough but in doing so is reserving space all the way down the page, i.e. the grey box it's in is infinitely tall. You can hide it, perhaps a bit too well as the hidden box looks more like a design feature than anything containing content. Yes there's an icon but it's unclear what it does. The other odd thing is in that mode, with it collapsed or not, the page's content width isn't fixed but grows to fill the space. I like that, but I think it contradicts some of the design guidelines Flow is following.

Maybe your user script is causing problems and clashing with the new behaviour? Try disabling it and if it doesn't work try clearing your cache.--JohnBlackburne^words_deeds 14:59, 5 June 2015 (UTC)

@Oiyarbepsy: Yes, I think your user script may be interacting badly with the new side rail feature. We've moved the header content to the side rail, and you can collapse the side rail to see the page at (almost) full-width. You probably don't need that user script anymore, because you can adjust the width of the discussions with your browser and the side rail.

@JohnBlackburne: The design guideline has changed -- it was too restrictive, and there's value in letting people choose the width that they want. I'm glad you like the new change. :) DannyH (WMF) (talk) 01:10, 9 June 2015 (UTC)

It's good that it’s not set in stone, but a bit early still to see how it will all work. Far too many rough edges. After the above I commented with a few more thoughts on the test page itself.--JohnBlackburne^words_deeds 01:56, 9 June 2015 (UTC)

Flow page header edits

Tracked in Phabricator
Task T106459

I just tried to correct a minor misprint ("notofication") on the head of Wikipedia talk:Flow/Developer test page (twice). This didn't work. There was no warning or reservation; I got up an edit box, did the edit, and seemingly saved it; but it doesn't take. There seems to be a bug, either in some inbuilt restriction of the right to edit not being displayed, or in the saving process.

If indeed the possibilities to edit the page header is to be restricted (e. g. to Flow developers or to enwiki administrators) then there should be a warning about this, or at least not seem to be edit possibilities. Best, JoergenB (talk) 19:55, 15 August 2015 (UTC)

My edit seems to have gone through, so probably a bug rather than an intentional restriction.--Anders Feder (talk) 20:24, 15 August 2015 (UTC)

There's a rare bug about this (not showing changes, until the page is manually refreshed), but it hasn't been possible to consistently reproduce outside of the developer's local testing environment. I'll reopen phab:T106459. Quiddity (WMF) (talk) 21:53, 31 August 2015 (UTC)

Watching?

Is there any way to watchlist an entire page with Flow instead of just a single topic? I tried watchlisting Wikipedia_talk:Flow/Test_page and it only adds a single topic, not the whole page. Maybe I'm doing something wrong? Short Brigade Harvester Boris (talk) 20:16, 3 May 2015 (UTC)

It's on my watchlist as I get notified every time a new topic is created. Looking at my raw watchlist I see Wikipedia:Flow/Developer test page on there which is probably what’s doing it (as that's the page it's a talk page of).--JohnBlackburne^words_deeds 20:23, 3 May 2015 (UTC)

I get notifications on MediaWiki about a) new topics and b) new posts in watched topics, not about any other changes on the page. Grüße vom Sänger ♫ ^(talk) 21:02, 3 May 2015 (UTC)

Yes seems there’s no way to be notified of every change on a page. You could visit it every time you see a new topic is added and watch that topic. I'm sure something will be added to let you automate this, it's an obvious additional way to watch a Flow page on top of the existing options.--JohnBlackburne^words_deeds 21:10, 3 May 2015 (UTC)

@JohnBlackburne: Exactly that, at a minimum. There are some notes and napkin-sketches in a few team email threads, about possibilities beyond that minimum, that they'll hopefully get onwiki (or phabricator) soon. I'm pushing for Watching to take as much complexity (future growth) as possible into account (i.e. many of the thoughts in the age-old mw:watchlist wishlist), but that will obviously have to be tempered by practicality. (e.g. At the extreme end of the spectrum: I'd love a way to get emailed for changes on some pages (or topics), and echo-notifications for others, and just notifications for new-topic-creations at others, and to only watch the main/project page (not the talkpage) on still others, and some only for a limited time, and and and ... ; all along with various options for what appears in the watchlist itself. But, that kind of power would add a ton of columns to various databases, and a ton of complexity to coding/testing/maintenance, and quite a bit of complexity to the UI... So they're researching what is feasible/realistic). More details on all that, and a wide invite to discussion, when I/they know more. Quiddity (WMF) (talk) 23:56, 8 May 2015 (UTC)

For Flow pages, there are two sets of stars. The star up next to the new topic button (in the usual location) will watch the entire page. The stars near the topic headings will watch only that topic. I have the entire page watched and new topics appear on my watchlist. Oiyarbepsy (talk) 12:52, 4 May 2015 (UTC)

Just what I said: New topics appear, but no answers to not-watched topics. So it's not a "watch the entire page"-star, just some subset of changes to the page: a) changes to watched topics and b) new topics. Grüße vom Sänger ♫ ^(talk) 15:00, 4 May 2015 (UTC)

I've come across this feature for the first time today. I don't like the fact that new topics now go to the top of the page. Even worse that this, I especially don't like automatic watching of a post. I posted a courtesy notice to WT:HANTS re an AfD of an article that falls under their remit. As such, there is no need for editors to reply. There is even less need for me to be notified that they have replied. The purpose of notifying the AfD was to encourage editors to a) comment, and b) improve the article to demonstrate that it should be kept - if that was how they felt. My watchlist is confined to a very few quality articles that I monitor to ensure the remain quality, and a very, very few editors that I keep an eye on, mostly vandals although I do occasionally mentor editors at a distance and watchlist their talk pages for this purpose.Mjroots (talk) 07:54, 1 September 2015 (UTC)

Not a huge deal for me, but I would also prefer that topics one has participated in are not watched by default. Possibly there could be some intuitive checkbox you can check before posting if you want to watch the topic, but IMO it should default to off. The watchlist simply becomes too noisy otherwise.--Anders Feder (talk) 07:59, 1 September 2015 (UTC)

Wording

Should this

Flow will eventually replace the current Wikipedia talk page system

be changed to this?

Flow may eventually replace the current Wikipedia talk page system

Flow should need to get community consensus before it is implemented and should not be forced onto the community IMO. I hope the wording in this document will reflect this. Doc James (talk · contribs · email) 19:39, 24 August 2015 (UTC)

@Doc James: I hope you understand why many of us have no confidence in that, despite our respect for you. Take for example the views of Jan-Bart, the chair of the board. BethNaught (talk) 20:37, 24 August 2015 (UTC)

I hope you also understand that many of us do not share the view that an alienating 1990s user interface is crucial to Wikipedia's success.--Anders Feder (talk) 20:41, 24 August 2015 (UTC)

I don't think that Doc James was stating explicitly support for the current way of operating talk pages, just noting the need for community consensus for its implementation. Jo-Jo Eumerus (talk, contributions) 20:47, 24 August 2015 (UTC)

I didn't say he did. I was just making sure we agree that "community consensus" does not equate "the consensus among the group of users who complain about any and all improvements".--Anders Feder (talk) 22:26, 24 August 2015 (UTC)

@Anders Feder: If that is the consensus view of the community I for one will accept it. The point is that the WMF must not be allowed to steamroller over us in order to implement Flow. BethNaught (talk) 20:48, 24 August 2015 (UTC)

Yes this is about process not about product. Just because something is new and expensive does not mean it is better. Doc James (talk · contribs · email) 20:53, 24 August 2015 (UTC)

We are seeing a lot of change on the board. We have three new boardmembers including myself that started in July. Jan-Bart and Stu step down the end of this year and thus we will have two more new board members soon.

The only way we are going to "succeed" is by the community and the WMF working together. And the only way we can work together is as equals. Yes democracy is messy and slow but no one has ever found a better way to make decisiosn.

We sort of currently have a reader oriented format of Wikipedia (called mobile) and a editor oriented format of Wikipedia (called desktop). Doc James (talk · contribs · email) 20:53, 24 August 2015 (UTC)

Pinging DannyH (WMF) and/or Quiddity (WMF), as the WMF staff listed as handling this page. Either a comment or action on Doc's request would be great. Thanx. Alsee (talk) 18:51, 28 August 2015 (UTC)

Done. :) Quiddity (WMF) (talk) 21:42, 1 September 2015 (UTC)

Thanks User:Quiddity (WMF) :-) Doc James (talk · contribs · email) 01:20, 2 September 2015 (UTC)

Do you still need user test data?

Previously developers here asked Wikipedia:WikiProject Breakfast to test flow and applied template:Flow-enabled for the research period. At Wikipedia:Wikipedia Signpost/2015-09-02/News and notes it is reported that Flow is no longer being developed.

Do you still need test data from this and other WikiProjects? What is your plan for notifying people who agreed to support Flow research by using Flow? If you are no longer requesting users to use Flow for your testing, then may I request that at WP:Breakfast and other communities which consented to participate in testing that you report the end of the test and offer to revert the discussion forum to the usual format?

Thanks. I hope that the effort volunteers gave to testing this was useful to you. I raised the general issue of winding down studies at meta:Research_talk:Committee#Interaction_with_research_participants_at_the_end_of_a_study Blue Rasberry (talk) 15:02, 4 September 2015 (UTC)

Based on the statements above, I am guessing that Flow is actually still maintained and supported. That is, if folks there want to keep Flow for now they can do so.Jo-Jo Eumerus (talk, contributions) 15:54, 4 September 2015 (UTC)

Priorities for the Collaboration (Flow) team

Hi everyone, here's a copy of the message from Dannyh:

For a while now, the Collaboration team has been working on Flow, the structured discussion system. I want to let you know about some changes in that long-term plan.

While initial announcements about Flow said that it would be a universal replacement for talk pages, the features that were ultimately built into Flow were specifically forum-style group discussion tools. But article and project talk pages are used for a number of important and complex processes that those tools aren't able to handle, making Flow unsuitable for deployment on those kinds of pages.

To better address the needs of our core contributors, we're now focusing our strategy on the curation, collaboration, and admin processes that take place on a variety of pages. Many of these processes use complex workarounds -- templates, categories, transclusions, and lots of instructions -- that turn blank wikitext talk pages into structured workflows. There are gadgets and user scripts on the larger wikis to help with some of these workflows, but these tools aren't standardized or universally available.

As these workflows grow in complexity, they become more difficult for the next generation of editors to learn and use. This has increased the workload on the people who maintain those systems today. Complex workflows are also difficult to adapt to other languages, because a wiki with thousands of articles may not need the kind of complexity that comes with managing a wiki with millions of articles. We've talked about this kind of structured workflow support at Wikimania, in user research sessions, and on wikis. It's an important area that needs a lot of discussion, exploration, and work.

Starting in October, Flow will not be in active development, as we shift the team's focus to these other priorities. We'll be helping core contributors reduce the stress of an ever-growing workload, and helping the next generation of contributors participate in those processes. Further development on these projects will be driven by the needs expressed by wiki communities.

Flow will be maintained and supported, and communities that are excited about Flow discussions will be able to use it. There are places where the discussion features are working well, with communities that are enthusiastic about them: on user talk pages, help pages, and forum/village pump-style discussion spaces. By the end of September, we'll have an opt-in Beta feature available to communities that want it, allowing users to enable Flow on their own user talk pages.

I'm sure people will want to know more about these projects, and we're looking forward to those conversations. We'll be reaching out for lots of input and feedback over the coming months.

On behalf of the Collaboration team, Quiddity (WMF) (talk) 22:23, 1 September 2015 (UTC)

Very much appreciate the update. I think the shift in focus is a smart one. A few "small" changes to what we have right now would make collaboration much better. I assume that notification between WP languages is on that list? Best Doc James (talk · contribs · email) 01:23, 2 September 2015 (UTC)

Yes, work on Global Notifications is also on the roadmap for next quarter. Quiddity (WMF) (talk)

I'd say this was probably a good call. Next step would be what elements within Flow could be a benefit to our current wikitalk pages. Some ideas would be making pages topic-based rather than section-based, simple new-post and reply buttons, visual editing of posts, and post-based notifications. The ability to cross-post was the never-implemented Flow feature I dreamed of (figuratively), and it would be great to make it easy to do this on wikitalk pages. We have a huge number of little-watched talk pages where questions never get responses, so some way to put these obscure talk page topics onto a central discussion board would be a great help. Oiyarbepsy (talk) 03:09, 2 September 2015 (UTC)
Good points, thanks. Quiddity (WMF) (talk) 19:00, 2 September 2015 (UTC)
To re-emphasize: Starting in October, Flow will be in full maintenance; it's not being abandoned. Further work on the discussion system will need to be driven by communities voicing their desire for further work on it. Quiddity (WMF) (talk) 19:00, 2 September 2015 (UTC)

Addendum: As a pattern that we're all familiar with, it's more likely that people will comment when they have negative or critical feedback, particularly at a centralized forum. While it's helpful to point out things that are not user-friendly or frustrating to use, it's also helpful for the team to know what is going well - so we can do more of it. I’d like to encourage people to speak up (here or onwiki) when there's positive feedback as well – this goes for article-editors as much as software-developers. There are people on many wikis who have been happily using Flow, but they haven't gone out of their way to broadcast that information off of their usual home wiki. What do you like about this software? Is it headed in the right direction, even if it doesn’t seem complete? Are there things about it that the Collaboration team could continue to focus on in the future?

See also, the threads on wikitech-l and on wikimedia-l, for additional discussion.

Hope that helps, Quiddity (WMF) (talk) 22:45, 2 September 2015 (UTC)

Please feel free to disregard all voices that solely have bad things to say. In article space we call such users disruptive and there is no reason to think that such users are not active in the project namespace as well.

Among the features of Flow that looked most promising was that it split individual comments and sections into discrete entities. The current old-style talk pages do not make any such distinction - a talk page is just one long jumbled mess. This make it exceedingly difficult to make tools that consume or otherwise interact with talk pages. There is tool that tries to analyze !votes, for instance, but the other day at WP:VPT, someone complained that the tool was not reading their !vote right - the messy structure of the talk page effectively broke the tool. The analyses that such tools are trying to deliver are important to understand and document larger trends in comments made by individual users or by users in general, but because of the noise in the input talk pages, they are not reliable.

New users also regularly complain that the format is awkward, and one has to wonder how many potential contributors simply stop bothering when they instead of adding encyclopedic material has to learn all sorts of bizarre codes for signing, indenting, bulleting, pinging etc. etc. If one's mission is to drive away subject matter experts and retain the turf for a small acrimonious core of "old-timers", on the other hand, then the existing talk pages do a magnificent job.--Anders Feder (talk) 23:44, 2 September 2015 (UTC)

How do you know subject matter experts are being driven away and that Flow would draw more of them? That's a genuine question, not a challenge. I know of lots of subject matter experts who are active on Wikipedia including myself. Don't take this the wrong way -- again, I'm not questioning your intent, just asking to see the evidence that supports your hypothesis (we subject matter experts tend to do that). Short Brigade Harvester Boris (talk) 01:26, 3 September 2015 (UTC)

Improving the talk page system is a good idea. The "little notifications" at the top of our screens are not controversial and are well liked. They can be improved. Agree being able to watch sections of talk pages would be supper helpful and hopefully we will see it come to the current talk page system. Doc James (talk · contribs · email) 02:24, 3 September 2015 (UTC)

As a subject matter expert, do you have evidence of the opposite? In between the absence of evidence for either conclusion, it is a view that it could.--Anders Feder (talk) 02:30, 3 September 2015 (UTC)

I would say, that the disconnect Flow creates between normal wikiformatting everywhere and this forum impersonation will create more difficulty for newbies, as it's harder to show them stuff on the talk page about the real stuff in the article. Now all is the same, you don't have to change your working from maion page to talk page and back, with flow it's no longer that way. Grüße vom Sänger ♫ ^(talk) 04:38, 3 September 2015 (UTC)

I am unable to think of a way for those who do not want to use FLOW to not have to. With VE you can simply not use it if you like the old system. It was not going to be like that with FLOW. Thus a much harder bit of software to roll out. Plus the WMF needs to spend more time developing things the community asks them to. Doc James (talk · contribs · email) 07:52, 3 September 2015 (UTC)

This section does link to some research data regarding our talk pages. People trying to weigh the benefits/costs of a Talk-->Flow transition may find some information there. More peripherally, most Internet venues of communication look like Flow and not like Talk, which may say something about the suitability of both for discussion. One consideration of mine (I don't think I've found the answer yet): Does Flow allow to put header posts (or sticky threads) on talk pages? The main difference I see between talk pages as they are nowadays and a forum is that we use talk pages for header statements, such as e.g which WikiProject cares about a page. Jo-Jo Eumerus (talk, contributions) 09:32, 3 September 2015 (UTC)

Re the research: mw:Flow/Research is a joke. The data supposedly showing that experienced users think wikitext talk is a problem comes from a sample of 28, all self-selected in response to a biased question. BethNaught (talk) 09:39, 3 September 2015 (UTC)

@Jo-Jo Eumerus: The "About this board" description area, which is shown either at the side (in desktop view, if our browser window is wider than 1170px) or at the top (if it is thinner than that, or in mobile) is where permanent or 'sticky' templates, instructions, and introductions can be put; see Wikipedia talk:Flow/Developer test page for example. Quiddity (WMF) (talk) 19:22, 4 September 2015 (UTC)

Finally. How about using some of that newly freed programmer time to actually make the core MediaWiki application look and function like something from this decade? — Scott • talk 21:51, 3 September 2015 (UTC)
- Would you be willing to share some examples of what you want? Specific suggestions are more likely to happen. -- Ypnypn (talk) 23:24, 3 September 2015 (UTC)
  - Have you stopped by Phabricator (previously, Bugzilla) any time recently? There are tasks in there relating to basic functionality that have gone unaddressed for years and years and years. Here's one: T7875. "Group similar pages in watchlist (aka multiple watchlists)". Filed in: 2006. Nearly a decade later, MediaWiki users still don't even have the incredibly rudimentary feature of being able to create separate lists of bookmarks. The thing is an antique; it's embarrassing. There are hundreds of similarly basic and trivial improvements proposed there that have been similarly ignored, while show-off projects like Flow have had heaps of donor money and scads of programmer time spent on them. The WMF has never had any idea about priorities. I can only hope that Flow being taken out back and put out of its misery heralds a long-overdue change in that. — Scott • talk 18:01, 5 September 2015 (UTC)
    - Tool Labs is another critical feature of the project which has not been made a priority of the WMF and needs to be. I think heaps of us would rather the WMF spend two months to get https://tools.wmflabs.org/ up to stable working functionality so we don't have tools repeatedly going down intermittently. Putting some developer support in to some of the tools abandoned by retired users would be awesome as well... --IJBall (contribs • talk) 16:48, 6 September 2015 (UTC)
    - @Scott: No kidding. I did some pushing on that particular issue earlier this year and threw up my hands in disgust at the prototype, the idea that other developers control the fate of user requests (a long standing issue) and the last question. Seriously, after almost ten years, you still have to ask the question, "what is the thing you want to achieve here"? On a related note Quiddity (WMF), can you tell us what's happening with the results from the "what features would you like to see?" surveys the WMF ran back in December and again with a different format in June? --NeilN ^{talk to me} 23:39, 6 September 2015 (UTC)
      - @NeilN: The results of the gadgets survey fed into ongoing work at mw:Community Tech team/All Our Ideas (IIRC they're also discussing items with WMDE, specifically around Dewp wishlist). See mw:Community Tech team for more details and other related work. Quiddity (WMF) (talk) 23:38, 11 September 2015 (UTC)
- I kind of thought the whole point of Flow was to make our discussions look and function like something from this decade. Oiyarbepsy (talk) 11:40, 4 September 2015 (UTC)

At the risk of sounding unnecessarily harsh, could some native speaker translate that message from WMFish to English? As far as I understand, the original plan was to turn Flow into a customizable tool to be used in all instances listed above, with slightly different functions active in article talk pages, user talk pages, FAC discussions and so on (different workflows, same tool). Now it seems Flow drops out from the agenda and will be left as-is, halfway through development, with some limited support for those communities which already made the step and implemented Flow somewhere for tests.

Sorry, but I'm confused and slightly disappointed. Many Wikimedians spend considerable time and effort trying to convince their communities that Flow is a step in a good direction, that this time the Foundation is working hand in hand with the communities to develop and introduce a functional and badly needed tool. Was it all in vain? And what's the point in testing Flow on our wikis when it's not actively developed and the tests will never lead to wide-scale adoption of the tool? //Halibu tt 12:42, 4 September 2015 (UTC)

Translation is an appalling tricky business. I still remember listening to Lila's keynote talk from last year's Wikimania, which I loosely translated (and I still think it a pretty good rendering) as "the Ministry's interfering at Hogwarts."

This statement sounds to me as if the WMF figured out, or at least decided to take the position, that the tool they'd built was in some sense or other not general enough for the purposes for which talk pages are used.

Flow can't work for at least two basic reasons: First, talk pages get a lot of their power from the fact that they work by exactly the same rules as article pages, so that no matter what other sort of facilities you provide for supporting talk pages, they'll fail to be the one thing they truly need to be: facilities that work exactly the way ordinary wiki pages work. Second, even aside from that, talk pages have an immensely general facility that can be used to do pretty much anything at all, amounting in power and versatility to a programming language, whereas Flow seeks to provide specific facilities, which its designers kept studying to 'understand what is needed', and they could never actually provide what was needed because no matter how many specific facilities you provide, you'll never catch up with the need to allow everything that a truly general facility allows. In other words, a facility that actually doesn't work exactly the same way as ordinary wiki pages will never actually work exactly the same way as ordinary wiki pages, and a facility that is actually not general-purpose will never actually be general-purpose.

Unfortunately, there's no clear indication of whether the WMF understands those two things, and given what's gone on in the past year, and in past years, I lean toward pessimism. The statement talks about "complex workarounds" for "complex workflows", which they might talk about if they understood, but would also talk about if they were still stuck on the idea of providing specialized tools instead of a low-level general-purpose facility from which the wiki community can grow what it needs. --Pi zero (talk) 19:59, 4 September 2015 (UTC)

Talk pages are mostly used for meta-information (WikiProject templates, for example) and for discussions, though. I am not certain if that general statement applies to everything, there. Jo-Jo Eumerus (talk, contributions) 20:12, 4 September 2015 (UTC)

The point of flexibility is to be able to suddenly change gears, with no prior indication there would be a reason to do that. It's of no use whatsoever to see that it would have been useful and then sent a suggestion into a pipeline where maybe someday some functionality might get added; there is simply no substitute for the power already being there, which is why it's impossible to accumulate specifics when what is wanted is generality, and it's impossible for a centralized development model to provide specific facilities that would have been possible for the community to develop if they'd been provided with truly general facilities with which to develop them. (Cf. n:User:Pi zero/essays/vision/sisters.) --Pi zero (talk)

Yes, I can clarify. I'm sorry that the message that I posted was confusing. Flow is being maintained and supported, and we need to have conversations with each wiki that's been using it about what's coming up. There are some wikis that have started using Flow on user talk pages, and they really like it. It's important to me and to the team to make sure that the people who are using Flow continue to have a good experience with it.

What's happening now is that Flow is going to be one of the extensions that the team maintains, along with Echo and Thanks. Echo wasn't in active development for at least the last eighteen months, but we're doing the early work on global cross-wiki notifications right now, and that's another project that we'll be working on this fall. So "not in active development" doesn't mean cancelled and killed.

We talked about the Workflows project at Wikimania a couple months ago. Here’s an updated version of the slides that we used: Workflows - Collaboration team 2015 (revised). At the time, we said that we were planning to work on it starting early 2016.

When it got to budget and planning time for the Foundation, we had to assess the relative value of the work that we were doing. What we ultimately decided was that starting on Workflows was going to have a greater positive impact than making more discussion features. So the Workflows project moved from "3 to 6 months from now" to next month.

Meanwhile, as I said, there are some communities that are using Flow on user talk, village pump and help pages, and they find it really valuable. We want to make sure that they continue to get value out of the work that's gone into this project. Later this month, we're going to release a Beta feature for communities that request it, which will let people opt-in to use Flow on their own user talk page. We will fix bugs as they come up.

I hope that helps to explain things better. Is there anything people would like to know more about what we're planning? DannyH (WMF) (talk) 21:11, 4 September 2015 (UTC)

CLARIFICATON I found Quiddity's explanation unclear, confusing, possibly unintentionally misleading (or it least I was initially mislead by it). So I carefully looked into what they are working on, and directly asked the Project Manager DannyH. It turns out that Flow development is still continuing full speed ahead. When Quiddy said Starting in October, Flow will not be in active development, as we shift the team's focus to these other priorities - it turns out to mean the Flow team will be focused on developing a specific subset of features for Flow. When Quiddy said To better address the needs of our core contributors, we're now focusing our strategy on the curation, collaboration, and admin processes that take place on a variety of pages, it turns out to mean they are working on a project which is designed to NOT WORK AT ALL on our existing pages.

More specifically they are developing "workflow" which - in theory - should be a great thing that everyone would love to get. Currently things like filing an AFD are an ugly multistep process. The community has created scripts, such as Twinkle, to automate the AFD process. Step 1 add AFD template at the top of the article. Step 2 create a specially formatted page for the deletion discussion. Step 3 list that page on the daily list of AFD discussions. The WMF has a lovely mockup for workflow, where the community will be able to click a few buttons and fill in a few boxes, and it will create an automated AFD process, just like the AFD scripts we currently use. We could then use the tool to create similar automated processes for Fine Article Nominations, and all of the other stuff we do. And the WMF would properly integrate those automatic-processes with the public interface. Instead of each person having to install a script like Twinkle, everyone would automatically get access to the new AFD option, people working on Fine Article Nominations would automatically get access to all the Fine Article Nomination process options, etc.

Obviously the WMF COULD create this system for existing pages - the community can (and has) already built scripts for many of these things ourselves. The WMF decided not build that tool. The WMF has decided to build a version that won't work, at all, on our existing pages. They're building it as a restricted subsystem of Flow-chatboards. It works if we eliminate all of our AFD pages, eliminate our Article Talk pages, eliminate our user Talk pages, eliminate our Administration pages, and convert everything to Flow chatboards. Alsee (talk) 23:09, 6 September 2015 (UTC)

I was interviewed a couple months ago by a WMF staffer. During the interview I showed him how I used Twinkle to process reports at AIV, ANEW, and RFPP (he had no idea Twinkle could do those things) and MusikAnimal's helper script to formulate responses. I hope the WMF did not use what I demoed as an incentive to reinvent the wheel. Other wikis might benefit from these features, but we already have them here, with volunteer developers that are far more responsive and receptive than WMF developer staff. Give them proper support, learn how to adapt their scripts for other wikis, and work on features we don't have. --NeilN ^{talk to me} 23:58, 6 September 2015 (UTC)

NeilN You were an interviewee? Ha, I was recently reading the results here. I would give you a barnstar for all the hard work you contributed, but it's only compatible with posting on Flow pages. And the devs are still busy trying to draw a copy of one of our existing barnstars. Alsee (talk) 18:01, 7 September 2015 (UTC)

@DannyH (WMF): Is Alsee's description above accurate? Oiyarbepsy (talk) 02:25, 8 September 2015 (UTC)

What about making the mobile platform suitable for collaborative editing? I'm not talking about gee-whiz features but improvements to basic functionality. For example, I can't even figure out how to get to an article's Talk page when viewing the article on mobile. Short Brigade Harvester Boris (talk) 02:53, 8 September 2015 (UTC)

Workflows are going to need to use structured discussion elements, in the same way that we currently do by hand (or Twinkle) -- in some cases, creating subpage threads that are transcluded onto a larger board. We're planning to use Flow elements as a service within Workflows, in the same way that Flow uses VE as a service.

We're not going full speed ahead on Flow -- we're stopping development on the discussion features that we planned to build next quarter. But our team has been planning to work on Workflows for a long time, and we talked about it at Wikimania this summer as the next project that the Collaboration team was going to work on. So the Workflows project moved from “3 to 6 months from now” to next month. You can see early concept work on Workflows in this document: Workflows - Collaboration team 2015 (revised).pdf. It's a big project. DannyH (WMF) (talk) 17:04, 8 September 2015 (UTC)

DannyH (WMF), I'm a programmer, you're a programmer, but saying "X is a service of Y" is meaningless technobabble on this page. It doesn't matter how the compiler is linking the code. From our point of view.... for all practical purposes.... if it doesn't work without Flow then it could just as well be a subsystem of Flow. When you say We're planning to use Flow elements as a service within Workflows, that translates as a 'Yes, the Flow team is still going full speed ahead on a Flow project'.

I think it's worth noting here that I made a request to DannyH (WMF). The statement higher up the page says Further development on these projects will be driven by the needs expressed by wiki communities. I requested he build workflow for existing pages and our current editor... I then went further and asked If I bring you an RFC result expressing the need that workflow be built for existing pages and our current editor, will that do it?[6] Alsee (talk) 18:02, 9 September 2015 (UTC)

To reiterate my original point, how is Workflows (or Flow, or whatever) going to be useful on mobile if people can't even get to the talk page to begin with? Short Brigade Harvester Boris (talk) 00:37, 10 September 2015 (UTC)

@Short Brigade Harvester Boris: There is now a talkpage link on the standard mobileweb design, at the bottom of each page, e.g. https://en.m.wikipedia.org/wiki/Monk - I don't recall when it was added.

Flow does work with mobileweb too, e.g. the test page. Though it hasn't been given as much attention yet (see tracking task phab:T93430).

Mobile-apps are outside of my familiarity. Quiddity (WMF) (talk) 18:56, 10 September 2015 (UTC)

I see it in your example when browsing from a desktop, but the Talk page link does not appear on my phone (it's a Moto G, which is a fairly common model). Neither does it appear on my Samsung Galaxy Tab 10.1 (again, a common model). Something is seriously wrong if a feature is supposed to exist but doesn't actually show on common devices. Short Brigade Harvester Boris (talk) 01:35, 11 September 2015 (UTC)

@Short Brigade Harvester Boris: I was very confused, because I have the same phone model! I went digging, and found phab:T54165. Currently, the talkpage links are shown to logged-in users whom have greater than 5 edits, or logged-out users who have opted-in to the beta setting. HTH. Quiddity (WMF) (talk) 23:38, 11 September 2015 (UTC)

Ah, that's it. When using a mobile device I never log in, so the talkpage link doesn't show. Thanks. Short Brigade Harvester Boris (talk) 00:37, 18 September 2015 (UTC)

DannyH, I'm a little confused by the implications of "Workflows are going to need to use structured discussion elements". Looking over your wireframes, and Quiddity's initial comment, "workarounds...that turn blank wikitext talk pages into structured workflows", I get the impression that the Collaboration team sees the "workflow" as being strictly limited to the structured discussion (talk) page. When I think of a "workflow" in the context of AfD, for instance, I see it in somewhat broader terms: I have to 1) place a notice on the article, 2) set up a discussion of the deletion (which will be linked by the notice), with appropriate categories, and I should 3) notify interested parties about the discussion. The existing tools mentioned above (e.g., Twinkle) handle all three of these; you seem to be focusing exclusively on number 2. Would workflows support 1 and 3 as well? Choess (talk) 05:45, 10 September 2015 (UTC)

Yes, we'd definitely address 1-3 in your list. We're working on defining common components of workflows across the site. Starting the process involves announcing and listing the discussion, and resolving it can involve notifying people, or just taking the announcement template off of a page. DannyH (WMF) (talk) 20:53, 11 September 2015 (UTC)

Choess, I have been discussing this issue with DannyH on his ~~Talk~~ Flow page. When he says "Workflows are going to need to use structured discussion elements" that means Workflow is not going to work on Wikipedia at all. Not unless and until we eliminate all of our Talk pages and replace them with Flow chatboards. Danny promised the project was going to be driven by the needs expressed by the communities. That statement turned out to be .... less than accurate. I asked whether he'd listen to an RfC expressing the need that Workflow work on existing pages. It was explained to me that an RfC wasn't needed and wouldn't be listened to, because the community are a bunch of change averse Luddites. I then asked whether he'd listen to multiple Wiki RfCs or a cross-wiki RfC, reasonably representing a consensus of our global community. It has been nearly a week, Danny has been actively editing, but no response. Alsee (talk) 14:18, 21 September 2015 (UTC)

Danny, if I had received a statement like the one above about my project, I would want to talk to my immediate boss ASAP, whether I need to come in ever again after next Friday. Let's look at the facts and then build conclusions: Obviously Flow will not replace talk pages, obviously because talk pages have many purposes and Flow addresses only one of them (and badly). Just as obviously even the most basic functions of Flow can't work within talk pages but need their own structure, therefore Flow and any decedents will not be used at all in connection with talk pages. Accordingly "workflow", what ever that might become, will not be able to edit neither articles nor talk pages or it will need to be so far independent of Flow that it is useless to be called a continuation. Flow is just as dead as the parrot. --h-stt !? 16:51, 10 September 2015 (UTC)

Some feedback

I decided to try Flow today, and experimented with previewing for an hour or so. Since I found a lot of issues, I decided to write up a description of my experience. As background, I don't use any complex templates or much beyond what's required for regular talk page discussion, which is what I focused on here. I'm sure I'm identifying some things that have fixes already planned or which I just didn't figure out how to do, so please let me know when that's the case. This is just what I found from playing around with the syntax and interface while thinking of the ways I use talk pages. Unfortunately, most of the entries in the list would make me avoid Flow until they were addressed, but perhaps this can be useful to whoever watches this page.

Closing a page or using the Refresh button doesn't give you any warning before you lose your data.
Since preview takes me to the VE, it can mess up the formatting when I go back to make more changes (e.g. generation of nowiki tags if I accidentally forget to close a ref tag). These changes can't be undone by Ctrl+Z, so I have to manually remove the tags or discard my edit.
Preview stays in the edit box, so I can't view what any title formatting will look like, or how the text will look when spread across the full screen.
Except for previewing of very short comments, this is considerably slower than the current system. The speed varies (I'm not sure why), but even in wikitext mode, I sometimes have a noticeable delay for hitting the Enter key or Ctrl+Z, opening or closing collapse templates, etc.
Also in preview, inline references are always numbered 0, and images only display grey boxes. I assume you have to know about this already if it isn't specific to my setup, but it happens with all my extensions off as well, so perhaps it's related to my preferences.
I don't see any way to look at the preview and wikitext side by side.
AFAICT, I can't do anything that normally requires editing the full page. For example: several uses for collapse templates, reordering or deleting sections, as well as adding general notices to the top of the talk page like FAQs or DS warnings.
Copy/paste did some weird things, like reflists appearing in the middle of an article when I copy it over, or paste failing to overwrite selected text. These weren't reproducible in the time I had. (Also unreproducible: the edit window froze a few times, but I wasn't able to find any causes.)
I can't use the scroll bar to easily jump to the end of my comment, because other comments are at the bottom. I can use the internal scroll bar in wikitext mode, but not in preview mode. The same issue also means the scroll bar doesn't tell me where on the page I am, e.g. for estimating relative section sizes in preview.
The post revision page (e.g. [7]) doesn't tell me who made the comment. I can't move forward or back to other comments, and there's no option to revert if the comment is vandalism. The diff view (e.g. [8]) shows the user and has a revert option, but still doesn't allow navigation.
Other missing diff functionality: there's no "name (talk | contribs)" link (applies to the revision page too), I can't diff the first version of a post, there's no diff link from the history page, the diff doesn't show me the comments above or below, I don't see any way to compare the diff and preview on the same page, and I don't see any way to check the diff of a comment before saving.

A few more specific things of varying importance.

Opening "Browse topics" and immediately scrolling down fast makes the scroll bar "bounce" off the bottom. (Navigation is inconvenient as well, but it shouldn't be too bad as long as there's a way to e.g. set the TOC expanded by default.)
Copying an article, deleting it in the preview (using Ctrl+A) and then switching back leaves the wikitext for categories and DEFAULTSORT, but switching back and forth again removes those also.
The {{refn}} template doesn't get separate entries from the inline references. Also, no error is generated if you invoke a ref name that doesn't exist.
The collapse templates {{cot}} and {{cob}} don't work in the preview.
Switching to preview and back will change "[[foo]]s" into "[[Foo|foos]]." Not a big deal on its own, but my intuition is that previewing shouldn't actually change any of the code that I wrote.

Caveats: there are also a few general things about the interface, but I'm leaving those out for now; I didn't test any direct changes, so I wouldn't have found anything that happens during saving, moving pages, etc; and I did most of my testing at WikiProject Breakfast, which isn't a very complex page right now, so I can't say anything about how discussions would scale. Sunrise (talk) 01:51, 18 October 2015 (UTC)

I deleted the main testing page on enwiki 11 days ago and didn't get any reply or action (see the section above this one), so don't feel discouraged if your lengthy and detailed testing experiences don't get an answer either. The future of Flow is very uncertain at the moment (though it is shrouded in Newspeak in the communications from the WMF) and it seems that not much interaction with enwiki should be expected (they probably prefer to discuss things with the few wikis that seem to somewhat appreciate Flow so far, like the French, but it seems to have backfired a bit with the Swedes). In any case, if they ever want to restart development of Flow (or claim that it is ready to use), posts like yours here will be very useful. Fram (talk) 06:54, 19 October 2015 (UTC)

Thanks Fram - I was aware of some uncertainty, but I haven't been following these discussions too closely. It just happened that I felt like looking into this, and once I'd started I thought I might as well finish and then post my results. Sunrise (talk) 03:52, 21 October 2015 (UTC)

Can we please get rid of it (oh wait, I already did)

I know that Flow is rolled out on other wikis and used on some occasions. I guess they either have received a much better version, or are less critical. Major bugs noticed right at the start of the rollout here (more than a year and a half ago) are still present, and actually worse than ever. I'll not focus on how everyday users will experience it, that's a lnegthy post for another time (let me note though that performance is abysmal. But all the back-office actions related to a Wikipedia page suck massivley when you enter the wonderful world of Flow.

Database errors, see Topic:Sp8k7m07gvsarmq8 (useful, isn't it?)
History: when you go to Wikipedia talk:Flow/Developer test page, you see the 100 most recent changes. Now try "older 100" or "oldest". Hmm, exactly the same ones. Try "250": hey, you get more history! Try "older 250": nope, doesn't work. Try 500 ... wait ... wait ... wait ... nothing happens, just keeps on searching. Now, 100 edits goes back to 15 September 2015 (at the moment), and 250 goes back to 11 September 2015. But the actual history should go back to February 2014 and thousands of edits. Sorry, you no longer can check these, you have to do this topic by topic (and hope that no topic has gotten a lot of edits...).
So, let's try it in a different manner. Go to the contributions list of an editor with a lot of edits to Flow pages, and select specifically all his edits to the "Topic" namespace: [9] No results... Mind you, it worked for a short while in the summer of 2014 apparently, [10] Or then again, it doesn't: it lists an edit at 16:55 on 3 August, but the topic history doesn't list anything close to that date... [11] So, a totally useless option, but available to everyone since more than a year now. Please don't add clutter which is useless at best and wrong at worst
What happens if I want to delete Wikipedia talk:Flow/Developer test page? I get a standard warning: "This page has a history with 29 revisions: Page history" Wait, 29 revisions? That can't be right, surely? It doesn't even match the number of topics created so far, which is a lot higher. So what is being counted here? No idea.
So, can I actually delete it (contrary to what happened in the past?) Deleting it gives "action complete: "Wikipedia talk:Flow/Developer test page" has been deleted (view | salt). See the deletion log for a record of recent deletions. " And hurrah, it is actually deleted.
On restoration, I don't see any of the history of the page, so I don't know what I'm restoring. Restoration actually works though.

This means that, contrary to what is the case on all other pages, you can't

Can't check a deleted page without actually restoring it
Won't be able to do history merges / splits
Probably a few scenarios I don't even think about now

A second test, deleting the page and then recreating it, seems to haev effectively removed Flow from the page. Restoring the page does nothing for the history. The Flow contents seem to have totally gone...

So, I deleted it once again, and restored every revision except my last one. O-oh...

Error

An error has occurred.

Return to Main Page. [6e61b410] 2015-10-07 12:27:10: Fatal exception of type "Flow\Exception\FlowException"

Conclusion; this thing can't be maintained at any serious level, and should be removed from all live wikipedia environments until it is tested and workable. Feel free to restore the Wikipedia talk:Flow/Developer test page to the Flow version with all its history (though it isn't visible). But before you do, please check whether something like Topic:Soxgwu1j8bubl9w9 is visible to non-admins. If it is, then you have one further reason to not deploy this anywhere. If it isn't, then great, at least that part works. Fram (talk) 12:31, 7 October 2015 (UTC)

@Quiddity (WMF): Some other brilliant things. People at mediawiki and some other places can now make their user talk page a Flow page. Taking one example, [12] this user receives the Tech News through the Mediawiki message delivery. I repeat, someone gets on Mediawiki through Mediawiki Message Delivery their Tech News. One would suppose that that would give any technical problems and that they would notice i such a thing went somehow wrong, no? Still, week after week, the topic (section header on a normal talk page) looks like this: [[m:Special:MyLanguage/Tech/News/2015/41|Tech News: 2015-41]]

Then again, the currently second section on [13] has the nice title Special:TranslatorSignup & Flow

It looks as if there is still some work to do before this is ready to use...

By the way, perhaps one of the Flow developers (or if none are left, one of the people promoting the rollout of Flow in this state to other wikipedia-versions and user talk pages) can check the following: create a user talk page with some topics. Delete the page. Create the page again (not restoring, recreating from scratch, like a non-admin editor would do after an admin deleted the page), again as a Flow page. Do the old topics get reattached to the page or not? I would test it with the Developer test Page I deleted, but we aren't able yet to flow-enable pages (disabling is now possible by deleting the page and then rcereating it, apparently). If they do get reattached, you have another major reason not to roll out Flow any further anywhere. Fram (talk) 13:02, 7 October 2015 (UTC)

Wrong ping in previous post, @Quiddity (WMF): Fram (talk) 13:09, 7 October 2015 (UTC)

@Jdforrester (WMF):, why did you claim in your edit summary "Restoring; please do not test deletion on things the community has not said local users can undelete. Sorry for the delay!"? Which "community" would that be, and where has "the community" said this? Where, if not here, can we test the admin-functions on Flow pages? And when are these supposed to work? After all, this tool is live on many Wikis already, pushed as it is by the WMF, even though it is dreadfully incomplete (ever tried to check the history of a Flow page? Right...).

It looks as if you can't undelete it as well, which is not surprising but rather ironic. Please, in the future, communicate at the talk page when you want to tell us something, don't communicate through edit summaries. And inform us of what went wrong and what you plan on doing to correct this (suggestion: get rid of Flow completely). I thought the WMF would have learned at least that much after all these years and all these fiasco's. Testing is only a distant dream, but the basics of communication with "the community" should be acquired by now. Perhaps Lila has some more pruning of the organisation to do... Fram (talk) 20:55, 4 November 2015 (UTC)

@Fram: Hey there. I think it's stupid that per community request no-one can convert pages to Flow (even sysops like yourself) on this wiki, yes. However, that's where the current consensus is – I'd be delighted to re-configure it to give people the ability to enable and disable it, but as we announced a while ago our main focus is elsewhere, principally on cross-wiki notifications. Obviously we're going to get this fixed, but given that Flow is in maintenance mode at community request, it has to take its turn alongside other work. Once we get this fixed I'll ping you and explain what was broken and how we fixed it, if you're interested. Jdforrester (WMF) (talk) 21:18, 4 November 2015 (UTC)

The difference being of course that this page was Flow-enabled, but somehow lost it. And also, enabling/disabling Flow is not the same as "undeleting" things, which you bewilderingly claimed in your edit summary. Feel free not to fix it and just get rid of Flow everywhere, that will enable you (WMF) to focus your attention and workforce on more fruitful endeavours. Like implementing the few good things from VE into standard wikitext editing, which is still (and will remain for a long time) the number one editing environment, despite the total lack of attention to it from the WMF, preferring to spend most time and money on pet projects instead. If you want to fix one thing with Flow (and it is tough to say where to start, considering the massive amount of fundamental problems), start with the botched history page. That shouldn't be too difficult surely, but no progress has been made despite this being mentioned from the very start. Otherwise, you can also take the below section into account, so that the people who do test this get at least the impression that anyone at WMF still cares. Otherwise, please disable Flow on all pages on enwiki, also on those few projects that use it once every two months or so. Fram (talk) 07:59, 5 November 2015 (UTC)

If you wonder what I mean by "history", take a look at Phab 67088, opened after a report from me in May 2014, and closed in February 2015 as closed resolved. Yeah right... Oh, and suddenly in September 2015 we have Phab 112230 with the same problem, opened by the person who solved the previous one. It's like a déjà-VE all over again. Still, with 968 open Flow bugs, I guess you'll all be kept busy for the foreseeable future. Fram (talk) 11:14, 5 November 2015 (UTC)