User talk:BethNaught/Draft Flow RfC

How about the Teahouse tools?

The primary reason why Flow is being pushed is because new editors need to learn about wikicode before participating in any existing conversation. However, the Teahouse is proof that it's possible to ease the entry point for total beginners with the "wp-teahouse-respond" widget, that adds a "Join this discussion" button to post at the bottom of the thread and even includes a mini-tutorial for signatures.

I'd like to see as number 3 in the proposal the suggestion to include this small widget at all talk pages where newbies are likely to participate (at least Article Talk, User Talk and Deletion discussions). The widget has shown its value in real usage, and is similar in spirit to the "Start a new section" button that was accepted at the top of talk pages.

I believe this RfC would be a lot more productive if the possibility of an alternative solution was proposed as part of it, instead of a binary "it's Flow or nothing". At least we would know what the community thinks about the problem that Flow is trying to solve, even in the case that it doesn't like this tool as the solution. Diego (talk) 10:53, 11 February 2016 (UTC)

Discussing Flow is complicated enough as a single topic. I think it would be an extremely bad idea to muddy up this simple narrow-focus RFC with additional topics. Any improvement idea deserves a separate RFC that can fully focus on it. Alsee (talk) 23:11, 11 February 2016 (UTC)

Fair enough. However, I see no harm in posting such RFC at the same time, right after the Flow RFC is posted. This way we can have separate yet simultaneous conversations, and people could see that Flow is not the only possible option. I'll create my own draft proposal at User:Diego_Moya/Draft_Talk_RfC. Diego (talk) 09:30, 19 February 2016 (UTC)

RfC not needed

There is almost certainly consensus for the basic premise of this proposal (i.e. to convert the 2 remaining pages back to wikitext, and to not create any new Flow boards on Enwiki without a broader community consensus). RfCs are a massive time investment. In the interests of saving editors' time, I suggest starting a simple proposal on VPT, asking:

"Proposal: We should remove Flow from the 2 existing pages (WikiProject Hampshire, and a sandbox page, converting them back into wikitext), and not create any new Flow boards on Enwiki without a community consensus in the future."

I expect rapid consensus, and then we can make a Phabricator task to convert the pages back. Quiddity (WMF) (talk) 19:14, 2 September 2016 (UTC)

I don't see how an RFC to get consensus for one version would take "massively" more time than an RFC to get consensus on the other version. But far more significantly, I am strongly interested in the reason for (apparently?) wanting to avoid possibly uninstalling the Flow extension. Alsee (talk) 14:27, 3 September 2016 (UTC)

It's a little disappointing that there's a conversation going on that directly affects the only (non-sandbox) live users of Flow and nobody has placed a notice about this on the WikiProject Hampshire talk page. RFCs are part of the dispute resolution process and only really needed if consensus can't be established via more straightforward discussion and maybe a bit of !voting. As such I agree with Quiddity that an RFC on whether or not to remove Flow from WT:HANTS would be a using a sledgehammer to crack a nut - just start a discussion at WT:HANTS and let's go from there.

I don't see any pressing case to uninstall Flow completely. Keeping our options (and our minds) open seems a more sensible approach. Although WMF won't be actively working on Flow in the near future it remains an open source piece of software that any willing developer can contribute to. As a user-friendly discussion interface it's excellent; the fact that it encourages proper discussion as opposed to !vote counting is, in my view, an asset not a flaw, but it's far from impossible to develop additional functionality for "structured discussions" within Flow. Unless having Flow available has some intrinsic disadvantage, even if we're not actively using it, pressing for a full uninstall is unnecessarily extreme. WaggersTALK 08:20, 6 September 2016 (UTC)

The pressing case is that keeping semi-zombie software deployed inconsistently on the English Wikipedia is a perfect example of accumulating technical debt.  — Scott • talk 15:47, 7 September 2016 (UTC)

There are a number of extensions that are not directly used in Enwiki, but included in Special:Version because it is less technically-complex to install them on all Wikimedia wikis, e.g. the numerous Wikibase extensions. It would be very complicated (requiring additional development) to "uninstall" any of these. They are just "not used" in all Wikimedia wikis. HTH. Quiddity (WMF) (talk) 00:17, 7 September 2016 (UTC)

