Meta:Babel/Archives/2016-11

Динопедія

Я хотів би створити вікіпроект про динозаврів під адресою https://uk.dinopedia.org . Логотип- https://commons.wikimedia.org/wiki/File:Ceratosaurus_mounted_white_background.jpg . --Боровков Роман (talk) 19:11, 3 November 2016 (UTC)

Making the "NOINDEX" tag work on all namespaces on Meta-Wiki

Tracked in Phabricator:
Task T150245 resolved

Hello. I've proposed that __NOINDEX__ works for all namespaces here at Meta-Wiki. Currently, the tag cannot be used on the main namespace as well as on others. Given the nature of this wiki and that we store some pages and archives such as Vandalism reports which get indexed. We've got several requests in the past to hide from search engines some pages and we've found that the only way to do it is by modifying the robots.txt, which requires an admin. Leaving here a note at request of Dereckson. Regards, —MarcoAurelio 23:39, 15 November 2016 (UTC)

Thanks for the note! I commented on the Phabricator task. Given this edit, the current example use-case is somewhat moot now. I imagine there might be other use-cases, though. --MZMcBride (talk) 00:09, 16 November 2016 (UTC)

Thanks. It's active now and NOINDEX works on all pages here now. —MarcoAurelio 11:14, 11 December 2016 (UTC)

This section was archived on a request by: —MarcoAurelio 11:14, 11 December 2016 (UTC)

Flow

Where did the discussion to enable Flow here go? And why is it not here? --MF-W 02:18, 27 November 2016 (UTC)

Noooooo... ♪♪♪Let it Go!, Let it Go!, ♪♪♪We don't want Flow here anymore, ♪♪♪Let it Go, Let it Go!♪♪♪,Turn it away and slam the door!♪♪♪Let it Go, Let it Go!♪♪♪ Flow sucks badly anyway!.♪♪♪ ...--Stemoc 02:26, 27 November 2016 (UTC)

You mean this one? The discussion is taking place on Wikimedia Forum for some reason. --MZMcBride (talk) 05:05, 27 November 2016 (UTC)

Where is Flow enabled, appart from Talk:Flow/Developer test page? —MarcoAurelio 13:16, 27 November 2016 (UTC)

I'm assuming you're asking about where Flow is enabled on Meta-Wiki specifically. I attempted to answer programmatically: Special:Permalink/16104905. The first query shows pages that are marked as Flow boards. The second query shows all pages that are not marked as CSS, JavaScript, or wikitext.

If you want to know where the Flow extension is deployed to Wikimedia wikis, you will need to consult <https://noc.wikimedia.org/conf/>. --MZMcBride (talk) 18:42, 27 November 2016 (UTC)

Thanks, that was what I was looking for. Maybe we should move it here. --MF-W 20:17, 27 November 2016 (UTC)

Enabling flow on one page (Research:ORES paper)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

In my humble point of view I feel there's no community support for the proposal. —MarcoAurelio 18:53, 24 December 2016 (UTC)

---

Moved from Wikimedia Forum

Hey folks, I'm working on writing a new research manuscript at Research:ORES paper (will be renamed to something more interesting at some point). I'd like to enable mw:Flow for the discussion page. I plan to experiment with using Flow as a public forum to discuss the manuscript (a mixture of Wikipedians and non-Wikipedians).

I wanted to raise the proposal here because there was an RFC that happened in the past with no-consensus. See Meta:Requests for comment/Enable flow in the Research talk (203) namespace. I closed this old RFC the future of Flow support from WMF engineering was not clear and that raised some serious concerns. However the Flow documentation now says:

The [Collaboration Team] will continue to fix bugs, and make sure that people who are using Flow continue to have a good experience.

Rather than re-open the RFC at this point, I'd like to experiment by enabling Flow on a single page in the Research namespace (the aforementioned Research:ORES paper). Any concerns? --EpochFail (talk) 01:28, 23 November 2016 (UTC)

Hi EpochFail. My sense is that people active on this wiki (Meta-Wiki regulars) have little interest in Meta-Wiki being a test bed for experimental software. Nothing in your post here convinces me that attitudes have shifted. I'm not sure I even knew that Meta:Requests for comment/Enable flow in the Research talk (203) namespace took place, but knowing about it now, it personally makes me even more hesitant. I sympathize with wanting better discussion tools and I sympathize with wanting to be able to do your own thing on your own pages, but if you're looking for consensus from the Meta-Wiki community to expand the use of Flow, it seems unlikely you'll find it.

