Change 112639 had a related patch set uploaded by MZMcBride:
Remove ArticleFeedbackv5 from Wikimedia wikis

https://gerrit.wikimedia.org/r/112639

swalling wrote:

Thanks for filing the bug and making the config patch MZ.

If he hasn't published it already, Fabrice is working on an un-deployment plan which account for how to warn people adequately, and let them migrate any feedback they care about to a Talk page or elsewhere. He mentioned this at http://lists.wikimedia.org/pipermail/ee/2014-January/000882.html and I think he is probably ready and willing to take charge on notifying local communities etc.

Notifications are easy: it's already been disabled on de.wiki, fr.wiki is loudly asking disabling and has been promised it will happen in a matter of days (counting from two weeks ago), en.wiki was always informed of the plans and it's in English so everyone can write there. :)

Ah, of course Fabrice's report, if not delivered before the disabling of AFT this week, will be a useful recap to link when closing all the bugs requesting AFT on other wikis, which have not followed all the details of the project so closely.

Pre-notification to en.wiki sent as bug 54197 comment 6 + https://en.wikipedia.org/?diff=prev&oldid=594948670

There are several wikis interested in ArticleFeedback (see e.g. bug 44601, bug 48777, bug 38443, bug 43328, bug 31641) which might be happy with the extension as it is now. en/de/fr Wikipedia not wanting it is hardly a valid reason to remove it from all WMF wikis altogether.

True. The reason is that it is unmaintained and non-functional and there are no plans to fix it:

• bug 54197 is a critical bug, even though it was put a configuration patch on the specific case;
• feedback is wasted time because users will never be able to see it, see bug 58956.

Also see https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=595328778#Article_Feedback:_Next_Steps (though en.wp specific)

Thanks guys.

I have posted our report on AFT5 here, with our team's recommendation to retire this tool from our two pilot sites:
https://www.mediawiki.org/wiki/Article_feedback/Version_5/Report

I also posted this announcement on enwiki AFT5 talk page:
https://en.wikipedia.org/wiki/Wikipedia_talk:Article_Feedback_Tool/Version_5#Article_Feedback:_Next_Steps

And I announced our recommendation in french as well on frwiki's Bistro:
https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Le_Bistro/12_f%C3%A9vrier_2014#Outil_de_Retour_des_Lecteurs_:_.C3.A9tapes_suivantes

Based on the community feedback we've received so far, I'm comfortable with MZ's proposal to remove AFT5 on enwiki and frwiki in two weeks, on Monday, March 3, 2014, as discussed here on Gerrit:
https://gerrit.wikimedia.org/r/#/c/112639/

This should give enough time for editors to preserve any feedback they want on their article talk pages, using the 'Discuss on talk page' tool.

Let's reconnect a few days before, by Feb. 28, to confirm there was no community request for more time. Assuming there are no further issues, we're good to go with this plan on our end.

Take care.

Added to https://wikitech.wikimedia.org/w/index.php?title=Deployments&diff=99329&oldid=99276 , hour and person can be adjusted later.

(In reply to Fabrice Florin from comment #9)

This should give enough time for editors to preserve any feedback they want
on their article talk pages, using the 'Discuss on talk page' tool.

I doubt that's enough in itself, more important will be the release of the data in a consumable format as previously done for de.wiki (but not with latest data yet). I'm glad you plan to do that too :), I'm confident it will be easy and fast enough.

