CentralNotice uses UserDailyContribs if it is installed:

					// Add the user's edit count for the past year
					$userData[ 'pastyearseditcount' ] = getUserEditCountSince(
						time() - ( 365 * 24 * 3600 ), // from a year ago
						$wgUser,
						time() // until now
					);

Unsure if that data is actually used though.

In T85984#959968, @Legoktm wrote:

Unsure if that data is actually used though.

Doesn't look like it.

This is used by some community banners and user scripts. Not sure how essential it is, though. The recent banner that used it was the stewards election banner. Maybe we should consult and announce somewhere ahead the change? Also, maybe someone could elaborate on motivations (other than de-crufting)? Thanks!!! :)

The API module provided by the extension appears to be used by ArchiverBot and MysteryPedia.

In T85984#1463891, @AndyRussG wrote:

This is used by some community banners and user scripts. Not sure how essential it is, though. The recent banner that used it was the stewards election banner. Maybe we should consult and announce somewhere ahead the change? Also, maybe someone could elaborate on motivations (other than de-crufting)? Thanks!!! :)

I don't see this being used in the stewvote and stewnoms banners and the banners in that search result shows old banners. I think we can notify users with User-notice and then go ahead with this.

In T85984#1463898, @ori wrote:

The API module provided by the extension appears to be used by ArchiverBot and MysteryPedia.

ArchiverBot is managed by @whym but it uses archivebot.py?

In T85984#1463899, @Glaisher wrote:

I don't see this being used in the stewvote and stewnoms banners and the banners in that search result shows old banners. I think we can notify users with User-notice and then go ahead with this.

Hmm, you're right, my bad! Stewards banner used an API call instead. Yeah, the last actual use in a banner seems to be the 2013 Picture of the Year banner.

What about userscripts on other projects/languages? Gadgets?

For CentralNotice, we can also send a message to the centralnotice-admin list.

Certainly if it's unused, it should be removed, since it's running in the MakeGlobalVariablesScript hook...

In T85984#1463905, @Glaisher wrote:

In T85984#1463898, @ori wrote:

The API module provided by the extension appears to be used by ArchiverBot and MysteryPedia.

ArchiverBot is managed by @whym but it uses archivebot.py?

I do use the API, but the dependent script is https://github.com/whym/cdc not archivebot.py. It's a client-side tool to generate stats which I find handy to keep an eye on some of my bots work: http://rawgit.com/whym/cdc/master/cdc.html?user=ArchiverBot&days=1

More importantly (in terms of the number of end users), @Rillke's EnhancedPOTY.js at Commons seems to use the API for voters' eligibility checks.

There seems to be another dependent tool made by @jeblad: https://no.wikipedia.org/wiki/MediaWiki:Gadget-contributions-report.js.

Change 225839 had a related patch set uploaded (by Legoktm):
Mark ApiUserDailyContribs as deprecated

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

Change 225839 merged by jenkins-bot:
Mark ApiUserDailyContribs as deprecated

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

Mark ApiUserDailyContribs as deprecated

Thanks @whym for pinging me here. Yes, EnhancedPOTY.js can use these data if eligibility of polls is set up to consider deleted contributions as well. There is currently no such poll, though. As for libAPI.js, it's just a list of what it believes it supports.

This is used by some community banners and user scripts. Not sure how essential it is, though.

Restricting banners to subsets of users based on user groups and edit count is encouraged by the CentralNotice guidelines and should definitely be facilitated by the software. It would be a severe regression if some banners were suddenly exposed to a larger audience.

What features are now available in CentralNotice to allow such filtering? Please document in the help page. If none, please file a bug against CentralNotice.

In T85984#1579182, @Nemo_bis wrote:

This is used by some community banners and user scripts. Not sure how essential it is, though.

Restricting banners to subsets of users based on user groups and edit count is encouraged by the CentralNotice guidelines and should definitely be facilitated by the software. It would be a severe regression if some banners were suddenly exposed to a larger audience.

What features are now available in CentralNotice to allow such filtering? Please document in the help page. If none, please file a bug against CentralNotice.

They can use mw.config.get( 'wgUserEditCount' ) and mw.config.get( 'wgUserGroups' ). Also added to the help page.

They can use mw.config.get( 'wgUserEditCount' ) and mw.config.get( 'wgUserGroups' ).

Well, that doesn't suffice for use cases such as elections with activity requirements. Thanks for expanding the help.