Posting the RFC

I'm about to go to sleep, but I'm considering posting the RFC tomorrow or the next day. I think the comments at Flow_survey_released firmly establish interest and viability of the proposal. I also think the RFC-close will probably come around the same time that they are writing up the survey results. I think it would be good for the WMF to process this RFC reality-check at the same time they are considering the survey results. (The survey was extremely WP:canvassed invitations to the talk pages of Flow-enthusiasts, so it's going to suggest grossly inflated levels of community support.)

If someone wants to post it before I get to it, you are welcome to add my name on the signature line as co-sponsor. Alsee (talk) 07:11, 16 September 2016 (UTC)

Hold it. WT:FLOW is basically an anti-Flow zone at the moment, and all it really shows is the RfC will have 10 probably bankable supporters. The WT:BREAKFAST RfC was quite enough conflict and I wouldn't want to reopen a wound while Flow is moribund here unless I were absolutely convinced the proposal would pass. If you did post a proposal I would of course support it. Tbh, this RfC was drafted in anger, and I was leaving it like the sword of Damocles until the WMF tried anything stupid. I'm not convinced this is the right time to go ahead. BethNaught (talk) 08:20, 16 September 2016 (UTC)

If the proposal were to fail, if EnWiki consensus is that we are eventually deploying an upgraded Flow, then I (and others) need to constructively engage with that reality. If the proposal were to pass, if DeWiki and other major wikis concur that Flow is never going to fly, then proponents need to come to terms with that reality. From a Neutral POV I think this is an important discussion whichever way it goes.

This is exactly the time that the RFC needs to be run. This is the point of minimum pain and maximum flexibility. The WMF is in the process of deciding how to proceed. Discussion becomes almost impossible once a decision has been made on how to proceed. Most staff will have assigned job duties. They will simply not be in any position to debate or alter their fundamental job-assignment. Once a decision has been made, a lot of work goes into setting assignments and quarterly planning. It would be very disruptive for management to consider upending those plans.

One of the core aspects of Confirmation bias is that it takes very little information to form a position, but it is extremely difficult to change that conclusion when contrary evidence is presented. This survey was canvassed to an extreme level, any results on "prefer Wikitext or prefer Flow" will be grossly biased. That percentage will be culturalized at the office as a "known fact". Those who object to Flow will be consciously or subconsciously discounted as a loud irrelevant minority. That's part of what happened in the Media Viewer conflict. Everyone at WMF offices "knew" that 70+% percent of readers surveyed wanted Media viewer. In reality the survey found that a majority of global readership responded no on Media Viewer. Once the initial false percentages became "knowledge" it was extremely difficult to alter that "knowledge". Critics were dismissed as an unreasonable irrelevant fringe, when in fact they were the majority.

The WMF has been switching entire wikis to 100% Flow, based on a THREE person support... were one account is a few months old and the other two accounts have ~2 edits per month. The WMF has been slowly digging deeper and deeper into a position that is increasingly difficult to back off from. They would utterly loath the disruption of rolling back an entire wiki. The more they roll it forwards the more they feel obligated to provide permanent support. They obviously don't want to permanently support another LiquidThreads, if they'd going to permanently support Flow then the only reasonable long term goal is full deployment.

The first thing I intend to post in the RFC are examples that will make people's heads explode. Reverting an edit can damage the original version. Flow can display lines (or entire paragraphs) in the wrong order. It can give you wrong wikitext when you click edit, and damaging that content when you try to save a change. Simply clicking preview can randomly mangle what you typed in, and repeated previews can progressively mangle what you wrote. Previewing or saving in Flow can delete entire chunks, mis-rendering the results and dumping raw templates and wikimarkup into the displayed text. That's just the tip of the iceberg. I think many "neutral" people will be ready to grab pitchforks.

Right now is when the strategy is being evaluated. Now is when this needs to be discussed. (Note: I'm making the case for "now", but I'm certainly interested in waiting to hear your thoughts.) Alsee (talk) 22:04, 16 September 2016 (UTC)

Thank you sincerely for your detailed comments. I feel like I understand your position much better. I'm afraid my response will be less verbose. Basically, I don't feel that there is at present enough WMF–community conflict on enwiki to galvanise moderate opponents and "neutrals" as you put it. I'm worried that the WMF will find any excuse to plough on based on even a small opposition.

Nevertheless I am moved by your responses. I realise waiting for WMF to move will make the changes more difficult to undo in a later RfC, technically and socially. If you think it should still go ahead now, you have my leave (such as it is) to formally propose it. I will unprotect the page now (sorry if that looked like a dick move).

Given my above comments, though, I think it is necessary to have several strong early support statements before opposition comes in. I have enough material to organise into a decent statement but won't be able to now until tomorrow evening at earliest. I would you request you co-ordinate with me on timing, and suggest you contact people who have already expressed interest in this draft for opening statements. Signing off now. Thanks, BethNaught (talk) 22:45, 16 September 2016 (UTC)

Re: "They would utterly loath [...]" - no, the team is completely willing to convert the 2 Flow pages remaining here back to wikitext, and vow to not enable any new Flow pages here until/if ever the community requests it, etc, per the section above.

Re: "[...] if they'd going to permanently support Flow then the only reasonable long term goal is full deployment." - no, there are many extensions or configurations that are only installed/set on some wikis, and don't/won't adapt well to other wikis. It's not ideal, but it is reasonable. Flow will only ever come [back] to Enwiki if the community wants it. It was enabled locally here so that editors could test it out here for collaborative-development purposes, but that clearly isn't progressing well at the moment, so let's cease.

What is needed to do so amicably, without deepening the divide? A rhetorically charged RFC is only going to further damage the relationships, which doesn't help any of us in the long run. Quiddity (WMF) (talk) 23:17, 16 September 2016 (UTC)

To be absolutely clear, the survey will have zero impact on Flow deployment decisions, and was never intended to do so. Quiddity (WMF) (talk) 00:30, 17 September 2016 (UTC)

I have no trust in you whatsoever in this matter. After Wikipedia:Miscellany for deletion/Wikipedia:Article request workshop, I do not believe you about future deployment practices; Jdforrester's recent attempts to push VE here by salami tactic RfCs and outright lying could easily be transferred to Flow when WMF wants. BethNaught (talk) 07:33, 17 September 2016 (UTC)

Quiddity (WMF), there was a misunderstanding. I have complete confidence the WMF would convert the inactive page or two here. I didn't mean EnWiki when I said "They would utterly loath the disruption of rolling back an entire wiki." I haven't been following Flow deployments closely, but I noticed KabWiki for example is in the middle of a full deployment.[1] User_Talk, Article_Talk, Wikipedia_Talk, File_Talk, every Talk page wiki-wide. I find it hard to picture the WMF being eager to roll back Flow from every page on a wiki, based on a three person request.

Regarding an amicable solution... I don't know if you'd like it, but I could toss out a thought. What if we had a quiet little Talk-page RFC to convert Project Hampshire, and a quite little XfD on Flow-test. Could the WMF agree to quietly uninstall the unused Flow extension? I believe that would be the outcome anyway. It would avoid amplifying hostility to Flow or any spillover against the WMF. Alsee (talk) 09:07, 17 September 2016 (UTC)

@BethNaught: lesson-learned from that mistake; clearly testing individual pages at the request of individual community members is not wanted here. Flow in particular requires a happy community acceptance because it (currently) is designed to replace, vs most other features which can be optional. Also, yes, I should do more of my "pushing back against a team/manager idea/proposal in public", but that often isn't feasible or productive. Things have been getting better over the last year though.

@Alsee: That sounds good to me, and is also the final outcome I am expecting, modulo the keyword "disable" as discussed above. Re: Kabwiki, many significant decisions are made by small numbers of editors, on the very small emerging communities/wikis; see kab:Special:ActiveUsers for example, and the related column at m:List of Wikipedias for the rest. HTH. Quiddity (WMF) (talk) 17:30, 17 September 2016 (UTC)

Quiddity (WMF), could you clarify what you mean? I can't find anything matching "keyword 'disable' as discussed above". If I try to force an interpretation then I see at least two possibilities.

Would the WMF agree to uninstall an unused Flow extension if EnWiki quietly and successfully resolves all remaining Flow pages? If not then I think we're back at a noisy Village Pump RFC to address everything together. Alsee (talk) 18:32, 18 September 2016 (UTC)

@Alsee: IIUC, the desired end-state is: For there to be no Flow boards in use at all on Enwiki, and no future Flow boards without a significant community consensus to restart trialling the software. I.e. nobody does anything new related to Flow on Enwiki. That is readily achievable, and agreeable.

If you are additionally asking to hides all existence of the software, this is a bigger request. This would have to be the sole task for at least a couple of the developers to invest a couple of months of effort (as estimated by the lead dev) into making and testing a new feature for Flow and MediaWiki to do this. This would be somewhat like an RfC asking for developers to hide all existence of the TimedText extension on a wiki that had previously used it but no longer wants to. This would be a lot of effort with minimal outcome, when those limited developer hours (there are only 3.5 developers on the team) could instead be directed at more productive work, such as improvements to notifications, recent changes, watchlist, etc., fixing bugs and implementing long-desired features. Quiddity (WMF) (talk) 22:18, 19 September 2016 (UTC)

From my perspective what is being asked for is that Flow is uninstalled, or to put it another way that it is not possible for anybody to do any Flow stuff. What you are suggesting means keeping the software enabled but promising not to use it. I don't see that "hiding all existence of the software" is asked for: for example, when Gather was disabled, the software was uninstalled but the database tables were not immediately dropped; for the Article Feedback Tool, we have a legacy of a few mangled logs. For Flow, if all the boards and topics were deleted anyway, the deleted revisions would be in some potentially unparseable non-wikitext content model, but not completely down the memory hole. Is there a reason you can't you just uninstall Flow from Enwiki but leave the deleted data in place? BethNaught (talk) 22:32, 19 September 2016 (UTC)

Quiddity (WMF), I very definitely did not request development of a new Flow feature. Please see MW:Manual:Extensions#Uninstalling_an_extension:

Alsee (talk) 05:49, 20 September 2016 (UTC)

@BethNaught: IIUC, one of the differences with Gather is that it was completely uninstalled everywhere - https://wikiapiary.com/wiki/Extension:Gather - ditto AFtv5 (but wikiapiary isn't as clear there, because other non Wikimedia wikis still use it). It's 'safer' (in terms of avoiding unexpected/untested breakages) to keep it installed-but-unused.

Overall, it is excruciatingly clear that no new Flow activity is wanted on Enwiki. Nobody has even suggested it in a long time (apart from 1 or 2 non-staff editors). The current team members have less-than-zero desire to put it anywhere it is not wanted, and we would all actively oppose/overrule it if asked. It is only even possible for the people with global sysadmin or staff user-rights, and they're equally unlikely to misuse those tools. HTH.

@Alsee: It looks like that section was added by an IP editor in 2012, and has barely been touched since, following discussion at mw:Manual_talk:Extensions#Uninstalling.2FRemoving_Extensions. As noted there, it only applies to "more simple extensions". I'll ask on the talkpage about its accuracy and how widely applicable it is. Regardless, Flow is not a simple extension, and every step of integration (by any extension) requires some additional complexity to back it out cleanly. Quiddity (WMF) (talk) 00:11, 20 September 2016 (UTC)

Considering how deeply Flow integrates/intrudes into so many systems, I do expect uninstalling Flow will be rather more involved than the quoted uninstall description. However one of the fundamental purposes of an extension-based-design is that it can be rolled back without undue difficulty. I expect you'll have to ask the lead dev, or someone on the team, for specific details on uninstalling Flow. I wonder whether they will be relieved or dismayed that we want a simple uninstall rather than heavyweight development of rather dubious "hide" feature, chuckle. Alsee (talk) 18:44, 20 September 2016 (UTC)

It seems to me there are two issues here now. One is the general principle that an extension, by definition, should be something that can be added on or removed (completely) with ease, and that Flow doesn't seem to tick that particular box - Flow isn't an unpluggable plug-in as such. The rights and wrongs of that can and, I'm sure, will be discussed at length but it is what it is. So that leaves the second issue, concerning what to do about Flow on the English Wikipedia. It seems clear that a "hard" uninstall would be unnecessarily burdensome and waste software development resources that are sorely needed on other tasks; the same aims can be met by disabling it across the wiki.

There is a third thing to consider and that is the welcome news that some additional development work has been pencilled in on Flow for next year, and that that work may remedy the issues some people have with the software. Should that be the case and the community agrees to give it a second chance, re-enabling it would presumably be far easier than re-installing it. There are of course a handful of people with stubbornly entrenched views who religiously despise Flow in any form rather than remaining open minded to what it can potentially achieve, but hopefully such people are in a minority. WaggersTALK 08:10, 21 September 2016 (UTC)

Welcome news to some, but hopefully such people are in a minority.

See, other people can play that game too.  — Scott • talk 13:22, 21 September 2016 (UTC)

A big digression into the kind of discussion that should be happening in the RfC itself
The following discussion has been closed. Please do not modify it.
If you make it a game then it's a very childish one. Flow has potential; there may be some issues with it but the mature thing to do is to acknowledge that in time they may be fixed. To take some purely ideological stance against it is silly and detrimental to the wiki as a whole. WaggersTALK 14:38, 21 September 2016 (UTC) Your argument is based on the premise that Flow has potential, which is vague and legitimately disputable. Your attempt to dismiss others' arguments as purely ideological is fallacious: from ideology, "Ideology is a collection of beliefs held by an individual, group or society." Where are the negative connotations you are meaning to imply? And it is not, as you suggest, stubbornly entrenched religious despite to oppose Flow, when reasonable arguments against it can be and are made, including by me. To say it is so seems to me to require a WMF corporate-style mindset that Flow is the best way forward and that anyone who disagrees is either ignorant or a luddite, which is an ideology in itself, is it not? BethNaught (talk) 15:20, 21 September 2016 (UTC) Waggers, there comes a point where trying to upgrade software is counter productive. If you built a submarine and you need a helicopter, trying to bolt rockets onto the submarine only compounds the original design error. Alsee (talk) 03:17, 23 September 2016 (UTC) I certainly haven't seen any substantial "reasonable arguments" against the concept of Flow on this page. As a discussion tool it works, and works well. There are some additional features we'd like to see and they can (and, in time, probably will) be incorporated - that's no reason to throw away what we have now. The discussion above is riddled with "us and them" language and dubious assertions about when best to post the RfC in order to gain the most traction for one side of the debate. It's very difficult to assume good faith when I read comments like those. If you really want what's best for Wikipedia, its editors and readers, please start to acknowledge at least that we're all on the same side and that Flow is not some evil scurge that must be eradicated at any cost. We are one community, it's time to erase the battle lines and work together. The aims of Flow are laudable and entirely in keeping with the aims of Wikipedia as a whole. The software itself, while incomplete, goes a long way towards meeting those aims - it's certainly much easier to use than wikitext. Yes it's not perfect, but just like Wikipedia itself the mantra is to start somewhere and gradually improve it. Wikipedia is not a battleground, please stop treating it like one. WaggersTALK 08:18, 23 September 2016 (UTC) You seem to be under the misapprehension that this is the RfC.  — Scott • talk 09:12, 23 September 2016 (UTC) @Waggers: The main arguments against using Flow as the primary coordination tool in Wikipedia have been made at the WT:Flow page during the years of the project. I appreciate that you try to defend what you perceive as the benefits of the tool, but you won't appreciate why such arguments are unconvincing to us if you ignore the many technical reasons for the strong opposition, which are objective and not based on a battleground mentality. I can post a non-exhaustive summary of several solid reasons why Flow is not regarded as a good fit for en:wiki, which have been previously discussed at length: Flow breaks with the all the conventions and tools of the wiki platform on which the encyclopedia was written. It is: hard to access its history (and thus hard to keep everything audited and openly peer-reviewed), hard to keep track of changes to new posts in an existing conversation, hard to discuss article content (the primary purpose of talk pages) since wikitext is poorly supported and page structure is tightly controlled, and impossible to define new workflows (to handle unexpected or one-off situations) without the assistance of developers. (Moreover, it is unclear how well it will support bots, so many maintenance activities that are commonly automated would need to be severely redesigned) All these activities are between easy and possible in mediawiki, but unsupported in Flow for any foreseeable future. Also, Flow does *not* work well for discussions of the size we have at en.wiki: Its design is based on chats and comment boxes like those found in blogs and newspapers, which are aimed to casual, drive-by posts by random participants. This is seen as a liability for talk pages which are supposed to have exhaustive exposition and exploration of ideas to their detailed consequences. Keeping track of a back-and-forth exchange of ideas between more than two persons is hard. The complexity of the page layout in Flow increases exponentially with the number of people involved, and it has no tools to add structure to the conversation. All the above flaws are structural to the way Flow has been conceived and developed, so they can't possibly be fixed by incremental changes unless most of the project is redesigned almost from scratch. (On a side note, I don't even personally agree that Flow is easier than wikitext itself, since markdown is one of the most user-friendly technologies ever created; but I agree that talk pages hard to use, though I think the mediawiki tool and the large amount of templates in en.wiki are responsible, not the text format. That problem is largely alleviated by the mobile and stand-alone app versions, though, which shows that better tool support in mediawiki could achieve the same goals). There are also some procedural complaints as well regarding how the project itself has been conceived and carried on, which explain why this kind of objective analysis is accompanied with strong emotional opposition. The original design was created with little input from the community (thus failing to capture essential requirements), and communication between the WMF and the community was extremely poor for a long time. Additionally, there's a reasonable complaint that the WMF developers could dedicate work to improve mediawiki itself to achieve many of the same goals for which Flow was intended, but the community requests of small or medium features in this direction are disregarded. Now I don't know if you weren't aware of these reasons or did know them and find them "unreasonable arguments", which is entirely within your right. But dismissing them won't make them go away, so please acknowledge that we're on the same side of trying to do what it's best for the encyclopedia even if many of us consider that Flow can do a great harm to the project if it's ever widely deployed. Diego (talk) 09:45, 23 September 2016 (UTC) Thanks for that summary Diego, it does indeed set out some issues I was unaware of, despite regularly monitoring some of the discussions around Flow. As you say the discussions have often become overly emotive, for understandable reasons, and sadly that has often meant that the signal-to-noise ratio has been poor. Scott is right to point out that this isn't the RFC itself (I was never under the illusion that it was) but this is a discussion about whether or not an RFC is necessary at all. Perhaps we could complement Diego's list of Flow's failures with a list of its successes (yes, there are some) and include that as important context for the RFC if it is to go ahead (perhaps as an appendix on a separate page if not within the RFC itself). This discussion of course relates to my "third thing" in the post above and I'm aware it's a bit of tangent from the important discussion about whether the RFC should propose a full uninstall including the not insignificant developer resource that would require, or the easier but equally effective option of disabling (but not uninstalling) Flow across the wiki. Apologies to BethNaught and Quiddity, I didn't intend to hijack that discussion but to summarise it! WaggersTALK 10:02, 23 September 2016 (UTC) Compiling a list of Flow's strengths, as seen by its supporters, seems a good idea. Could you write such list so that we can tear it appart include it in the RfC along with the drawbacks? ;-) This way people participating in the RfC will have all the context available. Diego (talk) 10:22, 23 September 2016 (UTC) A few random thoughts: You don't need to sign )and don't get pestered by a bot to do so) It establishes a clear separation between what is an article or policy (which one should edit with more care) and what is discussion space. Most of the rest of the world uses boxes rather than free form. It does not require as much infrastructure in the form of signature bots, templates etc. You can watchlist a specific conversation without getting noise from all other conversations on the same page. Per post/per conversation editing history is easier to moderate (e.g redacting private information) You don't accidentally end up posting a post in the wrong place, or at least not as commonly. Also, Diego's "contra" list needs to mention structured discussions like RfC as they are much easier to organize in freeform talk format than in Flow. Jo-Jo Eumerus (talk, contributions) 15:54, 23 September 2016 (UTC)