(In reply to Nemo from comment #7)

True. The reason is that it is unmaintained and non-functional and there are
no plans to fix it:

• bug 54197 is a critical bug, even though it was put a configuration patch

on the specific case;

• feedback is wasted time because users will never be able to see it, see

bug 58956.

Certainly the extension is functional: it is possible to give feedback with it, and to view the feedback given. You might have your own opinion about what is the minimum acceptable level of functionality, but I don't see why you should get to force it on others. The features you mention (auto-archiving and watchlist integration) weren't even planned when many of the bug requests above where made, so it is unlikely most wikis would consider their lack a dealbreaker.

As for being unmaintained, it is a stable extension successfully deployed on several high-profile wikis, which means there is no particular reason to expect it would cause problems once it is not actively developed. And if it does cause problems, it can be removed at that point - its data is kept separately and it is not integrated with other functionality much, so it can be turned off at any time without data loss. The majority of the extensions that are deployed on the production cluster have the same status: they don't have any designated active maintainer, they were written once by someone, successfully deployed, and after that they are happily used as long as they don't cause problems, even if the original author has long since left.

The history of the various projects tells us that different wikis have different norms, needs and expectations, and a tool which is hated on one wiki can be successful on another one (FlagRevs and LiquidThreads are two recent high-profile examples). That AFT was not welcome by three large wikis (or not welcome by the majority of the editors on those wikis, anyway) is no reason to think that no other wiki will have a different opinion. Personally I would find it infinitely disappointing if, after spending man-years on this project, the Foundation would just throw it away when there are still projects interested it, even though it might take at most a few hours of developer time to enable and configure it on those projects.

I'm sorry but you clearly didn't even read what you're commenting: just look at bug 54197 comment 0; and you mention LiquidThreads as example, well LiquidThreads deploys have been frozen (wontfix'ed) for years.

The majority of the extensions that are deployed on the production cluster have >the same status: they don't have any designated active maintainer, they were >written once by someone, successfully deployed, and after that they are happily >used as long as they don't cause problems, even if the original author has long >since left.

Bugs (or at least important ones) in most legacy extensions without developers assigned to them tend to get fixed by platform team or interested random volunteers in my experience. I don't think its fair to compare AFT's status to your average not actively developed extensions (Except maybe LQT, its status is probably similar to that)

(In reply to Nemo from comment #12)

I'm sorry but you clearly didn't even read what you're commenting: just look
at bug 54197 comment 0; and you mention LiquidThreads as example, well
LiquidThreads deploys have been frozen (wontfix'ed) for years.

bug 54197 means that archiving does not work reliably; that is a non-issue if you don't mind archiving being disabled in the first place.

LiquidThreads is wontfixed because it is being superseded by Flow; also, unlike AFT, it does modify core features (specifically how talk page content is stored), so having to convert a wiki from LQT to Flow (or even just backing out of LQT) is a significant maintenance burden. Backing out of AFT is just a trivial config change.

(In reply to Bawolff (Brian Wolff) from comment #13)

Bugs (or at least important ones) in most legacy extensions without
developers assigned to them tend to get fixed by platform team or interested
random volunteers in my experience. I don't think its fair to compare AFT's
status to your average not actively developed extensions (Except maybe LQT,
its status is probably similar to that)

The video extensions for example have not been actively developed for a while (by the WMF, anyway), and I would guess they are more complex than AFT, but I'm sure no one thinks that a good reason to disable them.

The way I see it, worst case there will be serious bugs and no one will fix them, in which case the extension can still be turned off at that point; given that it uses a separate table, it's unlikely that any problem it causes would persist after that. Best case, there is no such bug and a bunch of wikis get a useful tool they wanted, for free.

You keep making stuff up... Last reply from me, not productive to continue.

(In reply to Tisza Gergő from comment #14)

LiquidThreads is wontfixed because it is being superseded by Flow;

This was a particularly funny joke. Bug 19699 was closed in 2012 and the last LQT enabling was in 2010 if configuration comments don't lie; most were in 2009. In short its usage was expanded only while it was actively being developed and feedback was (potentially) of some use, though it turned out to be useless because LQT has never received further development except by volunteers. LQT is a prime example of why AFT must (similarly) be shelved but (dissimilarly) as soon as possible.

sri wrote:

Hi Guys,
This is Sri - New to the Ambassador role. I would like to be part of it , i will keep checking , contribute wherever or whenever i would be able to!!:)

This is to inform/update I am trying to send my message before February 28 2014 , so that i am in the list of Ambassadors!!:)

From this email i understand i should send across to confirm, Is that correct

This is what i am talking about
"Whether this is a good idea or not is being discussed now at bug 61163 [1]; if you are ambassador for a wiki which is planning to use or trial ArticleFeedback, you should probably get involved. (The tentative date of removal is start of March.)
"
This came from
': [Wikitech-ambassadors] Disabling of ArticleFeedbackv5 (unmaintained) imminent
Inbox
x

Tisza Gergő gtisza@gmail.com via lists.wikimedia.org
3:48 AM (5 hours ago)

to Coordination "

So i am trying to confirm, hope i am in.

If you would like to check about me
our websites are www.ultimizedsolutionz.com and www.saisupersol.com

We love to be part of this team, learn, contribute and provide input wherever i can.. I used to work for Oracle for 16 + Years!!:)
Thanks again
Sri

Sri: This is Bugzilla where bug reports about specific software changes are discussed - please take discussing team membership to mailing lists. Thank you!

sri wrote:

Ok i will find out what is the mailing lists. Again i apologize for any inconvenience that could have caused to you guys. I am really sorry..even though i have been working from PDP 11 -IBM Minproprietary system till today!!:) i need to know where to pith in. I will search for the mailing list later. Again please feel free to point me the url or so if you wish as well. Again thanks a bunch. I will not post anything about team. I am sorry again.
Thanks & Best Regards
Sri

