WiKirby:Proposals/Failed Archive

The following proposals have been rejected by WiKirby's community:

Proposals

Treat internal data titles as conjectural (May 30th, 2021 - June 12th, 2021)

Following a discussion with fellow staff members of the wiki, I would like to propose a small change to the Naming policy regarding the status of titles based on internal game data. Currently, WiKirby treats these names as official for the sake of categorizing articles as well as determining whether or not they should receive "Good" status. However, I've come to take issue with treating these names as official for the following reasons:

1. Retrieving these names requires referencing the internal data of games, which strictly speaking is not legally accessible to the public. As such, these names cannot be formally cited without violating our general content policy, and as such, should be considered unverifiable for that reason.
2. These names (where they differ from official names) were never meant to be the formal names that the entities in question would be known by, or they would have been publicly revealed. In the event of no official name for the subject, it can be helpful to reference internal names where possible, but with the idea that they are not the proper names.
3. In some instances (such as the internal name for Bombot "Crap"), the name does not quite match the way the entity appears or functions, and/or may be awkward to use. If this was an official name, we'd have no choice but to use it, but in this gray area, I think it's better for all our sake that the internal name be ignored.

Specifically, if this proposal passes, the DataTitle template will be altered to re-categorize under "Articles with conjectural titles", and the naming policy will be changed to reflect this re-categorization. Additionally, articles marked as "Good" with internal data titles will have their status revoked, and future candidate articles with internal data titles will not be eligible for "Good" status until such time that an official and public name is found for it.

I believe that is the extent of it. Let me know if there are any concerns. --Samwell (talk) 23:20, 30 May 2021 (UTC)

Support

1. Treat them unofficial and (for wiki purposes) unverifiable. Case-basis, what the policy already says (these may be used as additional sources to back up names) they can be helpful to make a good conjectural title, but should be valued at the same priority as any conjectural titles. Thanks to Samwell for clarifying below. ⁠–⁠Wiz (talk · edits) 23:50, 30 May 2021 (UTC)

Oppose

1. They're still names the developers used themselves to some extent, at least, so I don't think we should group them with completely made-up titles. Magma (talk) 23:29, 30 May 2021 (UTC)
2. Yeah, I disagree with this thinking. I don't think we need to illegally share ROMs to verify that the data exists within them; if multiple outside sources can corroborate the information, such as other wikis or dataminers, then that should provide us with the verifiable evidence without violating the content policy. I think of it as a similar case to Japan-only content, like Kirby Wii Music Selection; while that album was never intended for distribution outside of Japan, its contents have been covered online by numerous other sources, which provide us enough verifiable information to create a comprehensive article about it without having to pirate the album.
   I don't think internal names should be treated as end-all-be-all official, but I don't think they should be considered conjecture, since they are what the developers officially used to an extent. If an internal title is suitable for the subject—so obviously not like "Crap", but more like Burner Guardian—I see no reason why that should hold it back from being marked "Good". StrawberryChan (talk) 03:34, 31 May 2021 (UTC)
3. As StrawberryChan said, just because we can't share it legally doesn't mean that we can't cite it. In addition, while it is possible to make up a name, you could also theoretically do that for anything cited from the games, and names are no different. Like with citations from the games, internal names are verifiable by looking at your own copy of the game, with the only difference being that you have to dump the ROM first to do so. As for names not being official, they are still names used by the developers and therefore different (at least to an extent) than names made up by a fan. ---PinkYoshiFan 21:04, 31 May 2021 (UTC)
4. Actually, I don't think having an internal or conjectural title is a reason to not be featured, so I have to disagree. --kirb 23:11, 31 May 2021 (UTC)

Neutral

