WiKirby:Proposals/Failed Archive

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

Proposals

Autopatrol Badges on Userpage-less Members 031522—032922

This proposal is pretty short and sweet to the point:

• The administration team should not create userpages for users to exclusively add the autopatrol badge.

I believe that users should have the choice as to whether or not they have a page representing themself, and that other users regardless of the reason should not be permitted to create these pages. I have seen at least six users get pages solely because of the autopatrol badge. All users already have a talk page, and I do not see any reason why it cannot simply be added there instead. If the lack of a user page is seen as an issue, why not request one is created while informing them on their talk page about their rank raise? This isn't inherently a problem as much as I find it to be a courteous formality. Trig - 16:57, 15 March 2022 (UTC)

Support

1. Some users probably don't want a userpage, and I support the idea that they shouldn't have a blank userpage created for them by somebody else solely for a badge. Now, if they create their userpage sometime after being granted a rank, they might forget to add the badge. I'm not sure if displaying a badge is absolutely necessary. This situation could be solved by initiating a conversation, and only granting Autopatrol after the user replies back and preferably creates their userpage by request. ⁠–⁠Wiz (talk · edits) 22:28, 15 March 2022 (UTC)
2. Ultimately, if a user dosen't want a userpage, they don't need a userpage. If they get autopatrol, they can have the badge on their talk page. If they make their userpage and have no badge, then it's not really a big deal since you can always check the user talk page or their usergroups. ---PinkYoshiFan 22:15, 16 March 2022 (UTC)
3. It seems unnecessary to require a userpage for the badge. I assume that there are plenty people out there who'd prefer to not have one for understandable reasons. Why shpuld they be forced to have one then? And it's not like this proposal would stop them from ever creating one either. Infinite Possibilities (talk) 19:02, 23 March 2022 (UTC)

Oppose

1. It is my firm belief that any user who enters any rank above Autoconfirmed should have a userpage, even if there's not much on it. I think if we're going to change policy on this, it would be to require users to create a userpage for themselves before they can be given Autopatrol, rather than making a blank page for them. --Samwell (talk) 18:48, 15 March 2022 (UTC)
2. I agree that users should have a userpage in order to posses a rank. --kirb 22:32, 16 March 2022 (UTC)
3. I honestly don't think this really needed to be a proposal, but either way, I also think anyone granted Autopatrol should be required to have a userpage. As said above, it would be a decent idea to instead make it so an editor must create a userpage before being given a badge. It could be brought up on their talk page or Discord as an offer. -- Jellytost♡ (talk) 23:30, 16 March 2022 (UTC)

Neutral

1. I do agree that the current ideal -creating the userpage of an user just to put an autopatrol badge- should be changed, as that is a bit unfair to the user and having a page where the only content is a bronze page isn't so much better as a blank page, but between the two parties here -giving autopatrol as normal but without creating the page, or directly making the userpage a required for autopatrol- I don't really have a strong lean to either of them.
   I do think that an user having a red link to them gives a bit of an unprofessional impression, so a user with that "unprofessionalism" being marked as being a "trusted" user is a bit bittersweet for me. But also, if the userpage is a required for autopatrol, we would definitvely see cases like "Hi I just created this page for autopatrol. There is not much to say for now", and although something as simple as that isn't so bad, as it confirms that the one behind the user is indeed a human, I don't think that that would be ideal either. So I am just OK with whichever decision is took here, both have equal pros and cons for me.
   Either way, I think that notifying the user in their talk page about autopatrolship would be ideal if they don't have an userpage yet: If the ranks is given without the necessity of a userpage, it would be good communicating the user that they were raised, but that the medal wasn't put in their userpage because they just plainly lack one, and if the userpage is a requirement instead, it would be good giving a heads-up that the user in question met every required for the rank except having the page, as in that way the user wouldn't be oblivious about the rank offer. -Kirbeat (talk) 13:53, 29 March 2022 (UTC)

Discussion

I can see the reasoning behind this, but shouldn't it have been brought up as an informal discussion first? This seems too minor for a proposal. ---PinkYoshiFan 16:59, 15 March 2022 (UTC)

Strongly disagree that users need user pages to need ranks. Why should someone need an insignificant and optional page in order for a rank? A low-effort single-line userpage is no different in content than a userlesspage, and is worse for the site space-wise. People have no obligation to provide any information about themselves if they do not choose to. Trig - 21:13, 17 March 2022 (UTC)