This page is turning into a debate on Flow itself. It's unproductive. Megabytes of those arguments already exist in the WT:Flow archives, on the WMF's Flow pages, on the former Executive Director's Talk archives, and in countless other locations. The Executive Director was extremely in support of Flow, and you can see her own conclusions from her talk page discussions here. Even her optimistic evaluation was It is not clear if Flow could ever be/become a replacement for Talk in its current concept.

Unless someone suggests a persuasive alternative quickly then I say we post a date for the RFC on WT:Flow, interested parties can have a few days to prep their RFC response, then we post the RFC directly on Village Pump Proposals. (Not just a link to an RFC subpage. I think this is important and warrants direct visibility on the page.) Although we may still be able to avoid an RFC if Quiddity (WMF) brings back an answer on whether the WMF is willing to amicably uninstall Flow if/when the community renders it 100% unused. Alsee (talk) 06:25, 24 September 2016 (UTC)

The uninstall/disable issue needs to be resolved before the RFC is posted. I'd be willing to support the disable option; I'd strongly oppose wasting developer time on making a full uninstall possible. WaggersTALK 12:22, 26 September 2016 (UTC)

@Alsee and BethNaught: Simply not having any active flow boards (by converting the remaining 2 back) is the simple option. That would retain the existing logs and revisions for proper attribution, and hence is vastly preferable. It's already well understood that no new Flow boards are wanted here.