1. I am going to stay neutral for now, and see how the discussion goes. As a software developer, I know it is a good practice to give names to your variables, files, objects etc when you work on software, but not everyone does it. But, judging from the Kirby games I've seen internal files of, HAL does a great job at doing that. That is of course not a rule, plus you have to remember HAL is a Japanese company, and, this time as a non-native English speaker, using English words wrong or just mixing two languages to name data is also very common when you're coding. Many Kirby games have a mix of English and Japanese names internally. So, considering all this, ideally, I would rather just make the conjectural part of the naming policy be more flexible, and we would decide which internal names are accurate and which are not, and which ones could be adapted (again, many times they're in Japanese, or have Japanese parts). At the end of the day, these names are a weird gray area, but they are still more official than fan names, which is why I don't agree with considering them a subcategory of conjectural names. - Gigi (talk • edits) 21:26, 31 May 2021 (UTC)

Discussion

Now, I'm already seeing some opposition roll in. To those inclined to oppose, I want you to make the case of whether or not a name should be verifiable for an article to be marked "Good". If if you think it should be verifiable, then you need to answer how an internal data name can be verified without referencing an illegally-distributed ROM. If not, then you ought to be able to answer why it's okay for us to mark articles that have non-verified titles as "Good". --Samwell (talk) 23:34, 30 May 2021 (UTC)

ROMs can be obtained legally, just so you know. If you have the game, there are various means of dumping a ROM. Of course I won't mention them, but please don't think ROM = illegal. Also, by this logic, we couldn't accept any images or audio ripped from games, as they're all gotten from ROMs. - Gigi (talk • edits) 23:41, 30 May 2021 (UTC)

I didn't say the ROM couldn't be obtained legally. I said it couldn't be distributed legally. In order to verify an internal data name, I think it would be necessary to distribute a ROM, since simply having an image of a file path or something of that source is not sufficient, due to it just being an image that cannot be verified without the ROM. --Samwell (talk) 23:43, 30 May 2021 (UTC)

I see it now, but I still don't see how it is different from referencing a guide or something, that we can't know for sure if it's the real deal with just a picture (it could be fabricated). If we need more verification, we can always ask whoever provided it, mainly if it's an obscure guide, such as in the case of the recently added picture of Shinichi Shimomura. We could always have more than one person verify in-game files or something if one person as a source isn't enough. Or just... trust whoever sources it if it's a trusted user like a staff memeber. I don't know, I just fail to see how this is an issue here, unless we start to make sources a requirement for every single article name, and for me that's overkill.

And to clarify, I'm not against this proposal, I just don't think this argument holds water. - Gigi (talk • edits) 00:09, 31 May 2021 (UTC)

It is a bit of a gray area, and I can see where you're coming from. My main point of distinction is whether or not the source material for something can be verified without resorting to legally questionable methods. I am under the general belief that every article dealing with a specific subject needs to have a verifiable name, and if that article does not have a citation after its name, then it can generally be understood that the name is verified by easily accessible information, such as the game(s) it comes from. When dealing with more obscure subjects, it is reasonable to expect a citation for its name, and in many cases, those can be found through in-game text, manuals, developer commentary, or similar. In order to properly cite a name based on internal game data, therefore, it should be expected that one directly reference the internal data from where it comes, instead of just saying "this came from internal data" as we currently do. How should one make the proper citation in a trustworthy and legitimate manner? If you can think of a reasonable way to do this, then I can withdraw this proposal. Otherwise, I think we should err on the safe side and treat these names as unofficial. --Samwell (talk) 00:19, 31 May 2021 (UTC)

I understand where you're coming from, but internal data isn't the only kind of names that aren't easily found by someone in the Americas. Again, I want to talk about Japanese guides, and go further to music track names like StrawberryChan mentioned, and earlier today I remembered of an edit I did on the Hyness page around a month ago, that cited a Japanese only magazine, Nintendo Dream, that I could not easily even find references of online (I got hold of this information thanks to an r/kirby Discord user who I trust, and since this was shared by him over two years ago in that Discord, I had to do further research to find out what exact edition of the magazine it was, plus find a single user on Twitter that talked about that part of the interview of the magazine). That is why I don't understand why internal data should be the only one that needs to be more specific when we source it, when we do when it comes to other pieces of information that are as hard, if not harder, for us to find. And it is really not possible to be more specific when it comes to internal data, unless we sourced an specific file or folder (eg. "from internal data of its 3D model"), and even then, again, I honestly don't see why we need to be specific.

Much how we treat information that is not easily accessible due to the fact that Kirby is a Japanese game series and we're an English wiki as verified if it comes from a trusted user, I fail to see how we cannot do the same for game files. - Gigi (talk • edits) 21:18, 31 May 2021 (UTC)

A little clarification

Just to be clear, the proposal does not seek to merge the categories "Articles with titles based on internal game data" and "Articles with conjectural titles" together. Instead, the former will merely be made a sub-category of the latter. --Samwell (talk) 23:56, 30 May 2021 (UTC)

Scrap the weekly rotation on featured articles and images (April 13th, 2021 - April 27th, 2021)

So, it's come to my attention that we seem to be having trouble remembering to manually update the featured article and image rotation every Sunday. Due to this persistent negligence, I think it may be best to scrap the rotation system altogether and go back to how things were done before: that is, only showing the newest feature on the main page at any given time. Perhaps what we could do instead is have a cycling set of links to previous featured content similar to how the DYK template operates which automatically updates every day, which would display below the main featured content boxes, but that would be separate to this specific proposal. --Samwell (talk) 20:19, 13 April 2021 (UTC)

Support

Oppose

1. As the one who proposed implementing cycling in the first place, I can't agree at all. How do we know we can have a constant feed of new FAs, and not end up with another KDL2 situation? How do we get an older FA featured again? We have a host of fine articles that were featured in the past, and I don't see a justifiable reason to just ignore that. Featurement doesn't mean a whole lot when it's just a one-time deal. And if the problem is simply forgetting to update it, perhaps there's a way to automate it; but either way, I fail to see how that in itself is a justifiable reason to scrap cycling altogether. If you have revisions to the current system in mind, I'm all ears, but I just can't agree with going back to the way it was. --YFJ (talk · edits) 04:11, 14 April 2021 (UTC)
2. Like Gigi said in the comments, it would probably be better to make the system more organized (rather than destroying it), and like YFJ said, previosly featured articles should still get shown on the main page at some point, especially to avoid an FA that doesn't ever get changed. ---PinkYoshiFan 14:30, 14 April 2021 (UTC)

Neutral

1. I'm indifferent about this. While the current system is by no means perfect, this one has problems too, as YFL pointed out above. Additionally, I don't mean to sound rude as I lack knowledge and experience, but why would taking a step back be the solution? I'm sure there was a reason why it was changed before. Wouldn't it be better to come up with a new, improved system? Infinite Possibilities (talk) 10:00, 14 April 2021 (UTC)

Discussion

About the rotation, and how it often doesn't happen because it's forgotten, I wonder if that's due to how it's just a task that isn't very organized or documented anywhere. Wouldn't it be better to try to delegate the task to someone (or a group of users) and/or create a guide on how to update it? And perhaps create a supplementary page with a list of all featured pages and articles to help with the rotation. Just some ideas that came to my mind. In short, I just think we could try to make the system easier for updating rather than scrap it entirely, and while I thought of automatizing the rotation, it may not be needed if we can just organize the task better. - Gigi (talk • edits) 14:23, 14 April 2021 (UTC)

"NIWA wikis" template to replace its notice template equivalents (March 31st, 2021 - April 14th, 2021)

{{:User:Vipz/Sandbox|transcludesection=NIWA wikis
|title=This template
|Nookipedia=Template:Other Wikis
|NWiki=Template:Otherwikis
|SuperMarioWiki=Template:NIWA
|XenoSeries=1
}}

There was this template in my backlog of ideas, and it came up to viably replace Template:SmashWiki, Template:MarioWiki, Template:MetroidWiki and Template:NWiki in order to condense the space multiple such interwiki links take, as well as to distinguish them from maintenance-related notice templates.

Current templates look okay (or even better) on smaller (mobile) resolutions, but I think they are sometimes obnoxious with their yellow tone and take too much space when used, especially in sections. This alternative would work well in "External links" sections, although there are examples where it could be less wieldy to use.

Note that =1 will link to {{FULLPAGENAME}}, otherwise to another specified article. —Viperision (talk) 13:48, 31 March 2021 (UTC)

Support

#The pink not looking like the improvement templates (and more Kirby-like) and the whole thing being more compact (especially if there are multiple interwiki links) are both great. This also would fix the fact that not every wiki has a template, which while not necessarily a problem, doesn't hurt for consistency's sake. ---PinkYoshiFan 23:01, 1 April 2021 (UTC)
#This looks like it'll be a nice improvement. Having the notice templates look like maintenance ones is inconsistent and takes up space, so this will be a better way to handle these interwiki links. --DeepFriedCabbage 20:58, 10 April 2021 (UTC)

Oppose

Neutral

• This seems like a good initiative to cut down on notice space. That said, I do wonder how truly necessary this is, since not a lot of our articles will have/need links to multiple different wikis. Also, I'm wondering if it would be better to format this so it appears on the left side of the page, rather than the right. --Samwell (talk) 15:10, 31 March 2021 (UTC)

Discussion

Re: @Samwell, yeah I thought about it, only a handful of wikis will ever be inter-linked in mainspace this way (the fact there are only these four templates for this purpose shows itself), relatively low number of times. As for the alignment, a parameter can be easily made to appear anywhere you want. Nonetheless, this proposed template is meant to just be an alternative for wherever the mentioned four templates are used. —Viperision (talk) 22:59, 1 April 2021 (UTC)

I wondering - where this template will be put? Not every page has external links section, and making such section solely for this template doesn't look nice (especially when it's on the right). Superbound (talk) 15:46, 10 April 2021 (UTC)