First off, I really don't think userpages are at all a significant space issue. Secondly, seeing a username, particularly in discussion spaces, which is a red link just gives off an unprofessional impression for the wiki overall, especially if that user is part of staff. Third, there's no "obligation" to give information about yourself on your userpage. You can put whatever you want on there as long as it doesn't break any rules. --Samwell (talk) 21:49, 17 March 2022 (UTC)

^ My point exactly. Was just about to say that myself. -- Jellytost♡ (talk) 22:09, 17 March 2022 (UTC)

I think userpages are significant. :P I think it would be generally advisable to have one. Even if it's not much, it lets the readers know that there are real people behind the site. --kirb 00:30, 18 March 2022 (UTC)

How is that in any way unprofessional? Because a user has no want to participate actively in an optional namespace that inherently makes them less valuable editors by this merit? If users don't choose to put information about themselves on their userpage, what is left? Is it not worse to see something along the lines of "I made a userpage because I needed to in order to be autopatrolled"? If it was for an administrative position, there is a stronger argument for this, but given that auto-patrol is not a staff rank, it should not have any merit to a user's ability to participate in discussions, especially regarding proposals such as this. If I, as an editor, wasn't allowed to vote on a proposal regardless of how many edits I might have contributed because I didn't have a user page, I would honestly find that absurd. In regards to Kirb's statement, I don't think people will conflate red named users with bots or otherwise not-people. A lack of userpages certainly don't deter editors on other sites such as StrategyWiki, Wikipedia, or any wiki that allows IP edits, and I can feel the "we're not other sites" argument being written already, I remind you that it is a basis of which we can compare ourselves to: It clearly is not an issue for editors of other sites and therefore it should not be made an issue here as well. Trig - 13:22, 21 March 2022 (UTC)

Ease image quality standards regarding sprite-based screenshots (March 1st, 2022 - March 15th, 2022)

Greetings. I'd like to ask for a simple change to our current image standards regarding sprite-based screenshots. As is currently the case, only pristine-quality PNG screenshots may avoid the image quality tag. This makes sense in theory, because we want to present the best-quality images we can. However, I feel like, for screenshots at least, this is unnecessary, since we are not The Spriters Resource. As long as the image can be clearly read, I don't believe it needs to be absolutely flawless.

As such, I would like to propose that jpg screenshots of sprite-based games no longer be tagged with the image quality template, provided they are the correct resolution and have no significant problems. Mind you, this does not mean the images are automatically eligible for "Good" status, simply that replacing them is no longer a priority. What say you all? --Samwell (talk) 03:51, 1 March 2022 (UTC)

Support

1. I never really saw the point in controlling the extension. While jpg is lossy, it doesn't really matter if an image is lossless or lossy so long as the compression doesn't cause any issues with the quality. ---PinkYoshiFan 19:10, 1 March 2022 (UTC)
2. I'm in agreement with this. It feels unnecessarily restrictive to have it this way, and this will shift the focus to images that are actually low quality. -- Jellytost♡ (talk) 21:01, 7 March 2022 (UTC)
3. I don't think that JPGs should be as high up as a priority as some other things. They capture the image well, just not as perfect as PNGs. They are good enough for people to look at them, and understand what going on. Although I am new here, I still understand that everything does not need to be perfect. From looking at this website before registering, and after most of the time, I did not even notice the JPG images. --BasicPerson (talk) 22:43, 12 March 2022 (UTC)

Oppose

1. For a wiki to provide high-quality information, I would prefer to have images be of high-quality. I believe that great strides have already been taken to work on getting new images and would not like to deincentivize that movement. What I could suggest is that this policy is upheld until Project Clean-Up's replacements are resolved to mostly resolved and then we re-discuss the boundaries of loosening restrictions. I would be against ever letting non-native JPG capture screenshots be marked for good, but agree that if there are a substantial minority (>5%) of these screenshots, that it may be acceptable not to use Image-quality but rather just have a maintenance list found on the PC-U. Trig Jegman - 03:54, 2 March 2022 (UTC)
2. Slight oppose; I would also much prefer to have PNG screenshots in general over JPG screenshots. I think it's fine if they aren't tagged with the "low quality" mark, but I do think replacing them should be a priority. Even if it's not visible at a glance, JPG screenshots do still have significant detail loss compared to PNG, and to me it'd be preferable to present sprite-based images as close to the original console as possible. StarPunch (talk) 00:11, 9 March 2022 (UTC)
3. Voting this last minute after thinking for a long time, I will oppose. Sprite based game are called that because they use sprites, and you lose the quality of the sprites when they are saved as jpgs. While one may argue that is not visible many times, that is still an issue, and I do think screenshots of sprite games should be marked low quality when they are jpg files. jpg files have a whole spectrum of image quality, and I don't think that just become some look fine that they shouldn't be treated as low quality. Ultimately, if we stopped marking them as low quality, I feel we would pretend there is no issue, when in reality we do plan to replace them all with pngs in the future. So, factoring all this, opposing. - Gigi (talk • edits) 23:17, 15 March 2022 (UTC)

