Why is that a problem? The comment lacks an argument why you would want to completely uninstall (delete) the extension code on a wiki which would mean you'd be unable to access Flow pages. Instead you could leave it installed and just agree to not use Flow pages anymore if you don't want to use Flow anymore.
Wow, a lot of comments on this ticket :)
Hello @Aklapper thank you for your answer. Not being able to revert properly the addition of a feature bothers me greatly. Did that mean that these wikis would have to have flow installed for life?
Hello @Trizek-WMF Any developer can decline changes requested by wikis. Obtaining a community consensus does not make it possible to make all the changes desired by the communities. If an employee is going to take care of this ticket, it would be nice if he also looks at T188806: create a Flow uninstall script so that that entire problem can be properly solved.
Hello @Jnanaranjan_sahu Anybody can send a patch on gerrit that edit the wiki config then purpose it in a swat. It will also mean that this person will have to take responsibility for the changes they implement. Responsibility that I will not risk as mentioned above. Fell free to do so, but don't force me to do so if I have any reservations, and as far as possible don't push that in production before questions raised on this ticket are answered.
@Framawiki I am not forcing anyone this is just a proposal. I can create a patch request myself but I am proposing to know the positives and negatives. I respect your views too. My point is why a community who wants to use flow will ask to disable. I want to know the issue. I hope if there will a time come when it needs to be uninstalled then there will be a fix for that too.
Hello @Aklapper. Thanks for your answer. I just don't like the idea of installing a feature that can't be deleted properly. If I may say so, I don't understand why it wasn't in the checklist before flow was even put into production!
I think a good compromise could explicitly indicate to the community requesting this tool that its deactivation is currently impossible, despite all the problems it raises (distorts contribution statistics, makes it impossible for most community tools to access its data, does not update the templates that are included in posts... as explained in above links). If a wikis wishes to use this tool, I think it should be well informed of the resulting consequences.
@Jnanaranjan_sahu Even if I don't think any comments will be posted, would it be possible, as a matter of form, to at least post a note on the page where the consensus took place about the above issues? We can then wait a few days before continuing. Thanks!
@Framawiki, if "any developer can decline changes requested by wikis" that should be with a good reason. Commons' concerns are good to know, but they don't shape what other communities should do. Odia Wikipedia is already testing Structured discussions. I'm sure Odia Wiktionary people know the advantages and the inconvenient of StructuredDiscussions. :)
I think you should create a Mediawiki page listing all disadvantages you mention, so that communities would be honestly informed about the limitations before making the request. However, that page must also list the advantages shared by several wikis (quoting from memory of discussions I've read: simplified discussion workflows, an interface more familiar to newcomers and mobile-friendly, better notification system, wikitext and visual editing provided...) to allow a fair choice.
To be honest. There is no active member on that project. Only people checking the page but rarely someone edits there. Odia Wikpedia Community can be considered on this case and they are okay with enabling it. We had a discussion on Odia Wiki and people are agree with it. As I have initiated this on Odia WIkipedia I thought I should also ask for other two projects of Odia Language. It is okay if you enable if there is no problem installing. Or we can close this task as not required now which can be reopened later.