In T85984#1579725, @Nemo_bis wrote:

They can use mw.config.get( 'wgUserEditCount' ) and mw.config.get( 'wgUserGroups' ).

Well, that doesn't suffice for use cases such as elections with activity requirements. Thanks for expanding the help.

Thanks!! Banners can also make API calls, like this one does. Do you think that would be sufficient?

@AndyRussG: I think @Nemo_bis meant that in some procedures you need to calculate "how many edits editor X has made in the last Y days" which no other API seems to support.

For example, jawiki's administrators process requires voters to have 5 edits in the last 30 days. (The full conditions are a bit more complicated and the check is manually done there, though.)

I don't suppose anyone's announced this as something that's happening? If not, happy to do so myself, but don't want to step on anyone's toes.

In T85984#1610580, @Jdforrester-WMF wrote:

I don't suppose anyone's announced this as something that's happening? If not, happy to do so myself, but don't want to step on anyone's toes.

I sent a notification/request for information to a few lists now: http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical.ambassadors/1287

I have http://tools.wmflabs.org/liangent-django/recent_contribs/ but I'm not sure whether any person is using it.

There's also a bot posting this data to the wiki https://zh.wikipedia.org/w/index.php?title=Wikipedia:%E6%9C%80%E8%BF%91%E7%BC%96%E8%BE%91%E6%AC%A1%E6%95%B0%E6%9C%80%E5%A4%9A%E7%9A%84%E7%94%A8%E6%88%B7/Latest&action=history but I'm also not sure how often people are reading it.

I updated Extension:UserDailyContribs to add {{deprecated|1.26}} and status=unmaintained.

I use this table for ad hoc research queries. I plan to also use it for research participant recruiting, but have not yet done so. Removing the table will add an extra step to those workflows.

I consult with this table every now and then, when a question related to editor activity arises, it's handy to have this information readily available in a table. If removing the extension is necessary for a reason, I can live without this table but I just want to call out that it's a good to have for me.

The table has been used extensively in the past for analytics / data analysis purposes, it would be practical to keep it but it's also trivial to generate these numbers post-hoc (for example as part of the edit data cubes @Milimetric and @kevinator were speccing out a while ago). I don't feel strongly about keeping it or removing it.

@yuvipanda do you know if we have people querying this data via quarry?

It looks like @IKhitron has used the table. https://quarry.wmflabs.org/query/4833 https://quarry.wmflabs.org/query/4814

For Cat's sake, how could you find these queries, @whym? They have no names, and they are in draft.

In T85984#1648966, @IKhitron wrote:

For Cat's sake, how could you find these queries, @whym? They have no names, and they are in draft.

A Google search with "FROM user_daily_contribs" lead me to your quarry pages.

I see...

In T85984#1652551, @Nemo_bis wrote:

while a gain in removing the extension still has to be pointed out

One less master query on page save.

Change 246689 had a related patch set uploaded (by Ori.livneh):
Turn off UserDailyContribs extension

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

Just to note: the related CentralNotice patch (below) is deployed.

https://gerrit.wikimedia.org/r/#/c/225669/

Change 246689 merged by jenkins-bot:
Turn off UserDailyContribs extension

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

This removal has broken our user contribution report on nowiki which is enable as standard for all of our users. I see the removal was declined beforehand and "suddenly" removed one month afterwards?

Notice at Wikipedia:Torget#Bidragsutvikling. The actual gadget that is broken is MediaWiki:Gadget-contributions-report.js.

I noticed some time ago that this was broken, but forgot the whole ting. At that time the extension was already removed.

Like Stigmj I would really like an explanation why this was declined after a lengthy discussion, then reopened a month later and the extension promptly removed a few days later without further discussion.

Please reopen this task and at least explain what happen.

at least explain what happen

The argument we were waiting for was finally made on why disabling this extension mattered:

One less master query on page save.

Translated, this means that uninstalling the extension made editing slightly faster for all users. I don't know how faster, although perhaps someone at the time calculated the timings of the extension's methods and perhaps the information can be derived from graphs like https://performance.wikimedia.org/#!/year ; I guess between 1 and 50 ms or so.

In contrast, the arguments on the usefulness of the feature were not considered strong enough, presumably because the feature degradation seemed to affect few users and/or to be easy to overcome with some query rewriting. You could file a report in WMF-General-or-Unknown and cc Community-Tech to have your gadget fixed, hopefully it's not too hard.