I bet @aaron will know :)

As far as I understand it user_editcount doesn't increase at all when you move a page, while the other edit counters increase by 2 (1 for the move, 1 for the created redirect). As user_editcount doesn't decrease when a page is deleted, it approximates the total edit count. Except that for accounts older than the field in the database it was initialized with the live edit count IIRC, so deleted edits from the early age are not counted, even if they were restored later.

total edit count = user_editcount + 2 * number of moves
is quite exact for most users

In that case, it sounds like we need to call $user->incEditCount() during page moves.

@srishakatux: This might be a good Hackathon project.

Documentation[1]:

user_editcount is the rough number of edits and edit-like actions the user has performed.

This field is not an exactly accurate copy of COUNT(*) FROM revision WHERE rev_user = user_id. However, it should be roughly accurate if the update scripts are consistently run and it's the only place edit count data is available to the software, so it's stillused for serious purposes like deciding whether accounts have been autopromoted.

A number of things could cause this value to be incorrect. For example, it may be out of date or, for old accounts, NULL if the update script (initEditCount.php) hasn't been run. Also, some deletions may not affect it consistently.

See also T21311 or T134359
I see no reason to change anything here

[1] https://www.mediawiki.org/wiki/Manual:User_table#user_editcount

@Umherirrender: I'm confused. You're saying that we shouldn't try to make user_editcount more accurate?

In T163966#3219130, @kaldari wrote:

@Umherirrender: I'm confused. You're saying that we shouldn't try to make user_editcount more accurate?

I have nothing against accurate editcount, but
a move is not an edit, it just results in two revisions (or one if suppressredirect),
page protection also results in a revision, but it is not an edit,
successfully import results in one revision, but it is not an edit,
revision merge can create a revision, but it is not an edit,
changing content model results in a revision, but it is not an edit

The question is about the meaning behind edit and the editcounter. Call it revisioncounter and than it could keep the same as shown on Special:Contributions/Special:DeletedContributions or queried against revision/archive table.

It would be nice if initEditCount() matched the incremental methods. It's odd that they don't agree. That would mean:
a) Making initEditCount() check the archive table
b) Including all null edits in the incremental methods (or making initEditCount exclude revisions with rev_text_id matching the prior rev)

@Umherirrender: Moving an article seems like an "edit" to me (in the general sense) as you are changing the title of the article. Same for creating a redirect. While it's true that it isn't done with the Edit tab, it's still making a visible change to the page.

Regardless, it doesn't make sense for MediaWiki and X-Tools to use 2 completely different definitions of "edit". Adding @Samwilson and @MusikAnimal to see if they have any thoughts on this (as they are currently re-writing the edit count tools in X-tools).

Hmm, well on the surface, when I think "edit count", I think the number of items I see at Special:Contributions and Special:DeletedContributions. That's how I used to do counts (painstakingly) before I knew about edit counters or Anomie's useridentifier script. The same is obviously true with the revision history of a page. There I see page moves, and XTools and others count those as edits, too.

However it is true that the parent revision ID of the page is not changed when you do a move, page protection, etc (right?). In that sense it doesn't make sense to count these actions as edits. So one other solution is to update XTools to discount page moves and the like. We already have an "automated edit counter" that detects these non-edits, so we could filter them out in the same way. It works by looking at the edit summary, which means we wouldn't be able to do the same for archived revisions :( That would still bring the numbers closer to what user_editcount conveys, though.

At any rate, this discrepancy has caused massive confusion over the years. As a maintainer of XTools responding to questions, I have actually never known what to tell people – so thanks for at least figuring out what the issue was! :)

I posted the question to the English Wikipedia Village Pump to see what other community members think.

Change 354701 had a related patch set uploaded (by Henry Huikeshoven; owner: Ad Huikeshoven):
[mediawiki/core@master] Added increase editcount upon page move

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

Change 354701 merged by jenkins-bot:
[mediawiki/core@master] Added increase editcount upon page move

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

Here are the opinions that were expressed at the English Wikipedia discussion:

• Jo-Jo Eumerus: don't count anything else (status quo)
• Graham87: include page moves, automatically-created redirects, protecting/unprotecting a page, imported edits (in other words, everything listed at Special:Contributions and Special:DeletedContributions)
• WhatamIdoing: include automatically-created redirects, but don't add anything else
• Nyttend: include page moves, automatically-created redirects, protecting/unprotecting a page, imported edits (same as Graham87)

So from our very tiny survey, we got no consensus :P

Change 357522 had a related patch set uploaded (by Kaldari; owner: Kaldari):
[mediawiki/core@master] Adding release note about counting page moves as edits

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

Change 357522 merged by Kaldari:
[mediawiki/core@master] Adding release note about counting page moves as edits

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