I imagine it could just go wherever the current templates for this stuff go now, at the start of pages or sections (should work fairly well as long as a parameter to make it on the left is implemented). ---PinkYoshiFan 17:14, 10 April 2021 (UTC)

I think it would work a lot better being in the bottom section, off to the right, like MarioWiki handles it. If we just had one of these replace all of those notice templates, it would be much more obnoxious. --DeepFriedCabbage 20:58, 10 April 2021 (UTC)

@PinkYoshiFan here it would look horrible in my opinion.

@Obsessive Maroi Fan there's problem, as this wiki almost universally uses {{ref}}, making it impossible to put it there, and it would be awkward having this template in urelated section like "Names in other languages" or "Gallery". This is how it would look like if put on one of the smaller articles in the bottom section, where it's rather unnoticeable in my opinion. Superbound (talk) 05:59, 11 April 2021 (UTC)

I thought we would just handle it like I mentioned, but I forgot about the ref thing, and the ways you've shown don't look good at all. I'll withdraw my vote on this for now. --DeepFriedCabbage 06:45, 11 April 2021 (UTC)

{{ref}} can be modified to include an optional parameter for code injection between ==References== and <references/> to make this template usable in that section like on SMW. For the Metroid article example - I haven't figured out how to give margins to infobox templates (ideally these boxes wouldn't touch). Here are two alternative ways with left float (separated from text by placing the template in a new paragraph). Regardless of this template, this is how the current MetroidWiki template would look with "lightpink" border and "pink" background.

