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

Please fill out this survey, which is administered by a third-party service. It will not require an email or your username. See our privacy statement

Trizek (WMF) (talkcontribs)

Distribution of an invitation for Mediawikiwiki users will be done today or at the beginning of next week. It has been postponed due to difficulties to identify active users on that wiki.

ImperfectlyInformed (talkcontribs)

I wasn't really a fan of this survey. I ended up filling out N/A for almost everything. I don't think it's fair to say Flow is better or worse than the alternative right now per se, because it does have weaknesses and strengths. I don't want to mislead the Product team into thinking that Flow is perfect, but I also don't want to discourage them. Flow is necessary, and lots of good progress has been made. Admittedly, I haven't really played with Flow much.

Not necessarily comprehensive list of specifics:

  • I do feel like it is not as good as Reddit, which most internet denizens are familiar with. For example, I would like to be able to vote on comments and collapse threads.
  • Outdenting and adding section headings is unclear, and doesn't roll up into a table of contents, as SMcCandlish has noted below (altho I have trouble finding real specific improvement suggestions from the discussion below).
  • "Hide" is weird - not really clear if that hides it for everyone or just me, but I think it hides for everyone? Maybe it should be report or something. Most users (including someone like, who has been editing since 2007) don't feel comfortable just hiding someone's comments.
  • More whitespace and larger font than I'd like. I guess that's probably configurable, but again, think about the audience... Wikipedia discussions are often HUGE, so extra whitespace can get annoying quick.
Trizek (WMF) (talkcontribs)

Thank you for your feedback, ImperfectlyInformed!

Flow is not perfect, we know that, and there is a lot of things to improve on it. We expect to have enough community feedback to create a strategy for the future.

I've read some random comments and results, and Flow users mostly have the same opinion as yours: Flow is good, but not that much. It must be improved because there is a lot of features missing. I've also read some comments like yours, suggesting that kind of improvements. I hope we will adress these concerns soon.

Reply to "A survey has started about Flow"

Error when moving from flow back to liquidthreads.

3
50.254.138.165 (talkcontribs)

Hello,

Due to some minor issues with flow that I won't go into, I have decided to go back to LIquidthreads temporarily. I removed the "require_once "$IP/extensions/Flow/Flow.php";" statement for flow from LocalSettings.php, and re-added the require once statement for liquidthreads. Everything is working great except on the talk pages I had created when I was using Flow. To clarify, talk pages that were not created when flow was enabled work fine, only the ones that were created using flow. When I try to access the talk pages that previously had flow pages created on them I get the error:

/index.php/Talk:Organization MWUnknownContentModelException from line 353 of /var/www/html/includes/content/ContentHandler.php: The content model 'flow-board' is not registered on this wiki.

See https://www.mediawiki.org/wiki/Content_handlers to find out which extensions handle this content model.

Backtrace:

#0 /var/www/html/includes/content/ContentHandler.php(290): ContentHandler::getForModelID(string)

#1 /var/www/html/includes/MediaWiki.php(405): ContentHandler::getForTitle(Title)

#2 /var/www/html/includes/MediaWiki.php(286): MediaWiki->initializeArticle()

#3 /var/www/html/includes/MediaWiki.php(745): MediaWiki->performRequest()

#4 /var/www/html/includes/MediaWiki.php(519): MediaWiki->main()

#5 /var/www/html/index.php(43): MediaWiki->run()

#6 {main}

I know this has something to do with ContentHandler.php and switching the content model away from flow board, but I am unsure how to do this.

Thanks and any help is greatly appreciated.

Mattflaschen-WMF (talkcontribs)

"I removed the "require_once "$IP/extensions/Flow/Flow.php";" statement for flow"

By doing so, you uninstalled Flow. That is why Flow boards no longer work. I don't recommend uninstalling Flow. I think it will cause issues such as broken logs. (You can add that line back to re-enable it.)

If you want to stop using it, you can just move the Flow boards to archive pages (there is a moveBatch.php in core that may be helpful).

If you really want to uninstall Flow, you can first use maintenance/convertToText.php (in the Flow extension) to convert the pages to text, then delete the original Flow versions.

