mysekurity wrote:

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

rspeer wrote:

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 .

demi-wikipedia wrote:

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.

mysekurity wrote:

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.

robchur wrote:

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.

robchur wrote:

*** 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.

demi-wikipedia wrote:

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?

robchur wrote:

(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.

ryan.delaney wrote:

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.

tisane2718 wrote:

I will be implementing this via an extension. http://www.mediawiki.org/wiki/Extension:PWD

tisane2718 wrote:

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.

tisane2718 wrote:

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.

@awight: What are your thoughts on pure wiki deletion? I worry that tasks such as T106458 are ignoring the many hours of thought people have put into this issue and surrounding issues.

@MZMcBride: Agreed, I was parroting an editor's off-hand suggestion and didn't uncover any of the related bugs during few quick Phabricator searches.

Is there a tag for "blocked on editor consensus?" I'd like to support the "Pure wiki deletion" discussion and help implement the feature if we agree it should be written. This is an obvious case of confusing software, encrusted in a layer of congealed tradition...

Community-consensus-needed is for configuration requests; removing. Additionally, from Brion's and Tim's comments above it's clear this is a desirable feature in MediaWiki, although the exact requirements are not fully clear.

Enabling this on Wikimedia wikis is another matter, which is probably best addressed when there is an implementation.

Sometimes the simplest ideas end up taking the longest to implement :)

Today I again ran across an example where this would be useful on wikisource.
--> a wiki editor (retired) published an italian paper about WP under gfdl, long ago.
--> someone translated it into english, and put it on en.ws.
--> en.ws removed it in '06 as out of scope (not accepting translations at the time). clear case for PWD.
--> later '09/'20 requests to undelete (so people could read the translation, which existed nowhere else online) were rebuffed b/c proof of license was not obvious.

I have now proposed a completely different usecase: to migrate article to an abstract one.

Many wikipedias (in Wikipedia with more than one million articles, at least including Cebuano, Swedish, Dutch, Egyptian Arabic, Chinese, Vietnamese, Waray) contains large number of bot-generated articles. Once Abstract Wikipedia is a thing, it may be benefical to migrate bot-generated articles to Abstract Content. Once the content is migrated to an abstract one, the local article should be removed though their old content can be recovered by anyone.

This isn't relevant to the Abstract Wiki work except that in many years once Abstract Wikipedia is live everywhere, this task might be a good thing to do. Un-tagging.

English Wikipedia recently proposed this again.

Personally I also support this system. There are some more use cases of soft deletion:

• User pages need to be deleted before a global one can be displayed. However this make old versions of user pages no longer visible.
• Abandoned drafts can be soft deleted which can recovered by anyone.
• ...... (maybe something more)

(quoted to village pump)

Soft deletion would preserve public access to the history of an article, but restore the status of a page as a red-link; see the mockup to the left.

Mock up: https://en.wikipedia.org/wiki/File:Deletion_demonstration.jpg