The "uninstall/disable" option is the complicated option that would require a couple months of new development work. It would have no significant benefit, beyond concerns that "someone (staff or global-sysop)" might (perhaps accidentally) ignore the obvious and well-known consensus and create a new Flow board(s).

However, I asked specifically about ways to prevent anyone at all (including staff) from creating new Flow boards on Enwiki, and the lead developer says this is possible, and would be a lot easier and safer to accomplish. I'll file that now, as phab:T146727. Does that seem like a reasonable solution? If yes, would you like me to start a discussion to convert back to wikitext on the WikiProject and an XfD for the sandbox page? Quiddity (WMF) (talk) 00:23, 27 September 2016 (UTC)

Quiddity (WMF), the months of development work was to build a new hide feature. If it would take months of dev work merely to uninstall then the devs would be incompetent (which I definitely do not believe). If the Flow code is genuinely that defective then that's a powerful argument to put in the RFC, that Flow desperately needs to be disentangled and uninstalled before exactly that problem grows progressively worse.

Setting aside the implausible notion of incompetent devs, and setting aside any possibility of a bad faith claim of difficulty in order to avoid uninstalling, I assume there was a miscommunication and someone told you a time frame for some sort of feature development rather than simplejust uninstall. Alsee (talk) 13:54, 27 September 2016 (UTC)

