In one of the earlier discussions about revising the deletion schema, Happy-Melon pointed out, "Right now everyone who has ideas for *an* implementation isn't working on it because they don't know if it's *the* implementation we want." It seems to me that if one proposal is clearly superior, we may as well pick that one, so someone can get to work on it; but if the proposals are about equally good, then we may as well pick one at random, or whatever proposal is slightly better than the others, so someone can get to work on that one. http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/48109
The RFC over at MediaWiki.org hasn't received a lot of comment. Is there any objection to my implementing the "new field" option described at https://www.mediawiki.org/wiki/Requests_for_comment/Page_deletion ?
I.e., I would add a new field, page.pg_deleted (analogous to revision.rv_deleted). Also, I would add revision.rv_logid to store the log_id of the deletion event. Upon restoring a page, only the revisions pertaining to the selected deletion event(s) would be restored. So, suppose you revision delete some revisions from a page for copyvio reasons. Those revisions are now updated as rv_deleted=[whatever value we want to use to signify the kind of access restrictions imposed by the deletion], and revision.rv_log_id=1, assuming that is the first log action ever performed on that wiki.
Later, you delete the whole page (update rv_log_id=2 for the remainder of that page's revisions) for notability reasons. Then you decide you were mistaken about notability, but the copyvios would still be a problem. You undelete the page, selecting only that second deletion action. You only restore the revisions that have rv_logid=2, and leave the rv_logid=1 revisions deleted. This will render the archive table obsolete, so it can be deprecated/eliminated.
I would like to code this for v1.23. https://bugzilla.wikimedia.org/show_bug.cgi?id=55398 Thanks.