Talk:Flow

Jump to: navigation, search

About this board

The Collaboration team has enabled Flow on this talk page (documentation).

Previous feedback is on Talk:Flow Portal/Archive2 (using old Liquid Threads), and on our labs server.

You can leave your message in any language, but answers will be made in English (or your language if we speak it).

By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL

Where are my posts [https://tools.wmflabs.org/guc/?user=S%C3%A4nger here]?

2
Sänger (talkcontribs)

If I take a look at my global contributions, I can't see any of my Flow posts, why is this so? Grüße vom Sänger ♫(Reden) 09:55, 27 August 2016 (UTC)

P.S.: They are here.
P.P.S.: Why is the link broken in the headline?

He7d3r (talkcontribs)

Re: P.P.S.: See phab:T59153. It is the same reason why links do not work in edit summaries.

Reply to "Where are my posts [https://tools.wmflabs.org/guc/?user=S%C3%A4nger here]?"

How long is this Flow testing going to continue?

49
SMcCandlish (talkcontribs)

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)

SMcCandlish (talkcontribs)

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)

Sänger (talkcontribs)

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)

SMcCandlish (talkcontribs)

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)

Trizek (WMF) (talkcontribs)

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

SMcCandlish (talkcontribs)

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)

Quiddity (WMF) (talkcontribs)

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.

SMcCandlish (talkcontribs)

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)

Trizek (WMF) (talkcontribs)

"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. :)

SMcCandlish (talkcontribs)

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.

Trizek (WMF) (talkcontribs)

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. :)

SMcCandlish (talkcontribs)

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)

Trizek (WMF) (talkcontribs)

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?)

SMcCandlish (talkcontribs)

"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)

Trizek (WMF) (talkcontribs)

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. :/

SMcCandlish (talkcontribs)

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)

SMcCandlish (talkcontribs)

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.

Trizek (WMF) (talkcontribs)

> 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).

SMcCandlish (talkcontribs)

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)

Sänger (talkcontribs)

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)

SMcCandlish (talkcontribs)

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)

Trizek (WMF) (talkcontribs)

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.

SMcCandlish (talkcontribs)

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.

Trizek (WMF) (talkcontribs)

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. :)

Alsee (talkcontribs)

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.

Trizek (WMF) (talkcontribs)

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?

Alsee (talkcontribs)

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

SMcCandlish (talkcontribs)

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.

SMcCandlish (talkcontribs)

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)

Sänger (talkcontribs)

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.

Sänger (talkcontribs)

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)

SMcCandlish (talkcontribs)

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)

Trizek (WMF) (talkcontribs)

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.

Sänger (talkcontribs)

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

Trizek (WMF) (talkcontribs)

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.

SMcCandlish (talkcontribs)

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)

Trizek (WMF) (talkcontribs)

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.

SMcCandlish (talkcontribs)

"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".

Trizek (WMF) (talkcontribs)

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

SMcCandlish (talkcontribs)

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!

Sänger (talkcontribs)

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)

Trizek (WMF) (talkcontribs)

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.

Sänger (talkcontribs)

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)

Sänger (talkcontribs)

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

Sänger (talkcontribs)

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 ;)

Sänger (talkcontribs)

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.
Sänger (talkcontribs)

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.

SMcCandlish (talkcontribs)

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).

Sänger (talkcontribs)

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.

Reply to "How long is this Flow testing going to continue?"
Сунприат (talkcontribs)

Recently stopped working flow and flow page history. I found the problem: In the Firefox extension Adblock plus with filter EasyPrivacy ( https://easylist-downloads.adblockplus.org/easyprivacy.txt ). many people use Adblock. Could you check what there interfere with flow

Quiddity (WMF) (talkcontribs)

I've tried enabling the extension, and the additional filter, but Flow and Flow history pages still work for me. http://i.imgur.com/d7p0M4u.png Do I need to change any other settings, to reproduce this problem?

Also, please could you check your webconsole (ctrl-shift-k), and see if there are any errors from gadgets or userscripts after a page reload on a Flow page? Gadget/userscripts that give "TypeError" messages, having been creating some problems, tracked at phab:T111624. Thanks. :-)

Сунприат (talkcontribs)

Yes, the filter must be turned on before first loading Flow. If Flow loaded before turning on the filter, then after turning it continues to work. Try: Preferences - Advanced - Network / cached Web content - Clear Privat - delete cookies- delete all