Neutral

1. It doesn't matter much to me either way. As long as we have the JPG images on a list somewhere, it should be fine for them to not be marked low quality. It's also kinda nice to have them marked. --kirb 16:22, 8 March 2022 (UTC)

Discussion

Just to be clear, this proposal will not apply to ripped game sprites. Those will still need to be PNG and as clean as possible. --Samwell (talk) 03:56, 1 March 2022 (UTC)

Just to reiterate, addressing Trig's opposition:

• This proposal does not seek to mark non-native-resolution jpg screenshots as "Good". It doesn't even seek to mark native resolution jpg screenshots as good. It merely seeks to remove the label of "low quality" from these latter screenshots.
• This proposal does not seek to "deincentivize" getting replacement screenshots for the wiki. The images I am proposing be removed from the "low quality" list may still be replaced at users' discretion with PNGs if/when they want to.
• I challenge the statement that the screenshots addressed by this proposal are not high quality. See these three images for examples of what I am talking about. --Samwell (talk) 15:43, 2 March 2022 (UTC)

To address BlazeBlade's point, it is planned for these images to still be listed on WiKirby:Project Clean-Up if this proposal passes. --Samwell (talk) 20:17, 8 March 2022 (UTC)

PRO Rule Change 2

In the event a user is blocked during a proposal, another user may sponsor the proposal to continue it. It is not necessarily likely that this will occur, but should a user get blocked on a proposal the community at large is voting on, it seems unfair to completely remove it and be forced to wait an exceptional period of time (56 days) for it to be rebooted. Instead, if a person who is available to host it is willing, then they may take the proposal under themselves instead of it becoming cancelled/voided. The time available for a member to adopt a proposal is 48 hours after the blocking of the original proposer, and the proposal should be extended by one day for every 12 hours it takes for someone to adopt (IE, if it is adopted in 5 hours, no extension. If adopted in 17 hours, extend by one day. If by 24 or more, extend by 2 days).

Support

1. Even if someone is blocked, that doesn't neccesarily mean their ideas are bad. ---PinkYoshiFan 13:38, 19 February 2022 (UTC)

Oppose

1. There's nothing to sponsor or adopt; either the proposal passes or it doesn't. Just don't remove it. ⁠–⁠Wiz (talk · edits) 05:33, 21 February 2022 (UTC)

Neutral

1. I really don't have strong feelings either way here, personally, mostly because I believe this case would be very unlikely to happen. - Gigi (talk • edits) 16:37, 20 February 2022 (UTC)
2. I agree with this change on principle, but I think you've overcomplicated it with the extension clauses. I think a flat 3 days to sponsor a proposal if its original proposer is blocked should work just fine. --Samwell (talk) 17:04, 20 February 2022 (UTC)
3. I agree on the above. Decent idea, but no need for so many steps, especially with how unlikely this is to happen at all. -- Jellytost♡ (talk) 02:19, 1 March 2022 (UTC)
4. I agree that a proposal shouldn't be removed along its user, as the user getting blocked doesn't necessarily say that the proposal isn't a stable one. There is already the Restriction #2 which specifies that "Proposals which violate the law, as specified in the general content policy." shouldn't be done. So, if we have a user that does a wacky proposal, be by violating the general content policy like fully covering a Mario game that has nothing to do with Kirby, or some other extreme thing like "removing this wiki", to say something, would be removed anyways, be the proposer blocked or not. Also, I don't know if in the actual case in which the proposal is removed along the user "blockement" another user should wait 56 days to propose the same thing again, as the 56 days things mention that it apply to proposals that are "approved", "rejected" or "vetoed by the administrators", while proposals that are taken down by its proposer being blocked is counted as being "removed", so I don't know if the 56 days of wait also applies to that case, as nothing seems to deny that a proposal can be re-proposed immediately if its user is blocked.
   So, while I do agree that the proposal being taken just because its user is blocked is unfair, I don't think that the actions proposed here are the best way to go. My ideal way of thought would be to just keep the proposal up as normal and that's it, effectively removing the second section of the Voting regulations rule #2, which seems to be Vipz'(s?) way of thought. If the user is blocked by doing a lot of out-of-place things, including the proposal, then it would be removed anyways, but if the reason of the block doesn't have to do with the proposal at all, I don't see why it should be removed. If that doesn't go through tho, my second way to go would be to let anyone retake the proposal, but without any 56 days restriction (which, again, seems to already be the case as nothing seem to deny it), but probably adding some separation period between the removal and the "retakement" would be good to cool down things a bit, and a 3 day of spacing as Samwell suggested would be a good period.
   It's just that I don't oppose this proposal per sé, as I think that removing the proposal in cases like these is unfair, but I don't support the way suggested here either. I think that one of the two ways that I suggested here (not removing the proposal or removing it but letting other user start it closely, either with or without 3 days passing) are better options than that one. -Kirbeat (talk) 07:46, 1 March 2022 (UTC)