Some articles don't have a "References" or "External links" section, but placing it in the very bottom right above navboxes seems how other wikis handle this. —Viperision (talk) 12:42, 11 April 2021 (UTC)

Y'know, it was suggested on the Discord by erika that instead of having a separate template for linking to other NIWA wikis, we could instead add those links to the infobox for the subject in question. I think making the infobox slightly taller in order to cut down on other more intrusive templates may be the best solution here, and probably something we could enact without needing to make it a proposal. --Samwell (talk) 13:46, 11 April 2021 (UTC)

That seems like a good idea, but what about articles line Nintendo that don't have infoboxes? ---PinkYoshiFan 14:01, 11 April 2021 (UTC)

I think we could keep the old notice templates for articles like that as a temporary measure. Ideally, the Nintendo article should have an infobox of some kind or other in future. --Samwell (talk) 14:06, 11 April 2021 (UTC)

I like the infobox idea, albeit that idea derails from this proposal entirely, which means that most likely it will need to separated from this. I don't mind creating {{Infobox-Company}} or {{Infobox-Staff}}. Also if it comes to existence I want to create a special template for inserting interwiki links here to preserve icons as they look cool.

If that doesn't come into play however, I'm not against modifying ref template like you suggested @Viperision.

Putting NIWA template on left just looks... ugly, I prefer the above mentioned infobox solution.

Pink notice templates could work as a (hopefully temporary) notice template on pages without infoboxes, through as a replacement for current ones don't make sense - one of the points of the original idea was to reduce space taken by them, and it won't work like that.