50.254.138.165 (talkcontribs)

Thank you.

Reply to "Error when moving from flow back to liquidthreads."

What can interested users do to help the development of Flow (when it starts again)?

2
BurritoBazooka (talkcontribs)

I really like Flow, and dislike the English Wikipedia's current talk page system. I have witnessed a lot of instances where users are confused about the talk page system and end up using it wrong, many times resulting in their opinions not seen by the relevant people, nevermind considered; and other times resulting in historical discussions being difficult to follow without using the page history to see who said what when.

I think Flow is better for new users, and is a good way of encouraging their input on Wikipedia, thus making Wikipedia grow as a project - at the very least by making it easier for them to submit properly filed edit requests. Although I have a personal leaning towards the freeform style that Wikipedia's talk page system allows for, I want to see Flow succeed for the greater good, and I think there are many others like me. I'm glad to see it being implemented in other Wikimedia projects and I hope that it will benefit them greatly.

I recently noticed that the English Wikipedia has had its Flow extension uninstalled because of the halt in development.

What can people like me do to help Flow succeed? Is there a donation page especially for this extension? Could there be one next time development starts? Is there a bounty program? A box to tick showing our support?

Trizek (WMF) (talkcontribs)

Hello BurritoBazooka

A good way to help talk page improvements is to show how important it is for you. Thank you for your message!

Flow extension has been uninstalled from English Wikipedia after a community discussion. Some other communities are using Flow on user talk pages, as a Beta feature (people can opt-in) or as the default discussion system (like here, on mediawiki.org).

At the moment, Flow development is stalled, waiting for a decision concerning talk pages improvements. That decision will be partially based on the results of a survey I'm working on at the moment. I hope we can reach a firm decision in 2017. There is no donation page dedicated to that project, but, if you are a developer (PHP), you can help for sure.

You can remain informed about the next steps concerning Flow by subscribing to our monthly newsletter (edit: as you already did).

Reply to "What can interested users do to help the development of Flow (when it starts again)?"
Sunpriat (talkcontribs)

In five minutes anonymous has made 54 changes https://ru.wikipedia.org/w/index.php?title=%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:%D0%9F%D0%B5%D1%81%D0%BE%D1%87%D0%BD%D0%B8%D1%86%D0%B0/Flow&limit=100&action=history

1)to undo his actions have to do again 54 actions

2)he changed the topic title - (from "Horror..." to "") - it turned out that this cannot be undone. When the topic title not in English, for example Russian, in the field "from" fit smaller number of letters. If the topic name is long, it is not entirely fit - " from "Horror..." ". In the history page the line has a buttons "solved" and "hide", but there is no button "cancel" - thus the last part of the title of the topic is lost forever!

3)you can unhide the answer, but but cancel is not working as expected - it turns out that I'm getting a new author as the last editor for summary, for the posts of other users, and so the theme goes up. And it says that I've changed it, although I wanted only to undo the vandalism, returning back the old dates and text for last the real authors of the text. Expected that the cancel will return the oldest date and the previous value of the "last changed text was the user".

This comment was hidden by Trizek (WMF) (history)
Trizek (WMF) (talkcontribs)

Hello Sunpirat

I forgot to answer your questions, sorry. :/

1) We know. that's a problem. However, the Nuke option now works for that.

2) I'll ask @Etonkovidova to have a look at that problem.

3) Just to confirm, you mean that unsuppress a comment creates a new entry in the History of Flow and attributes the edit to the sysop instead of the original author?

Sunpriat (talkcontribs)

3) A new entry in the history - it is OK.

Developers are allowed all users to edit posts after a certain time after starting the Flow. Perhaps this part was designed earlier, when was not allow to all.

https://www.mediawiki.org/w/index.php?title=Topic:T9uj52wvz4druk45&action=history I see it:

23:22, 17 August 2016 . . Roan Kattouw (WMF) (talk | contribs) edited a comment on "TestingAReallyLongTopicNameThatShouldReallyWrapItself" . . (-1)‎ (undo|hide)
Edited by Roan Kattouw (WMF) 18 August 2016 2:22 AM

