Not sure why this task was ever closed. It definitely isn't a duplicate of the one suggested but an entirely different issue.

It appears the CommTech team is working on this.

I've got a rough plan for this that I think will work. However I'm going to side-step this until T225239 and related work is resolved. The implementation will depend on the outcome of that investigation.

Change 521403 had a related patch set uploaded (by MusikAnimal; owner: MusikAnimal):
[mediawiki/extensions/PageTriage@master] [WIP] Index articles-from-redirects by newest revision and not the first

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

I'm not sure what to do with this. https://gerrit.wikimedia.org/r/521403 makes the datestamp be the revision that changed the redirect to an article (let's call that the "article-from-redirect revision"); that part was easy. Changing the author however is a different story. ArticleCompileUserData::compile() and ArticleCompileBasicData::compile() both need to reference the article-from-redirect revision. Currently they are just running a query to find the oldest revision. I don't think it's that easy to pass around the relevant revision to these compile methods, similar to what is done with https://gerrit.wikimedia.org/r/521403. I believe these methods might get called over multiple requests, too, so we might need to persist the ID of the article-from-redirect revision for easy referencing.

I mentioned T225239: [4 hours] Can we figure out when redirects become complete articles and the previous reviewed state? was related. For that, even if we stored the revision ID (from which we can get the SHA), it would be referencing the last revision that was reviewed, which is not necessarily the article-from-redirect revision.

I just wanted to say out loud where I am with this task, in case someone else has ideas. I will continue to investigate.

And mind you, once a article-from-redirect is reverted back to a redirect, the datestamp/author for that entry in the queue also needs to revert back to what it was before.

@MusikAnimal I think your logic is right for both articles and redirects.

Update: Discussion of this ticket and the proposal can be found on the project talk page.

This is the new query used in my patch:

SELECT rev_id
FROM `revision`
LEFT JOIN `change_tag` ON ((ct_rev_id = rev_id))
WHERE rev_page = '534366'
AND (
  ct_tag_id = (
    SELECT ctd_id
    FROM `change_tag_def`
    WHERE ctd_name = 'mw-new-redirect' -- or 'mw-removed-redirect'
  )
)
ORDER BY rev_timestamp DESC
LIMIT 1

Production EXPLAIN results:

This is for Barack Obama, an extreme example with about 27,000 revisions. It took just over a second to run. Realistically however we'll be dealing with new pages and old redirects with no more than a few hundred revisions. "Libertarian capitalism" (page ID 1085480) is a real-world example of a page with article-from-redirect history, and the query runtime was 0.00 seconds.

The query needs to be ran on master, and under the current system it's apparently ran on every edit (post-save), though subsequent queries to the same page within a short time frame should be very fast thanks to caching/buffering/whatever. Overall I think this is acceptable...?

In addition to possible concerns with the query, there are existing issues with the extension that might be exasperated. Mainly, that the query will unnecessarily be ran on every edit (which is already the case, but with a much simpler query). I think this needs to be addressed first, and whether or not that's worth our time, I'm unsure. In addition, the logic introduced with my patch feels fragile to me. I've tried to make the tests comprehensive (relative to the new code), but I can't even get them to pass, and I am not super confident the patch won't cause other unintended side effects. Finally, I suspect the community may not be pleased with some aspects of the new system. We cannot cleanly do any sort of revert detection, so if editor A changes the redirect to an article, and editor B changes back to the redirect, editor B incorrectly gets credit for the redirect itself. Flip that around and you have a worse scenario -- editor A writes an article, editor B changes it into a redirect, then editor C turns it back to the preexisting article. Now any messages you send to the creator using Page Curation will go to the wrong person :(

Overall, after two weeks of development, I'm going to suggest we forgo this. The real issue exists with MediaWiki itself, whereby there's no notion of page authorship after a change in redirect state. For instance, the action=info page will always show the author of the initial revision, regardless of the redirect history. We may have to accept that this is just a caveat of how revision histories works in MediaWiki.

@MusicAnimal What does this status mean to a layman? Is it done or isn't it?

It means it's not done @Kudpung and Musik is saying he doesn't practically think it can be achieved.

@Barkeep49, in which case it's probably not a priority anyway. A 'nice-to-have', but not essential.

I think it's a little more useful than that - any article created from a redirect are automatically indexed for instance and if a user is creating troublesome articles (or really good ones) from redirect we can't filter by their creations. But overall I agree this is not a must have.

This work was ruled as out of scope, after analysis and two weeks of work from the Community Tech team. I'm removing the Community Tech tag from this ticket, as we've now wrapped up the Page Curation Improvements project. Further details can be found on the Page Curation Improvements project page. Thanks!

Change 521403 abandoned by MusikAnimal:
[WIP] Index articles-from-redirects by article revision, not redirect

Reason:
Unsuccessful. See https://phabricator.wikimedia.org/T157048#5410849 for more

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

Related T225009

I'll have to thoroughly read this ticket, but my idea is...

Idea 1

Use the edit page hook to detect if an article in mainspace is getting flipped from a redirect to an article, and then add some kind of metadata to the SQL table pagetriage_page_tags with the redirect flipper's username and the redirect flip date.

Then tweak everything else accordingly.

Idea 2

We can write whatever data we want to ptrp_created. So use the edit page hook to detect redirect flipping and write the redirect flip date to ptrp_created, instead of the page creation date.

Note: MusikAnimal mentioned that T240065: Introduce redirect log could help with this ticket. Umherirrender in that ticket also points out perhaps we could do something using the revision tags mw-new-redirect, mw-removed-redirect, mw-changed-redirect-target