I'm pretty sure I've made similar comments elsewhere, but I think a lot of people felt "burned" by LiquidThreads, the spiritual predecessor to Flow (even though some people involved in Flow's development vehemently denied that). The migration path away from LiquidThreads or Flow is very difficult, so escaping a bad decision becomes a lot more complicated in the event that Flow, like LiquidThreads or the solutions before it, get abandoned.

I thought Flow had been put into "maintenance mode" and was slowly dying off. The "ee" mailing list's activity can perhaps attest to this, though mw:Flow/Rollout says Flow has spread to about a dozen additional Wikimedia wikis in 2016. I consider myself somewhat technical and I don't know what Flow as a "beta feature" means. It gives the impression that a user can enable or disable Flow in his or her user preferences (i.e., Special:Preferences), but that... can't be right, I don't think. Flow pages (boards, whatever) can't simply be disabled by a user, as far as I know. If they could, I imagine you'd see a lot faster adoption of Flow! --MZMcBride (talk) 03:14, 23 November 2016 (UTC)

Addendum: I finally found mailarchive:wikimedia-l/2016-September/085114.html, which provides some background and context. --MZMcBride (talk) 03:20, 23 November 2016 (UTC)

It is possible to enable Flow on several wikis as a Beta feature, by selecting an option in user preferences. At the moment, this Beta system is out of order and we are fixing it. Trizek (WMF) (talk) 09:03, 23 November 2016 (UTC)

•  Oppose In addition to what said above: it is not appropriate to expose people to inconsistent discussion systems; Meta-Wiki contains a lot of our wiki history, which ought to be preserved in a future-proof format like wikitext; I see no indication whatsoever that this system will improve in the future and I see practically no fixes of user-reported bugs or feature requests, except some dangerous, harmful and annoying regressions which should have been resolved on day 0 by starting the project with a proper design (rather than the totally flawed design made in 2012 and early 2013). Nemo 07:05, 23 November 2016 (UTC)

Just to be clear, you're opposing me doing what I think needs to be done in order to get my collaborators working on-wiki and out in public. Currently, scholarly practices like discussing a manuscript in progress happens in private. I think that's a great loss and a missed opportunity for Wikimedia. I'm trying to re-engineer scientific practice to be more open. My collaborators won't be using talk pages because they just don't make sense to anyone who's worked anywhere other than Wikipedia on the internet. I think it's worthwhile to bring scholarly practice to the wiki and you're saying "no". Why?

Nemo's list of phab task seems very cherry picked. I could do that about any production system. E.g. ORES is dangerous and annoying. You'll see that we're primarily focusing on operational concerns -- not user-reported bugs and requests. Yet we'd like to deploy prediction models for Meta anyway. So, apparently, we are interested in experimental software running on Meta. (Also, I should note that the list that Nemo links to has many user-reported bug fixes.)

I think I'm pretty representative of the community of people who document their research on meta. I'm at least the most prolific contributor to that space. MZMcBride notes that I'm unlikely to find consensus on Meta about using Flow *at all*. That might be true, but of people who actually edit in the Research namespace on Meta, we have a clear consensus that we want to have Flow. This is a serious point of departure between our subcommunity and the rest of the Meta. By saying no to running Flow on one page as an experiment, you're preventing us from trying it at all. Nemo complains that by enabling Flow on one page, we'll have "inconsistent discussion systems", but what alternative do we have for showing you (Meta-Flow-naysayers) how much of a difference it will make to us (Meta-Researchers)? --EpochFail (talk) 16:06, 23 November 2016 (UTC)

Yes, I manually picked the latest resolved tasks that I could find which were closest to being user-reported. I remind you that it's you saying that Flow is maintained and everything, against the latest official statement, so the onus of proof is on you, not the others. I don't know what the ORES comparison is for, so I'll skip that.

The RfC did not show such a consensus in the "subcommunity", as far as I can remember. As for ways to show the difference Flow will make, I guess one option is to study the impact of the usage of Flow on other wikis.

However, even before we start collecting evidence on what will be good for the wiki and the Research namespace, there might be a need to discuss and clarify the general goals and principles: it's certainly possible that there are conflicting goals here, e.g. «re-engineer scientific practice to be more open» may not be everyone's first goal. Nemo 17:14, 23 November 2016 (UTC)

I brought ORES into the discussion to challenge the assertion that Flow development is in an undesirable state for use in Meta.

When I asked JMatazzoni about the status of Flow development and support, he directed me to the quote I pulled from the Flow documentation above. "The [Collaboration Team] will continue to fix bugs, and make sure that people who are using Flow continue to have a good experience." I feel like that is a pretty clear statement, Nemo. What else do you want?

Regarding the past RFC, all participants who had actually edited in the Research namespaces (with the exception of you, Nemo) supported switching to Flow. All provided substance for their arguments while you provided almost no explanation -- claiming that you'd be "forced to stop" commenting on research pages if Flow was deployed. This is obviously not true and only betrays a strong ideological bias you have against the software -- usability aside. I think that shows a pretty clear consensus, honestly.

I understand that your first goal might not be to bring Science to Wikimedian practices of open discussion and open access, but it is something that those of us Wiki Research scholars active on Meta *are* trying to do. Do you feel like this is in conflict with Wikimedia's goals? I don't think so. I think it's clearly well-aligned and I don't understand how you could disagree. --EpochFail (talk) 18:19, 23 November 2016 (UTC)

•  Support This change would help people who want to participate in on-wiki discussions around a particular research project, and whose input would be valuable to that research project, but who are not comfortable using wikimarkup on talkpages, contribute to that project. As EpochFail says, it's about getting external collaborators working on-wiki and out in public. There also is nothing inherently wrong with exposing people to inconsistent discussion systems. I'm not aware of any principle of design that asserts that consistency trumps usability: the mechanism used for discussion should be designed to meet the needs of the target audience. Furthermore, we develop specialized workflows and workarounds across all our projects to address particular needs. We used a gadget on the Teahouse Q&A board to make it easier for newbies to participate, and there have been no negative consequences of that decision that I've seen (MZMcBride and I argued back and forth about this point extensively in the early days). Nemo_bis is your objection to Flow specifically, or would you also be opposed to enabling the Teahouse Q&A gadget (or another gadget-based solution) on this single page as well? Jtmorgan (talk) 19:48, 23 November 2016 (UTC)
  • Hi Jtmorgan. Yes, you were able to create your own special snowflake on the English Wikipedia called the Teahouse. Building infrastructure and tools that fit many use-cases is hard. Hacking together your own custom/one-off thing is easy. If you're interested in helping out with the hard work instead of marginally increasing our collective technical debt, both phabricator:T7642 and phabricator:T33919 remain unresolved. :-) --MZMcBride (talk) 18:53, 27 November 2016 (UTC)
• I have no issue with this. – Ajraddatz (talk) 02:43, 26 November 2016 (UTC)
•  Support I have been using the Flow system for half a year on my home wiki and it works quite well. That does not imply that there are no problems with the system, but hey there are bugs all over Mediawiki, so it is no different than the rest of the code. — Jeblad 17:32, 27 November 2016 (UTC)
• Personally, I think Flow is still pretty bad software and I don't really wish to see it spread further at this time. That said, as someone who doesn't use Special:RecentChanges here and who likely won't be impacted by the use of Flow on this wiki, it's difficult for me to oppose. --MZMcBride (talk) 18:56, 27 November 2016 (UTC)
• Oppose I don't think Flow should be enabled on any pages here, no matter what the excuse. --MF-W 01:05, 28 November 2016 (UTC)

┌─────────────────────────────────┘
Quick summary: In support, we have Jtmorgan and EpochFail (me, the proposer) because we think it will make it easier for our collaborators to work with us. Jeblad supports saying that he has had positive experienced with Flow on another wiki. I also use Flow on another wiki and I would much rather use it than talk pages (FWIW, I have not drank the koolaide; I do not use VE because I'd rather write wikitext). Ajraddatz sees no issue with this proposal moving forward -- which I think implies light support.

MZMcBride is against this because he thinks Flow is "bad software" but admits he won't be personally inconvenienced. Nemo is against enabling flow on just one page because it might be inconsistent and has concerns over maintenance of Flow (despite clear statements documented above). MF-W opposes with no explanation.

To me, this reads pretty clearly. We have reasoned support from those who stand to benefit. I don't see a clear challenge to the "this will bring more contributors to Meta" argument. We have a report of positive experience from an actual Flow users. From the opposition, I see general statements about not liking Flow ("bad software") from non-users and concerns about it's maintenance state (that have been addressed).

So, this is a bit messy, but I see reasoned arguments (which stand unrefuted) in support and vague statements about software quality and maintenance (that have been refuted) in opposition. Given that Jtmorgan and I are the only ones who will be inconvenienced if things go badly and we'd only be enabling Flow on one page, I think this is consensus enough to move forward with the proposal. --EpochFail (talk) 21:42, 29 November 2016 (UTC)

How utterly convenient that you think your own arguments are unrefuted and opposers' refuted. Maybe an admin should rather determine the result (and I still think this section should be moved to Meta:Babel). --MF-W 15:02, 3 December 2016 (UTC)

Make a list of valid arguments for and against, and disregard who said what. It isn't that many valid arguments, most of what is written is simply opinions. A lot of people misunderstands our goal, thinking the goal is the use of specific tools, and thereby refuse to use anything but pure wikitext. — Jeblad 20:29, 3 December 2016 (UTC)

Hi EpochFail. I think saying Flow is pretty bad software is fairly relevant to a discussion about extending its usage here. Did you want to get into specifics about Flow's problems? If so, we could start with its gibberish topic page titles such as Topic:Rph3qplet97huylg. Or we could discuss how much vertical screen space a single-sentence reply takes up. Or we could examine the crazy low reply depth limit.

It's a bit strange to cast Flow critics as non-users. It's not as though most people here are blindly discussing an abstract concept. We're not discussing a future software product that's currently in the idea phase. It's because people have experienced Flow that they don't like it, in my estimation. --MZMcBride (talk) 08:05, 4 December 2016 (UTC)

I'm reacting "bad software" critiques, that have answers documented in Flow's FAQ. I'm not saying that everyone have to agree with choices that have been made, but I want people to know on which well-founded reasons these choices have been made.

Gibberish topic page titles are like that because of topics centralization. Flow has been designed to allow cross-pages and cross-wiki display. Imagine that you have that conversation on a personal "inbox", and also on Meta:Babel, here and on MediaWiki Flow board. That's possible with development that have to be done, but it needs an unique ID. It is not possible to have multiple topics titled Topic:Hello. However, it is possible to change topic names, to have something more explicit, like Topic:Hello-RdZ3SJY7W5Wtr, but still with that unique ID somewhere.

Vertical space is here to improve readability, compact discussions are not easy to read. That vertical spacing can be changed in your personal CSS.

Concerning replies, Flow has a different system than the not accessible one, based on definition lists, used on old-style talk pages: you don't indent to reply, you indent when you digress. It improves readability too. That's why discussions are like that everywhere else on the Web. Trizek (WMF) (talk) 09:40, 5 December 2016 (UTC)

Except you don't really "indent when you digress", you indent when you make a reply that's not the first reply to a post, even if that first reply was actually the digression, and you get the chronological ordering of the discussion out of whack when doing so. Or else you just shove your reply at the end and hope that context is enough to make it clear to everyone what you're actually replying to, and force everyone reading to follow the mixed-together threads of conversation without any UI guidance helping them to do so.

BTW, which "everywhere on the web" are you talking about? The only places that come to my mind seem to be encouraging one-off throwaway comments rather than in-depth discussion (or are email where messages are expected to include enough quoted context for each message to be entirely standalone).

P.S. To make it clear, I'm replying here in my personal capacity. Anomie (talk) 14:31, 5 December 2016 (UTC)

Hi Trizek (WMF). Your reply reads like that of a paid advocate for Flow, which is perhaps unsurprising given that that's pretty much your professional role. Sure, these questionable design decisions are documented, but that doesn't make them correct. These same criticisms have been brought up many times (a quick skim of mw:Talk:Flow confirms). My guess is that Flow will fail due to the stubbornness of the development team in these areas. Telling users, for example, to edit their personal CSS to fix the vertical spacing is not an acceptable workflow or workaround. I don't need to be convinced that the current discussion system is inadequate, but the proposed replacement is somehow worse. --MZMcBride (talk) 14:38, 5 December 2016 (UTC)

Anomie, my exemple of indentation was about Flow: it doesn't use indentation. The indentation system of wikitext talk pages is not intuitive: when do you indent? To each reply in theory, and you can indent more between two replies to digress. And you can go back to the first mine when the conversation has too much indentations. That's not intuitive -- for beginners, but not only. It also can be painful for an experienced user to understand how to indent; wikis have different ways to do that (colons and/or bullet-points, visual assistance while reading or not...). I think Flow is overall easier to use, and the survey I'm working on has results that confirm that (publication in December if everything goes well).

Replies to your question about "everywhere else on the Web" are in the FAQ.

MZMcBride, if you read me as a paid advocate, I'll also give you some background: I've been hired to be a community liaison because I was highly supporting Flow as a volunteer. I support Flow or at least a new structured discussion system because I believe in it. But I'm also very aware of that extension's weaknesses and I do my best to have improvements done. The survey will give us some information that may change things: I don't know if the result will lead to an abandon of Flow and the creation of a new project, or anything else. But I wish we will improve discussions.

We (the team) are aware of criticism made by some users. We also see silent users that use Flow daily and don't complain (despite my questions and requests for feedback). Documented decisions are criticized, they may not be correct, right; the problem is that I see most of time critiques based on "that's changing my workflow". I don't think that's always a valid argument. Re:Customize the interface: that's really common for advanced users, they also use gadgets. Remember that Flow is a work in progress. That's not a finished project and constructive feedback is still welcome to improve it (if there is a decision to improve it).

Trizek (WMF) (talk) 17:12, 5 December 2016 (UTC)

Trizek (WMF): You don't seem to have actually responded to my point, instead you seem to have constructed a strawman of some sort and replied to that instead.

Your FAQ link doesn't seem to mention at all what you are referring to when you say "everywhere else on the Web". The specific question you link merely quotes one guy who says branching conversations are bad (in his personal opinion, as far as I can tell, no examples given), and links to another guy in a footnote who uses StackOverflow and Twitter as his examples of "good" discussion systems. Anomie (talk) 17:27, 5 December 2016 (UTC)

I've been away for a while. It seems that there are a few points to respond to. MF-W, you have raised no argument at all, so your challenge to my assessments to the arguments made falls kind of flat, don't you think? Maybe you could make your own arguments and assessments rather than jumping directly towards attacking my qualities. It seems that Anomie has some concerns about the software in general. I think it's clear that these concerns don't outweigh the benefits to the users we would like to target in this deployment of Flow (ON ONE PAGE!!!), so I'd kindly like to ask him to take his general complaints to a more general forum. MZMcBride says that "saying Flow is pretty bad software is fairly relevant", but only provides his concerns about centralized topic IDs (which many see as a valuable feature) as an example that makes the software "bad". In the past, no arguments about what actually makes the software bad were made at all, so I appreciate his one example. However, I feel like that one example does not detract from the usefulness to newcomers (specifically academic researchers whom I collaborate with) in the Research namespace (in which none of the opposers are active -- even Nemo these days). To state it simply, those of us who are active there (and would be affected) really want to see this happen and I would appreciate if that is taken into consideration. Can someone who opposes this at least acknowledge that they won't be affected by this -- and that everyone who will' be affected by this is in support?--EpochFail (talk) 16:16, 8 December 2016 (UTC)

Hi EpochFail. Does this request have an associated Phabricator Maniphest task? --MZMcBride (talk) 03:09, 16 December 2016 (UTC)

I made [1]. HTH, Elitre (WMF) (talk) 08:09, 16 December 2016 (UTC)

•  Oppose. The proper RfC to enable it in the whole namespace was declined, so now you are trying to advance Flow on page by page basis by discussions on random pages? I am pretty sure that people interested in such a high-tech thing as ORES are capable of learning how to press the edit button and indent text with proper number of colons. That might be true that I as some other opponents are not active in Research namespace, but advance of the beta extension which has a lot of known shortcomings as opposed to plain wikitext is something of the whole wiki scope and should be managed on that level. --Base (talk) 00:11, 18 December 2016 (UTC)
• Enabling it on a single page as a test case seems reasonable to me. If we're able to attract more people to contribute and discuss their work on wikis in public, I think that's overall a win. Legoktm (talk) 05:47, 18 December 2016 (UTC)
• I as well am very sceptical with regards to enabling this anywhere on meta. I fear this may justify deployment of this tool to even more pages. I am already very frustrated with the possibility to enable flow for ones own talk page on some wikis, it makes it very hard to communicate with users among other issues (long page loading time, counterintuitive administration of flow boards, …). I understand that I will probably never come across this individual page, but I don't see why enabling this feature after a failed RFC is so badly needed. --Vogone (talk) 08:02, 18 December 2016 (UTC)
• So someone made a RfC about this and withdrawed it by saying he would ask again in a RfC, when you can determine its long term status. Until now we had no second RfC about this topic, but since today it’s alive. We had nor a consensus to enable it nor to keep it disabled because the RfC was withdrawed, but the arguments against are numerous and after all we should keep the status quo. All in all it seems a bit like you want to enable it step by step first on this page then on another because the community didn’t let you enable it on the whole namespace. – KPFC 💬 21:08, 20 December 2016 (UTC)
• I think that the community recently expressed that they don't want Flow enabled on Meta, and I see no consensus either to enable it here as well, even on a single page. —MarcoAurelio 16:18, 24 December 2016 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Improper closing of discussion

Concerns about the closing of the above discussion and the quality of the summary. Closure & summary found to be correct by other bureaucrat.

MarcoAurelio has closed the above discussion with the following statement: "In my humble point of view I feel there's no community support for the proposal." There are two serious issues with closing this discussion. This summary of the discussion is untrue to a simple observation. There is obviously *some* community support for the proposal. In fact, all contributors who would be affected by support of the proposal have shown full support. Any closing authority should note this in their summary. As it stands, this summary of the discussion is clearly not a good-faith summary of what took place in the discussion. The discussion had not ended. There were open questions that had yet to be addressed. I'll restate mine: Can those opposing state clearly how they will be negatively affected by this specific proposal? The discussion is not complete until these questions are addressed or have clearly been purposefully left unaddressed. Explicitly choosing to not address questions like this should be considered when closing. Regardless, closing the discussion before those who were questioned about their reasoning have a chance to respond is obviously premature. In my assessment, MarcoAurelio has closed this discussion inappropriately and we should re-open the discussion *after* the popular set of winter/solstice holidays that are currently keeping people away from their activities online. --EpochFail (talk) 17:52, 28 December 2016 (UTC) I've edited my statement to strike "-faith" from my assertion of the quality of the summary statement of the closing admin. I did not intend to accuse MarcoAurelio of operating in bad-faith, but rather had intended to make a statement about the qualities of the summary. I regret for causing hurt feelings and I hope that this explicit action will serve as consolation. --EpochFail (talk) 00:48, 30 December 2016 (UTC) After reading your allegations, my closure stands, but any other admin is free to reopen it if it feels it is indeed improper. Let me explain: The discussion has lasted a month. That's a fair ammount of time even for Meta, and the majority of the regulars here disagree with using Flow in this project on any way. Several proposals have been raised and all of them have failed, including that one. Your arguments looks more emotional than policy based. Having some support is not the same as having community support, and the true and real community of this site do not want this feature here, no matter how good the intentions of the people involved here are. Demanding explanations only for those who oppose but not to those who support as well subdues those set of users unfairly and mean that the opinion of those people should be given less weight. That's not how we work here. If they don't want to answer the questions they're in their right to do so and their opinions shouldn't be disregarded. I feel that my closure reflects the feelings of the Meta-Wiki community towards your proposal. I could have written a more complex, flourished statement, but the result would be the same: there's no consensus. I'm also not buying the argument of the Christmas hollydays. The section above shows pretty clearly that Meta-Wiki folks are still here and, moreover, a) that the closure was not innapropriate and, b) that reopening the discussion when 99% of the people of this project is against this feature would be a waste of our valuable time. I'd also appreciate if you could present evidence of your accusations towards me that I've acted in bad faith or I'll have to consider that as a personal attack. Thank you, —MarcoAurelio 19:16, 28 December 2016 (UTC) Currently your comment in the discussion you closed looks as if you provided an opinion in the discussion, and then closed it favoring the same way as your comment. That seems rather improper to me. Legoktm (talk) 08:32, 29 December 2016 (UTC) If you mean the last comment to the discussion above and the closure at the top, they're both closing comments. Please, assume good faith. Thanks. —MarcoAurelio 10:52, 29 December 2016 (UTC) Fortunately, the inactivity around this holiday is not a matter of debate. See https://quarry.wmflabs.org/query/15128 as evidence that there's currently a substantial activity drop around this time of year on meta. MarcoAurelio, can I ask you if you see me as a member of the Meta Community? How about Jtmorgan? Or Guillom? Surely my admin status means that I'm, to some extent, a member of the Meta community. I've been contributing here for years. The three of us have built most of the content in the Research namespace and we regularly bring new researchers and research to Meta. We are a legitimate subset of the Meta Community. Your comments imply otherwise. Also, I have not accused you of anything except improperly closing the discussion. I've said nothing about your intentions. --EpochFail (talk) 15:30, 29 December 2016 (UTC) Please don't go circling and presente evidence now on where I have acted in bad faith as you said ([...] bad faith summary) or strike it. I've been volunteering on Wikimedia sites for nearly 10 years and I've always had my best intentions on it. If you still think my closure is innapropriate you can challenge it to the other bureaucrats of the site. I still think that my closure reflects the feelings of the community, and the discussion above makes it quite clear if it was any doubt. Moreover, if the discussion was not ended, why Trizek (WMF) was so eager to convert that page into a Flow board on 19 December? Is there any interest of talking about that? —MarcoAurelio 15:45, 29 December 2016 (UTC) MarcoAurelio, I'm still not seeing where I have accused you of bad-faith. I was making a statement about the nature of your summary. As I said, a "good-faith summary of what took place in the discussion" would acknowledge all points argued. Saying that there was "no support" is obviously not true. What did you hope to achieve through saying that there was "no support"? For your other question, it seems that MZMcBride had noted on phabricator that "There's certainly not unanimous support for this request, but I think there's consensus to move forward." and after that, the change was made. I was under no impression that this conversation needed to be closed. --EpochFail (talk) 00:33, 30 December 2016 (UTC) Again, what's wrong with you? This is disgusting. Jesus, just drop the stick. Please stop assuming I have some sort of shadow interests in this subject. I'm "hoping" nothing. I read the entire discussion and took also the past precedents to conclude that there's no support to implement your proposal. My alleged improper closure has been confirmed below fwiw. In purity, the conversation was unilateraly closed by your team when you decided to convert that talk page into a Flow board obscurely via a Phabricator ticket. After that, there was no point in continuing the discussion. I'm not perfect but I think the improperness is not comming from me here. —MarcoAurelio 18:11, 31 December 2016 (UTC) MarcoAurelio A couple points of clarification. My team is Wikimedia Research. I sometimes collaborate with the mw:Collaboration team, but they are not "[my] team". I didn't file the phab task, enable Flow, or close the task. Also, please cease with your profanity and asking "what's wrong with [me]". I'd hope that you were "hoping" to accurately summarize a discussion that had clearly come to a conclusion so that we could archive and reference it later. That's a legitimate "hope" if not the only legitimate "hope". Please stop trying to imagine slights where none are intended. --EpochFail (talk) 20:01, 2 January 2017 (UTC) I don't understand why it's acceptable to ask that «those opposing state clearly how they will be negatively affected» by something. Are opinions now valid only if produced by personal interest? I thought we still had some superordinate goals and that the discussions were meant to find consensus on what's the common good; it's strange to read multiple people advocating for the elimination of altruism. I can certainly oppose something that will negatively affect others. Nemo 11:04, 29 December 2016 (UTC) Hey Nemo. I feel that those who supported the proposal have made their case quite clear. Can you give me a counter-example? At the very least, those who have shown support are gesturing towards the *proposal itself* which is a relatively clearly stated argument. On the other hand, I feel like those in opposition have not provided an argument from which to discuss. "I don't want it" or "It's bad" is not an argument that can be discussed. "This proposal failed before" is neither true nor an argument. (I'd withdrawn the proposal until the maintenance plan of Flow was clear and we could continue the discussion.) Regardless your altruism argument falls flat because the vast majority of those who would be directly affected by this change have signaled support for it (literally everyone but you). You still haven't even addressed the fact that Flow works better for newcomers because the only empirical evidence that we have makes that clear. You haven't addressed my direct experience working with external researchers on talk pages or even discussed the potential boon to our projects it would have if we could get them doing their research the Wikimedian way on Meta. If you'd give me some counter-arguments against the merit of the proposal, I'd address them rather than simply repeating my own. --EpochFail (talk) 15:30, 29 December 2016 (UTC) Now tell me if this is not some sort of harassment towards those who voted against the proposal the continuous and ad nauseam calls to justify themselves over and over. —MarcoAurelio 15:47, 29 December 2016 (UTC) Just catching up on this. I was surprised that a proposal to ban Flow always-and-forever from MetaWiki was opened on Christmas eve, and then closed four days later. And that the closing admin justified their closure with the argument that "Meta-Wiki folks are still here" and "99% of the people in this project are against the feature". Furthermore although I have been working on this wiki for almost 6 years now, in both a volunteer and a staff capacity, I've been instructed not to participate in this discussion with my staff account. So apparently I am not a real member of the Meta community, as either a volunteer or a member of the staff? This baffles me. In any case, if the participants in this discussion wish to escalate this conversation to another forum, I'm open to participating there (assuming I'm allowed to). But I no longer have any confidence in the current process, and do not believe that further participation in this discussion is productive. Jtmorgan (talk) 20:51, 29 December 2016 (UTC) There is a misunderstanding: #Proposal to remove Flow on Meta-Wiki is not closed, although the harsh meta-comments have certainly succeeded in discouraging further participation. Nemo 21:03, 29 December 2016 (UTC) Nobody forbids you to comment, Jtmorgan. Not me, not anybody; but if you've been here for so long you'll remember that concerns have been expressed several times when staff accounts are used for non staff issues. Do as you wish, but if you think it's better for you not to participate it's your choice. What I ask anyone is that they comment and they let comment the others in a paceful and constructive way. It is not correct to constatly ask the voters to justify why they vote one way or another. That indeed discourages participation (and I'll say that it's forbidden from the wiki I came from, but that's another subject). That's all. And please if my language is unclear, say so, I'm just en-2. About the closure, no comments. I've clarified the closure of the other discussion above and I stand by it, as I did it in good faith and honestly believe that's the consensus from the participants here. Ironically, the discussion had no point in continuing since Trizek (WMF) enabled the Flow board on the page, which I've just noticed some hours ago. EpochFail says that the discussion didn't ended to challenge the closure. How funny, because then the enabling of the Flow on that page shouldn't have happened either. I'd hope this is not that the Flow team wishes to push this feature ignoring the communities, because then, maybe, we should be having a word with their bosses about this questionable behaviour. And as always, I'm willing to be corrected if I'm wrong, but I'm not going to tolerate being insulted as EpochFail did just because the result does not please him. —MarcoAurelio 21:28, 29 December 2016 (UTC) I did not intend to insult you, but rather to question the quality of your closing statement which is clearly an inaccurate representation of events. --EpochFail (talk) 00:43, 30 December 2016 (UTC) I appreciate your striking. And yes, while not intended, I felt insulted, not because you think my closure is wrong, to which you have the right to disagree, but because I feel that you thought and still think that I have some sort of shadow interests in this and that's not true. I'd prefer not to continue arguing over this. Thanks,—MarcoAurelio 18:11, 31 December 2016 (UTC) MarcoAurelio, this isn't an argument. This is a discussion. I don't think you have a shadow interest. But I do think you have been not been fair and I think you have made it clear that you do not feel as though I deserve fairness. I'm not the only person to observe that your closing summary is just a recapitulation of your personal opinion. Participating in a discussion in good-faith involves being willing to explain your position and being open to considering other people's positions. If your position is challenged, you should openly discuss the merits of the challenge. Closing a conversation in good-faith involves providing an accurate summary of discussion and weighing the arguments based on their qualities. If anything, editors with advanced rights like us should be held to a higher standard than other editors. You shouldn't just edit in good-faith, you should also clearly demonstrate good-faith. I think we can agree that your closing statement does not achieve a clear demonstration of good-faith. Maybe you'd like to edit it. --EpochFail (talk) 19:55, 2 January 2017 (UTC) I think MarcoAurelio's closure was quite correct. It is also very ridiculous how Research_talk:ORES_paper is now a flow page, despite the closure (and am I seeing correctly that it does not even support indentation of "replies"?!) --MF-W 00:19, 30 December 2016 (UTC)

Jeblads summary :D

Some point from me on pro and cons for Flow. And no, I don't want to discuss LiquidThreads. There is a lot of arguing whether Flow is an active project, and as far as it is available on Wikimedia-projects it is active. Someone claiming the project to be "bad" in some way, without substantiating the claim, does not hold as a valid claim, it is just an opinion. Then there is the evil conspiracy to take over Meta and turn it into a huge Flow-table. Nope, won't happen.

Pro

• Clearer reply structure, what do you actually reply to
• It is easy to insert remarks to previous replies (branch on necessity)
• Can use VE-style editing, yet wikitechies can use their wikiweirdietexties
• Permanent link is truly permanent compared to fragment links to sections
• Rant can easily be hidden
• Threads can be summarized
• Voting on replies are possible, even if not implemented (mumble)
• Reusing thread on different pages, even if not yet implemented (2xmumble)

Cons

• If you disagree with the last reply it is not clear how you make this visible
• Lot of whitespace (is this a valid functional point?)
• Can make confusing wikitext (user links etc.)
• Not obvious how to show in wide layout (you remove the rightmost column to make another wider)
• Permanent link is gibberish (can this be readable for first entry with a given title?)
• A thread can not easily be read in full, ie. you do it by opening the permanent link
• Some oldtimers does not get it how they switch between edit modes (perhaps because the symbols doesn't appear clickable [Oh, they are blue now!])
• Special chars not available (not sure if this is a Flow-problem)
• People like to "pin" badges on the discussion page, and it is not obvious how to do that

I can't really see any good arguments for not using Flow on a single page, but I can see room for improvements of the extension as such. — Jeblad 08:48, 24 December 2016 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Proposal to remove Flow on Meta-Wiki

Tracked in Phabricator:
Task T63729

Discussion

Given that enwiki has been allowed to opt-out and that several attempts to get this enabled here have failed in all fashions (Flow in all talk pages, then in a namespace, then as beta feature on talk pages and now on a single page), I think that it is time to end this recurring discussion and decide if we want to opt-out from this feature entirely. Thanks. —MarcoAurelio 16:23, 24 December 2016 (UTC)

•  Support due to no community consensus to use it here and repeated failed attempts to enable it. —MarcoAurelio 16:25, 24 December 2016 (UTC)
  • MarcoAurelio, there's consensus among the community of people who primarily contribute to the Research namespace to have it enabled there. Why do you neglect to acknowledge us? --EpochFail (talk) 18:20, 31 December 2016 (UTC)
  • I should point out too that there have not been repeated failed attempts to enable Flow. I don't know about anything before the RFC I filed last year, but that RFC didn't fail, it was withdrawn due to the unclear state of Flow maintenance. This new proposal was made and was assessed by an independent Meta-pedian as successful before Marco improperly closed it. It's absurd to call this "Past failed attempts". --EpochFail (talk) 15:56, 3 January 2017 (UTC)
•  Support, was enabled abusively. Nemo 18:37, 24 December 2016 (UTC)
  • Nemo_bis, what do you mean by abuse? Who is the abuser and the abused? Please make your accusation clear. --EpochFail (talk) 15:58, 3 January 2017 (UTC)
•  Support yep please. Using flow on meta is not a good idea for me. --Ks-M9 ^[disc.] 22:02, 24 December 2016 (UTC).
  • Hi Ks-M9. Per the proposal above, those of us who work on research documents and do outreach to bring in research professionals see flow as a clear improvement over talk pages. Why do you think that our judgement is wrong here? --EpochFail (talk) 15:52, 3 January 2017 (UTC)
•  Support per above. --Steinsplitter (talk) 09:02, 26 December 2016 (UTC)
  • Hi Steinsplitter, per which comment above? It's important to know what argument you are supporting. --EpochFail (talk) 15:56, 3 January 2017 (UTC)
•  Support - seriously, just LET IT GO!, it was possibly one of the worst waste of WMF money ever. They should have renamed it to 'Totally Flawed'--Stemoc 09:20, 26 December 2016 (UTC)
  • Hi Stemoc, what does the economics around Flow have to do with the proposal here? Can you make it clear why you think no one should be allowed to use Flow on Meta? --EpochFail (talk) 15:59, 3 January 2017 (UTC)
•  Support This totally useless, non inclusive to people who use old computers, have a bad internet connection and old browsers, need to go.--AldNonymous^Bicara? 11:13, 26 December 2016 (UTC)
  • Aldnonymous, I think you might be mistakenly thinking of LiquidThreads. Flow is fast and efficient. LiquidThreads was not. --EpochFail (talk) 16:02, 3 January 2017 (UTC)
    • Surely you must be joking, right?, EpochFail, why do you think I'm supporting this removal? Because I already experienced it, while obviously you don't.--AldNonymous^Bicara? 20:15, 3 January 2017 (UTC)
•  Support per above. Defender (talk) 15:35, 26 December 2016 (UTC)
  • Hi Defender. Per which comment? It's important to know what argument you are supporting. --EpochFail (talk) 16:03, 3 January 2017 (UTC)
•  Support definately. —Ah3kal (talk) 17:08, 26 December 2016 (UTC)
•  Support per above. KPFC 💬 17:55, 26 December 2016 (UTC)
•  Oppose Agree it needs work but we need to be looking at new tech to engage new editors, not just throwing out every attempt. When wikis started they were more intuitive to use than regular ways of designing webpages, now they are significantly less so, and that needs to be fixed. – Ajraddatz (talk) 18:08, 26 December 2016 (UTC)
  • Hi Ajraddatz. If I were buying a car, I think it would be reasonable to assess and judge its manufacturer. I would say the same is true when picking/evaluating software. When I see tasks such as phabricator:T130470, I don't think the Wikimedia Foundation is acting in good faith or should be trusted to be a responsible party. In the face of failure, there's no accountability or introspection or any of the other actions that might mitigate future mistakes. Why allow another bad software deployment to run its course here? It took years for the LiquidThreads mess to be cleaned up. I completely agree that we need a better discussion system, but I have very little confidence that the Wikimedia Foundation can deliver on this. Do your experiences suggest otherwise? --MZMcBride (talk) 07:34, 3 January 2017 (UTC)
    • Yes. I use flow on my Wikidata talk page, and it works quite nicely. Obviously it isn't perfect, and my talk page doesn't get too many messages (sad reacts only please), but I think it lowers the barrier to participation and works for smaller scale discussions. Obviously, this discussion using flow would be an absolute nightmare - I don't think it should be widely deployed. But it seems to work well in small discussions, and my day-to-day wikilife isn't impacted at all if this group wants to use it on their one page. As to confidence in the WMF, I've been on Wikia when they were trying to get a similar system working, and I think it is very hard to get right. But once the Wikia system was implemented, which everyone said would be the Worst Thing Ever (TM), it started being widely used and ultimately lowered the barrier for participation. So maybe, a modified version of flow can do that here too. And one final point: Vogone seems to insinuate below that I support the implementation of flow regardless of consensus. I said no such thing, and am merely a community member here expressing my own opinion on the subject. – Ajraddatz (talk) 10:23, 3 January 2017 (UTC)
      • I think you got my comment wrong, what I meant is that this proposal here is a reaction to several failed attempts which have shown that the meta community largely does not want to have experimental software, specifically flow, enabled here. Opposing in this section and repeating arguments from the section above will not cause the community as a whole to change their minds, but only prolong these messy discussions. This is where I disagree with you. I am not against "new tech to engage new editors" per se either, but I — and so do apparently many others — do not think flow is the right tool for this. This overall community assessment, no matter if "right" or "wrong", is a reality, as it can be clearly seen on this page. --Vogone (talk) 11:21, 3 January 2017 (UTC)
•  Support - Ugh... this again. WMF needs to stop raising the barrier for everyone to contribute and let the existing systems work. ~ Matthewrbowker ^{Drop me a note} 18:11, 26 December 2016 (UTC)

  Did you read the discussion above? It's about using Flow to *lower* the barrier for new contributors. Legoktm (talk) 08:42, 29 December 2016 (UTC)

  Yes, and I disagree with it. I find flow very difficult to use, when it does work. In fact, your argument about "lowering the barrier" is the same one presented when Visual Editor was forced onto wikis, with roughly the same result (note: My three tries with visual editor resulted in in two "undefined error" and one lost save). Trying to find something on mw.org involves trying to remember a random ID. And invariably, the reply button is disabled or non-existant. ~ Matthewrbowker ^{Drop me a note} 20:02, 30 December 2016 (UTC)

  Matthewrbowker, our user studies suggest that Flow is much easier for new editors. This is a robust study employed using the scientific method, so should not be refuted with anecdotes, but maybe you have concerns about the methodology? But if we're using anecdotes, I work with researchers who are new to operating publicly on wikis all of the time and they struggle with using talk pages, but not flow. At this point, I've trained ~60 people how to use talk pages and they always ask me why we're using such a cumbersome system. They just *get it* when they arrive because they're already familiar with that type of discussion system. Could you maybe be judging flow for some earlier development state? I've had no such problems with Flow. --EpochFail (talk) 16:34, 3 January 2017 (UTC)

  I am speaking from experience here. Flow has no reply button visible, the only way I can make one appear is to disable Javascript. I also have a pad next to my computer to write down topics I'd like to look at again. A scientific study (from 2014!) is not enough to refute my own experience, nor is it enough to change my !vote.

  You speak of nebulous "researchers" multiple times throughout this thread. Yet none of them have bothered to show up and defend Flow. My impression is: they really don't care. You can welcome them of course, I'm quite willing to properly format their comments should they choose to make some. But considering you forcefully created a Flow board dispute community consensus, I can't invite them personally. ~ Matthewrbowker ^{Drop me a note} 17:44, 4 January 2017 (UTC)

  Just a note that I've modified my comments above. For the first time, I found a reply button on Research talk:ORES paper, I suspect I had an addon out of place. I will also invite the researchers to participate in this discussion, unless anybody objects. ~ Matthewrbowker ^{Drop me a note} 04:37, 7 January 2017 (UTC)

•  Support per above. --Az1568 (talk) 19:45, 26 December 2016 (UTC)
•  Support per above. -- Freddy2001 ^talk 20:18, 26 December 2016 (UTC)
• Support Considering all attempts (enable flow everywhere, in research only, on a single page, as described by MarcoAurelio above) to introduce this feature have failed, this here is the only logical consequence. I couldn't agree less with Ajraddatz that we should be introducing features the community has rejected, especially features where no major further rollouts are planned in the future, just to feel more "modern". Especially on meta, "engaging new editors" is not really the top priority … --Vogone (talk) 21:09, 26 December 2016 (UTC)

  Vogone, Are you aware that a substantial sub-community of meta is fully in support of using Flow? In our work in the Research namespace, engaging new editors is one of our top priorities. We want Researchers who study our wikis/communities to work and publish on wikis too. And it's working! We've made substantial progress in the last 6 years. Please allow us a little bit of a benefit of a doubt when it comes to telling you what we need to pull professional researchers & scientists towards the wiki! --EpochFail (talk) 18:26, 31 December 2016 (UTC)

•  Support. While I do agree with Ajraddatz's statemenent that we need new editors engagement, the kind of editors we need on Meta is somewhat high tiered in terms of wiki skills. E.g. we need translators who would not mess up, we need translate admins who must learn a deal of extra wikimark-up plus crazy use cases for it, we need admins who know how to admin, we need people writing grant proposals who can deal with all those complex tables and whatever what is now part of the pages' layout, we need people creating and expanding pages about some projects, either outreachish (but who know about outreachwiki) or onwiki — that all needs good wikimark-up knowledge, as does drafting posts for blog and well I guess writing research materials. I am not talking about being parser functions guru for the latter ones, but article-level wikicode is a must, IMHO. I actually struggle to find a real example of where we would need a complete noob showing up. Perhaps research namespace is indeed the most truth-like example, but come on, the guys go to research Wikimedia and cannot learn the language Wikimedians are using? Sounds a bit fraudish with all the due respect(, just in case I have absolutely no intentions to offend someone or anyone). With all that being said is it such a problem to count the number of colons and indent your post with one more? There are some CSS techniques for those who struggle to understand which reply is to which comment, and that's probably the only real problem appearing here. Does Flow solve anything? I highly doubt it. Actually LT was better, in my opinion, since we are mentioning it here. But they both are too raw and the only place where their pros beat cons is the Wikinews Comments namespace. With current status of Flow it is also clear that those gibberish topic names and all the rest of problems are either never or almost never going to be solved, and while helping some theoretical not able to submerge into wikicode newbies it will make a hell of an experience for admins and experienced users. Come on, I actually loathe using talk pages on Mediawiki.org now, since it implies waiting forever till the page loads and then having to find how the heck to reply in the way you want. So please do not spread this thing any further, and it is past time for its roots to be plucked. --Base (talk) 00:21, 28 December 2016 (UTC)

  I actually struggle to find a real example of where we would need a complete noob showing up. That's just wrong. You interpret a "complete noob" as someone who is entirely clueless. In this case, wikitext discussions are holding back people who are fully competent in their own respective fields, and are struggling with wikitext. We WANT their contributions. Legoktm (talk) 08:40, 29 December 2016 (UTC)

  Entirely clueless about wiki to be precise. Basic knowledge of wikitext is something which is within the baremost minimum, IMO. I also believe that knowing that minimum is also a prerequisite to research wiki. Just as if you research China it looks logical to at least have a clue about the language, even if you are a culture researcher and not a linguist. I am not talking about some even slightly advanced wiki stuff, I emphasise on this. Besides the respective field in question in the case of ORES is probably AI. Now come on, that high tech thing is easy for them while some silly mark-up is not? I might believe that psychology or other humanities specialists would struggle first 30 minutes of experience but not those guys… What we have now is some theoretical people struggling with wikicode on the one hand and on the other hand existing editors me including who just cannot work in Flow. Even though I like theories in general… --Base (talk) 12:26, 29 December 2016 (UTC)

  Ahh yes, but we need people who are much more clued into social science, statistics, and machine learning to work on the Wiki. Very often, they are not that tuned into any particular wiki process that is not part of their immediate research activities. FWIW, I do not find that this group struggles with Wikitext at all. That's not the problem. The whole dynamic of editing pages in order to have a conversation *exists nowhere else on the internet* so it's a big barrier. You want Researchers to be more in tune with Wiki processes? So do I. But I don't think that the barrier to entry of talk pages is an important one that we get value out of maintaining. In my work pulling researchers to discuss their activities on wiki (that I've been doing for more than 10 years, 6 here on meta) I've found that Flow is a great solution to a problem that we have. Why do you think my judgement is wrong in this case? --EpochFail (talk) 18:31, 31 December 2016 (UTC)

•  Support per above —JuniorX2 ^Chat_Hello! 00:38, 28 December 2016 (UTC)
• Someone sang - let it go. (If this isn't obvious,  Support.) — regards, Revi 05:36, 29 December 2016 (UTC)
• This entire discussion is ridiculous. I'm trying to figure out how everyone participating in this discussion is negatively affected by the existence of Research talk:ORES paper and I can't. It's mostly just "I don't approve, so they can't get their work done". And that's disappointing to me, since I'd much rather encourage people to hold their discussions in public on our normal wikis. Legoktm (talk) 08:40, 29 December 2016 (UTC)
  • Well, for one, I'm interested in Research:ORES paper, but I'm now unable to participate in its talk page. Some people have expressed their concerns about Flow and their fears that disabling the extension completely is the only way to prevent its future expansion; this opinion might feel harsh, but it doesn't look ridiculous or irrational to me. Nemo 10:37, 29 December 2016 (UTC)
    • I'm astonished to learn that even with opposition to this proposal the page was converted to Flow nonetheless. What a blatant abuse, yet again. —MarcoAurelio 10:53, 29 December 2016 (UTC)
  • This section is not about Research_talk:ORES_paper; it is about the whole of Meta. --MF-W 00:23, 30 December 2016 (UTC)
    • MF-Warburg, obviously this is related to Research_talk:ORES_paper and is intended to prevent the use of flow on that page as well as other spaces. --EpochFail (talk) 18:34, 31 December 2016 (UTC)
•  Support: I'm sympathetic to the argument that Flow will be isolated to a specific talk page, but Flow is dead software. The deactivation of the extension on the English Wikipedia is very strong evidence of this, in my opinion. Myself and others tried repeatedly to tell people to not use Meta-Wiki as a test area for experimental software and those concerns were ignored. The natural consequence of this—a sharp rebuke of the extension—is pretty predictable.

  The biggest issue I have with Flow is that very few people seem to want it. Maybe Legoktm or EpochFail or someone else can explain why Flow is in such a state that users are not saying "when will my home wiki be next to get this great tool?!" What's sad to me is not that there's a discussion to disable Flow on Meta-Wiki with strong support. As I said, I think this response was easy to see coming. What's truly sad to me is that as we enter 2017, we still have a pretty horrible discussion system and no viable alternatives. Trying to blame or shame users to accept Flow is the absolute wrong approach. In my mind, if users aren't looking at the software and saying "oooh, I want that today," then the problem lies with the software. We've seen time and again new features introduced to the wikis without objection and sometimes with fanfare and joy. The problem is not change, the problem is that people have tried and then really disliked using Flow. Make something that people want to use. Build a carrot, not a stick. I don't know how many other ways I can say this or how many times we have to go through a failed software development process before this lesson takes hold. --MZMcBride (talk) 02:54, 31 December 2016 (UTC)

  • Ahem.. Why is it that the community of people who build and maintain the Research namespace on meta is not considered a valid community? We've been waiting for Flow. We want it today. I use Flow on other wikis and I really prefer it. We have clear evidence that our external collaborators prefer it. Why is this not taken into account? This proposal isn't about prevent Flow from being force onto anyone. It's about preventing a legitimate community from being able to use it at all. We want it! Let us have it! It won't affect you. --EpochFail (talk) 18:09, 31 December 2016 (UTC)
    • Hi EpochFail. I really do mean it when I say that I sympathize with you. While it would be more disconnected and I'm generally a big advocate of not doing this, you may want your own wiki. Either research.wikimedia.org or rcom.wikimedia.org or whatever, or you could make it separate from Wikimedia wikis and really do your own thing there.

      The most direct answer to your question about why your view isn't taken into account is that decisions are made by those who show up, both on-wiki and off-wiki. You're a numbers guy, you can easily count the supports and opposes in this section and see what's going on.

      Being part of the Meta-Wiki community and being part of meta.wikimedia.org means finding a way for your sub-community to grow and thrive within the larger Meta-Wiki ecosystem. You want to have it both ways, being hosted here, but also free to install and use experimental software. I want to have it both ways as well, with you and other researchers contributing to Meta-Wiki, but without the experimental software. And so we find ourselves at an impasse.

      Both in the wiki world and in the real world, it's not possible to be totally isolated like you want to be. I think Flow has garnered enough of a poor reputation that it will bother people just to see evidence of Flow being installed and used in common areas such as Special:RecentChanges. It might also help (y)our understanding to not just view Flow on Meta-Wiki in a vacuum: part of the opposition to Flow comes from seeing how both Flow and its predecessor LiquidThreads failed. There's emotional baggage here for many people, plus regulars on Meta-Wiki (myself, you, others in this section) are used to wikitext discussion, as awful as it is. Perhaps you're not giving enough credit to researchers and their ability to figure out how to respond with wikitext. It's not elegant or ideal or even really intended, but wikitext discussion does actually work. :-) --MZMcBride (talk) 19:26, 31 December 2016 (UTC)

      • I'd be lying if I said it didn't cross my mind to find a new Wiki to call home. I think that technical reports about Wikimedia stuff belongs on the wiki that's about Wikimedia stuff. I don't think that we Researchy folk need to be welcomed by any core community in order to participate legitimately. We've had more cross-over from people in the Research namespace contributing to other parts of Meta than old Meta-pedians contributing in the Research namespace, but that's OK. Many of our contributors come from other wiki communities -- which is another good reason for being on Meta. I responded in 16199752 re. vote counts. TL;DR: I think that we can and must do better than counting votes.
      • Also, you know that you can use Wikitext in Flow, right? That's what I do. I'm an old enough Wikipedian to use wikitext 100% of the time. But seriously, the reasons I want to use Flow isn't to avoid Wikitext. By having structured conversations you can get better notifications and it's easier to not lose your place in a big conversation (like this one... ugh.) when previewing your message. Also, it's obvious how to operate when you arrive. Professionals scare away from volunteer work really easily, but a little wikitext scares them way less than a giant discussion page when you hit "edit". --EpochFail (talk) 19:13, 1 January 2017 (UTC)
        • User:Alsee may be able to provide you some examples of Flow mangling wikitext. (Sorry for the casual invocation, Alsee.) BethNaught (talk) 20:34, 3 January 2017 (UTC)
•  Oppose I don't understand how people need to push back on proposals that won't affect them. The community of people who want to use Flow in the Research namespace are the only people who would be affected by enabling it. We've all shown support here and in the past. I take full responsibility for making sure that patrolling happens. It's only people who do not operate in the Research namespace who have voted in opposition (with the exception of Nemo who fully admits an ideological stance against using the software). In my view, this whole discussion is absurd. I can't believe that others find it so comfortable to minimize the point of view of others -- to vote something down because they have some weird agenda against the WMF. This has nothing to do with the Wikimedia Foundation and everything to do with making our volunteer work easier. Everyone who works with us wants Flow. What other legitimate points of debate are there? --EpochFail (talk) 18:18, 31 December 2016 (UTC)
  • Why are you assuming that everyone is a rational and logical actor? Has it ever been your experience on-wiki or off-wiki that people regularly act in this way? The news reminds us daily that people often act in foolish ways and in ways that are against their own interests. Lashing out at this reality is futile. Instead, you have to convince enough people that your way is a better way. This isn't a community of robots or developers, it's a community of weird wiki people from around the world. All people come with biases and insecurities and grievances and other baggage, but their vote/voice counts just as much as yours, for better or worse. So if you want to find consensus to try out experimental software here, you need to convince enough other people here that doing so is a good idea. Flow, in its current state, doesn't seem to convince enough people.

    I completely agree with you that there's a lot of anti-Wikimedia Foundation sentiment in discussions about Flow. It's plain to see in many comments. However, even if this sentiment is unfair/unfounded/irrelevant, when evaluating a piece of software, it's often very relevant to know who's writing and maintaining the software. Flow was a project of the Wikimedia Foundation and its current development status is relevant in deciding whether to continue to expand its use on any Wikimedia wiki. --MZMcBride (talk) 19:39, 31 December 2016 (UTC)

    • MZMcBride OK. Fair points all around. But I believe we can be better than that. Isn't acting logically and rationally during disagreement a big reason why Wikipedia's been so successful? On English Wikipedia, "Consensus is ascertained by the quality of the arguments given on the various sides of an issue, as viewed through the lens of Wikipedia policy." Of course, this proposal is not in or about English Wikipedia, but I think there's a lot of wisdom in expecting discussion participants to justify their positions. Can't we all present our best arguments for and against and see which arguments are effectively challenged and which ones are not? I don't know any Meta policies that are in question with regards to using Flow, so maybe we should have a discussion about which lenses are most useful and then apply our best arguments. I see bringing newcomers to the Wiki/open practices from professional (and generally pay-walled) research settings as a clear application of Wikimedian values (and of course anyone who knows me will be familiar with my rants), so I want to talk about Flow through that lens. I've heard some discussions of software quality but I feel like they have been addressed to the extent required for the minimal proposal made, but I'm open to the idea that that part of the conversation isn't done yet. I really appreciate Legoktm and Matthew chiming in to help clarify technical points. I think they'd be invaluable if we *do* want to continue discussing software quality & maintenance. Anyway, think we owe it to each other (and the rest of humanity) to weigh arguments when we find that we disagree. It's our best chance at working together effectively. --EpochFail (talk) 18:56, 1 January 2017 (UTC)
•  Support per above. --Atcovi (Talk - Contribs) 19:03, 31 December 2016 (UTC)
• Comment There appears to already be a task open to remove Flow from Meta... opened 2 years ago: T63729. If anyone is interested, here are currently open Flow tasks (there are 1098), and here are Flow tasks with no owner (there are 1049). ~ Matthewrbowker ^{Drop me a note} 20:41, 31 December 2016 (UTC)
•  Support per all the criticisms which have been levelled at Flow in the past, at w:en:Wikipedia talk:Flow, w:en:User talk:BethNaught/Draft Flow RfC, s:en:Wikisource talk:Scriptorium (by me) and so on. The WMF should be aware of these problems but is still sticking its fingers in its ears and asking for blockers, refusing to admit that it is possible for Flow not to be considered a good thing by some wikis. Hell, the Enwiki opt-out only happened because of Alsee's persistence in knocking it into the relevant WMF staffer's brain, at the draft RfC, that a user revolt was coming and that they would lose. We need to take a stand and make it clear that we don't want deeply flawed experimental software messing up our wikis. BethNaught (talk) 23:29, 31 December 2016 (UTC)
• Strong oppose. I'd like to get some coherence to user talk pages and allow users to opt in using Flow on every wiki they use, instead of have a mix of Flow / non Flow pages. Then, projects could be able to opt in for Flow, as demonstrated above. --Dereckson (talk) 03:58, 1 January 2017 (UTC)
• Support. Flow is dead in the water. At this point, every installation of it is a liability, both in terms of functional maintenance and as an attack surface for malicious hackers. — Scott • talk 12:26, 1 January 2017 (UTC)
•  Support, an oppose just prolongs the inevitable and makes a bigger mess to clean up on that day. --Rschen7754 22:45, 2 January 2017 (UTC)
•  Support --Krd 15:56, 3 January 2017 (UTC)
•  Support the only sane answer. User:Scott sums up my position perfectly. ^demon (talk) 18:45, 3 January 2017 (UTC)
•  Oppose It seems like people have this weird notion of "the only solution is the old crappy solution". We do need a better discussion system, and opposing all attempts to move forward is pretty childish. If you believe something is wrong with Flow, then take the time to write down what you believe is wrong, and test out your hypothesis, both by doing what you claim is wrong and trying out what you think is right as far as possible. Usually you are not right, but those that made Flow. Yes there are bugs and errors in Flow, no it is not that many. — Jeblad 20:36, 3 January 2017 (UTC)
•  Support per above. Meta is not a testwiki. I have no grudge against the foundation, but I do feel this extension is overcomplicated and lacks compatibility with normal wiki-editing. It would encounter far less resistance, IMO, if, just as VisualEditor (which I personally believe to be a success even though I don't use it), it would maintain the wikicode editing option while also allowing users with less knowledge of wikis to comment on the talk page. Flow is an attemt to reinvent the wheel while forcing everyone who's been used to the usual wheels to use a system of magnetic levitation. Savh^ñ 21:59, 3 January 2017 (UTC)

  Thanks for this comment, I was already considering to leave a very similar one somewhere in this discussion. --Vogone (talk) 22:05, 3 January 2017 (UTC)

•  Support. I see Qgil-WMF requested "actionable blockers". Fully addressing that would take multiple pages. But ok, I'll play along and toss out a few. But since I'm "playing" along, I'll indulge myself a bit. I got Flow uninstalled from Enwiki via a nice quiet friendly collaboration with WMF staff. We all agreed what the outcome of the RFC would be, so there was really no point to running the RFC. And we agreed that running that RFC would just result in in pointless heat as Flow got flamed, and that some of that heat would spill over against the WMF. I normally avoid the flamethrower, but I'll let a little toastiness slip in here.
  1. The lead designer of Flow (who is no longer with the WMF) was told by a multitude of editors that proper wikitext support was an absolute non-negotiable requirement for any wiki discussion system. A multitude of editors told him that Flow was never going to be successfully deployed without proper wikitext support. Some of them warned of dire consequences if the WMF ever tried to force out something like that. Seriously... who would even think of building a wiki discussion system without wikitext support? Him. A WMF staff member who despised wikitext so much that he flat out told us "I would dearly love to kill off Wikitext".[2] Well, not just him. Him and the support of a WMF establishment who agreed with him. A WMF establishment, who to this day, still occasionally advocate a long-term goal of sabotaging wikitext on article-pages in the same that manner wikitext is sabotaged in Flow. The lead designer clearly got tired of hearing everyone say proper wikitext support was absolutely necessary, and having to blow off person after person after person. He said we should just achieve "Zen acceptance" of the fact that the WMF was going to replace talk pages, and that he was not going to provide wikitext. The Zen Acceptance quip sounds to me a lot like "Shut up, we don't give a damn what you have to say, and there's not a damn thing you can do about it". Then he went ahead and built a Flow that literally can't save wikitext!!! Later, a wikitext-simulator was grafted onto Flow. I happen to be a programmer, and as a programmer I'm saying that grafting a wikitext-simulator onto Flow was an utterly unholy hack. It resulted in a pathologically complex mess riddled with bugs, a mess which has cost untold programmer-hours and wasted untold donor-dollars trying fix things that never should have broken in the first place.

     How Flow works: You can type in wikitext. When you click to preview or save, Flow literally throws away your wikitext. It translates it to something else. When you're done previewing, or if you saved and try to edit it again, Flow gives you a new wikitext box. And it fills that wikitext box with new, fictional wikitext. It has to invent new wikitext because it threw away the original wikitext. That new wikitext usually resembles your original wikitext. Or it may give you slightly mangled wikitext. Or it may give you completely broken wikitext. I've got a text file filled with examples that I've been collecting. I'll give you the example the Flow dev's probably hate the most. A bit of perfectly valid wikitext that makes Flow fail spectacularly:

     {{#if:redflag|<span style="color:red;|<span style="}} font-weight: bold">This text is Red.</span>

     Copy that. Go to Flow. Paste it into the fake-wikitext mode. Click save. Flow chokes and spews broken raw wikitext onto the screen. That's your comment. Now click to re-edit your comment. Check the wikitext it gives you back... it's wrong and broken. Flow choked and just threw away random chunks of the wikitext you entered. So Flow chokes on valid wikitext, and when you try to re-edit a comment, Flow can give you back corrupt wikitext. Why? Because Flow literally can't save wikitext. Any time you type in wikitext, Flow throws it away. Any time Flow shows you wikitext, you're looking at fictional wikitext. And there are staff at the WMF who think this is a great idea. Staff who hope, in the long term, to make articles work like this. Every time you hear the WMF promise that they would never considering removing wikitext editing of articles... remember that that THIS is what they mean by "keeping wikitext editing of articles". They mean they might replace article-wikitext with this dysfunctional simulation of wikitext editing.

     Remember when I said this was an unholy hack that breaks things that never should have broken in the first place? Well, Flow manages to break the braindead-simple revert button. You undo an edit and the comment goes back to what it was before. Right? Well, in Flow, reverting the last edit can BREAK the content that was there before. That's impressive... that is an absolutely breathtaking level of Fail. They managed to break the undo button.

     I've got another example where Flow manages to display entire paragraphs in the wrong order. Save it in an article and you get paragraphs 1 2 3. Save it in Flow and your comment will display as paragraphs 2 3 1. Neat.

     I've got another example where Flow creates a tumor in the wikitext. Each time you preview, or each time you save and re-edit the comment, Flow adds garbage to the tumor. Each time you preview or save, the tumor keeps getting bigger and bigger. If you save and edit 10 times, you'll get 40 characters of garbage in the middle of your wikitext. If you save and edit 100 times, you'll get 400 characters of garbage in the middle of your wikitext. If you click preview a 500 times, while also saving 500 times, you'll get 4000 characters of garbage in the middle of your wikitext. No one is going to edit a Flow comment a thousand times, but some people at the WMF want to do this to articles. Articles do get edited thousands of times. If no one cleans up the tumor, this phony-wikitext system would grow a tumor of tens of thousand of characters of garbage wikitext in the middle of the article.

     I've got tons more, but I'm sure I've made my point. Flow can't save wikitext, Flow has a broke-ass wikitext simulator with truly epic levels of Fail, and staff members who think fake-wikitext is a great idea constitute a potentially serious threat to Wikipedia.

     Dear Qgil-WMF: My first "actionable blocker" is that Flow needs to be rebuilt from the ground up so that (1) any article text pasted into Flow renders the SAME WAY that it did in the article, (2) Flow actually saves the wikitext that I type in, and (3) when I re-edit something, it gives me back the same wikitext that I typed in originally. That will fix a multitude of issues all at once. I'd like to offer a little reminder that countless editors effectively submitted this blocker to the lead designer three and a half years ago, before the Flow prototype was even built.

  2. Blocker #2 is an easy one. Right click the reply link to open in a new tab. (Some people, like me, use right-click-new-tab a lot.) Write a nice big reply in the wikitext box. Now preview your comment. Oh wait.... it's impossible to preview because broke-ass Flow lost the button to switch to preview mode.
  3. Blocker: Everyone has been screaming for years about the excessive whitespace issue. A four page normal talk page discussion will scroll about ten pages tall in Flow. The WMF supports the design, citing research on whitespace and readability. I've read it. Wikipedia is not a chat board, and it's not a general webpage. Wikipedia is a workplace. If you try replacing your programmer's environment with this sort of whitespace factor you are going to have a lot of very angry programmers.
  4. Any sizable Flow discussion involving more than maybe three people rapidly turns into unreadable spaghetti. The threading model generates a confusing mix of top-posting and bottom-posting, and indentation totally craps out after just a few replies. On EnWiki we commonly have discussions with dozens of people, and sometimes over a hundred. I doubt that there is any automated threading algorithm that would really solve the issue. Complex discussions are inherently complex, and the thing that keeps complex discussions manageable is that we apply human intelligence to structure (and sometimes restructure) our discussions for clarity and intent. Blocker: Threading model that can do half as well as human intelligence, add support for refactoring a discussion.
  5. History page. Trying to view anything in the history yanks it entirely out of context. We actually need to see what the discussion looked like when that comment is posted. This is really important when we're investigating accusations and disputes and misbehavior. To understand what someone did, to understand their intent, we need to see the discussion as they saw it when they made the edit.
  6. Talk page archives ain't great, but infinitely-scrolling-webpages are atrocious.
  7. Several of us engaged in extensive discussion of Flow with the former Executive Director, Lila Tretikov. I am not going even begin to bring all of that to here. I will simply QUOTE her response to those issues: "It is not clear if Flow could ever be/become a replacement for Talk in its current concept." Blocker: Abandon Flow's "current concept", per the former Executive Director's own conclusion. Grin.

  I'll stop now because this !vote is grossly overlong already. I see no prospect that Flow can be upgraded into a viable replacement for Talk pages. Once you've built a submarine you can't upgrade it into a helicopter. Strapping rockets onto a submarine trying to make it fly only makes the design even more broken. At that point it's cheaper and easier to just build a helicopter from scratch.

  In the EnWiki discussion, there was a shift in the topic of debate. The issue became "do we really need to uninstall the extension completely, or can we simply have zero Flow pages active?" The conclusion was to uninstall the extention completely. The reasons are security and stability. The Flow-code is still live in the system, even if zero pages have Flow active. Flow is an unusually large, complex, and invasive extention. It hooks into many other parts of the wiki software. Virtually any programmer can tell you that having a large unused chunk of code in your software pointlessly increases your security and stability risk. There are more places for bugs to hide, and there are more complex interactions that can trigger bugs. I know for a fact that there are security-critical Flow bugs listed on Phabricator because I stumbled across one. Security-critical bugs are hidden, so we can't see what they say. It is clear that Flow-pages are not going to be active here on Meta, so there's absolutely no reason this wiki should bear the added risk of leaving the extention installed. This risk is compounded by the fact that the WMF is interested in reviving development of major new Flow features. Every time new code is deployed there is a risk of new and undiscovered bugs. That is an inherent cost that comes along with any software development. However there is no reason for this wiki to bear that cost if we're not using Flow. Alsee (talk) 23:57, 3 January 2017 (UTC)

• Followup comment regarding security: I just came across this Flow bug on Phabricator. That bug is now fixed, however it well illustrates the security threat. As long as the Flow extention is installed, merely turning off the current Flow pages provides little defense against the threat. Even with zero active Flow pages, there are a multitude of ways that someone could try to create, access, or revive a Flow board or an individual Flow topic. At that point, the bug I linked would enable someone to type malicious script as the title of the topic. That's how simple the attack was, just type in a malicious title. Then they can add a ping to an admin, to a checkuser, to a bureaucrat, or to a steward. That person would get a notification. The moment they clicked that notification, the topic would load, the title would appear, and the script would execute. That script would execute with the authority of the admin, checkuser, bureaucrat, or steward. There is a technical term for this in the security field. The term is "bad". This particular bug has been fixed, but this kind of bug is why it is bad to leave a large complex extention installed when you're not using it. Alsee (talk) 16:13, 4 January 2017 (UTC)

 Support uninstalling Flow from Meta. I have not contributed to the Research pages yet but I might do that in the future, or to any other page for any reason. I have posted a couple of comments in flow pages in MediaWiki.org and I find it problematic because (among other things) you are not able to see or edit the full wikicode behind the page, it is not possible to navigate the history of changes across all the topics in the page, it is no possible to properly archive items removing them completely from the page, infinite scrolling makes it difficult to navigate, review, investigate and read old discussions and the section/topic links are unreadable IDs instead of proper section links. I find particularly agravating that if a page is converted to flow, users cannot contribute to it anymore using the regular wikicode editor. People should have that option regardless of the visual aparence of the page. --Lsanabria (talk) 18:18, 8 January 2017 (UTC) (Response moved here from another section, by Alsee (talk) 07:22, 10 January 2017 (UTC))

Other meta-comments

• Since this is a request for a site configuration change, please let me test here the Technical Collaboration Guideline (a draft welcoming your feedback). The recommendation for community decisions is to submit blockers in order to identify the specific problems of a software product. This would allow the Flow project / the Wikimedia Foundation Collaboration team to have actionable items to discuss and work for. If you want to proceed with this request, could you identify these blockers, please?--Qgil-WMF (talk) 09:39, 29 December 2016 (UTC)
  • The blockers have been expressed on mw:Talk:Flow and other relevant talk pages, for years now. Let's not pretend users never articulated their issues. Whoever at WMF is interested in understanding more can read the LQT and Flow reports (3975 and counting) and the various discussions, to understand what problems the users have. As for me, I articulated some of the hard blockers in my messages between December 2012 and February 2013 (don't ask me for direct links, I have no idea how to get something out of Flow archives), and they've never been solved; a Product Manager has then declared that it's too late to solve any of those design issues. Nemo 10:47, 29 December 2016 (UTC)
    • A proposal is being made to remove Flow from Meta. I think it is fair to ask the Meta community for the specific problems of the software that are considered blockers for its use in this wiki. If the Meta community is able to agree on specific blockers, then this proposal will be stronger and actionable. Different communities have different priorities. While some Wikimedia communities decide to keep Flow away for now (true), others want more of it as soon as possible (also true). Therefore, pointing generally to mediawiki.org talk pages, Phabricator projects or the feedback of one community member to a product manager years ago is not really useful to deduce what blockers motivate MarcoAurelio to make this proposal here today, and others to second it.--Qgil-WMF (talk) 08:14, 30 December 2016 (UTC)
      • It's also not useful to ask for volunteers to do more work for something they're not interested in. Nemo 09:07, 30 December 2016 (UTC)
        • If someone is proposing to remove a software product altogether, isn't it fair to ask what are the main problems of such software product? Agreeing on 1-5 blockers shouldn't be hard for a community agreeing that Flow is totally unfit for their wiki. Identifying specific blockers is also useful to have more productive conversations and to lead further development in some direction. Adoption is an indirect reason (users and communities adopt software or not based on specific factors). Adoption is analyzed better when users at large are actually free to adopt the software. This is not the situation in Meta, where enabling a single Flow page generates a harsh discussion. Other Wikimedia communities have been more open about trying Flow in real scenarios, getting a wider diversity of users to use Flow, and they are providing specific feedback about what needs to be fixed or improved first.--Qgil-WMF (talk) 10:35, 31 December 2016 (UTC)
          • Quim, please, don't start now demanding explanations about this. I think Nemo bis and all others before me and the 4 failed previous proposals have said why they don't want Flow on Meta, but it seems you've decided to ignore it and go forward. I do not think that's okay. I am sorry if this frustrates the Flow team. Rather to ask for explanations for removing an experimental software, I think it'd have been rather more productive to ask for opinions before enabling it everywhere, and on Meta specifically. Bon Nadal i Any proper. —MarcoAurelio 12:25, 31 December 2016 (UTC)
            • MarcoAurelio and others. I am well aware of the past, I was also there. My motivation to use the Technical Collaboration Guideline here was to have a productive and forward-looking discussion about Flow, but maybe it is not the right time or place. This proposal is about not treating Meta as an early adopter of Flow. You say blockers must be found in previous discussions. I disagree with the reasoning but I understand it. The Flow survey results will be published this quarter. They will help identifying the major problems expressed by users and they will also help the Flow team defining a plan for next steps. Something that I still don't understand is why Flow cannot even be enabled in a Meta namespace that has a specific audience and a specific purpose, and is asking for it. Meta is a community of communities, a place for all Wikimedians. I can understand that some people don't want to see Flow boards popping up in unexpected places for unclear reasons. But... is it possible that pushing out Flow regardless of the plea of one of these self-contained communities (and inviting them to find a new home if they don't like the decision) is pushing intransigence beyond consensus?--Qgil-WMF (talk) 11:17, 2 January 2017 (UTC)

• • Hi Qgil-WMF. I think, in some ways, the Meta-Wiki community is indicating that it does not wish to be subjected to test/beta/experimental software. Countering this indication by pointing to a test/beta/experimental guideline seems to miss the point.

    If you're interested in getting additional feedback about Flow's flaws, perhaps you could start by getting the previous survey data released? Looking at phabricator:T144730, it seems that a survey about Flow took place in September 2016 and the results of this survey still have not been published over three months later. Before you ask volunteers to spend additional time providing feedback about Flow, why not respect the time that they've already donated?

    In this vein, I think it's also important for you and others to acknowledge/recognize that most people are not here to be software guinea pigs. Some users are interested in testing out software and providing feedback, but that's not at all the primary reason that people contribute to Wikimedia wikis, nor do we want it to be. Our goal is to build free content and the constant attempts to push bad software on users (and then demand that they provide feedback about why the software is bad) is pretty aggravating and irritating to people who simply want to get work done in their limited volunteer time. --MZMcBride (talk) 14:44, 31 December 2016 (UTC)

  • Qgil-WMF: I hadn't intended to see in the New Year, but now I have I might as well tell you what I think of the TCG. Year after year the WMF has forced out disruptive and controversial software projects. In 2013, it took a community revolt on English Wikipedia for the rollout of VE, which (as I understand it) was ultimately revealed to have been rushed out in part due to financial grant terms, despite it causing significant damage. In 2014 controversy over Flow erupted. It took over a year of kicking and screaming for the WMF to concede that it wouldn't necessarily roll it out globally in the future, and yet more months before it was removed from enwiki, and even then only under threat of a serious flaming at RfC. In 2015 Gather was introduced to enwiki. In this case indeed, actionable blockers were proposed: collections could not be deleted, collections automatically used non-free content in violation of the EDP, the moderation system was very hard to use, and enwiki admins were being expected to patrol it with no benefit to serious contributors of content. Only one of these things was addressed. Complaints continued to be raised about the rest of the problems, but Moushira Elamrawy, the liasion for Gather, instead of understanding and passing on the gravity of these complaints, tried to pacify the community without taking any action about the problems. Eventually an RfC demanded Gather be removed. Then Toby Negrin needed a lot of convincing that yes, we actually meant it, and we wouldn't allow him to kick it into the long grass (link). Yes, the proposal looked reasonable on the face of it, but all trust had broken down.

  So here we are. Bugs and problems with Flow have been discussed at great length before, elsewhere. Do you see now how your demands for blockers at this stage are repugnant to me? For years the WMF has needed to be coerced into listening to community concerns on major software projects. Time after time, staffers have tried to avoid dealing with the issues. Now the TCG says that, to slow down a deployment, the community must declare actionable blockers. It doesn't allow for philosophical differences of opinion. It doesn't mention a community outright rejecting a feature. It's a codification of the existing uphill battle communties face when trying to get their fundamental, deep concerns heard about a project in progress. So please engage with the issue at hand—to Flow or not to Flow—instead of trying to obstruct the community's opinion by bureaucratic means using a draft document. BethNaught (talk) 00:26, 1 January 2017 (UTC)

  Hi BethNaught. Thank you for taking the time to share your comments and experiences. I find them insightful and useful, particularly to underscore that the decision to install or remove Flow on Meta-Wiki does not exist in a vacuum, as I've been trying to explain to EpochFail. Nemo just cross-referenced your comment with phabricator:T130470 ("Conduct a Gather extension postmortem"). I think this Phabricator Maniphest task is one of the saddest we have. It's very telling that trying to get the Wikimedia Foundation to engage in any kind of introspection or reflection after a failed deployment results in buck-passing and calls to simply "look forward." (cc: Jkatz, TNegrin) --MZMcBride (talk) 15:42, 1 January 2017 (UTC)

  Thanks for assuring me my comments were meaningful and not an ill-judged midnight ramble. I've copied them (mutatis mutandis) to the phab task and the TCG talk page on MediaWiki wiki. BethNaught (talk) 16:09, 1 January 2017 (UTC)

• • @Alsee: I'm not sure what point it is that you're trying to make; could you explain? Given that that bug is nearly a year old, is it that anything which had security bugs recently should not be deployed? You are aware that would also include MediaWiki core itself, right? (Note: I'm WMF staff, but I've never worked on Flow) --Dan Garry, Wikimedia Foundation (talk) 22:39, 4 January 2017 (UTC)
    • As far as I can see, Alsee is referring to deployed but unused extensions. MediaWiki core on the other hand is clearly being used here. --Vogone (talk) 23:07, 4 January 2017 (UTC)
    • Dan, it appears clear that Flow is not going to be in use here. So the two options to weigh are installed&unused vs uninstalled. I don't see any weight in favor of installed&unused. I know that the WMF often leaves other unused extentions installed. I'd suggest you consider uninstalling them as well. However Flow is of particular interest. It is unusually large, unusually complex, it has an unusually high entanglement with other parts of the system, and the WMF has indicated continued development. Seriously massive, seriously complex, and seriously invasive development work... such as the proposed Workflow design. A nasty workflow bug could hit any part of the system, or even take the entire wiki down. I'm not saying it's a high risk. I'm merely saying that the case for uninstalling outweighs the case for leaving it installed&unused.

    Oh... and I'll admit that uninstalling Flow does have nice side-effect. It sends a hard-to-ignore message bouncing around WMF conversations. A message that yes, we really do mean it. We honestly are not interested in Flow popping back a few months from now with a few new tweaks and bells and whistles. I see no prospect that Flow can be upgraded into a viable replacement for Talk pages. Every additional dev-hour invested into upgrading Flow is a dev-hour wasted on a ship that has already sunk. Those dev-hours are better spent on things we do want and need. Of course that is merely my opinion, but it seems that community consensus roughly coincides with my opinion. Alsee (talk) 01:42, 5 January 2017 (UTC)

    • • @Alsee: Thanks for the clarification! Deploying unmaintained or unused code is a best practice in the internet software industry for the reasons you've mentioned, so that makes sense. However, the Flow extension is actively maintained, and is also in-use as EpochFail notes that Flow used productively in the Research namespace. In summary, I find the basis presented for the undeployment here (that the extension is unused and will never be used) to be factually incorrect, so I cannot see an undeployment of the extension happening on that basis. As noted before, I'm not the product manager for Flow, so that's not my decision, but I am a product manager for other things (such as search) so hopefully the indication I can give is helpful. Now, regarding other unused extensions that are deployed here that you mentioned, if you could give me more information about those, such as the names of the extensions and the wikis that they're on, then I'd be happy to investigate for you and see what I can do about those. --Dan Garry, Wikimedia Foundation (talk) 02:00, 5 January 2017 (UTC)
        • Dan, I don't know which extentions are unused. Quiddity told[3] us some were unused. Regarding my comment about Flow being unused here, I was referring to after this proposal is resolved. The proposal is to remove Flow, and it's running 80-something percent support. I'm just making the case that any "remove" outcome here should be interpreted and implemented the same as happened at EnWiki. All Flow pages were deleted, then the unused extention was uninstalled. You can see on EnWiki's list of installed extentions[4] that there's no Flow. Alsee (talk) 06:18, 5 January 2017 (UTC)

• After talking with the Collaboration team and the Community Liaisons, we have agreed that our best position here is not to interfere with this discussion or its resolution. The principle is that Wikimedia communities may decide whether they want to be early adopters of Flow or not. When I suggested to test the Technical Collaboration Guideline here and identify specific blockers for Flow in Meta, I did it with the best of my intentions. This caused more stress, and I apologize. The reactions here show that it is better to focus on polishing the TCG, and test it first with new projects following its recommendations since the beginning. About the future of discussion pages in Wikimedia, an analysis of problems and strengths perceived by users of wikitext and Flow discussion pages is being prepared based on the Flow satisfaction survey results. --Qgil-WMF (talk) 09:14, 6 January 2017 (UTC)

Closure

Do we have a standard closure time for a proposal like this? Is it 7 days, 14 days, 30 days? --MZMcBride (talk) 07:42, 3 January 2017 (UTC)

• 14 days feels standard, but 30 days would be more cautious (unless there are no new participants for several days in a row). --Nemo 08:08, 3 January 2017 (UTC)
  • Okay, we'll wait until about January 24, 2016 for an uninvolved user to close the discussion and determine the appropriate path forward. I think being cautious makes sense. We can update phabricator:T63729 when there's a resolution here. --MZMcBride (talk) 02:25, 7 January 2017 (UTC)

Clarification of purpose

We confirmed it's clear to everyone that MarcoAurelio's proposal meant uninstalling the extension.

Ping to everyone who has !voted, regardless of how they !voted User:MarcoAurelio User:Nemo_bis User:Ks-M9 User:Steinsplitter User:Stemoc User:Aldnonymous User:Defender User:Ah3kal User:KPFC User:Ajraddatz User:Matthewrbowker User:Az1568 User:Freddy2001 User:Vogone User:Base User:JuniorX2 User:-revi User:MZMcBride User:EpochFail User:Atcovi User:BethNaught User:Dereckson User:Scott User:Rschen7754 User:Krd User:^demon User:Jeblad User:Savh The title of the RFC is Proposal to remove Flow on Meta-Wiki. It directly refers to the removal of Flow from EnWiki. On EnWiki all Flow pages were converted to wikitext, then the Flow extension was completely uninstalled. The RFC question asks if we want to opt-out from this feature entirely. I think it is best to avoid uncertainty on what an affirmative outcome would mean here. Aside from my own !vote above, most participants do not appear to been explicit on whether opt-out from this feature entirely means: "reduce active Flow pages to zero"; or "fully uninstall the extension". Reducing active Flow pages to zero is the simpler option, and it will effectively keep Flow out of our way. Uninstalling Flow would ensure that the unused extension has no side effects on the wiki, it would ensure this wiki is unaffected by any future security or stability bugs in Flow, and it sends a firm message that we don't want Flow popping back any time soon with a few minor upgrades. Given the direct references to wanting to opt-out like EnWiki, I believe the intent here is that Meta should also uninstall Flow completely. If this RFC passes, I support full uninstall, per the case I presented in my !vote above. I invite others to clarify their intent, or to present arguments for how an affirmative outcome should be implemented. If the "Proposal to remove Flow" fails, any question of uninstalling would of course be null and void. Alsee (talk) 04:30, 7 January 2017 (UTC) Uninstall. Things that shall not be used don't need to be kept. --Krd 07:06, 7 January 2017 (UTC) I understood this proposal to mean uninstalling Flow as on enwiki. BethNaught (talk) 07:30, 7 January 2017 (UTC) My proposal to remove Flow from Meta-Wiki meant to uninstal it. Thanks. —MarcoAurelio 10:41, 7 January 2017 (UTC) Confirming that my vote was meant to support the motion of complete Flow uninstall. --Base (talk) 15:13, 7 January 2017 (UTC) Well, it has to mean uninstall, or there is always the possibility someone (i.e. WMF staff in this case) will start a new active Flow page. --Rschen7754 15:33, 7 January 2017 (UTC) I still stand upright concerning my vote. --Atcovi (Talk - Contribs) 15:43, 7 January 2017 (UTC) I understood this proposal to be about uninstalling the Flow extension entirely. While I !voted against it, I think that was clearly the intention. --EpochFail (talk) 16:48, 7 January 2017 (UTC) Remove it completely, not from Meta but from all wikimedia wikis and please stop using meta to test broken stuff, we are not a test wiki and Flow has been a bad idea since day 1.--Stemoc 23:28, 7 January 2017 (UTC)  Oppose As I have been pinged; no I do not support this RfC in any form. — Jeblad 01:48, 8 January 2017 (UTC) Uninstall. I support to opt-out of flow, per the MarcoAurelio's proposal. --Ks-M9 [disc.] 17:23, 8 January 2017 (UTC). Moved Lsanabria's response to the main voting section, by Alsee (talk) 07:22, 10 January 2017 (UTC) Apparently this totally confusing section is now turning into a second vote. I suggesst removing/collapsing it. --Vogone (talk) 21:16, 8 January 2017 (UTC)

---

• There seems to be a clear consensus to not use flow here on meta. As uninvolved crat, I'm going to cloe this discussion and ask the proposer (@MarcoAurelio:) to take the necessary steps etc. -Barras talk 21:13, 23 January 2017 (UTC)
  • I have updated Phabricator T63729 "Remove Flow from Meta-Wiki" to reflect the result here. Alsee (talk) 23:09, 23 January 2017 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.