- A link to the most recent revision containing the comment on each page where the comment has ever appeared (unless the page has been deleted or the revision has been hidden)
In case the most recent revision containing the comment has been hidden, but the page hasn’t been deleted, would it be possible to have a link to the most recent non-revdel’ed revision (if there’s any)?
In the currently proposed implementation, it wouldn't be possible, because we delete data about all comment revisions other than the newest and oldest, to save disk space. (I'll note this on the page.)
We could just stop the deleting, but IIRC I did some back-of-the-envelope calculations and came up with "way too much space". I don't have the numbers though, I should re-do this.
It would be possible to have a link to the oldest revision though, at least.
But I think this is unlikely to come up in practice – in what scenario would you hide just one of the revisions containing a comment, but not all? I think that either the comment should be hidden, in which case you'd hide all revisions containing it, or it is just an innocent bystander in the hiding of another comment, in which case the page would be edited to bring it back after hiding the other revisions.
I didn’t think of innocent bystanders “surviving” the revision deletion, but there may still be edge cases of this edge case:
Since it’s an edge case of an edge case, it’s not very severe, but it would still be nice to have. For the practical part, can’t you hook into the revision deletion? If you do, you could re-add the rows for the latest visible revisions and clean up rows referring to the hidden revisions—which in total would probably (very) slightly reduce the number of rows, since the row about the offending comment would be removed, not replaced (unless the administrator forgot to hide all revisions containing it, but that’s really just the edge case of the edge case of the edge case…).
I admit I didn't think about hooking into revision deletion (it can be done: Manual:Hooks/ArticleRevisionVisibilitySet), but after thinking about it a little, I don't think it's feasible.
To correctly re-add the rows for the latest visible revisions, we have to first find which is the latest revision containing each comment – it doesn't have to be in the previous revision, so we potentially have to re-process the entire edit history of the page (up to the known oldest revision containing it, I guess).
Of course this probably would almost never happen in practice, but it would be possible to maliciously create such a revision that hiding it would result in huge database load, so we'd have to add another special case on top of this to prevent that.
Or if we ignored this possibility, and just looked at the previous revision, we'd occasionally still return incorrect results – just like in the currently proposed version, except that it would be much more difficult to document and understand the limitations.
Also regarding the "just stop the deleting" and "way too much space". I did a test where I just removed the code that deletes old rows (). On my local test wiki, the database tables would take up this much space:
| Table name | Size in MB | Rows | ||
|---|---|---|---|---|
| (only oldest and newest) | (all revisions) | (only oldest and newest) | (all revisions) | |
| discussiontools_item_ids | 0.86 | 0.86 | 4046 | 4046 |
| discussiontools_item_pages | 0.50 | 0.50 | 3822 | 3822 |
| discussiontools_item_revisions | 0.95 | 20.55 | 8352 | 171850 |
| discussiontools_items | 0.53 | 0.53 | 3393 | 3393 |
| Total | 2.84 | 22.44 | ||
(there are 4046 recorded comments or headings across many revisions of 165 pages, some created for testing and some copied from elsewhere)
I'm not sure how representative this is of real-world usage, but I think somewhere between 10x and 100x increase would be expected on a real wiki as well. (Depending on how many comments are present in a usual talk page revision… Most have few, but village pumps etc. can have hundreds, and some user talk pages where the owner refuses to ever archive them have thousands.)
When I was estimating disk usage in production in T303295#7850298, I figured enwiki gets ~11,500 comments per day, corresponding to about ~1-2 MB of data per day (that might have been an underestimate, looking at it now). Handling 100-200 MB per day probably wouldn't be impossible, but it would require additional maintenance and maybe additional hardware and didn't seem worth it (although I wanted to do it before I estimated this).
I think there would be value in creating a new section for the set of Usability Improvements we're working on.
To start, I think it would be worthwhile to share how the metadata that appears beneath each level 2 section heading is "calculated".
The above prompted by the question @Nux raised in Topic:Wxw6b0v9kxz0wfri.
@Enterprisey, @Tacsipacsi, @Ladsgroup, @Jack who built the house, anyone else:
I understand that this page might be useful to a script/gadget writer who wants to incorporate the Reply tool inside a larger process. Do you know of anyone/any group that would be interested in this level of detail?
@Whatamidoing (WMF): Nobody/nothing comes into my mind right now, but probably a links to this page from relevant places (e.g. Extension:DiscussionTools) can help increasing its visibility.
I myself would certainly be interested, but don't know anyone else except for your mention list yet.