P.S. I closed the Phab task as a miscommunication, no one requested it. If anyone would like to request it, they can certainly reopen the task. However it seems pointless on top of an uninstall. Alsee (talk) 14:33, 27 September 2016 (UTC)

Extensions that create new types of content or log entries generally aren't easily uninstallable. If the Flow extension were to be uninstalled, the content (i.e. comments etc), history and log entries created by it could no longer be viewed, because the code to render them lives in the extension. The same goes for other complex extensions. This is why the simple and effective resolution is to prevent any/all new Flow activity, and convert the 2 existing boards back to wikitext. That way you won't ever have to touch/see Flow activity on Enwiki again, and everyone can get back to work on more pressing issues. As BethNaught wrote above, (emphasis added), "From my perspective what is being asked for is that Flow is uninstalled, or to put it another way that it is not possible for anybody to do any Flow stuff.", which is what I wrote phab:T146727 to firmly resolve. Quiddity (WMF) (talk) 19:57, 28 September 2016 (UTC)

Arbitrary section break

Quiddity (WMF), "If the Flow extension were to be uninstalled, the content (i.e. comments etc), history and log entries created by it could no longer be viewed" Right. Exactly like when Gather was uninstalled. The data is either deleted or left as an unreadable inaccessible ghost on the disks. The only content being preserved is one page being converted back to wikitext. The WMF knew out how to preserve the history during the Project Breakfast conversion, but didn't bother. Naturally I think the WMF should have preserved the history. The half-baked conversion was acceptable if that was what it took to get the WMF to follow through on your[2] promise that Flow could and would be removed if the experiment failed.