And my final, a little bit small, worry, is that "slightly taller [infoboxes]" might not be just "slight" in case of some pages. Superbound (talk) 18:34, 12 April 2021 (UTC)

I think we might end up doing the infobox solution over the one in my proposal. In that case, I'm not sure whether the original proposal is to be vetoed (regardless of the vote outcome). I'll try to make these into the infobox in near time. ⁠–⁠Wiz (talk · edits) 19:18, 12 April 2021 (UTC)

We could just make the link section collapsed by default, but yeah, this isn't the same proposal anymore. Since it's at less than three support and zero oppose, it's just going to go on infinitely unless something happens... Should I change my vote to oppose then to stop this proposal? ---PinkYoshiFan 20:36, 12 April 2021 (UTC)

You don't necessarily need to change your vote, since the rules stipulate that at least three supporting votes are needed to make a proposal pass, and there's only one right now. I suspect this discussion will go into the failed archive pretty soon. --Samwell (talk) 20:22, 13 April 2021 (UTC)

@Viperision I've created an infobox part for infobox solution here, are you going to request to veto this proposal and repropose it, then? Superbound (talk) 12:42, 14 April 2021 (UTC)

Semiprotect featured content (8/7/2020-8/21/2020)

It was brought up on the wiki's discord server by Gigi that all FAs should be semiprotected, which I agree with, since they are some of the best the wiki has to offer and are showcased on the main page. This is what I am proposing:

• Semiprotect all featured pages and images for the reasons listed above
• Update WiKirby:Featured content policy and possibly Help:Protected Page to reflect this change

---PinkYoshiFan 20:26, 7 August 2020 (UTC)

Support

1. FAs, but not necessarily because they're so (could as well be the popularity of the subject), are too often vandalism-targetted. 2–3 months ago it happened with Meta Knight and King Dedede, at likely a well planned time frame with no admins available at hand (with why patrollers should have some rights to intervene a mass real-time vandalism idea). Autoconfirmation is very easy here, it also encourages potential editors to look around the wiki, but be it a spelling mistake or a larger edit there's always the talk page or mere wait of a day and 5 edits. We don't have that many FAs to be targetted, or edits that they could fly under the radar, but between those could be cherrypicked (popular subjects) before it happens. —Viperision (talk) 15:40, 8 August 2020 (UTC)

Oppose