Trizek (WMF) (talkcontribs)

I've also tried (actually, I use EasyPrivacy on Adblock since a long time on Firefox), and I have no errors.

Сунприат (talkcontribs)

This is because the banner! So if you do not close the banner.

https://www.mediawiki.org/beacon/impression?anonymous=true&project=wikimedia&db=mediawikiwiki&uselang=en&device=desktop&country=RU&debug=false&randomcampaign=0.7845689079641667&randombanner=0.9887423652085535&recordImpressionSampleRate=1&status=banner_shown&statusCode=6&campaign=wlm+2015&campaignCategory=wlm2015&bucket=1&bannersNotGuaranteedToDisplay=true&banner=wlm_2015&bannerCategory=wlm2015&alterFunctionMissing=true&result=show

/impression?

http://img9.tempfile.ru/14272/154216a286/617348e3bf4535cd11c26cd1.png http://img8.tempfile.ru/14272/15c47aacc8/9f8996769b0418ef440b23b3.png http://img6.tempfile.ru/14272/159702efe3/e5859117e958c4e43c49a15f.png http://img7.tempfile.ru/14272/1529f923aa/369fd0ea01a975fb43a81a74.png

Over the Flow board some gray screen. You can not click on it and a "waiting" cursor over it.

Trizek (WMF) (talkcontribs)

Thank you for the precision.

I've tried it on my side (remove cookies to display the banner) and nothing happens (Xubuntu 14.04). I've reported it.

This comment was hidden by Martinligabue (history)
Reply to "EasyPrivacy"

Suppressing a single revision of a post

2
Erasmo Barresi (talkcontribs)

In the context of a discussion on the English Wikisource, @BethNaught suggestedthat, in Flow, "posts can be suppressed, but with regard to their history, it's all or nothing - if any revision of a post needs to be suppressed, its whole history must be. Worst case scenario: a malefactor forces the blanking of discussions by inserting suppressible material into each post therein – such material cannot be just reverted and suppressed like in wikitext." Is there any plan to fix this? Personally, I'd like to see Flow used on a much larger scale, but I think this issue is a blocker for many communities.

Trizek (WMF) (talkcontribs)

It is possible to hide/suppress/oversight a specific post, but not possible (yet) to hide/suppress/oversight a specific diff for that post.

At the moment, there is no improvements scheduled. But we are going to ask communities using Flow about which improvements should be made. Have a better way to deal with History has been suggested multiple times and will be included into that community consultation.

I'm going to read that discussion, thank you for pointing it out! :)

Reply to "Suppressing a single revision of a post"
Valvular (talkcontribs)

I want to know if my is alright i try to message to people but they don't respond. ~~~~

FriedhelmW (talkcontribs)

Try sending a Wikimail to yourself. If that doesn't work, change your email provider.

Valvular (talkcontribs)

Ok try it thanks for ur advice.~~~~

Examples of large page of FLOW discussions, archives and searching of such

2
Billinghurst (talkcontribs)

Is anyone able to point me to a large (and busy) page of FLOW discussions so I can use that as an example for a community to see how well it could work. Also how pages could be archived, or summary of posts could be viewed/browsed, maintained and searched. Thanks.

Trizek (WMF) (talkcontribs)

I have some examples:

Concerning archiving, it is done automatically. You can browse topics by clicking on "Browse topics" at the top of a Flow board.

There is cases where summary are used on the three links posted above. It is not possible to search on summaries at the moment.

Hope this helps!

Reply to "Examples of large page of FLOW discussions, archives and searching of such"

Cannot show a redlink to illustrate a point

7
Summary by Trizek (WMF)

Very particular case: create a redlink on a namespace redirect.

Dcljr (talkcontribs)

