Topic on Talk:Structured Discussions

It's obviously difficult to use and most wikis want nothing to do with it. Not every idea WMF has needs to be pursued indefinitely.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  04:58, 24 July 2016 (UTC)

Just to be clear, I'm not sure I have an absolute objection to Flow being installed, anywhere, as a new page type (conversation pages, or "troll pages" everyone calls them), with current talk pages being renamed collaboration pages. This theoretically could actually be a boon, by shunting trolls and yakkety-yak people onto the troll pages with less churn and clutter on the collaboration pages. I remain skeptical because: It's a maintenance problem, as these pages have to be patrolled for BLP and COPYVIO problems. Noobs who don't know the difference will use the wrong page type (e.g. post article improvement ideas to the troll page where no one is actually looking). The troll pages will in fact be used for forum purposes, which many wikis have policies against. Even experienced editors might not be sure which page to use, e.g. if their idea for an article improvement is not fully formed and may need extensive discussion to iron out. There's potential for editorial strife and drama of the "you should have posted this crap to the conversation page not the collaboration page!" chest-beating sort. And random lame comments are sometimes actually helpful as they trigger watchlisted items we haven't looked at in ages. Even trolling comments can tell us how to improve articles sometimes, such as by reworking whatever it is that triggered the trolling. That last is something that has been done at en:w:Race (biology) for example, in direct response to outright abuse of the talk page to advance ranty points of view that are not, in themselves, aimed at article improvement.

On something like the Star Wars wiki, conversation- versus collaboration-page splitting is probably a very good idea, because fans are going to fan-gush, and the talk pages at such wikis have a strong tendency to devolve into fiction-related chatter and debate that has nothing at all to do with improving the content.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  06:36, 27 August 2016 (UTC)

They just don't get it, as usual.

They even ban the VirtualEditor from the talk pages just to get this junk some more traction.

Grüße vom Sänger ♫^(Reden) 09:37, 24 July 2016 (UTC)

VisualEditor is available in Flow talk pages; it's the "[[ ]]" button in the bottom right corner of the editing window. (I prefer source view, myself, but Flow is too broken to have a preview mode from what I can tell, so the only way to get one is to use that feature to turn VE on and then off again.

VE itself is too broken to use it reliably. E.g., if you add a sig or something else that VE wants to escape for some reason, with <nowiki>...</nowiki>, it will apply the <nowiki>...</nowiki> to the entire line, which is liable to mess up something else (and so on; the complaints list about VE is a mile long).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  19:16, 24 July 2016 (UTC)

Can you give me some details concerning that <nowiki> problem, precisely? That way we can have the most accurate information to fix it.

I don't use it enough to debug that much. When I close with a four-tilde sig, switch to VE, and then back to source view, the whole line is nowiki'ed. ~~~~

If it has some "code" in it, e.g. a {{foo}} template link or a explicit HTML b tag, or '''apostrophe boldfacing''', the sig nowiki stuff goes backward from the sig until it hits the the code. ~~~~

Notably, it even no-wikied out the apostrophe boldfacing in that case, though it will not if you just do this:

Here's some apostrophe boldfacing followed by a sig. ~~~~

This would seem to indicate that as soon as any new markup is introduced that some list in VE is looking for, it will break. And that whatever parsing it is doing already has serious problems. The underlying design paradigm of "wrap everything you can get away with in nowiki if you encounter sig code anywhere" makes no sense at all to begin with.

PS: A serious flaw of Flow is you can't view source on what I'm writing, necessitating that I have to describe it and hope you know what I mean. This is why flow will never, ever be useful at a wiki, because we frequently have to discuss and illustrate code in a "view source on what I just wrote" manner.

Here I am signing with a sig again, going into VE to preview, then back into source mode and manually stripping out the nowiki this time.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  18:42, 27 July 2016 (UTC)

Hi. Just two quick notes:

1. It is possible to view source on what you wrote. We just need to click "Edit" in the dropdown menu (and possibly also use the [[ ]] button to flip into wikitext-mode). See screenshot. It could be better (in many ways), but it does work.
2. Signatures aren't of necessity in Flow, as our posts are automatically attributed (and edits by other people are denoted). The few benefits that custom signatures have, will eventually be addressed via other means, per Flow#What happens to my custom signature?.

Hope that helps.

Whether sigs are "necessary" is irrelevant. They're a typical style here that many prefer, and VE's extreme and broken lengths to browbeat people into not using them are causing other problems. FAIL.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:13, 28 July 2016 (UTC)

"When I close with a four-tilde sig, switch to VE, and then back to source view, the whole line is nowiki'ed."

I have that problem when I use VE on a page too. It is not specific to Flow. I'm not sure if that problem would be fixed: signatures are only for classical talk pages, not for Flow or VE (which is not designed for discussions).

My question was more about other stuff with parasite <nowiki> markups. :)

I've also found that it will nowiki more than one visble line; it seems to nowiki backward from the sig until it reaches either a paragraph break (blank line) or something it recognizes as "code" in its very limited ability to parse. It's basically "style nazi" code, doing stupid unnecessary things to try to force people into never using sigs in situations in which some developer wants to force people to never use sigs. This is not part of the design spec of VE or Flow, and should be removed immediately as rogue developer bullshit.