1. Personally, I do not like the idea of semi-protecting all featured content by default, because it may end up discouraging new users from editing. Despite how it may seem, vandalism is actually a relatively rare occurrence here, and we can deal with protection on an individual page basis without too much issue. That is just my thought on the matter, and I am fine if people don't agree with me on this. --Samwell (talk) 20:28, 7 August 2020 (UTC)
2. I agree with Samwell, this action probably would chase away new users. Maybe autoconfirmed users only would be a better choice? However, that still could affect new users. MetaDragon (talk) 23:09, 7 August 2020 (UTC)
3. Per Samwell, I think pages should protected only when nessecary. Unlike what you say, not all fc is showcased on the Main Page, it only links to category with other featured articles (images don't get this treatment). However, I could go on compromise and semi-protect featured content that is currently on the front page Superbound (talk) 08:34, 11 August 2020 (UTC)
4. Agreed with only protecting featured content when necessary. For example, major characters like Kirby and King Dedede tend to be the most frequent targets for vandalism, but a song page like My Friend and the Sunset or The Greatest Warrior in the Galaxy wouldn't be as vulnerable. StrawberryChan (talk) 04:59, 16 August 2020 (UTC)
5. Honestly not a fan of semiprotecting pages unless absolutely necessary. We don't get a whole lot of vandalism here and if anything this would just discourage new users from editing. Obviously we wouldn't want a random vandal blanking Kirby, but semiprotecting every FA just seems counterproductive to me. Oppose. --YFJ (talk · edits) 05:41, 18 August 2020 (UTC)

Neutral

1. I've been thinking about this proposal for a while, mainly when it actually sparkled due to a comment I made in the Discord server. I originally made the comment after waking up, as a quick thought I had, without thinking too much about that. I never expected it to then become a proposal like this, so it felt a bit awkward for me to vote on this in the first few days. Now that I've thought about it a lot more, I've ultimately decided to stay neutral on this. While I do think most of the Featured Articles probably need to be semi-protected because they are huge articles with lots of details, and probably only need further edits to fix small things, I don't think literally every one needs to be as a rule, and some may get featured but be missing something that is big enough, such as this example. So with all things considered, if this passes I wouldn't mind it, and if it doesn't as well I don't think it will be a big deal, but I will however do start suggesting administrators+ to semi-protect certain pages if I feel they are target of bad edits, but it will be case-by-case as it is right now, of course. Gigi (talk) 14:24, 17 August 2020 (UTC)

Discussion

Hey MetaDragon- I mentioned in the proposal that it would be semiprotected, not fully protected, which is autoconfirmed only like you mentioned. As for chasing away new users, I don't believe it'll be that big of an issue since we have some of the laxest autoconfirmation requirements I've seen in NIWA. (Not saying that needs to be changed though) ---PinkYoshiFan 14:13, 8 August 2020 (UTC)

Ah, thanks for the heads up. As always I must take time to consider, I may decide to support after then. MetaDragon (talk) 18:03, 8 August 2020 (UTC)

Images in custom sigs (May 24, 2020- June 28, 2020)

As you may (or may not) know, there are some wikis that allow images in custom sigs, and some that do not. The current reason given by the page about custom signatures is "We'll accept symbols and wingdings, but full images are simply distracting to talk page posts." Images can be slightly distracting, but they should be fine as long as no animated images are used. It has been mentioned on the discord server for the wiki that it would make the file usage list large, but Special:Whatlinkshere can be used to only search for certain namespaces. Finally, there is the slight issue of the fact that images space out lines, but if they are small enough, that shouldn't be an issue. The screenshot is from smashwiki, which has a policy of only letting images be 20px high, which should work as a standard for us. Also, there would be a limit of one image per sig.

To recap, the proposed policy change is to allow images in custom sigs, but only one per sig, they must be 20px high, and they cannot animated. ---PinkYoshiFan 14:42, 24 May 2020 (UTC)

Support

1. Weak support. Everything seems reasonable, altrogh I'm still not convinced that hiding certain namespaces would justify using mainspace images. Superbound (talk) 16:46, 25 May 2020 (UTC)

Oppose

1. I'll go with oppose for now, for the same reason you cite from Help:Custom Signatures. There have been a few users with those already and some created text line misalignments, which, I suppose, could universally be resolved with font-nearing height limits, but it could still become distracting from the important discussed content. Less is more after all, just look at Superbound's signature. —Viperision (talk) 23:29, 16 June 2020 (UTC)
2. Took some thought but I'm going to side with Viper here, it's probably best if we keep things the way they are. There are plenty of ways to make your signature unique but there's a fine line between unique and distracting, and images may well fall into the latter category. --YFJ (talk · edits) 17:13, 27 June 2020 (UTC)

Neutral

What are the diffrences between symbols, wingdings and images? Superbound (talk) 07:13, 25 May 2020 (UTC)

It appears from Googling that symbols and wingdings are actually a typable font, while images are not. Also, images have much more potential to become complex. ---PinkYoshiFan 12:28, 25 May 2020 (UTC)

Alright. Superbound (talk) 16:46, 25 May 2020 (UTC)

Can these get archived? ---PinkYoshiFan 17:32, 30 June 2020 (UTC)

Split 3D Warp Star from Warp Star (May 15, 2020 - May 15, 2020)

3D Warp Stars that debuted in Kirby: Triple Deluxe have been merged with the Warp Star page. However, 3D Warp Stars look and function quite differently. Regular Warp Stars transport Kirby to a different area (with a short cutscene), and the more common 3D Warp Stars quickly move Kirby between planes. I think they are different enough to have their own page. --DeepFriedCabbage 19:35, 15 May 2020 (UTC)

Support

1. Yeah, that sounds fine. Not much need for a proposal in this case, I think. StrawberryChan (talk) 19:39, 15 May 2020 (UTC)

Oppose

Neutral

Discussion

Vetoing this proposal so this can be moved to Talk:Warp Star. --YFJ (talk · edits) 23:07, 15 May 2020 (UTC)