5. I don't see a reason to make this so complicated. If the proposal of a blocked user doesn't break any other rules, wouldn't it be easier to just keep it? Well, as it stands there's too many extra clauses in my opinion to fully support.Infinite Possibilities (talk) 07:23, 5 March 2022 (UTC)

R2 Discussion

In regards to Vipz's comment, rule 2 states that "Any proposal made by a user who is blocked during the consideration period will also be removed", which means that if the original user is blocked then the proposal wouldn't pass even if it has unanimous support. ---PinkYoshiFan 19:13, 25 February 2022 (UTC)

I think Vipz is trying to say that this proposal should be changed to suggest that the rule be removed entirely, rather than being given a sponsorship clause. --Samwell (talk) 19:15, 25 February 2022 (UTC)

PRO Rule Change 4

Failed proposals should not be started again for 60 days. This is to focus more on months as the duration for time instead of weeks.

Support

Oppose

1. This one I don't think is necessary. 8 weeks is still essentially two months, and everything else in the proposal process runs on weeks, so this should as well. --Samwell (talk) 17:04, 20 February 2022 (UTC)
2. This seems... very unnecessary. Really there's no need to change this, and as said, the rest of the process runs on weeks, so changing this would cause very unneeded inconsistency. -- Jellytost♡ (talk) 02:19, 1 March 2022 (UTC)
3. Yeah so, I understand the point here in that months are a more general thing than weeks, and that "2" is a easier number to keep track of than "8", but I really have to oppose to this thanks to the months not having a set number of days.
   Every week in existence has it length set: 7 days. While months instead aren't so set, as there are months which duration is 31, others which duration is 30, and then there's February which is either 28 or 29. So my problem with this is that, using two months as a way to keep track of things isn't stable. For example, if we have a proposal that, say, ends in March 3th, and we say that there are "two months" before it can be taken again, we would have a conflict: If we literally wait to the same day in two months, May 3th, we would wait 61 days, not 60; but if we wait the exact 60 days, it wouldn't be two months because it would be on May 2nd, thus one "day number" before. Even worse if we have an example with February.
   So as not every month have a set time-spam of 30 days (just 4 of all 12 have), we would be in a conflict like the one I presented before, independently of which measuring way is taken: If we go for exactly 60 days, the number of months couldn't be took exactly because of the day numbers, and if we go with the same date in two months, it would be between 59 days and 62 days, and actually, never 60, as there aren't two 30-days months next to each other. As you can see, the thing would be very unstable.
   And well, weeks aren't like that! As I said, every week is and will always be 7 days long, no matter what, thus: weeks are more stable. And again, I get that keeping track of the number 2 is easier than 8, and that months are more general than weeks, but really it is better having a more stable way of measuring things than one that is unstable. -Kirbeat (talk) 07:46, 1 March 2022 (UTC)

Neutral

1. A difference of four days doesn't really seem that big of a deal, and I don't think anything else on the wiki uses months over weeks for time between things. ---PinkYoshiFan 13:38, 19 February 2022 (UTC)
2. I really don't lean either way here, I feel using either metric works well and just requires some different math. Either should be good. - Gigi (talk • edits) 16:37, 20 February 2022 (UTC)

R4 Discussion

Wait, does it only apply to failed proposals, or to overturns as well? Otherwise we would have inconsistency for no apparent reason. Superbound (talk) 19:57, 27 February 2022 (UTC)

PRO Rule Change 5

Allow multiple proposals by the same user. Naturally, to avoid flooding, each proposal by the same user must be spaced by at least one week (seven days) from the first. Furthermore, for whatever weird circumstances would allow it, no user may make more than three proposals in the span of 30 days.

