Last modified: 2014-09-01 15:15:29 UTC
The Pure Wiki Deletion System (http://en.wikipedia.org/wiki/Wikipedia:Pure_wiki_deletion_system) is gaining a good deal of support on en:, but before it can go anywhere, it needs to be implemented in the software. The policy changes will be easier and more relevant to discuss if the software already supports the new system. We request these software changes: * A link to a blank page should show up as a red link. * When a user follows a link to a blanked page, the page should behave the same way that deleted pages do now, except there will be an additional message, reading: "A former version of this article was deleted by [USER NAME/IP] on [DATE]. The reason given for deletion was: [EDIT SUMMARY]. You may view the article's history, edit the last version, or type new article into the white space below." * The blanking or unblanking of a page should be logged, and listed on watchlists and recent changes like the other logs (the move log, the protection log, etc.) * Blanked pages should not show up in searches using Special:Search, random pages using Special:Randompage, or the list of all pages using Special:Allpages. * The URL prefix to a blank page should be listed in robots.txt, and the page will emit "noarchive" and "noindex" and "nofollow" tags, to prevent caching in search engines.
There should be an option to protect pages from being deleted, such as known articles (towns, actual things), and articles that are going through AfD discussions
I'm not sure why that option would be necessary; you can just revert it like any other edit. Please suggest changes to the proposal on its talk page: http://en.wikipedia.org/wiki/Wikipedia_talk:Pure_wiki_deletion_system .
It might be easier, and more clear, if instead of basing the above logic on a blank page, there is a purposeful directive ("#DELETED", for example) that can be edited into the page, like a redirect, for special handling.
I agree with Demi. I'm also thinking maybe an intermediate option would be having the page creators be able to delete their own pages, or pages that they've created/are the main (not adding templates/cats to) of. If this proposal fails, I'd like to see that at least come in, so as to take some of the strain off of the Speedy cat.
This will need some discussion in the relevant places on Wikipedia. When you start mentioning the CSD categories, you go out of the scope of BugZilla.
*** Bug 2288 has been marked as a duplicate of this bug. ***
As Brion pointed out last time this came up, the problem with it is that it requires blanking and unblanking to invalidate the caches of all pages which link to the target page. As such it's predicated on the creation of a purge daemon which can perform this task in the background, or some other efficient invalidation or update scheme.
I'm not sure I fully understand Tim's comment. When a page is reduced in size, don't the linked pages change the class of the link so that the (now a) stub can be displayed in a different color? Or is the cache purging required by a different feature in the specification?
(In reply to comment #8) The cache for those pages has to be purged in order that they'll be accurately reparsed on next view. The simplest case which would occur if this didn't happen is that you'd get "blue links" to nonexistent pages.
Restored from flood attack.
Tim Starling's comment might be alleviated by simply giving every user a "delete" button which would subsequently blank the article, add the blanking to the edit history, and perform any other necessary tasks.
No activity on this bug, proposal seems to have died out, and there are no current plans to implement this. => WONTFIX.
Been on my list for years.
I'm working on a deletion queueing extension, which may supersede this bug (uncontested deletion by non-administrators will be allowed).
Closing per #12 and #14. Better than the hacks this would need.
I will be implementing this via an extension. http://www.mediawiki.org/wiki/Extension:PWD
Extension complete. The prototype can be viewed here: http://rped.org/PWDwiki/ The problem mentioned in Comment #9 occurs in this extension, but I'm not sure what can be done about it.
Look at Article::doDeleteArticle, you should call Article::onArticleDelete( Title ); calling Title::resetArticleID( 0 ); seems also a good idea.
Platonides, I implemented your suggestion for article blankings (including when the blanked pages table is populated using the special page). Article unblankings presently trigger touchLinks(), invalidateCache(), and purgeSquid(). That seems to suffice; any other suggestions? Thanks.
The extension is obsolete, never implemented all the functionality that was called for, and is in need of a rewrite. Therefore, this bug should be reopened.
"Semi-deletion" seems like a better name, and easier to understand. It's analogous to semi-protection, which gives you some of the advantages of protecting a page and some of the advantages of not protecting it.
Why not just give deletedhistory rights to everyone? Then they could view deleted pages like admins can.
I've thought about that. Is there a downside, aside from what's described at https://en.wikipedia.org/wiki/Wikipedia:Perennial_proposals#Deleted_pages_should_be_visible ? That change wouldn't go as far as what the proposal calls for, though. To more fully adhere to the wiki way would require that non-sysops also be able to undelete the articles. I'm not sure what the downside of that would be, either, from a technical standpoint, other than that to hide all the revisions from view would require ticking a bunch of checkboxes for a RevisionDelete, rather than just hitting a delete button.
(In reply to comment #23) > I've thought about that. Is there a downside, aside from what's described at > https://en.wikipedia.org/wiki/Wikipedia: > Perennial_proposals#Deleted_pages_should_be_visible > ? > > That change wouldn't go as far as what the proposal calls for, though. To > more > fully adhere to the wiki way would require that non-sysops also be able to > undelete the articles. I'm not sure what the downside of that would be, > either, There's an issue where we can't get a list of log items for a specific user if that user is an anon (Its a bug. I think there's someone even working on that). Otherwise I see no technical reason to just use the permission system for people who want this sort of thing. > from a technical standpoint, other than that to hide all the revisions from > view would require ticking a bunch of checkboxes for a RevisionDelete, rather > than just hitting a delete button. I don't really follow. Revision deletion and normal deletion are totally separate (which is super confusing. Particularly for images). Giving people revision deletion ability is entirely separate from giving them normal deletion ability. You could give everybody both rights, neither rights or one of those two rights.
(In reply to comment #24) > I don't really follow. Revision deletion and normal deletion are totally > separate (which is super confusing. Particularly for images). Giving people > revision deletion ability is entirely separate from giving them normal > deletion > ability. You could give everybody both rights, neither rights or one of those > two rights. I'm saying that if sysops want to keep revisions from being viewed by the general public, they'll have to make more use of RevisionDelete, since the public will be able to view the deleted history (i.e. the revisions in the archive table). Hopefully the page deletion revamp will fix that confusing situation. https://www.mediawiki.org/wiki/Requests_for_comment/Page_deletion
(In reply to comment #24) > There's an issue where we can't get a list of log items for a specific user > if > that user is an anon (Its a bug. I think there's someone even working on > that). > Otherwise I see no technical reason to just use the permission system for > people who want this sort of thing. Yeah, logging actions done by anons may not have been a high priority in the design/programming process (see bug 14735) since most wikis haven't deemed it advisable to let anons take the sort of actions (e.g. page moves) that would be logged.
I guess another reason to use semi-deletion is that it eliminates the potential for, e.g., issues such as those described in bug 69047. A combination of semi-deletion and revision deletion would enable one to avoid using the archive table altogether.