When it's vandalism, I can only "undo". In the flow for reading, "post date" and "last changed by user" is displayed as "new" information (new last, new date). I did not "make changes" in message. I was expecting to see the old information that was before the vandalism (author before the vandalism, date before the vandalism). I would like to hide "the version", not to suppress (history for all) as the sysop. (But you can hide only entire post). If for vandalism you are encouraged to fight through to suppress, then the flow-suppress right also had to distribute a larger number of users.

Suppression we use only when obscene language. With the vandalism we use a rollback to the previous version.

Etonkovidova (talkcontribs)

Hi, Sunpriat!

Thank you for your detailed descriptions of issues.

1) Unfortunately, Extension:Nuke won't solve the issue of reverting multiple edits. Extension:Nuke works on deleting multiple pages. For wikitext based pages, the 'rollback multiple edits' is a very convenient option and that option should be implemented for Flow boards too. I am going to file a phabricator task for several issues with rolling back edits/changes on Flow boards/topics.

2) Here are two things

- I checked on how long topic titles are displayed in View history - checked both in English and in Russian. Topic titles are allowed to have 260 bytes and all of them are displayed in View history entries. It might be(although it does not seem to be the case you described) that if a topic is deleted/suppressed, some users cannot see the topic title. Can you provide a link to View history where you observed that topic titles are not displayed entirely?

- and, yes, rollback of changes in topic titles is not implemented. I will add it to the phab ticket I am going to file for the above case (in #1).

3) Yes, the 'undo' action for Summary edits will be attributed to a user who was performing 'undo' action as e.g. 'Summary last edited by [the user who performed 'undo' on Summary edits']. The phrasing probably needs some clarification or rephrasing. It seems that some discussion is needed on what information there will be most useful to users (and another phab task).

Sunpriat (talkcontribs)

4) situation in the description of the Board: https://ru.wikipedia.org/w/index.php?title=%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:%D0%9F%D0%B5%D1%81%D0%BE%D1%87%D0%BD%D0%B8%D1%86%D0%B0/Flow&action=history

(cur prev) 15:29, 26 October 2016 . . 95.49.124.43 (talk) edited the description . . (-28)‎ undo
(cur prev) 15:29, 26 October 2016 . . 95.49.124.43 (talk) edited the description . . (-627)‎ undo

there was a well-decorated description. a vandal came and made some edits in the description

problem: it is impossible to return to an older version - "The edit could not be undone due to conflicting intermediate edits.":

- apparently you can only sequentially undo changes

- it is impossible to access the wiki-text of the old version. The wiki-text of the old version, I can only see through the history and compare revisions. I can't do it comfortably fully open as the wiki-text and copy-paste with new edit or write old version over new. it only remains to copy paragraphs from the comparison of edits in the history


You also cannot see (filter, group) history of the Board description. The history of the Board description can see just thumbing through the pages of the whole Board history or using the next/previous edit - it's uncomfortable

---

2) I didn't notice that there is an active (cur prev topic). Then there is no problem. Yes, long headers are displayed completely (in contrast to beginning content of the posts in history page), thanks for the clarification.

---

3) And in the Topic Summary and in the Post. Yes. Imagine that in the Topic from 2016, a lot of messages will change vandal in 2026 and verse will be "changed in 2026". Thus we are creating a plaque to commemorate the vandal. Here https://www.mediawiki.org/wiki/Flow/Functional_Specifications/Moderation,_Protection,_and_Refactoring - it is not clear - we can suppress(so not to be seen the (last edit) date of the vandal version) one version of the post or we can only the whole post?

Etonkovidova (talkcontribs)

@Sunpriat

I filed talked to the team and filed a phabricator task about usability issues with View history for Flow board - https://phabricator.wikimedia.org/T150219. You may want to review to make sure that I've captured all points mentioned by you correctly.

Re #4

- the Suppress actions are not displayed to all users. The suppress action won't be displayed to the author of the post which was suppressed. I mentioned it as a question for discussion in https://phabricator.wikimedia.org/T150219.

- when suppressing a post - all versions will suppressed. Even if 'suppress' is applied only to a certain revision, the entire post will be gone. Suppressing a topic applies to a current state of an entire topic (users cannot select specific revisions to suppress).

