Nookipedia talk:Deletion policy

Proposing

Policy enacted after discussion and support. ~SuperHamster Talk 13:50, April 20, 2021 (EDT)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page.

---

Originally written in December and finally bringing this up for enactment - please give it a review, suggest any changes, and list your support/opposition. ~SuperHamster Talk 03:17, March 6, 2021 (EST)

Theres a lot here that I like and a lot here I do not. I believe it is easiest to read down the page and respond to what is present.

• To start, I do not understand the purpose of tagging specific people (mention "original creator") in the deletion template, and do not understand why there is both a reason and note parameter, since they could both reasonably accomplish the same thing.
• I can support having necessary reasons. The clear cut vs discussion deletion tactic seems perfectly reasonable to myself though I would encourage having a set time after deletion is requested (IE 90 hours after the tag is set; definite number) so that the period is wide enough that people that are not daily editors or are away can still have a chance to voice opinions.
• I am hesitant to support only staff removing deletion tags because I feel like there can be non-vandalism reasons for removing it.

• Article deletion requirements seem acceptable.
• Files generally seem fine, though I would encourage the creation of an archived/not-unused if there isn't one already (I truthfully forget!) to explicitly state some elements should not be deleted, even if seemingly unused. This should apply to categories and templates as well.
• Speaking of Templates/Categories, are there any particular things that should be stated about these types of pages? I feel as though they are generally common enough to warrant something.
• What happens to users that retroactively have more than 5 images? Are they all immediately approved? This should probably be clarified.
• I do not disagree with the User section per se, but find it incredibly vague to the point of just not really having a point. As a semi-active user on this site and others, I have never once found the need for more than additional 4 pages, which could reasonably be capped at 5. For maximum productivity, 5 pages with talks could reasonably used as 10 spaces. This doesn't include the already existent User: page. Perhaps a system is created where people can apply for more pages with specific reasoning as to what these pages would be used for in the excess of 5.
• There is a drastic lack of notation on Talk pages. I find that there can often be talk pages that serve no relevant purpose or no longer apply to the page, or rarely, talk pages will exist of pages that do not exist anymore. Something should be developed for these types of pages.
• You knew this one was coming so I'll be as thorough as I can about it. I fundamentally do not believe there is any need to use file, template, category, and talk redirects. I have yet to find a single issue that cannot be very easily resolved in some manner. There has been extensive discord discussion on this but to summarize, names can easily be replaced on pages, stuck out, or used as inline redirects [[New name|Old name]] without extensive harm. If we can replace all sorts of other aspects over time like text, templates, or tables, there is no reason to worry about file redirects. Page history in the history tab is still observable plenty fine. When deleting a file or similar, the new file name can not only be placed, but also linked to the new file. This allows the astronomically tiny chance of people using external links or looking at old standard page histories to locate new names for files--and could it not be argued that artificially preserving files on old page revisions is inauthentic to the content that was there? Redirects cause fewer links when browsing AllPages and can still be searched for and used in both the search bar and the autofiller. New users that are not familiar with the MediaWiki program may find frustration in why they cannot see say "Space.png" thats on the page they are on when they're taken to "Space PG Icon.png" instead. Most moves from file names are going to be done one time to upgrade from either a poorly formatted collection (for example, the recent AlbumArt-NH-Name to Name NH Texture) or from just having obnoxiously terrible names (RUU016.jpg, Screen Shot 2021-03-06 at 3.13.40 PM.jpg etc). Most of these file moves are on single, small pages and will not cause drastic widespread changes. Additionally, redirects could block the creation of other appropriate names for files and cause issues later when a name being used as a redirect is necessary for a new upload (For example, Violet NH Icon -> Violet NH Sprite). While somewhat disputed, it could be possible for someone to have a long chain of redirects leading to one image, which is completely unnecessary.
• whew thats a lot i just wrote there
• Anyway, if there ARE file redirects to be kept with things like Cargo or autofilling templates, then once again a not-unused template can easily be used to fix the issue.
• I agree with the undeletion ideas (and find it better written than other places) but would suggest that deletions of any page of any degree need to have over-explicitly clear reasoning as to why the page was deleted so that people don't attempt to revive pages that have no reason being revived.

Hopefully that has provided a significant amount of insight as to where I stand on this. TLDR says delete file redirects and to expand on some smaller specifics before making this a policy. Trig - 15:24, March 6, 2021 (EST)

I believe any sort of articles getting deleted should have a log and be archived in a place where we can see the discussions heading to deletion. I also believe the delete template should be allowed to be removed by anyone because it's not a big deal who removes it as bad removals are easily reverted and this just puts unnecessary heap on staff work. ™ 16:54, March 6, 2021 (EST)