It's especially boneheaded, because there are numerous legit uses of sig code that don't have anything to do with signing posts. For example, the ~~~~~ (5 tildes) version is very convenient for generating exact inline timestamps, and sigs of all three (three-tilde to five-tilde) types are useful in various template examples, which (as I pointed out in detail above) are something we often use in talk pages.

The fatal flaw here is in the false supposition that WP and its sister projects need a "discussion forum" that it utterly divorced from wiki coding. This has never been true and will never be true, since much of the time what the talk pages exist for is working on wikicode. Any thing that gets in the way to doing that, even slightly, is never going to be accepted by the community. And VE, outside the context of Flow, never has any business interfering with editors' use of sig code to begin with. So, it doesn't matter where this misfeature is coming from – VE itself or Flow, or as Sänger suggests below, in parsoid – it has to go.

Good point concerning the 3 or 5 tildes signatures, that can be useful. It has been reported, and I've added your comments to that task.

Concerning talk pages, I don't whish to have an endless discussion with you. Flow is appreciated by some communities or, on other places, individuals, especially when they need to work with beginners. You should ask these people about why they appreciate Flow. :)

I'm not arguing for the elimination of Flow from the whole world (e.g., at Wikias or private MediaWiki installations that want it, or even WMF projects where working heavily with code on talk pages isn't common); I'm arguing for it not being used on Wikipedia, at least not in it's present form. Presenting a BBS-like interface for noobs has to take a back seat to getting the work done.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:56, 8 August 2016 (UTC)

Flow may not be appropriate on your Wikipedia, but some communities appreciate Flow as a good tool for user-to-user interaction. Why preventing other communities to use it then? I still don't understand that point of view.

