Neither is editing, but edit counters seem to pop up everywhere. I'd suggest that some people find these counts useful, if not on wikipedia, then in other places where the extension is enabled.

matthew.britton wrote:

(In reply to comment #1)

Neither is editing, but edit counters seem to pop up everywhere.

Attempts to add a "top 5 editors in the past hour" feature to MediaWiki would be met with a similarly negative reaction.

Remove the feature, please.

For reference, this was added in r51626. Can't find the original bug.

pbirken wrote:

It has been in use for a long time on de-WP and on the one hand provides useful information in allowing for example to see if someone is overdoing it, while at the same time giving gratification to reviewers. If en-WP does not want it, remove it for that project only, but actually I suggest keeping it, since there's no real reason to remove it.

danny.leinad wrote:

I support Philipp (the same on pl-WP).

+a bit history...

"top5" has been enabled when user:aka had to disable on toolserver the "statistics tool" due to performance problems. The tool had been widely used by de. pl. and hu.wiki communities, so I suspect that the new MediaWiki feature was a good solution and should remain so.

This must be the only time in the history of everything that something was too performance heavy for the toolserver, so it got moved to core ;)

danny.leinad wrote:

(In reply to comment #6)

This must be the only time in the history of everything that something was too
performance heavy for the toolserver, so it got moved to core ;)

Current feature on Special:ValidationStatistics is only a small piece of former FlaggedRevs stats tool on toolserver. The old tool had various stats and graphs etc. :)

matthew.britton wrote:

(In reply to comment #6)

This must be the only time in the history of everything that something was too
performance heavy for the toolserver, so it got moved to core ;)

Move it back out to toolserver then.

(In reply to comment #4)

It has been in use for a long time on de-WP and on the one hand provides useful
information in allowing for example to see if someone is overdoing it, while at
the same time giving gratification to reviewers. If en-WP does not want it,
remove it for that project only, but actually I suggest keeping it, since
there's no real reason to remove it.

Would this be OK user-wise on toolserver only again? I don't see a performance reason why a top X list can't be there.

(In reply to comment #9)

Would this be OK user-wise on toolserver only again? I don't see a performance
reason why a top X list can't be there.

It shouldn't be much worse than the edit counting tools already on there.

pbirken wrote:

Well, the danger is that nobody finds it on the toolserver anymore (moving things twice makes everybody forget where they are). So, I would be against it, in particular since I don't see a real reason to do anything in the first place.

(In reply to comment #11)

Well, the danger is that nobody finds it on the toolserver anymore (moving
things twice makes everybody forget where they are). So, I would be against it,
in particular since I don't see a real reason to do anything in the first
place.

Also, any toolserver report would need to have the list for all FlaggedRevs wikis.

Putting this on hold until there's a consensus one way or another.

Why not make it a config variable, and if the enwiki people get community consensus, they could disable it just for them.

I'm re-opening this bug. There isn't any reason for it to be set to LATER. It isn't resolved and there's nothing holding up action on it (e.g., awaiting an updated version of some outside dependency or awaiting the death of Internet Explorer 5 or what have you).

(In reply to comment #14)

Why not make it a config variable, and if the enwiki people get community
consensus, they could disable it just for them.

There's already a configuration variable in core for this: http://www.mediawiki.org/wiki/Manual:$wgEdititis

(Which, by the way, is set to false by default.)

I'm not sure what the practice is regarding core configuration variable (re-)use in an extension is, but at least you can say there's precedent for this type of feature being wrapped in a configuration variable.

Marking dup of 25775, which *might* be useful enough to justify and would cover this.

*** This bug has been marked as a duplicate of bug 26268 ***