On the Goan Konkani Wikipedia just now, on a "Flow-enabled" talk page, I tried to purposefully link to a user talk page using a nonexistent namespace name (the original localized "user talk" name that had recently been changed via a Phabricator task) to illustrate how the original NS name was not being treated as an alias to the current one in existing wikilinks, as was intended. When I saved my comment, my link was automatically converted to use the current NS name, resulting in a blue link and thereby completely "missing the whole point" of my message. So, instead of "[making] the wiki discussion system more efficient for experienced users" and "[encouraging] meaningful conversations that support collaboration", the oh-so-helpful Flow system has actually made it more difficult for an experienced user to effectively collaborate. Thanks. (Can you tell I utterly despise Flow?) [And then I had to edit this comment again because the working interwiki link I provided in the first sentence was completely removed. Now it's an external link. -- Nope, it was just invisible, and my external link was actually saved as an interwiki link. Oh, the irony… Note: Had to switch to the wikitext editor to make this comment "work right".]

Trizek (WMF) (talkcontribs)

IIUC, you wanted to create a broken link and you didn't managed to? And you don't like the fact that there is automated redirects from incorrect NS names to the correct ones? As the Discoverer explains "The old user talk namespace name is supposed to be an alias to the new one.".

What you expect is a very particular case.

What would be the best? Change all links manually or by bot to remplace the namespace, or have that namespace redirected automatically? That limitation known, as an experience user, I'm sure you can find a way to explain your point concerning NSs, no? And I think this is problematic, with a lot of possible broken links.

Dcljr (talkcontribs)

Yes, I wanted to create a broken link because that was the problem I was trying to discuss. The old name is supposed to be an alias to the new one, but is currently not working as such. That was the exact problem I was trying to illustrate (in my comment on gomwiki). Now, forget about that particular gomwiki namespace issue, because it is soon going to be fixed. The rest of this comment will address the larger problem this brings up with Flow.

When creating the (broken) link in Flow, using the visual editor, I typed in what I wanted and a little drop-down menu popped up containing two suggested bluelinks and the redlink I typed. I chose the redlink, because that's what I wanted. I clicked to finish the link. I saw the link. It was red, as I intended. Now, when I completed my comment and saved it, the link turned blue because Flow had changed the namespace. This is not only not what I wanted, it's not what I was "promised" (i.e., shown in the visual editor) before I saved my edit. If an editor shows one thing and then saves something different, that's called a bug, and it indicates that the editor has not been designed properly.

Now, the preferred behavior would be (in the visual editor) either to (1) show me the redlink but warn me (somehow) that it's a broken link and give me the option to fix it or not — and then respect my choice in the matter; or (2) show a blue link with a warning that my link has been changed from what I typed/selected, give me the option to not accept the change, then respect my choice.

Does that seem unnecessarily complicated? Congratulations, now you see why I avoid the (regular, non-Flow) Visual Editor as much as possible. It turns trivial tasks like forming a wikilink, which can be done by an experienced wiki editor in about 5 seconds, into a carefully orchestrated series of steps (read: hoops) that takes 3 times as much effort. It may seem "easier" to wiki newbies, but to experienced wiki editors, it just obscures what is actually being done — meaning that sometimes what gets done is not what the user intended. (Bad experiences with their nascent [non-opt-outable] WYSIWYG editor is why I walked away from Wikia however-many years ago, and have never gone back. Badly designed user interfaces have consequences...)

So, why was I using Flow's visual editor to leave my comment in the first place? Because I didn't actually notice how I could switch to the "wikitext" editor. When I discovered I could do so, I did so. Editing my original comment in glorious wikitext, I was able to type exactly what I wanted. I saved it and got... exactly what I did not want. A bluelink.

On a non-Flow-enabled page, when one uses the wikitext ("source") editor, what you type is what is saved. Period. The same should be true on a Flow-enabled page. Inexperienced users (those not familiar with wiki markup) are not going to intentionally use the wikitext editor (unless they want to learn, of course). If a user chooses the wikitext editor, they are likely an experienced wiki user who wants to save precisely what they type. For the software to do otherwise is annoying and counterproductive.

Now, maybe the particular problem that has led me here really is just a quirk caused by the particular configuration issues on gomwiki. If that is true, well... "my bad", I suppose. But I know the problems I had on this page leaving my initial comment above were not caused by wiki configuration issues.

Suffice it to say, I "opt out" of most gee-whiz features that come down the pike (gadgets, beta features, and such), and Flow is one gee-whiz feature I most decidedly cannot opt out of (unless I simply refuse to use flow-enabled discussion pages — which, up to now, has actually been mostly true). Ultimately, it is the "unavoidable" nature of Flow (from the individual user's perspective) that is perhaps the one "unforgivable sin" that causes each problem users find with it to seem more like a creeping evil than an inconvenience......

OK, I'm done.

Trizek (WMF) (talkcontribs)

You case is not a Flow specific problem, it is a Parsoid problem.

I think the choice made here was to facilitate page redirections. I don't know why it is working on visual modes bot not on a classical wikitext page (Flow's wikitext is a wikitext based on Parsoid).

I can report the fact that you want to force a link to be wrong. But I'm pretty sure it will not be addressed soon, because it is a particular case, due to that namespace renaming. You want to create a broken link where people would be very happy to have a working link with a wrong syntax. Plus you have managed to explain what was the problem with the broken-but-not-broken link if I've understood correctly.

By the way, concerning Flow, you are contributing to the only two wikis which have enable Flow as the default talk pages system: gom.wp & mw.org. I think that's bad luck. :)

Sänger (talkcontribs)

Redlinks are something that quite often pop up on article discussions, to be able to use proper redlinks is a conditio sine qua non for any useful editor. Is there any reason for this mindless paternalism?

Trizek (WMF) (talkcontribs)

In the case we are discussing of, is not possible to create a redlink because of a namespace redirect defined on the configuration files for the wiki. It is an exceptional case.

For all other cases I can remember of, you can create all redlinks you want without any problem.

Dcljr (talkcontribs)

OK, I just spent over an hour constructing a link-laden comment on a Flow-enabled talk page only to lose all my work because I hit the "Esc" key to get out of editing a link, which happened unintentionally while I was "previewing" my comment.

Fuck Flow!

I will never be visiting — let alone editing — this page ever again, so don't bother replying to me.

Flow talk page manager doesn’t create my flow talk page on fr.wikisource

1
Summary by Metamorforme42

Ok, I tried again by disabling-re-enabling flow and my page was finally created.

Metamorforme42 (talkcontribs)

Hello,

I tried to convert my talk page on fr.wikisource as I did on fr.wikipedia and wikidata.

My talk page was archived as expected but my flow talk page wasn’t created.

Could you help me please ?

What pages can be translated on MediaWiki?

6
Сунприат (talkcontribs)

What pages of Flow documentation on the MediaWiki provided with markup for translation?

Quiddity (WMF) (talkcontribs)

The current documentation pages, are all too large, or too out-dated, and not well-written for translation. I want to research what the "Best practices" are, but I have not had time, recently.

Do you (or anyone) have favourite pages that you wish Flow would copy? (in layout and structure and wording).

Сунприат (talkcontribs)

Hide, suppress, moderation (Flow/Functional_Specifications/Moderation,_Protection,_and_Refactoring#Moderation_and_Suppression, Extension:Flow/Moderation#States_.26_permissions)

Indentation model Topic:Senq838us190rqlp

Flow - Rationale, Components of the discussion system, Release and features FAQ, Design FAQ

make them as Flow/Nomenclature

Quiddity (WMF) (talkcontribs)

Ah, thank you. That helps me understand which pages (and details) you want translatable. Yes, we will try to split the large Flow page into smaller sub-pages.

But I was also wondering, are there any other extensions/pages, that you really like, at mediawiki or other wikis? E.g. I will probably use these extensions, as a model or guide: Template:VisualEditor Portal/core, Template:ContentTranslation Portal/core, other?

This comment was hidden by Сунприат (history)
Сунприат (talkcontribs)

No, I do not have favorite pages, which could be taken as a model.

Reply to "What pages can be translated on MediaWiki?"
Pine (talkcontribs)

I believe that Flow is being used on an opt-in basis on Wikidata and Catalan Wikipedia, and is used on user talk pages by default on MediaWiki.

Is that correct?

Are there any wikis other than MediaWiki where Flow is enabled on all talk pages by default?

Are there any wikis where Flow is widely used on an opt-in basis, even if it's not the default?

Quiddity (WMF) (talkcontribs)
  1. Yes. For more details, Flow rollout is described and documented at Flow/Rollout.
  2. Not currently, but kab.wikipedia has requested it.
  3. Yes, Zh.wikipedia is a particularly active wiki, per the stats at https://edit-analysis.wmflabs.org/beta-enables/#projects=testwiki,zhwiki,wikidatawiki,cawiki,urwiki,bswiki,mediawikiwiki/metrics=Flow%20Beta%20Enables
  4. There's a survey coming soon, which will give more info/insight into all this.
Roan Kattouw (WMF) (talkcontribs)

Re #2, gom.wikipedia already has Flow on all talk pages.

Pine (talkcontribs)

Thanks!

Reply to "How widely is Flow being used?"