Support

1. Multiple proposals would definitely be a good thing if someone has multiple ideas or even just one idea taking multiple proposals (for example, it took a month to pass both uerlang proposals, but this would shorten that time by a week). ---PinkYoshiFan 13:38, 19 February 2022 (UTC)

Oppose

1. Opposing this one because I feel it's unnecessary if we allow proposals to pass in only one week if there is enough support. Controlling the 30 days also feels more complicated than needed. I feel it's much simpler to just not allow anyone to have more than one active proposal at a time. - Gigi (talk • edits) 16:37, 20 February 2022 (UTC)
2. Gonna go with Gigi on this one. Ideally, the objective of the proposals board is to adjust the way things are handled on the wiki until we reach a system that most everyone agrees with, and in that case, fewer proposals will be needed to keep tweaking it. We don't necessarily want to go the other way and have more and more proposed changes from users which keep reshaping the way the wiki operates. --Samwell (talk) 17:04, 20 February 2022 (UTC)
3. Yeah, keeping it up would be more difficult than it's worth it. Superbound (talk) 19:57, 27 February 2022 (UTC)
4. Yes. With the third rule change in this proposal, this is unnecessary and loosens things up a bit too much for comfort. -- Jellytost♡ (talk) 02:19, 1 March 2022 (UTC)
5. I was first going to vote Support, then Neutral, but ended here. Why? well: I get that this change would help to make the changes of proposals faster in the case that someone wants to do various proposals, but by seeing the other comments here, I realized that proposals here are made for serious widespread changes, and ideally there shouldn't be a lot of proposals at once, let alone two by the same user.
   I have seen that in other wikis (namely Super Mario Wiki) proposals are/can be about how to generally treat a specific topic like some specifics on the coverage of a game, or if to split/merge pages and so on. Here, the proposals are made to more hard changes like directly changing a Policy (which are basically the words on which the wiki generally acts upon), or deleting a template that will affect most articles, and so on. I've seen that more "lighthearted" changes here are managed either through the talk page of the relevant article/topic, or are directly discussed on the Discord, which mean that there won't be a big proposal for basically every change of track here, instead being reserved for the more bigger and serious ones. I want to cite Samwell's "We don't necessarily want to go the other way and have more and more proposed changes from users which keep reshaping the way the wiki operates" in that a lot of proposals per user isn't ideal as there isn't necessary going to be a lot of proposals going on here. Proposals in this wiki arrive in a timely and moderated manner, and rarely a user have various things to propose at the same time.
   So my point with this is that more proposals per user would be something that either would incentivize users to do more proposals than there should be, which would break WiKirby's way of doing things, and/or would be completely useless if the proposals are indeed done in a moderated manner. And, I know that this could be instead used as a "fall-proof" thing in the case that someone wants to do two serious proposals and it would be better to make both at once, but it comes to my mind that the community here is close enough that, if a case like that happens, and most users agree that both proposals indeed need to be done, some other user may go and just do the second proposal right away, which seems to me like a more ideal scenario. Also, if we count the last part of the rule about a third proposal and the 30 days, I oppose even more as that management would be ultra complex, and three proposals worsen the thing even more. -Kirbeat (talk) 05:45, 4 March 2022 (UTC)

Neutral

1. This is more or less an extension from R3 and I don't have a strong enough opinion on it. The idea is fine, but it doesn't sound like something that'd really improve proposals. Infinite Possibilities (talk) 07:23, 5 March 2022 (UTC)

R5 Discussion

I was going to vote either support or neutral, but when I started writing my reason in either case, I couldn't let go that last part of the rule about a third proposal with the 30 days thing, as I am not comfortable with it. So, is there a way to just completely remove that rule, and if this passes, make that the limit number of proposals per user is always 2?

I feel that a big part of the reasons of the opposition here are aimed toward that part of the rule, instead of the main thing. And, I don't think that a user could get to be able to create a third proposal, but "for whatever weird circumstances would allow it", and thus in the case that a user could get to create a third one in the word that this rule passes, I think that the best thing would be to just limit the thing to two proposals and that's it. Like "oh you have two proposals up and the conditions met for you to create a third one? well it doesn't matter, the max is still two, and you will have to wait until either ends to create another one".

I would directly request Trig to remove that part of the rule, but first I would like to see what do other users think about it. -Kirbeat (talk) 07:46, 1 March 2022 (UTC)

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)