Mainsite Mirror: https://scp-wiki.wikidot.com/forum/t-17024642/
Following the discussion on the Preservation of Important Works, I believe the consensus is that:
- Neither staff nor the community at large are interested in completely removing author's ability to remove their own works on the site, nor has it ever been an option on the table. Thus, the Wikidot deletion permission for page creator stays.
- It is also true that the liberal ability to delete pages, as well as staff's continued upholding of deletion requests has, on more than one occasion, been wielded against the wiki in an attempt to negatively impact it.
- Compromise between authors having total authorial autonomy of self-deletion and staff's duty to protect the integrity of the wiki's makeup will be imperfect, but any resolution is better than none.
The following proposals have been collected, summarized and streamlined.
Deletion Self-responsibility
Staff will no longer execute voluntary deletion requests. Authors will be wholly responsible for removing their own works, as well as maintaining their own deletion permissions. They can request for articles to be unlocked to this purpose, but staff can not intervene further on the author's behalf, which simplifies the rules, lower technical burden, and limits unnecessary crossovers of purview.
The following paragraphs on Deletions Guide will be removed:
If an author should request their material be removed, and be able to prove authorship beyond a reasonable doubt, these requests are granted. Authors may also request deletion of all their work to be done by staff. This will likely require a basic explanation of why, and may not be immediate, but generally speaking the wiki staff will acquiesce to such requests.
If circumstances imply that a request for deletion is being made during a time of distress, or there is evidence of malice or spite on the part of the user, requests for self-deletion may be delayed or denied.
Failed self-deletions (deleted:) will still be considered a technical error and summarily deleted.
Slug Reservation ability
Disclaimer: this is a composite proposal made to serve past precedents, current discussion, as well as any possible future need on staff's behalf.
Staff will have the ability to reserve slugs by creating placeholder pages. The content of the placeholder created here should be one (or more, if applicable) of the following:
- A disclaimer regarding the circumstance of removal (relevant discussion: Deleting Bright's articles)
- A redirect
- An idea summary of the work previously held at this slot. This will be tagged with rewritable and considered an open entry on Curations' docket
- Navigation-specific functions (e.g. disambiguation, See also)
Eligible-for-reserving slugs exists under the following conditions:
- SCP slots
- Staff may reserve slots in existing Series that were recently vacated due to non-negative-vote deletion and were at least one of the following:
- older than 2 years old,
- was a prize of a Contest (such as Kcon).
- Contest Staff (or equivalent) may reserve any slots in unopened Series.
- Staff may reserve slots in existing Series that were recently vacated due to non-negative-vote deletion and were at least one of the following:
- Non-SCP slugs
- Staff may reserve slugs that were recently vacated due to non-negative-vote deletion, which had 10 or more backlinks at time of deletion.
- The Technical Team can reserve any slug indefinitely for technical function or mitigation of technical issues (see Poisoned Slots)
Staff may move or summarily delete any articles posted to an eligible vacant slug up until 7 days after the initial vacation. If no placeholders are created within that timeframe, staff forfeits reservation rights to it until the next time it is vacated due to non-negative-vote deletion. Eligible slugs can also be voluntarily forfeited sooner than 7 days, at staff's discretion.
Placeholders may only exist indefinitely with a passing Staff vote (excepting Technical Team's purview). Otherwise, they can only exist for up to 6 months, after which they must be vacated, and the slugs considered ineligible for further reservation (until the next time it is vacated due to non-negative-vote deletion.) Fiats may be used to extend the duration, but for no longer than a year.
This is not meant to be used to perpetually occupy a slug, but rather to resolve the underlying situation in under 6 months where possible. Seek other methods to deprecate the placeholders naturally, such as the Slot Goblin contest.
Integration with Unlisting Policy
Slots vacated and reserved by use of the unlisting policy is not subject to the 6-month time limit.
The following is an optional poll on grant of deletion, for gathering opinions.
YEA | NAY | |
---|---|---|
Authors have deletion permission at all times | ||
Authors have deletion permission, barring certain exceptions (define exceptions in comment) | ||
Deletion permissions for certain works should be turned off after some threshold (define threshold in comments) | ||
Deletion permissions should be turned off entirely |
Easy-to-use-template:
||~ ||~ YEA ||~ NAY||
||Authors have deletion permission at all times || || ||
||Authors have deletion permission, barring certain exceptions (define exceptions in comment)|| || ||
||Deletion permissions for certain works should be turned off after some threshold (define threshold in comment) || || ||
||Deletion permissions should be turned off entirely|| || ||