(And I don't understand your metaphor with the back seat, sorry - maybe too much English-culture related for me?)

"To take a back seat" = "to play a secondary, subservient, or passive role". Those in the back seat of a car have little impact on its actual operation. Our arguments do not strongly relate to each other. Yours is that some people like Flow as user-to-user forum software. Mine is that it gets in the way of code-related work. These can both be true at the same time. Is it worth sacrificing some ability to work easily with wikicode on talk pages just to get alleged improvements in talk pages as forums? I clearly have an answer of "no" to that question, because Wikipedia is not a forum (see en:w:WP:NOT#FORUM for details, or Sänger's good explanation, below), our trend has been consistently toward making it easier not harder to work with code, and hardly anyone thinks Flow is great forum software anyway.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:11, 9 August 2016 (UTC)

Thank you for the explanation about the back-seat thing. Really appreciated! :)

Wikipedia (let's do that with Wikipedia) is not a forum and its talk pages are definitely not a forum, I agree. It is not on its DNA: the purpose of talk pages is to improve contents or discuss about Wikipedia itself. The link you are referring to is a rule about how to discuss. Flow works in accordance with that rule IMHO, because people are following that rule and prompt people to follow it (like on classical pages).

The only change is that we are structuring discussions (see below). It is possible to improve articles using Flow, or discuss with other users to improve the wiki's content. I don't have examples of wikis where Flow has converted a talk page to a forum on Wikipedia – if any, users don't do it because of Flow. Maybe the design looks too much like a forum chat and may let you imagine that it encourages people to use it as a forum? I'm not convinced by that, sorry! :) But I may not have seen examples. And you can't blame people who are sometimes have fun while they are discussing about adding quality contents.

Code is important, I fully agree with that. But there is also some things that we need to change to improve interactivity between users and have more people involved in writing quality contents. Flow helps to accomplish that task, by having a structured discussion system. Current discussions on classical wikitext pages are not structured discussions from a technical perspective, despite the fact there is a certain number of colons or bullet points added to each answer to provide a pseudo-structure (something that a majority of newcomers don't understand). With the current design of classical discussions, a piece of software can't know who has replied to whom – only humans can. We can't deliver notifications or improve how to move discussions without a structured system. But we have still discussed about that IIRC.

And you still can use code on Flow. Fully. You can write big parts of an article that you want to rewrite to submit it to others, or make some mockups in wikitext, and more. Actually, if there is limitations to the code part, they are minor. Again examples of things that blocks you to use Flow as code and which are not reported yet to be fixed are welcome.

And I still don't see why you want to prevent other communities to use it. :/

If that were "the only change", we wouldn't be having this conversation, and all the many discussions like this would not have happened. Flow has been tried by some wikiprojects, and the reaction was so negative that it was mostly abandoned, and spread no further. As for users turning a talk page into a forum, Sänger already provided an example below.

There's no convincing evidence that Flow does anything useful, much less fosters better communication and thus better content. That's a chain of alleged causality that is not demonstrated at even one step. "Traditional" talk page discussions appears to be structured well enough to serve their purpose. I agree the colon markup is not ideal (for multiple reasons, including that it's an abuse of definition list markup), but there are simpler ways to fix that than Flow. Just because WMF created ((em|an}} instance of threading software does not mean it is the one that should be deployed. We can deliver notifications; that's what the ping system is for. If you mean that people can't subscribe to threads, we have watchlisting, which at least subscribes people to the page in question while the discussion is running, after which they can un-watch it. Not perfect, but gets the job done. I'm unaware of any problems moving discussions.

I didn't say Flow made use of code in discussions impossible, just more difficult. It also costs us some other standard wiki page functionality.

I already said I don't want to prevent flow being used where people want it. People don't want it on WIkipedia or on many other code-intensive wikis. It is probably popular on Wikia, though, and various non-WMF wikis, and maybe some WMF projects like it, I don't know. What I don't want to see is it being imposed on editing communities that don't want or need it. I strongly suspect Meta is one of them, but I don't spend enough time on here to be sure.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:02, 10 August 2016 (UTC)

Trizek: I see where some of the confusion arose. When I said "What I don't want to see is it being imposed on editing communities that don't want or need it.", that was imprecise and misleading. What i meant was it should not be imposed on a community by technical "gatekeepers" at it, who often install new MediaWiki features and set defaults for what is on or off for new (or all) users without much input or discussion. I didn't mean "I fear that the WMF board is going to force this on everyone"; I don't see that they have any way to do that, other than theoretically by having the devs build it into MediaWiki in such a way that it cannot be disentangled, but I know they wouldn't try that.

Now that I think of it: As a package management issue, I don't think that Flow should be installed and turned on by default for WMF projects, even if available. I don't have an objection to it being on by default when it comes to Wikia, or the MW package that one can download and install on one's own server, though it should probably be an option that is obvious and can be turned off at install/setup time.

> Flow has been tried by some wikiprojects, and the reaction was so negative that it was mostly abandoned, and spread no further.

What data or tangible feedback do you have about that? The majority of communities which have discussed about having Flow are trying it. If you have data that I don't have, please share it. :)

Sänger didn't provided a tangible example I'm afraid. I'm not going to check manually all "wikivoyage or such"!

> There's no convincing evidence that Flow does anything useful

It has convinced more communities that LqT did before. +1,000 users on zh.wp are using it (graph has some wikis missing), 280 on fr.wp. I consider that as a proof of a relative success and trust. Note: I don't track non-WMF wikis.

> [wikitext talk pages] Not perfect, but gets the job done.

Sure they do. But that's "not perfect". As you note, they are not easy to use, pinging is not that easy to use, or watchlisting can be very tricky. :/ I base my feedback on all workshops for beginners I'm holding as a volunteer.

The idea is to improve that. Flow may not be the right way to do that in your opinion, but help a lot to solve these problems.

> I'm unaware of any problems moving discussions.

It is mostly a problem to have History not broken when splitting a discussion.

> I didn't say Flow made use of code in discussions impossible, just more difficult.

What would be cool to improve that?

> People don't want it on Wikipedia or on many other code-intensive wikis.

I don't have examples but I'll try to find some. :)

> What I don't want to see is it being imposed on editing communities that don't want or need it.

We are not going to do that at all. I swear. Please read the documentation: Flow is a Beta product, and communities can have it deployed only if they have a community decision to use it. During that discussion (or just after if we haven't noticed it), we clearly explain that Flow has limitations and we are not adding new features at the moment - repeating what is on the documentation. We can't say that we are forcing communities to use it and they are not aware of the current limitations.

Meta has had discussions started by community members about Flow (1, 2, 3) and say "no" (source).

Trizek (WMF)

'Sänger didn't provided a tangible example I'm afraid. I'm not going to check manually all "wikivoyage or such"!'

If WMF is relying on you, one person (just maybe looking around yourself, or expecting a random individual like Sänger to do a project-by-project study for you) to get an idea at the organizational and project-management level what the buy-in vs. rejection rate of Flow is, across WMF's own projects, it becomes suddenly clear why WMF has its head in the clouds (or the sand, whatever metaphor you like, and there's a third, less pleasant one) about Flow.

They need to devote an actual organizational effort, with multiple people (I would suggest a third-party user metrics specialist firm, like a major game company would use) to get an accurate picture of:

• How frequently Flow has been adopted
  • In WMF projects
  • In Wikia
  • In download-and-run-my-own wikis
• What the actual user reaction is to the installation and its functionality (and the changes to what had been the original functionality), on average.
• Lists of specific pro and con points and the frequency with which they are offered, and what sort of wiki they are offered on. This should help tell you all of the following:
  • Why it is sometimes adopted.
  • Why it is sometimes not.
  • Why it is sometimes kept post-install.
  • Why it is sometimes not.
  • What features people think talk pages (or something like talk pages) actually need on en.wiki, which is the flagship, and wikis like it.
  • What features people want on more social wikis that do not have anything like en:w:WP:NOT#FORUM.
• Where the common ground is and whether a single solution is even practical, rather than, e.g., both a "coders' talk page" solution and a "forum-like talk page" solution being needed, separately.
• Whether it is practical for WMF itself to be developing this/these, instead of the free/open software development community doing it.

I'm probably missing a few major questions that need answering, and each key point could be subdivided further; this is just off the top of my head.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  18:27, 26 August 2016 (UTC)

You keep referring to Wikia, and I can't imagine why. Wikia has nothing to do with the WMF. I believe that they aren't even running MediaWiki software any longer. I don't know if it's technically possible for them to run Flow at this time.

Oh, OK. Wasn't aware they'd dropped MediaWiki, if they have. The last time I edited on a Wikia wiki, a few months ago, they were definitely still using MW, though.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:18, 29 August 2016 (UTC)

Nah, I just checked Memory Alpha, and it's still MediaWIki. So, yes, Wikia is extremely relevant, as the largest deployed userbase of non-WMF wikis in the world.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:20, 29 August 2016 (UTC)

This is a case of "it's more complicated than that". Alpha Memory is running Wikia code release-435.005, plus several other things (MySQL, for example). They're still using wikitext, but that's not the same thing as using MediaWiki to run their systems. They started diverging from MediaWiki years ago.

So, the Flow extension is not compatible with that system? What about all the downloaded and installed MWs?

I provided that link, and it was not Wikivoyage, it was Wikinews.

There was a lot of talk about Flow on Meta in the wake of the MV/Superprotect disaster, mainly on Lilas talk page, now spread in various archives of it. Consensus within those community members, who took part over there was: DOA.

• Has to at least as flexible as current talk pages are
• Has to have at all features current talk pages have
• Should not have a separate touch-and-feel from the rest of the pages
• Has to be revertible without problems, if it wasn't declared fine after a test

Those were iirc the minimum requirements for any test in a live environment on a productive encyclopaedic Wiki. It could be fine for some more bloggish Wikia-projects, but those are no projects where any WMF money should be spent on.

Some discussion links: m:User_talk:LilaTretikov_(WMF)/Archive_5#Why_is_Flow_DOI.3F m:User_talk:LilaTretikov_(WMF)/Archive_11#Flow_update_--_action_requested m:User_talk:LilaTretikov_(WMF)/Archive_6#Where_are_we ..... Grüße vom Sänger ♫^(Reden) 18:46, 26 August 2016 (UTC)

Guys, I'm not going to re-write again everything we have already discussed about all these topics.

Flow is still in Beta, and you are still comparing it to active systems used since years. It is like asking a young kid to do an adult work or lift heavy charges.

Some WMF communities have adopted Flow (even "on a productive encyclopaedic Wikis"), in various ways, and are asking WMF for support. Are we supposed to drop them because you don't like Flow? No. We want to ask them what would be the next steps for a strategy concerning talk pages.

Flow is still in Beta

We know that. The disagreement is on your assumption that Flow can be upgraded into a viable replacement for Talk pages. The linked discussions are filled with people basically saying that isn't possible.

Some WMF communities have adopted Flow... and are asking WMF for support. Are we supposed to drop them because you don't like Flow?

Don't make this personal. Sänger merely reported what many community members said. The issue is whether the general community is going to accept Flow. If the general community rejects Flow then either the WMF is going to have to terminate support, or it's going to have to take on permanent support for a complex extension that only gets fringe usage.

We want to ask them what would be the next steps for a strategy concerning talk pages.

Wow. That is seriously wrong and offensive.

This "seek feedback only from those who already agree with us" thing is (full circle) what I've been talking about all along, and what Sánger referred to as the echo-chamber effect. So, the feedback WMF (represented by Trizek in this care) is receiving, in a forum it hasn't pre-filtered for "yes-men", is consistent that filtering for yes-men is a bad idea, and that Flow is not being widely adopted and not worth further investment. What else does it take to get the point across, I wonder? An article in the London Times?  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  18:40, 30 August 2016 (UTC)

I decline to continue point-by-point, two-party debate about this for another month. The key point here is, as you said, 'Meta has had discussions started by community members about Flow and say "no".' There are reasons Flow is being rejected. It won't magically stop being rejected until these issues (many more than have been outlined here) with Flow are resolved, and some of them may not be resolvable. I repeat that the desire to have a more user-friendly talk page experience does not necessitate accepting WMF's first-draft attempt at creating one. I don't feel it's necessary to re-re-re-discuss this point endlessly.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:29, 17 August 2016 (UTC)

If you want to focus only on communities that refuses Flow, you can. I still don't understand why - we tried to discuss about that, without any successful result alas!

I take care of all communities and opinions. Communities with positive thoughts about Flow don't have that much my attention. I take care more of communities which have identified problems and want WMF to solve these problems. That can be about Flow or about discussions in general. There is still no decision taken about keeping Flow how it is. Don't forget that.

I agree that's the constructive approach to take. I think what Sánger says below elucidates why the discussions and surveys and such have no produced successful results – people who don't find Flow useful and/or see it as a dying project simply move on and forget about it; from their perspective further time spent on it is wasted. Mostly it's just going to be big fans of Flow who are going to respond in-depth about issues with it. There's a "critical mass" point beyond which a project has to be scrapped and restarted, even if what comes after it shares a lot of the same code. See, e.g. Windows Vista and Windows 8, and then Windows 9 which didn't even happen; Vista passed a point-of-no-return and had to be dropped. Windows 7 was a success, despite having mostly the same codebase. Windows 10 is also doing well. There are many lessons like this in the software world and outside it. See, e.g., New Coke.

We will see what is the real opinion of the community soon, knowing that people who are not happy tend to be more vocals that the happy ones. :)

We will see what is the real opinion of the community soon

It sounds like you're talking about the planned Flow survey. Any positive results of that survey would be self-deception or fraud when the plan is to selectively invite feedback from your biggest fans and to exclude feedback from anyone who finds Flow unusable.

Rather than adding to the megabytes that have already been written on what's wrong with Flow, I will offer this summary of some of the discussions I already participated in:

It is not clear if Flow could ever be/become a replacement for Talk in its current concept. 
-- Lila Tretikov, former Executive Director of the WMF

The WMF and Community need to agree on a long term plan here. Right now we do not have that. EnWiki has already drafted an RFC to completely uninstall the Flow extension. As soon as the survey is released Flow will become an active topic again. As soon as Flow becomes an active topic someone WILL post that RFC to formally determine the community's position on the issue. I expect that RFC to get consensus.

EnWiki is essentially half of the global wiki universe. If EnWiki rejects Flow as unusable then it's pretty well certain that other major wikis will reject it as well. If Flow is NEVER going to get broad deployment then it's just another dead-end LiquidThreads2.0.

Either we need general agreement that Flow is going to become the replacement for talk pages and we need to move forwards on this together, or the WMF needs to stop pushing a dead-end project.

Alsee wrote, "If EnWiki rejects Flow as unusable then it's pretty well certain that other major wikis will reject it as well."

This is not true. The larger wikis make up their own minds. For example, enwiki rejected FlaggedRevisions, which has been used on all mainspace pages at other wikis for years. Enwiki initially rejected VisualEditor, but it's accepted at frwiki, itwiki, ruwiki, plwiki, ptwiki. Dewiki approached the WMF last year and asked to have it enabled for new accounts and IPs.

Also, not all projects are suitable for larger wikis. For example, some of the tiny Wikipedias are asking for RelatedChanges, which enwiki doesn't want (on desktop). That doesn't mean that one is right and the other is wrong; it means that enwiki has thousands of navboxes and well-developed articles, so a pre-loaded ==See also== section isn't valuable at enwiki, even though it sounds good to communities that are just getting started.

As responded in the Phabricator task you are pointing out, we will post invitations on VPs for wikis which are using Flow actively. We will both target people who are actively using Flow and other ones who are not using it (anymore or at all, or time to time) but want to raise issues and/or suggest ideas. This is a more formal, more open and more inclusive process than discussions on Lila's talk page.

We are not doing that survey because we want to impose Flow (because we don't want to impose it); we are doing it because we have feedback and requests for improvements from communities who enjoy Flow for user-to-user interactions.

It is not clear if Flow could become a replacement for Talk in its current concept, correct. I agree. That's why we are asking people who have tested Flow if that's it can be. If that's the case, we are asking which improvement would be helpful to improve that tool. That survey will make possible the definition of a strategy and a long tern plan. That plan may be to review entirely the concept or to move forward with the current base. I can't predict the future. :)

If en.wp's plan is to reject Flow in its current state (remember that it is a Beta product with known issues that can be solved), that's community's choice. I will feel sorry (and a little bit disappointed by) that decision but I don't think it will not block a possible evolution of talk pages (with Flow or something else) if there is other communities showing support. Do you have a link to that future RFC please?

Here's the Draft Flow RfC. We welcome any comments, corrections, or suggestions for improvement.

Thank you!

It looks like the RFC contains some false information. For example, I assume that the reference to some wikis having a three-way page system is about Wikinews. However, the English Wikinews has a mainspace–talk–LiquidThreads combination, and others seem to have mainspace–talk–talk combinations. I've never heard of a WMF wiki with a three-way system involving Flow.

I removed that. What other falsities do you think it contains? If something is blatantly false, feel free to remove it. You wouldn't be the first staffer to edit it.

What's the big difference between LQ and Flow for a user? Both are just forum impersonations, not real talk pages, designed for blahblah, not collaboration.

That's your opinion, Sänger.

Somewhere in this sprawling page someone referred to a three-way installation, where the Flow page was used as the "trollspace".  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:22, 29 August 2016 (UTC)

The message you're remembering is at Topic:T8bd1k6uy3n0saky#flow-post-t9bizs9xo3nushe4 and it explicitly says that this three-way system uses LiquidThreads rather than Flow.

Flow or LQT are in principle just the same: Talkpages downgraded to weak forum impersonations, so it fits well.

Ah, okay. I'm just mis-remembering. But open source is open source. It seems highly unlikely to me that Flow can't be adapted the same way.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:03, 31 August 2016 (UTC)

It's good to see that the process is meant to be inclusive, but it still seems to be a "how can we continue to proceed with what we've already planned to do?" move, rather than taking the approach of: "Is this useful at all, to whom, in what ways? In what ways is it un-useful (or even an actual hindrance) to others? Do people actually have any issues with the talk page system we have, what are they, and who are these people as a user class/group on average? If there's a good chance it's going to continue to not be adopted, what aspects of it are salvageable?"

At some point, when something has been in beta for years without the issues with it being resolved, and without a desire by a sufficient number of people to see it completed and released, it just has to be declared a failed project. This isn't a WMF thing or a Wiki editorial community thing at all, it's basic software development, basic project management, and basic business sense.

What we have planned to do is to define a strategy and know what are communities needs. Also, we will use that survey to ask some questions from your second batch to users, and I'm sure you will remind me (if I forget) the other half when we will define the next strategy for talk pages (if any). :)

Heh. I wouldn't depend on that, since this is not a discussion I get involved in frequently. I think this is the first time I've touched it in over a year, and was inspired to do so by a bug (the nowiki issue I reported when you use a sig), not because of a desire to campaign against Flow broadly. I'm a bit disturbed by the "were just going to proceed with Flow anyway because a minority of user want it and that's just enough of an excuse" approach, but have faith that the wikis I use regularly will not want either a) Flow to replace talk pages or b) VisualEditor to be the default for existing editors. I actually don't have any objection to VE being on for anon users by default and on by default for new registered users, as long as both can switch on-the-fly, and the latter can turn it off entirely in Preferences. I actually !voted to support both proposals at Village Pump on en.wikipedia.

That "people who are not happy tend to be more vocal" maxim principally applies to mass media situations (e.g., more people will write angry than praising letters to a company about a product they have made, more people with a bone to pick about a particular socio-political issue will write a letter-to-the-editor for their city newspaper than people who just want to say how rosy everything is). In a no-effort medium like this, where the "product" and the means to communicate views about it are the same thing and we're already using it every day, the opposite will often be true. This is among the points Sánger is making about an "echo chamber" effect (and see also later interpolation by Alsee, above).

Flow's fans will readily participate in later-round feedback surveys, bug reporting, testing, etc., regarding Flow, while those with no use for Flow simply ignore it all as noise at this point, because they've already made it clear what the problems are and most of them have not been resolved (and many cannot be). This same effect is readily observed when it comes to on-wiki proposals that are faulty. Discussion is hot at first, then when it becomes clear there is no consensus for the proposal, everyone stops talking about it except people who will not hear the bad news and who want to continue promoting the idea. That's actually a very good description of the collective reaction to Flow across the wikiverse.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:53, 21 August 2016 (UTC)

There was a very much welcomed decision taken by Lila to ditch this weak forum impersonation, but some devs kept their pet project alive against community wishes. Why should anyone take this non-starter serious any longer? I don't know, why you still stick to it, and not put more efforts towards wanted projects and real community wishes.

The general problem is the misunderstanding, that talk pages are a kind of forum; they are not. They are pages in the wikiverse for the collaborative improvement of content pages, the primary goal is to make the other side of the talk page better.

Somewhere in the first discussions about Flow someone mentioned iirc wikivoyage or such, where there are three joined pages: the article page, a collaborative improvement page in the normal talk format, and a LQT-page , thus in principle the same as Flow, usually called the trollspace, as no useful collaboration was possible, and it was better left ignored by the serious authors. Grüße vom Sänger ♫^(Reden) 10:36, 9 August 2016 (UTC)

Thanks for that actual example, and I agree strongly with your summary of what talk pages are for and why they aren't forums.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:11, 9 August 2016 (UTC)

Please see my long answer above: Flow can be used to improve contents and can deal with code. It just has a different design and provides a technical structure to discussions. It is not designed to be a forum tool at all.

I would be interested to see that LQT example. But you can't jump to the conclusion that Flow (or LQT) are responsible of an human problem. It is like blaming a car to be responsible of an accident while its driver was drunk.

I remembered it wrong, it was WikiNews. It was mentioned on Lilas talk page here by user:Pi zero as an example.

Thank you for that link.

That Wikinews case is one particular case I guess, where people have decided to have two discussion systems. That's their choice and it still does not prove at all that Flow is only designed for chatting. At the opposite, some small Wikipedias, like Konkani Wikipedia, have chosen to have Flow on all talk pages, because that's easier for newbies.

Is it really necessary to perpetuate this argument? Please just accept that some editors do not care for Flow, as a talk page editing environment, or as a system being imposed, at various wikis, over such objections, and have outlined their issues with it, here and in many other venues (in this particular one, we've only touched on a handful of these problems, and there are many others). It is not necessary for you to brow-beat against all criticism of Flow as if someone were saying bad things about your child or spouse. Please give it a rest. If we were at en.Wikipedia, I would refer you to en:w:WP:BLUDGEON.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:30, 17 August 2016 (UTC)

Perpetuate the argument also applies to you, I'm afraid: I care about people who don't care about Flow and we don't impose Flow if there is no community consensus or decision. There is communities where people have tried Flow and ended the trial. I4ve tried to explained it and I still don't understand why still discuss about that.

If I've been rude or intimidating in my messages, that may be due to the fact that I'm not a native English speaker. I'm sorry if I've been offensive. My point was just to give you the best answer to your remarks.

"Perpetuate the argument also applies to you" True enough. And, no, I don't think you've been rude or intimidating, just overly defensive. It really is okay that some people quite vocally don't like Flow. That's just how it is; arguing with all of them won't change their minds. A hard lesson I learned in my years as the online activist and later communications director at the Electronic Frontier Foundation is that you can't argue with all the critics, or too long with any one of them, or it looks desperate and recalcitrant. From a PR perspective, it's closely related to the concept of "don't feed the trolls".

PS: There's clearly been some miscommunication here. You keep returning to the theme (above, and below) of "we are not forcing communities to use Flow". No one here is saying that. When we speak of Flow being pushed on us, it's a general pattern of "marketing" Flow at us, then people at first one project then another installing it (site-wide or in particular places) despite lack of support for it, and other cases of a community being willing to try it provisionally, not liking it when they do, but still being stuck with it. Consensus-based decision-making breaks down when insiders in a project are using their influence and WMF connections to do things "WMF's way". It "politics as usual" getting in the way of the "wiki way".

thank you for your explanations. I would have prefer to discuss about all of this offline, face to face in a nice place. ;)

Sure. If you're working out of the San Francisco HQ, I actually work in SF much of the time. Can do lunch or something. I agree this is not the best medium for such discussions!

Sorry, but after the MV-desaster there is not much AGF left for the WMF in regard of forcing some unwanted stuff down the throats. Flow was declared dead by the former ED, who got much applause outside the echo chamber in SF for this decision, but some seem to stick to this piece of software nevertheless. As long as there is money wasted on Flow within the WMF, and people are somehow emotionally connected to this weak forum impersonation, it just looks like the good decision by Lila is contradicted by some devs, who still want their pet project spread, regardless what.

The problem with such echo chambers about dead projects like Flow is, that besides the fanboys and -girls nobody will give any meaningful feedback, as most have just given up on the DOA-project. And some devs seem to interpret this as not much opposition at all, which is utterly wrong. The so-called satisfaction survey just for the fanboys will be the next echo chamber experiment, done to keep this dead project alive for a bit longer with this biased "survey", based on wrong premises and a POV-questionnaire.

There was enough feedback already to ditch this experiment and not waste any more money and workforce for it, but have this diverted to community wishes instead, towards real maintenance and so on, but unwanted pet projects are still alive and kicking.

Grüße vom Sänger ♫^(Reden) 15:41, 20 August 2016 (UTC)

That's your opinion. I don't agree with you because you still spread wrong information (mark my word: we are not forcing communities to use Flow) but I still respect your opinion. I wish you will respect the opinion of people or communities who appreciate Flow.

That is my final answer to you.

It seems to be a Problem with parsoid, it was a Problem with far more wikisyntax before on Flow, now just the use of customised sigs ain't working with preview. Grüße vom Sänger ♫^(Reden) 08:24, 28 July 2016 (UTC)

~~~~ This was just short in preview, no tags anywhere besides my 4 tildes.

That was Windumb with IE, now mint with FF ~~~~

Let's see all those things the preview will do.

Wrong click first, was save instead of preview ;)