(In reply to sri@ultimizedsolutionz.com from comment #18)

Ok i will find out what is the mailing lists. Again i apologize for any
inconvenience that could have caused to you guys. I am really sorry..even
though i have been working from PDP 11 -IBM Minproprietary system till
today!!:) i need to know where to pith in. I will search for the mailing
list later. Again please feel free to point me the url or so if you wish as
well. Again thanks a bunch. I will not post anything about team. I am sorry
again.
Thanks & Best Regards
Sri

No worries. Mailing list is at https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors . Generally ambassadors read the list and inform their wiki community of upcoming changes.

sri wrote:

Ok great, I would be happy to do that as well. I am really keen and I love co-coordinating things, since this is what I have been doing for different Non-Profit Organization in the past. Appreciated for providing the input. Thanks so much again.
Sri

(In reply to Tisza Gergő from comment #11)

it is a stable extension successfully deployed on several high-profile wikis

No, it is not. The extension is "clearly not welcome by a majority of editors", per the Foundation's own assessment. It is only a narrow a view of success that omits this criterion.

That AFT was not welcome by three large wikis (or not welcome by the majority
of the editors on those wikis, anyway) is no reason to think that no other wiki
will have a different opinion.

That AFT was not successful at being broadly compelling to users is no reason to think that no other feature will. The volume of space that AFTv5 occupies is not measured in kilobytes or pixels, but in the cognitive load that it adds on developers and users.

"The important point is that the cost of adding a feature isn't just the time it takes to code it. The cost also includes the addition of an obstacle to future expansion. Sure, any given feature list can be implemented, given enough coding time. But in addition to coming out late, you will usually wind up with a codebase that is so fragile that new ideas that should be dead-simple wind up taking longer and longer to work into the tangled existing web. The trick is to pick the features that don't fight each other." - J. Carmack

Change 112639 merged by jenkins-bot:
Remove ArticleFeedbackv5 from Wikimedia wikis

https://gerrit.wikimedia.org/r/112639

The changed has now been deployed on the production cluster by Matthias Mullie.

We have now removed the Article Feedback Tool from both the English and French Wikipedia sites today at 19:30 UTC (see [https://gerrit.wikimedia.org/r/#/c/112639/ this Gerrit ticket] and [https://bugzilla.wikimedia.org/show_bug.cgi?id=61163 this Bugzilla report]). This means that no feedback can be posted or viewed anymore.

In coming days, we will archive the feedback data in a public hub, so it can be accessed forever. I will post on this thread as soon as the data archive is available:

https://en.wikipedia.org/wiki/Wikipedia_talk:Article_Feedback_Tool/Version_5#Article_Feedback:_Next_Steps

Thanks again to everyone who contributed to this experiment -- we're grateful for your support of this project. To be continued.