Your last comment acknowledged that Flow would not in fact be be "disabled" unless we uninstall it. You just acknowledged that with a supposedly-disabled Flow "the code to render them lives in the extension", and that code would will still be actively running and still affecting the system. I can certainly fill the RFC with links showing Flow dying with Fatal Errors, and to Phabricator showing that the devs are still finding and fixing security-critical Flow issues. There is absolutely no reason that EnWiki should have to suffer pointless side effects or disruption due to code that we're not using. The software is unusually invasive into the system and the WMF is considering complex new Flow development. There's no reason to gamble on side-effects, disruption, or the the entire wiki crashing, due to one or more of the thousands of current and future bugs while the WMF expands some experimental, invasive, and UNUSED aspect of Flow. Dealing with bugs is an accepted and reasonable cost of improving code that we're actually using. But any programmer knows that hooking a large chunk of extraneous and unstable code into the system degrades the security&stability of the entire system. That can be the central point of the RFC, if the focus of debate is going to be uninstall vs not-uninstall rather than Flow vs no-Flow.

To be honest, I'd kinda of enjoy Flow getting ripped to shreds in an RFC. It would be the most effective tactic to burn-in the outcome for the next decade. But I'd really like us (WMF&Community) to engage more as partners rather than combatants. It would be really nice if the WMF would accept that "not wanted" really means "not wanted", and amicably uninstall it. I think the security&stability argument of the unused extension is enough to ensure a "no-Flow" RFC will specifically include an "uninstall" outcome. Please, offer your advice up to management. Tell them whether you think the RFC will pass, tell them whether you think it will explicitly be to "uninstall". Heck, tell them there will be less hostility to Flow in the future if they avoid a conflict over it now. Alsee (talk) 20:20, 29 September 2016 (UTC)