OK, some things work, like bold, and probably italics.

Signature doesn't work after preview, i.e. with the VE in-between.

Let's try some other stuff: durchgestrichen, 1+1=3 and bold the other way.

Works as well.

I mean VE on normal talk pages, instead of Flow. The <nowiki>...</nowiki> stuff happens here as well, it's part of the underlying Parsoid-engine methinks.

But Flow breaks with the rest of the wikiverse completely, it changes talk pages into dumb forum stuff.

Ah, I see what you mean. I avoid VE so much, I'm probably not aware of where/if it can be used non-problematically, after however many bug-fixing rounds it has been through by now. I understand the desire for VE to exist – both user demand for "less geeky" tools and WMF demand to supply that demand – but for technical users, VE is mostly just a hindrance. A live-preview system as used by a lot of higher-end forum software would probably be a better approach. I'm on a lot of tech boards, and fairly often encounter this feature; e.g. you can be adding complicated code, and see that it shows up as code in the preview the instant you wrap <code>...</code> around it (or the BBcode or Markdown equivalent, if it's not using a subset of HTML for input). I haven't taken notes on which ones are doing what, so I couldn't offer a personal favorite at this point. I also wonder what plugins have been developed for MediaWiki by now; I know there are people building stuff that WP itself doesn't use yet (if ever).

I probably won't use VE as well, the normal editor is more convenient for me. Just for tables it seems, the VE is more comfortable, more intuitive, as the old fashioned stuff with lots of | and - and brackets.

But for n00bs it could be fine, as the VE seems to behave as a real editor, and doesn't break stuff any more.

This very page illustrates a problem with flow. The "force-threaded" nature of it increasingly buries the meat of the real conversation deep in the middle of the page (sometimes deep in several places in the middle of the page). There's a lot of value to out-denting, and we do this frequently on talk pages, often with identifying subheadings or as new top-level headings, for real reasons. I also see that the threading isn't even accurate. E.g., I replied directly to BethNaught's "I removed that." comment, but my reply does not appear to be a reply to that, but part of a "flat" and no longer threaded/nested conversation between her, Sänger, and Trizek, which started as an earlier reply to Beth's same post. The more I look at Flow, the more malfunctional or at least misfeatured it appears to be.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:39, 29 August 2016 (UTC)

So add a section heading:

Abitrary break

 Or highlight it. Or stick in images and tables and whatever you want. It's not that hard to get a visual indicator, if that's what you want to do.

Hmm. That heading still shows up as part of your own post, not as part of the page structure.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:00, 31 August 2016 (UTC)

You can switch to wikicode to do that, or use shortcuts on VE mode. And don't forget it is a software on Beta mode: improvements can be done.

This page gives me a "view history" option, with no ability to edit the overall page structure.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:05, 31 August 2016 (UTC)

My answer was just about posts. Page structure can't be edited (yet).

Yet that functionality is completely crucial to what we actually use "talk pages" (collaboration workspaces for). It seems unlikely that Flow will ever be editable that way (except perhaps by admins, with special skills and tools) because of how Flow works. Even if this could be resolved, Flow is not ready for use on any normal wiki as a talk-page replacement, even if it might be usable as an add-on feature beside talk pages, the way LiquidThreads was sometimes deployed. (Though without much actual use being found for them.)  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:03, 1 September 2016 (UTC)

The point wasn't "there is no possible way to work around any of Flow's inadequacies if you try hard", it's that generally people aren't going to try hard, with a net loss in utility of the average discussion page.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:02, 31 August 2016 (UTC)

That was an unhelpful pair of replies. The comment said that this page illustrates just how broken Flow's "force-threaded" nature is. Sticking a section headings inside a Flow comment is useless, and adding highlighting or images or tables inside a Flow comment clearly does nothing to improve this mess.

We ran an RFC inside of Flow, a small small one with few participants. People on both sides, including Flow fans, complained that it was unreadable. The RFC wound up being 6-to-3, but I couldn't even tell which way it went. I had to create a text file and copy text fragments out of Flow to figure out what the discussion actually said. That is how badly the imposed structured-discussions system fails.

This is exactly why the WMF should never build a major project with zero community input. The WMF built a youtube-style chatboard with zero work-functionality. Then the WMF made the catastrophic design error of grafting fake wikitext support onto it. You have a product that is impossible to upgrade to match the workplace power and flexibility of a Talk page. The WMF violated the Agile process. Agil is supposed to start with a Minimum Viable Product. The WMF thought the product was a chatboard. The Minimum Viable Product is a workplace. And that workplace has to start with genuine wikitext. I am sick of Flow constantly mangling my wikitext and exploding in endless new and absurd ways.

We do a wide range of complex business. Not all of it fits the "discussion" model, and when it is a discussion it often involves dozens of people. (Occasionally hundreds of people). Complicated discussions are inherently complicated. We use human intelligence to structure or restructure them at will. Flow turns into a mess when more than about three people have any non-trivial discussion.

Flow is unusable, and it's unfixable without restarting from the ground up. I find it hard to even speculate what the community would want in a ground-up design, but it wouldn't resemble Flow.

But all of this is a pointless repeat of things that have been said too many times before.

You need to ask the general community whether they would even want an upgraded Flow.

I've been involved as a volunteer during Flow development and provide critical feedback. I was not staff at that moment and didn't intent to. Affirm that WMF created Flow without community input is, well... a little bit hurtful to read. :)