Reply to "Undoing changes"
Sunpriat (talkcontribs)

- posts are "in the box" (a nickname, menu, answer, date)

- this adds parasitic text to the flow - conversation flow is interrupted disturbing "answer*thank" - it reads, it interferes

- left part of the flow is obtained overloaded text "nick-message-answer*thank...again"

- sequence "line-answer-line-nick-line" visually takes unforgivable plenty of space in the debate, eats space adding ragged white void "in the center" between "answer-date nick-menu"

- words answer*thanks constantly falls in the "read the post" - when you read posts in a row on the board is obtained as the radio traffic "A-bbbbb-c-d, A-bbbb-c-d..."(nick-message-answer*thank). This "thank" can be safely moved to the menu, or replace per symbol that is not read mentally

- bold nick dominates the text. Message is important and not the one who wrote it. If this is done in order to improve the vision of people with low vision, then again, it is more important than the appearance of the text and not the author.

This is variant image - the bottom line is raised up to the menu, and the discussion has become "easier" to read from top to bottom on the left

Trizek (WMF) (talkcontribs)

Thank you for these suggestions. Your feedback is shared by other users, that have suggested changes like yours. We need to have a look at it.

At the moment, no further improvements will be made until a clear roadmap has been defined. That will happen in a few months from now. More information about that will be posted on the new Collaboration team products newsletter.

Reply to "Heavy view"

There's something wrong with my talk page

5
北极星与南十字 (talkcontribs)

My user_talk page()crashed after disabling-re-enabling "Flow" system. Can you tell me how to solve this problem? Mainly thanks.

The information given by the system is "[V@hyawpAAEIAAFYdS4MAAAAW] 2016-09-26 00:57:15: 类型“Flow\Exception\InvalidInputException”的致命错误"

Trizek (WMF) (talkcontribs)

I'm sorry to hear that, 北极星与南十字.

I've reported your problem and I'll ask the developers to have a look at it promptly.

Do you know other users with that problem on zh.wikipedia?

北极星与南十字 (talkcontribs)

Thanks for your help.

I haven't heard of other people who meet the same question as mine. If I know about that, I'll report to you.

Willy1018 (talkcontribs)

NO mine "Flow" is crashed too The wrong announce to me is [V-DkGApAIDQAAGDL2WAAAACT] 2016-10-02 10:40:24: 类型“Flow\Exception\InvalidInputException”的致命错误

Trizek (WMF) (talkcontribs)

At the moment it is not possible to activate and deactivate Flow on a user talk page. Activate or deactivate Flow will lead to an empty page, with an error message.

Developers are fixing it. I'll post news when some updates will be available.

Reply to "There's something wrong with my talk page"

My Flow can not work now

1
Summary by Trizek (WMF)

At the moment it is not possible to activate and deactivate Flow on a user talk page. Activate or deactivate Flow will lead to an empty page, with an error message.

Developers are fixing it now.

Pdch226 (talkcontribs)

My Flow ConfirmEditer postion can not work

Reply to "My Flow can not work now"

How long is this Flow testing going to continue?

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

Whatamidoing (WMF) (talkcontribs)

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.

SMcCandlish (talkcontribs)

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)

SMcCandlish (talkcontribs)

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)

Whatamidoing (WMF) (talkcontribs)

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.

SMcCandlish (talkcontribs)

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

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)

Trizek (WMF) (talkcontribs)

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.

Alsee (talkcontribs)

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.

SMcCandlish (talkcontribs)

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)

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.

Whatamidoing (WMF) (talkcontribs)

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.

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.

Trizek (WMF) (talkcontribs)

Thank you!

Whatamidoing (WMF) (talkcontribs)

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.

BethNaught (talkcontribs)

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.

Sänger (talkcontribs)

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.

Trizek (WMF) (talkcontribs)

That's your opinion, Sänger.

SMcCandlish (talkcontribs)

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)

Whatamidoing (WMF) (talkcontribs)

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.

Sänger (talkcontribs)

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

SMcCandlish (talkcontribs)

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)

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.

Trizek (WMF) (talkcontribs)

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

SMcCandlish (talkcontribs)

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.

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