I will do that. Thanks. Quiddity (WMF) (talk) 20:44, 30 September 2016 (UTC)

Quiddity (WMF), any update on this? Alsee (talk) 09:51, 7 October 2016 (UTC)

@Alsee: Yes, the developers are working on code to enable a complete uninstall here. Quiddity (WMF) (talk) 20:30, 8 October 2016 (UTC)

Quiddity (WMF), thanks :) Is there a Phab link, or some other page so I can watchlist how it's going? Alsee (talk) 05:46, 9 October 2016 (UTC)

Sorry for the delay, I should have a good update on Monday or Tuesday. [I was on vacation (at Wikiconference North America) last weekend, and upon returning had a severe headcold that is only now lifting.] I'll add details and links here as soon as I'm uptodate on the progress. Quiddity (WMF) (talk) 03:13, 17 October 2016 (UTC)

@Alsee and BethNaught: The full details are in phab:T148611. Briefly, there's an improved version of the convert-to-wikitext script, which we can run on WikiProject Hampshire, and on Wikipedia talk:Flow/Developer_test_page, and also re-run on WikiProject Breakfast (for small improvements as detailed in the Phabricator task). That is ready to go. We'd then delete the Flow boards and topics. Finally, we'd schedule a "SWAT" slot to uninstall the extension (there are usually a few each week). Does that (and the details in the task) seem like a good path forward? If so, I can explain the details on WT:Flow, and the developers can carry out first few steps later this week or early next week, and complete it soon thereafter if all checks go smoothly. Thanks. Quiddity (WMF) (talk) 07:32, 19 October 2016 (UTC)

Sounds good. Thanx. Alsee (talk) 07:48, 19 October 2016 (UTC)