> But all of this is a pointless repeat of things that have been said too many times before.

Yep.

As usual, trying to use Flow to write this post was an infuriating experience. Aside form the general failings and bugs, I am seriously sick of Flow constantly mangling my work. Any software that does that needs to get a magnet to the harddrive.

>Affirm that WMF created Flow without community input is, well... a little bit hurtful to read. :)

If the WMF posted on community wikis inviting feedback before they started coding, I must have missed it. Can you point me to any such invitation? I would be eager to follow the invitation-link there to see what input the general community gave.

>> But all of this is a pointless repeat of things that have been said too many times before.
>Yep.

Ok. So Flow is unusable and unfixable, you already knew it, and you've got no response. We agree that repeating everything that has already been said on both sides is getting us nowhere. Could you respond to the key point on the next line:

>You need to ask the general community whether they would even want an upgraded Flow

In my case, I was at Wikimania, discovered that project and volunteered. I don't know if they were an invitation sent to all wikis at that moment.

I'm not going to repeat all arguments we have already written. That's was my answer to the "pointless repeating". It is not a recognition of the so-called fact that you think Flow is "unusable", because people use it and like it, and "unfixable", because I trust people with a technical background when they say it is possible. I have responses, they just don't fit to your idea of Flow's future.

We are going to ask communities which have a chance to try Flow for good (not just on a sandbox page), no matter if they have liked it or not. The key point is to have people who are able to compare both systems.