Thanks for reviewing, both of you. Responding to Trig's comments point by point:

• Re. informing the creator, that is via their talk page, not in the deletion template. I've updated the text to make this clear. If I create a page, it is very likely that I would want to be informed that it has been nominated for deletion. In addition to being good courtesy, creators will often have the best insight into why something was originally created, potential use, etc.
• Re. timing, I've left the option of immediate deletion, but also added a recommendation that deletion discussions (when they occur) should be left open for at least seven days.
• I've re-written the closure process to allow any editor to close.
• For unused files/templates/categories that should be kept, we do have Template:Do Not Delete.
• I may be wrong but I don't think template or category deletions are too common, and I don't think we have many norms around them. If anyone wants to write something up feel free, but I'm fine with keeping the policy as-is and maybe adding them in later.
• Re. limit of 5 personal files, that's existing policy, not new, so no need to specify any retroactivity.
• Re. userspace, to clarify, users can have as many subpages as they want if they are related to the wiki; the restriction is only for personal subpages unrelated to the wiki, such as documenting towns/islands. I've added a note that the general recommendation (soft cap) is no more than 3 personal pages. We don't generally have a problem with too many personal subpages, so I'm not really interested in introducing a hard cap, keeping track of pages, and having a system for users to apply for more subpages. Basically, if someone's personal usage of a userspace is extensive enough to draw attention of staff, then we'll talk and sort it out.
• Re. talk pages, I added a note that a deleted page's talk page should also be deleted, unless it has a deletion discussion that led to the page's deletion. Other common reasons for deleting a talk page (nonsense, out of scope, etc.) are covered by the rules that apply to all namespaces.
• Re. file redirects, it is not an astronomical tiny chance that we have external links - at a cursory glance, we have at least a thousand inbound external links to file pages. Over time as files are moved, inbound links break, which not only creates an unideal user experience, but it also impacts our SEO as these links lead to 404s instead of redirects. I'm not sure how file history would be inauthentic - the history will show files how they were meant to be shown at the time. But more importantly, when I'm looking at page history, I want to be able to click on a file and immediately be taken to it, instead of having to (in the case of galleries) copy the filename, search for it, and look at the deletion logs to find the new file. I'm not really concerned about the impact to new editors, because redirects are a core part of MediaWiki and any editor will be quick to come across them and learn how they work - but regardless, it's not really an issue because I am not saying that file names should not be updated in articles after a move, I am just saying that the resulting redirects should not be deleted. Special:AllPages is unimpacted given there's a checkbox to hide redirects. The proposed policy states that redirected names that have foreseeable future use can be deleted, so that is also a non-issue. Search results are indeed impacted by redirects as they do appear as their own results, but I do not think that's a huge deal that warrants their deletion. It basically comes down to the existence of redirects not hurting anything and aiding discovery, while deleting them is unnecessary destruction. Re. redirect chaining, that goes for any and all redirects, and we have Special:DoubleRedirects to track and take care of these (both manually and by bot). I don't think you and I will ever come to an agreement on this eternal battle, so I guess it's up to other commenters to chime in.
• I've added a note that staff should clearly specify deletion reasoning when deleting a page.

~SuperHamster Talk 19:37, March 6, 2021 (EST)

Oh almost forgot: the reason we had the separate note and reason parameters in Template:Delete is because the reason parameter would go into the template's header, while the note goes into the body. I've updated the template so there is just one reasoning field, and it will go into the body. ~SuperHamster Talk 20:01, March 6, 2021 (EST)

(edit conflict) I suppose the new file naming schemes were designed to avoid potential overlapping names (e.g. we don't really like "File:Blue Lamp.png" compared to "File:Blue Lamp NL Artwork.png" as the former isn't very descriptive to begin with and has potential for file name clashing especially if item gets redesigned) but even so, there's no stopping adding more descriptions or even just adding a number to indicate another version. ™ 20:03, March 6, 2021 (EST)

Yea, in the case of something like moving File:Blue Bed NL.png to File:Blue Bed NL Model.png, I would probably want to keep the file redirect as we shouldn't really have any files under the latter name in the first place. But in the case of moving File:Blue Bed NL Icon.png to File:Blue Bed NL Model.png, we'd probably want to delete the redirects if there's a chance we'll see icons uploaded as well. ~SuperHamster Talk 20:08, March 6, 2021 (EST)

Everything looks good! I  Support the enactment of this policy. ~ AlexBot2004 (Talk) 15:24, March 10, 2021 (EST)

 Support the policy in general. vmario97 (talk) 13:18, March 23, 2021 (EDT)

---

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page.