Topic on Talk:Article feedback

If someone gives a poor rating in one of the categories, and an edit of the article improves it for that category, are the ratings remembered for the version the person saw, or are they shown for the new version despite the fact that the article is now different?

Good question. Any answers available for this?

This post was posted by Peachey88, but signed as Ceyockey.

Right now, the tool displays a moving average of the past 30 ratings ratings for the past 30 revisions of an article. Mapping ratings with specific revisions makes sense, but it will take a bit of experimenting to get it right. For example, some revisions will only get one or two ratings (or maybe none), so we'd have to figure out how to handle these types of cases.

This post was posted by Peachey88, but signed as Howief.

See also the topic "Low traffic articles" on w:Wikipedia talk:Article Feedback Tool.

Do the past 30 edits include "minor edits?"

I would expect it does, which is problematic for two reasons:

1. A page may not change substantively in 30 edits, especially if there is a series of bot edits or general maintenance. (an obvious problem more specific to the already mentioned low traffic article issue)

2. Number of edits is an abysmal metric for determining when a vote has gone stale. Consider en:Max Bentley, and the significant changes I made in ten edits. The feedback tool would look ridiculous if there were a few 1-2 ratings before expansion that remained post-expansion. Even if the devs wish to retain the 30 edit metric, ratings should also become invalidated after the article changes in size or complexity.

The 30-edit limit definitely has some limitations, but all the others options seem to have problems, too. For example, imagine that you dramatically change the page in a few edits. Let's say that the tool junked the previous ratings because of a size and/or complexity change. Then let's say that someone reverted your changes, sending the article back to exactly what it was before. The old ratings would be entirely valid, despite having encountered dramatic changes in the meantime.

Also, evaluating the changes requires far more computing resources for the tool than simply counting up the number of revisions in the database, so even if it were possible to perform that with any sort of reasonable proficiency, I'm not sure that the devs would decide that it was worth the cost.

Maybe the tool could use checksums to determine whether the current version of a page is identical to one of the previous 29 revisions, and if so, discard any ratings after that previous version and the current one and get other older revisions until it is reached the desired amount of revisions (currently 30).

E.g.:

                                                        (vandal)
--R32-R31-R30-R29------------R28--- ... --R5--R4--------R3-R2-R1-R4-->
               |------------------ Current method ----------------|
   |------ Discarding reverted revisions ------|

There's some work in the pipeline to store hashes/checksums and facilitate the identification of reverts, but it may take some time before it makes it to the production servers: https://bugzilla.wikimedia.org/show_bug.cgi?id=25312