Hurtful to read, compared to ... repeated statements that the plan moving forward with Flow (and it is a plan to do so, not to see if the community wants moving-forward-with-Flow to happen) is to solicit feedback from the small segment of the community that uses Flow instead of from the broader community?  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:07, 1 September 2016 (UTC)

Yes, because that's personal.

The key points WMF needs to hear

As Alsee put it: "The Minimum Viable Product is a workplace" (i.e., not a chat forum), and "ask the general community whether they would even want an upgraded Flow" (i.e., don't ask just those who are already trying out Flow). These – along with "Flow is not useful for us because [long list of reasons]" – really are the key points of this entire discussion, not just on this page, but about Flow generally, across the whole Mediawikiverse.

"It's still in beta" is not an answer when a) the consistent response is that this needs to go back to pre-alpha for a reconceptualization, with a minimum viable product, a need-to-solution relationship, that makes better sense, and b) having a project in perpetual beta is no way to develop anything. Beta is a transitional phase, not a genre. While probably most WP people don't care if WMF [but why WMF, instead of the open-source MW dev community?] develops a web-board system for social wikis that want one, it's not just tiresome but downright alarming that various people at WMF are convinced that Flow is going to be a talk page replacement, and still do after their own recent executive director said otherwise. Even my own assume-the-best supposition that Flow was meant to exist alongside "traditional" talk (i.e., working and collaboration) pages turned out to only be true of the old LiquidThreads system. So I'm more alarmed now than when I started, despite all the handwaving on this page by WMF reps.

They keep insisting the organization is seeking input from the community at large, not just fans of Flow (though the forthcoming polls they describe appear to be the opposite). Well, you're getting open feedback now. This is not an opportunity for proselytizing the WMF "vision", or for pressing the same defensive denials until critics give up and go away; it's an opportunity for graciously accepting feedback at face value and in the good faith in which it is offered, even if it's inconvenient or not what you want to hear. It doesn't matter if the criticisms don't seem 100% correct to you. They are real, and if they don't match WMF's expectations, intents, or understandings, all that tells you is that you have another problem internally, of poorly getting across what WMF is doing and why. Your constituency/community/userbase does not have collective brain damage; WMF's communication is simply poor. But we knew that already, since that's the #1 community complaint about the foundation.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:54, 1 September 2016 (UTC)