Nookipedia:Proposals/Archive

This page is an archive.

Only Administrators may edit the contents of this page. Please direct any additional comments to the current talk page.

The following is an archive of past proposals, ordered from newest to oldest.

2025

[Passed] Ban the usage of Learning Language Models (LLMs) on Nookipedia.

Proposal:	Ban the usage of Learning Language Models (LLMs) on Nookipedia.
This proposal is to bar users from using LLM services like ChatGPT, Gemini, or Copilot to write articles on Nookipedia. While I feel like this might have been retroactively banned per rule #9 of our "Article style and etiquette" on our policy page, I think we need to make it official and state outright that using AI is not allowed. If successful, it will either be attached to rule #9 of "Article style and etiquette", or be a new rule itself. -- PanchamBro (talk • contributions) 05:07, September 18, 2025 (EDT)
Comments:	Good suggestion! I would go one step further and also ban the use of LLMs as sources of information for articles, even if the article text itself is written by the user. ~ AlexBot2004 (Talk) 05:23, September 18, 2025 (EDT) LLM writing already fails the "all edits must be written using the editor's own words" rule, but I still think it's a good idea to formally disallow it. Drago (talk) 11:30, September 18, 2025 (EDT)
Votes:	Support ~ AlexBot2004 (Talk) 05:23, September 18, 2025 (EDT)  Support Drago (talk) 11:30, September 18, 2025 (EDT)  Support, specifically not allowing the use of LLMs to write articles as part of rule #9 (and not a total ban across Nookipedia). ~SuperHamster Talk Contribs 13:10, September 20, 2025 (EDT)  Support, along with the points made by AlexBot in the comments above 🙏🏻 ~PoizonMushro0m 20:54, September 28, 2025 (EDT)  Support amethyst_hhh(talk) 01:56, October 15, 2025 (EDT)
Result: (100%)	Passed. The proposal was enacted by ~ AlexBot2004 (Talk) 23:40, November 1, 2025 (EDT).

Voting on this proposal has ended. (refresh)

[Passed] Minor adjustments to two-thirds majority voting requirements

Proposal:	Minor adjustments to two-thirds majority voting requirements
Currently, proposals, staff applications, and staff expulsion votes all require (approximately) a two-thirds majority of support to pass. However, the exact wording of the policies differs slightly between the three: This proposals page states a requirement of "2/3 majority (66%)" The staff application page states a requirement of "65% support" (no mention of whether that is from all staff or just voting staff) The staff demotion page states a requirement of "support from 65% of voting staff members" I am proposing that the wording for all three of these voting requirements be changed to simply "two-thirds majority." A true two-thirds majority would be 66.66...% (repeating), so I think it's best to avoid using percentage requirements entirely. Instead, results should be formatted as a ratio of support to oppose votes; if there are at least twice as many support votes as oppose votes (e.g. 4–2), then it is a two-thirds majority. Furthermore, I'd like to amend the staff application page to state that it specifically must be support from two-thirds of voting staff members, which would bring it in line with the staff demotion vote requirements. If approved, these amended requirements would only apply to votes that began after the enactment of this proposal. ~ AlexBot2004 (Talk) 03:49, May 18, 2025 (EDT)
Comments:	This would definitely keep it consistent (and the percentage for a two-thirds majority is...unfortunate). Drago (talk) 10:58, May 18, 2025 (EDT)
Votes:	Support Drago (talk) 10:58, May 18, 2025 (EDT)  Support Gbjockey (talk) 9:00, May 18, 2025 (MST)  Support Very reasonable change! ~SuperHamster Talk Contribs 06:11, June 13, 2025 (EDT)  Support amethyst_hhh(talk) 23:58, July 24, 2025 (EDT)  Support -- PanchamBro (talk • contributions) 05:07, September 18, 2025 (EDT)
Result: (100%)	Passed. The proposal was enacted by ~ AlexBot2004 (Talk) 03:54, September 21, 2025 (EDT).

Voting on this proposal has ended. (refresh)

[Failed] Disallow users from signing up just to have a user page

Proposal:	Disallow users from signing up just to have a user page
I don't want to target anyone in particular here, but over the years I've noticed that some users join and immediately make their user page, then continue editing that, but don't contribute much to the wiki. But Nookipedia isn't a social media site or forum, and staff do still have to monitor user page edits. I don't want to be too strict on user page/article edit ratios, but I'm proposing that we formally create a rule where users who create a user page are also expected to contribute at least a few edits in other areas too, in keeping with Nookipedia's goals. If this proposal passes, and a user is just doing a lot of user page edits with basically nothing on articles, staff would be given the ability to send them a talk page message about it, with their ability to edit user-space being removed if they continue to not edit anything elsewhere. Of course, users will be able to get their ability back if they co-operate and make some useful contributions. Drago (talk) 14:02, May 15, 2025 (EDT)
Comments:	I don't know. We're not, say, Super Mario, where we have a dozen or so games coming out per year to have editors focus on that game at all time. Animal Crossing gets by with some scraps here and there, and sure we still don't have full Pocket Camp coverage, but other than that...is that really a rule we should implement in a time of year where Animal Crossing hasn't received anything substantial yet? Maybe it's the tired person talking but I feel like if we had wanted to deal with a proposal like this, we would've done so five years ago with the peak on New Horizons. -- PanchamBro (talk • contributions) 21:06, May 15, 2025 (EDT) I don't think it's a good idea to force users to edit if they don't want to. It might negatively impact the quality of their edits to the wiki if they feel pressured to do so just to be able to customize their user page. I think user pages are beneficial to Nookipedia's health and growth, especially on the off-chance the user shares their user page on other websites or wikis, so I don't think there should be a rule that might detract them from creating and maintaining their user page. The one problem in a similar vein that does exist is users not previewing their edits when editing their user page and do like 20 edits in a short timeframe, but that one already has a solution with messaging them, and also the "PreviewRequired" user group. HylianAngel (talk) 21:18, May 16, 2025 (EDT) The main reason I'm proposing this is so we don't have to use up resources (mainly the staff's time patrolling edits) on users who have no interest in contributing. I agree that it's not a huge problem and can be mostly contained with the PreviewRequired sanction. If my priorities are wrong here and this fails, then fair enough. I certainly don't want to make the wiki less fun by bringing in a rule others deem unnecessary. Drago (talk) 14:14, May 17, 2025 (EDT) I think that users who only edit their userpage probably have no interest in contributing to the wiki (not that that's necessarily a bad thing), so I don't think forcing them to edit articles would really help much. I wouldn't want to turn away any regular readers by making them feel like they have to edit, and I also don't want users submitting low-quality edits just so they can get back to editing their userpage. As for patrolling, I personally haven't had much issue with these types of edits interfering with mainspace edits; userpage edits take much less time and effort to patrol, and if they end up cluttering Recent Changes, there are always filters that could show only non-userspace edits. ~ AlexBot2004 (Talk) 03:09, May 18, 2025 (EDT) I feel if we did this, people might be stressed out trying to find edits or make some quickly. Also, they might not have any edits that they can do. Since some people might be using a smaller device without the capabilities of a computer. So they might not have that much work to do. I think this might be stressful for other users. (SpaceBean (talk) 07:56, July 10, 2025 (EDT))
Votes:	Oppose HylianAngel (talk) 21:18, May 16, 2025 (EDT)  Oppose After further consideration and seeing HylianAngel's comments, I can't support this. -- PanchamBro (talk • contributions) 01:20, May 18, 2025 (EDT)  Oppose ~ AlexBot2004 (Talk) 03:09, May 18, 2025 (EDT)  Oppose In general, wikis and especially independent wikis need editors and positive acclaim. This kind of aggressive restriction only drives people away, building resentment and not only decreasing usership and editorship but even readership. Additionally, it's a step that I haven't seen any other wikis take. -- ToastyMarshmallow (talk) 13:20, July 5, 2025 (EDT)  Oppose I feel like that if this was supported by everyone, other users might get scared or upset. (SpaceBean (talk) 07:56, July 10, 2025 (EDT))
Result: (0%)	Opposed.

Voting on this proposal has ended. (refresh)

2024

[Passed] Migrate Nookipedia from CC BY-SA 3.0 to 4.0

Proposal:	Migrate Nookipedia from CC BY-SA 3.0 to 4.0
Nookipedia is, like many other wikis, licensed under CC BY-SA 3.0. This proposal is to migrate Nookipedia to using version 4.0 of the same license. 4.0 has been available since 2013, and includes some good improvements and common sense changes -- see this article for full details. Improvements include explicitly allowing attribution by linking to a history page (practical for wikis); a 30-day window to correct license violations; and better internationalization. Wikipedia moved to 4.0 last year (see this blog post), and a growing number of our fellow NIWA wikis have migrated (or plan to) this year (Inkipedia, Pikipedia, etc.). Regarding implementation: Creative Commons licenses are forward-compatible, which means that if you adapt a CC 3.0 work, you can license it under 4.0. For Nookipedia, this means that all existing content can and always will be considered to be a 3.0 work, but as new edits are made and articles become derivatives of themselves, they will be considered a 4.0 work. Regarding impact: This change has very little impact to the day-to-day experience of our editors and readers. Most impact would be seen by text re-use between Nookipedia and others. While Creative Commons versions are forward compatible, they are not backwards compatible. This means that 3.0 works can be used in a 4.0 work, but 4.0 works can't be used in a 3.0 work. By moving to 4.0, we will be better aligned with other wikis on 4.0, and can adapt both 3.0 and 4.0 text. Inversely, any wikis on 3.0 looking to re-use Nookipedia's 4.0 text won't be able to, but can also migrate to 4.0 if they wish. ~SuperHamster Talk Contribs 17:48, October 19, 2024 (EDT)
Comments:
Votes:	Support ~SuperHamster Talk Contribs 17:48, October 19, 2024 (EDT)  Support -- PanchamBro (talk • contributions) 21:28, October 19, 2024 (EDT)  Support ~ AlexBot2004 (Talk) 04:03, October 20, 2024 (EDT)  Support ~PoizonMushro0m 04:20, October 20, 2024 (EDT)  Support as well. Chubby Bub (talk) 07:33, October 20, 2024 (EDT)  Support -- Drago (talk) 11:24, October 20, 2024 (EDT)  Support ~ Vivian (talk) 14:42, October 21, 2024 (EDT)  Support -- ToastyMarshmallow (talk) 15:00, October 23, 2024 (EDT)  Support Crosstent ~ (Talk) 11:05, October 24, 2024 (EDT)  Support Thanks, --SunsetBay (Talk) 12:38, October 26, 2024 (EDT)
Result: (100%)	Passed. Will be implemented by SuperHamster and Jake. ~SuperHamster Talk Contribs 01:29, November 13, 2024 (EST).

Voting on this proposal has ended. (refresh)

[Passed] Modifications and additions to Nookipedia Policy regarding user page content and community interaction

Proposal:	Modifications and additions to Nookipedia Policy regarding user page content and community interaction
This proposal is in part a rework of a few ideas I proposed at Nookipedia talk:Policy in January of 2022, but also includes a few additional policies which aim to a) clarify some gray areas surrounding user talk pages and b) establish policy regarding backseat moderation. Additions to existing policy (in bold): User page content 4. Other than for necessary basic maintenance edits and reverting vandalism, editing or reverting changes to another user's user page is not allowed, even when censoring or correcting spelling or grammar. Concerns about user page content should be directed to Nookipedia Administrators or Bureaucrats. Community interaction 5. Do not remove other users' messages or revert edits to their talk page, except in clear cases of vandalism, personal attacks, being off-topic, or maintenance (removing duplicate messages, moving to correct talk page, etc.). As an exception, welcome messages and mass invites (e.g. "Invitation to Summer of Edits...") posted to one's own user talk page may be removed by the talk page owner. 6. Talk page messages older than 1 month may be moved by the talk page owner to an archive page, so long as a link to the archive is clearly provided on the user's talk page. Official warnings or messages from staff members concerning a user's edits or behavior may be archived after 6 months. 7. Do not interpret Nookipedia policy or enforce policy violations on behalf of staff members. With the exception of blatant spam or vandalism, which can be reverted by any user, all other potential policy violations should be posted to the Staff noticeboard or to the official Discord server (ping @staff) so that a staff member can take appropriate action. Editors should not speak with a tone of authority in comments or edit summaries in regard to potential policy violations. Doing so is considered backseat moderating and may result in a warning. (talk) 23:59, July 21, 2024 (EDT)
Comments:	I think changes to 4 and 5 are fine. Addition 6 concerns me slightly as I think it somewhat encourages a more constant stream of archival which is not useful. It seems pointedly addressing a single user case over the span of recent years and I don't think it's helpful for any party. I would just have the site suggest to archive after "significant time has passed" and after some significant size, whether thats bytes or headers. I'm also pretty iffy about point 7, because it effectively removes the ability for editors to enforce already defined policies. The line in particular causing concern is Editors should not speak with a tone of authority in comments or edit summaries in regard to potential policy violations. (although most of it is in the same realm). For an example, if a user is overtly violating the Nookipedia:Upload policy through the first bulled point When uploading the file, be sure to give it a meaningful name which describes its content., I'm not permitted to inform that user via talk page or edit summary that they are not following the policy (even though it is clearly defined via page)—or at least, that's how this policy change is conveyed. I think it's an overreach to stop users from micromanaging which more often then not needs to be a more direct intervention than a blanket fix. Because of my support for only half of the proposed changes, and distaste for the other half, I find it impossible to vote on this proposal at all and simply leave my commentary behind for reference. Trig Jegman - 00:55, July 22, 2024 (EDT) I appreciate your feedback, although I am a bit confused by what you mean by "It seems pointedly addressing a single user case over the span of recent years and I don't think it's helpful for any party." Could you be a bit more specific about the user case you're referring to and how this policy would be unhelpful? This policy was meant to address the grey area established by the existing point #5: "Do not remove other users' messages...". As it stands, archives of user talk pages are not explicitly permitted by the existing policy. This addition simply provides a framework for when it's acceptable to move talk page messages and warnings. The original time frame that I proposed internally to staff members when I was seeking feedback on this proposal was 1 year. This time period makes sense to me, as generally user talk pages do not receive a high level of activity, however this didn't take into account factors like site or user activity; a user who is very active or involved in the community, or who is active during periods of high site activity (like around the time of a new game release), would benefit from a shorter archive threshold as it would make their talk page more manageable/easier to navigate. While I appreciate the flexibility that language like "significant time has passed" allows for, I feel like it's not particularly helpful as it makes the policy unenforceable; what may be "significant" for one user may not be for another. Lastly, I just wanted to clarify here that an additional reason for this policy addition is that we've recently had issues surrounding user talk pages (including removal of user messages and warnings) by disruptive users, and so this policy change is also aimed at making it very clear the acceptable and unacceptable ways to go about this. As for point #7, these were my same concerns with this policy addition, and I would be interested in your suggestions on how to achieve the right balance here. The goal of this policy is not to require users to defer to staff to address comparatively minor issues like upload policy violations. Its goal is to make clear that users who are not staff should not be taking actions to remedy their own perceived policy violations, or mimicking staff behavior. As with #6 it was also created in an attempt to address recent disruptive behavior where the user in question was trying to act like a staff member by moderating edits and users. There is a difference between bringing something to another user's attention versus telling someone they are wrong or reverting edits based off perceived policy violations, which in this case were incorrect. In short, it's one thing to be correctly enforcing the policy, and another to be enforcing it wrong because you don't know it or don't understand it, and so this policy addition tries to make it clear that those who are not in a position to properly enforce the policy should not be doing so. Again, if you have any suggestions on how to improve the language so that it strikes the right balance I'd appreciate your suggestions. (talk) 02:54, July 22, 2024 (EDT) Hi, I really like this. It sounds good.  Support. I just have one question. What do you mean by an ‘authoritative tone’? I think that there should be a list of identifying things specifying what is authoritative and what is not. Just because I don’t really get what it means, and other people might not too. Thanks, --SunsetBay (Talk) 14:32, July 25, 2024 (EDT) I'm not sunmarsh, but I think I can answer this. In this case, "authoritative tone" means acting in a way that could make an uninformed user believe you are a staff member. There's no way to neatly define exactly what behavior constitutes that in a way that covers all possible cases while also not having false positives, so it's best to leave the interpretation of it up to the staff members on a case-by-case basis. This reason is also part of why point #7 is so important; policy is sometimes vague and up to interpretation, and in cases like that, non-staff should not be the ones to interpret it. ~ AlexBot2004 (Talk) 02:26, July 28, 2024 (EDT) That makes sense, thanks! Thanks, --SunsetBay (Talk) 06:37, July 29, 2024 (EDT) Unfortunately I'm going to have to oppose this proposal in its current form. I agree with most of the changes, but point #7 suggests that editors won't be able to remove anything from articles that violates a policy, and I think editors should have more freedom to remove things from articles that don't belong. On most open-editing wikis like ours, content can be added, removed and edited by anyone and I don't want to interfere with that. I also think that leaving a friendly message on a user talk page to point out that their edits may be inappropriate is acceptable too, as long as they're not being authoritative, but I do think comments that threaten disciplinary action (e.g. "Further changes like these may result in an official warning or block") should be left to the staff. Since a proposal can't receive major changes after voting starts, I'm opposing for now. Drago (talk) 10:42, July 28, 2024 (EDT) I'm in support of this proposal in its current form. If changes need to be done to address what has been stated by others above, that's okay. But I have always been opposed to users trying to skirt around warnings, changes to userspaces thaat are not their own, and trying to pose as staff. The latter can be especially confusing for new editors as they wouldn't know who is and isn't on the team, so they in good faith trust their judgement. Anything to prevent this is good in my book, but I'm open to see what changes take place if this proposal was to be revised and brought back later on. ~PoizonMushro0m 16:44, July 28, 2024 (EDT)  Oppose I don't really like how staff members can't really censor on User pages and User talk pages, I feel like staff members should due to younger audiences. Also, Users should be able to revert inappropriate behavior right away, just so almost nobody sees it. I feel like backseat moderating is bad so well done, but some stuff feels a bit wrong. SpaceBean (talk) 10:42, July 28, 2024 (EDT)SpaceBean (talk)
Votes:	Support ~ AlexBot2004 (Talk) 02:26, July 28, 2024 (EDT)  Oppose Drago (talk) 10:42, July 28, 2024 (EDT)  Support ~PoizonMushro0m 16:44, July 28, 2024 (EDT)  Support Lampshade59276 (talk) 17:01, July 28, 2024 (EDT)  Oppose SpaceBean (talk) 10:42, July 28, 2024 (EDT)SpaceBean (talk)  Support Thanks, --SunsetBay (Talk) 06:37, July 29, 2024 (EDT)
Result: (66.67%)	Passed. The proposal was enacted by ~ AlexBot2004 (Talk) 01:11, October 22, 2024 (EDT).

Voting on this proposal has ended. (refresh)

[Vetoed] Redesigned block templates

Proposal:	Redesigned block templates
Drago proposed a redesign of the current block template and I liked the idea so I decided to make my own adjustments. I made a redesign of CommunityBan if you want to redesign it too. Reasons Drago listed were ability to write longer/more detailed block reasons without it being messy, the convenience of not having to check the block logs to see how many times someone has been banned and not having to remove it after the block expires or a successful appeal is made. Super Mario World 12:09, July 4, 2024 (EDT)
Comments:
Votes:	Support, but these templates should not replace the current {{Block}} template, they should be called something else, like BlockNotice. AnimalCrossingExpert (talk) 04:20, July 6, 2024 (EDT)
Result: (0%)	Vetoed by (talk).

Voting on this proposal has ended. (refresh)

[Failed] Changing a mass of gallery pages

Proposal:	Changing a mass of gallery pages
How about instead of having "Tree/Gallery" as the title, we add {{DISPLAYTITLE:Gallery Relating To ''Tree''? On Furniture/New Horizons/All furniture, editors added {{DISPLAYTITLE:List of all furniture in {{NH|short|nolink}}}}. I think we should do what I specified above on the gallery pages. Now, this will affect more than 1000 pages so this is why I am doing a proposal. Acnh Player (talk) 15:28, May 12, 2024 (EDT)
Comments:	I don't think this makes the titles much more informative than they are now. Certainly not by enough to make it worth making the thousands of edits that would be required, even with the help of a bot. Drago (talk) 12:51, May 13, 2024 (EDT) Agreed with Drago. The display titles on the list pages clarify what the pages are, which isn't clear from the real title (e.g. someone seeing "Furniture/New Horizons" might not know it's a list of furniture). However, the gallery page titles already make it clear to the reader that they are a gallery relating to their respective subject. ~ AlexBot2004 (Talk) 15:05, May 13, 2024 (EDT) But listen. I want readers reading a more welcoming title than in the form: subject/gallery. P-L-E-A-S-E. Acnh Player (talk) 18:58, May 13, 2024 (EDT) Honestly, I'm opposing it. The naming scheme for galleries already makes sense, Gallery/tree already gets the point across, a gallery of images showing trees. Plus, while not my biggest concern, it uses a bit more byte space that could go to minor edits on the page itself. I oppose this. Login (talk) 14:26, May 18, 2024 (EDT) Too much effort for what it's worth and the current system does just fine and has worked for years, same can be said for other wikis that use Gallery pages pages as they use a similar system to Nookipedia. Why change what isn't broken... ~PoizonMushro0m 03:37, May 26, 2024 (EDT)
Votes:	Oppose Drago (talk) 12:51, May 13, 2024 (EDT)  Oppose ~ AlexBot2004 (Talk) 15:05, May 13, 2024 (EDT)  Oppose ~ Login (talk) 14:26, May 18, 2024 (EDT)  Oppose I just think that there’s not really a point in sooooo much work that can be avoided as the titles are good. Thanks, --SunsetBay (Talk) 01:04, May 25, 2024 (EDT) But listen. I have great ideas, and I am pretty sure this will make nookipedia more popular. Acnh Player (talk) 23:52, May 25, 2024 (EDT)  Oppose ~PoizonMushro0m 03:37, May 26, 2024 (EDT)  Oppose -- Dorsal Axe (talk) 17:35, May 26, 2024 (EDT)
Result: (0%)	Opposed.

Voting on this proposal has ended. (refresh)

[Failed] Adding tips from our experiences on to pages.

Proposal:	Adding tips from our experiences on to pages.
Adding a "Tips and Tricks" section, such as giving tips on the Turnip Market. - unsigned comment from Melodii (talk • contribs)
Comments:	Nookipedia is an encyclopedia, not a guide. It is our goal to provide readers with factual information, not to give tips or tricks. Guide content would be better suited for something like StrategyWiki. ~ AlexBot2004 (Talk) 17:05, May 26, 2024 (EDT) I'll have to agree with AlexBot here and say that StrategyWiki is a far better place for guide content. FYI, we did have guides in the past which had their own namespace. I wouldn't support bringing them back. Drago (talk) 10:58, May 27, 2024 (EDT)
Votes:	User votes on proposal:  Support or  Oppose + signature (*~<Melodii>~* (talk) 14:43, May 26, 2024 (EDT)).  Support Good idea. I think this will really make the readers learn more. Acnh Player (talk) 14:51, May 26, 2024 (EDT)  Oppose ~ AlexBot2004 (Talk) 17:05, May 26, 2024 (EDT)  Oppose This is outside the scope of Nookipedia.-- Dorsal Axe (talk) 17:35, May 26, 2024 (EDT)  Oppose ~PoizonMushro0m 04:18, May 27, 2024 (EDT)  Oppose Drago (talk) 10:58, May 27, 2024 (EDT)
Result: (20%)	Opposed.

Voting on this proposal has ended. (refresh)

[Failed] Adding more rights to patrollers

Proposal:	Adding more rights to patrollers
I think patrollers should be able to block users and edit protected pages. - unsigned comment from Acnh Player (talk • contribs)
Comments:	I'm not sure if this should be voted on as a proposal, and it might be better for staff to decide. But I'll give my opinion anyway: this change would make Patrollers too similar to Administrators and the second promotion wouldn't feel like a big step up. There also isn't enough vandalism currently to justify needing more users with blocking rights. I do think we should re-assess the role of Patrollers on this wiki (this is nothing against the users who currently hold the position, simply that I think the position itself is flawed), but I'm not sure simply adding more rights is the best way to do that. Drago (talk) 11:47, April 17, 2024 (EDT) I'll add that fully protected pages aren't in the mainspace, mostly consisting of policy and critical templates and modules. We can still view and copy their source codes, which is helpful for illustrating proposed modifications. BladeofEvilsBane (talk) 08:52, April 18, 2024 (EDT)
Votes:	Oppose --Drago (talk) 11:47, April 17, 2024 (EDT)  Oppose per Drago ~ AlexBot2004 (Talk) 00:38, April 18, 2024 (EDT)  Oppose per Drago BladeofEvilsBane (talk) 08:52, April 18, 2024 (EDT)  Oppose per Drago -- Dorsal Axe (talk) 09:17, April 18, 2024 (EDT)  Oppose per Drago ~ Vivian (talk) 15:19, April 18, 2024 (EDT) Why is everyone saying "per drago"? Hm.. Acnh Player (talk) 17:03, April 21, 2024 (EDT)
Result: (0%)	Opposed.

Voting on this proposal has ended. (refresh)

[Passed] Policies regarding staff promotions/demotions

Proposal:	Policies regarding staff promotions/demotions
This proposal contains several changes to the staff application/promotion process as well as new policies regarding staff demotions. Application/Promotion If accepted, the following policies will be integrated into the staff application page. Staff applications will require a minimum of 5 votes before the result can be determined. If the voting period ends before 5 votes are cast, the voting period will be extended for 7 days. Non-staff must start out as a Patroller. Our current policy merely suggests that non-staff start out as a Patroller, but this policy will require it. The only exceptions are users who were previously Administrators or Bureaucrats and either resigned or were demoted due to inactivity; these users can apply directly for their previous position. Patrollers must wait 2 months before they can apply for Administrator, and Administrators must wait 2 months before they can apply for Bureaucrat. A user who successfully applies for staff must add a verified email address to their account before they can be promoted. If one is not added within 30 days of a successful staff application, the application will be rendered null and the user will not become staff. On a similar note, Administrators who successfully apply for a Bureaucrat position must enable two-factor authentication on their account before they can be promoted. If it is not enabled within 30 days of a successful application, the application will be rendered null and the user will not be promoted. Demotion There are currently no official rules on staff demotion. If accepted, the following policies will be documented on a new policy page. If a staff member has not edited the wiki in over a year, they will be removed from their position. If the user resumes activity on the wiki, they may return to their previous position within a year of their demotion. After a year, the user must go through the staff application process again. Only wiki edits make a user 'active' in this regard. Activity in the Discord server or anywhere else off-wiki does not count. Note: If this proposal passes, any staff members who have already not edited in over a year will have a 30-day grace period after it goes into effect to resume activity before they will be demoted. Any staff member may voluntarily step down from their staff position or move down to a lower position (e.g. Bureaucrat to Administrator) If the user wishes, they may return to their previous position within a year of their resignation. After a year, the user must go through the staff application process again. If an existing staff member removes their email address from their account, they will have 30 days to re-add it or add a different email, after which they will be removed from the staff. If an existing Bureaucrat removes two-factor authentication from their account, they will have 30 days to re-enable it, after which they will be demoted to Administrator. If a staff member does not utilize their abilities as staff, improperly utilizes them, or is otherwise seen as unfit to be staff, they may be expelled from the staff by a vote. Only Bureaucrats or Directors may call for a vote to expel another staff member. The vote will be held on the wiki and have the same rules as a staff application: support from 65% of voting staff members and a minimum of 5 total votes. If an expulsion vote is called in bad faith, it may be vetoed by a Director. An expelled user may apply for staff again as a Patroller (regardless of their previous position) after 6 months. If a staff member clearly abuses their staff powers, vandalizes the site, or does any other action that would result in a block, they will be blocked from editing and removed from their staff position immediately. There's a lot here, but my hope is to remove some of the vagueness in our existing policies, as well as create new policies to account for all possible scenarios. Thank you for your time and consideration. ~ AlexBot2004 (Talk) 20:55, April 14, 2024 (EDT)
Comments:	Obviously not. Although I agree with the "minimum" vote, and non staff users can apply for anything, even bureaucrat. Plus, it should be a 80% agreement for demoting staff, because sometimes people are wrongly accused. Plus, if there is no vote for demoting a staff that clearly abused tools, who in the world decides that it is a clearly? There should still be a vote when demoting staff who clearly abused tools. Plus, staff that was removed and indefinitely barred from becoming staff again will just be mad and create a sockpuppet account. Plus, what if a director does something bad? Then a bureaucrat can propose a removal, but then the director removes it on sight. For example, lets say SuperHamster vandalizes every single page. But then, AlexBot2004 calls a proposal to remove him. And then SuperHamster can just remove that application because he is a director and can do that, as you mentioned above in your super-long boring description. Acnh Player (talk) 21:39, April 14, 2024 (EDT) I don't get this argument. So you're saying that if a admin abuses their rights in a clear malicious intent, we should wait by voting on their demotion instead of taking action immediately? Also, why assume the user's going to sockpuppet if they get banned? Staff rights is a responsibility, if anything goes wrong, we have to take action and take accountability for what goes on in the backstage. I'm confused. -- PanchamBro (talk • contributions) 01:36, April 15, 2024 (EDT) Solid set of rules. I do have two recommended changes: Regarding only a Bureaucrat being able to call for a vote to expel, I suggest it be Bureaucrats + Directors. "A user removed from the staff in this manner will be indefinitely barred from becoming staff again" -> I think we can remove this line. While it's very likely a staff member removed for abuse would never be staff again, I don't like absolutes like this. It's theoretically possible for someone to come back years later, be productive, and be re-accepted as staff. Other than that, the proposal looks great and I'm happy to support. ~SuperHamster Talk Contribs 02:40, April 15, 2024 (EDT) I've gone ahead and made both of those changes. For the first point, I initially worded the expulsion vote sentence that way since Directors are inherently Bureaucrats, but it is good to clarify. For the second, now that I think about it more, I agree that it is better to not have absolutes regarding being barred from staff. ~ AlexBot2004 (Talk) 02:50, April 15, 2024 (EDT) Thank you! ~SuperHamster Talk Contribs 03:25, April 15, 2024 (EDT) Sure I changed my vote. - unsigned comment from Acnh Player (talk • contribs) Another hypothetical situation where we might want to reallow someone who acts disruptively is if their account was demonstrably hacked or accessed by someone else. Chubby Bub (talk) 22:56, April 15, 2024 (EDT)
Votes:	Support I changed my vote lol. Acnh Player (talk) 19:05, April 15, 2024 (EDT)  Support These changes are definitely well needed especially given the lack of activity by most of our staff, and the fact that info on admin abuse is definitely well warranted. -- PanchamBro (talk • contributions) 01:36, April 15, 2024 (EDT)  Support ~SuperHamster Talk Contribs 03:25, April 15, 2024 (EDT)  Support Yeah, I guess I'm mostly on board. The only sticking point I have is that two months in between positions is mildly arbitrary and I think focusing on experience prior to the position makes a little more sense, but I guess I can see the point in why it is done this way too. Trig Jegman - 10:22, April 15, 2024 (EDT)  Support Drago (talk) 10:41, April 15, 2024 (EDT)  Support Thanks, --SunsetBay (Talk) 13:22, April 15, 2024 (EDT)  Support I had a few questions/concerns, mainly about absolutes, but they've now been addressed. Chubby Bub (talk) 22:56, April 15, 2024 (EDT)  Support ~ Vivian (talk) 15:19, April 18, 2024 (EDT)
Result: (100%)	Passed. The proposal was enacted by ~ AlexBot2004 (Talk) 21:32, April 21, 2024 (EDT).

Voting on this proposal has ended. (refresh)

[Failed] Changing the capitalization policy

Proposal:	Changing the capitalization policy
How about we change the capitalization policy so that every letter in the title has to be capitalized except words like "the" and "and"? The English grammar is like that, and Nookipedia should probably follow it. I know this will effect so many pages, but again, I think it is necessary. Acnh Player (talk) 14:35, April 14, 2024 (EDT)
Comments:	Personally, I feel the capitalization policy is perfectly fine as it is and actually refers to in-game capitalization. I can understand the meaning of your message, but the wording is a bit clumsy- is that how you phrase it? Raven Star (talk) 14:42, April 14, 2024 (EDT) The rules for capitalizing each word in a title generally only apply to published works or works of art. For anything else (including wiki articles), the titles are subject to whatever style guide the website/organization has in place. In our case, that is the Manual of Style, which dictates that article and section names should be in sentence case, and I see no reason to change that. ~ AlexBot2004 (Talk) 18:47, April 14, 2024 (EDT) U R WRONG Acnh Player (talk) 18:53, April 14, 2024 (EDT) No u r wrong Lexy (talk) 14:24, April 15, 2024 (EDT) Hm u didn't even vote. Acnh Player (talk) 19:07, April 15, 2024 (EDT)
Votes:	Oppose As per my above comment. Raven Star (talk) 14:42, April 14, 2024 (EDT)  Oppose ~ AlexBot2004 (Talk) 18:47, April 14, 2024 (EDT)  Oppose -- PanchamBro (talk • contributions) 01:36, April 15, 2024 (EDT)  Oppose Drago (talk) 10:41, April 15, 2024 (EDT)  Oppose We already decided to follow in-game capitalization for in-game terms. As AlexBot2004 says, wiki articles are not titled like they are published works. If anything it would lead to more confusion and inconsistency. Chubby Bub (talk) 23:01, April 15, 2024 (EDT)  Oppose ~ Vivian (talk) 15:19, April 18, 2024 (EDT)
Result: (0%)	Opposed.

Voting on this proposal has ended. (refresh)

2023

[Passed] Disable WebP and WebM uploads

Proposal:	Disable WebP and WebM uploads
Recently there's been some discussion among staff about disabling WebP and WebM uploads. As this is a content-related issue, though, I thought voting on it here would be the fairest way of deciding. Although it's relatively rare that editors upload this type of file, they're usually low-quality and there's no advantages to them over the preferred PNG or JPG formats. If this proposal passes, existing WebP and WebM files will be converted to another, compatible format. Drago (talk) 14:02, August 15, 2023 (EDT)
Comments:	Something that is troubling with this proposal is that with WebP images we don't know if the image was originally a PNG or JPG file, so we'd need to decide very carefully what format to choose when converting these images. Now this can be simple for sites like Fandom, whose CDN will display a WebP for anonymous users but the real image for users, but press release images by Nintendo or any other official sources are more hasty. In my opinion, any image with transparency should be a PNG, while others should be JPG. -- PanchamBro (talk • contributions) 01:12, August 16, 2023 (EDT) Personally, I would support this proposal if WebP is the only one that gets disabled, but I think WebM, as a video container format (which is not meant to replace PNG and JPG files), might be more useful just in case. Starry Windy★ 10:52, August 17, 2023 (EDT) WEBM has more suitable replacements such as MP4, OGV, MKV, or even APNG. I wouldn't allow them for the same reasons, just with different, more supported formats to go to. Trig - 15:44, March 29, 2024 (EDT)
Votes:	Support -- PanchamBro (talk • contributions) 01:12, August 16, 2023 (EDT)  Support-- I think this maybe a good idea as then people don't have to add a higher qualiy one after SunsetBay 10:26, August 17, 2023 (EDT)  Oppose-- Per my comments above. Starry Windy★ 10:52, August 17, 2023 (EDT)  Support—Usually just an indicator of content taken elsewhere. Poorly supported format. Trig Jegman - 15:44, March 29, 2024 (EDT)  Support ~ AlexBot2004 (Talk) 15:52, March 29, 2024 (EDT)
Result: (80%)	Passed. The proposal was enacted by ~ AlexBot2004 (Talk) 10:05, April 11, 2024 (EDT).

Voting on this proposal has ended. (refresh)

[Failed] There should be one member of staff online at all times.

Proposal:	There should be one member of staff online at all times.
I think that there should be one member of staff on all times. There could be a serious incident and with no staff online, no action except telling off could be made against the offending user. - unsigned comment from FroggyPotter (talk • contribs)
Comments:	I don't want to be biased, because I helped my sister write this one, but I think it is pretty good! I understand both sides-- but I'm conflicted. On one hand- I get why staff can't be on at all times. But on the other- I think that situations would be attended to faster. So, yeah, I'll think about it. Thanks, --SunsetBay (Talk) 09:56, September 5, 2023 (EDT) I agree that it's ideal to have staff around and to cover all time zones, but an idea like this would just not work. Real-life always comes first, and editing Nookipedia is more of a fun hobby, even for staff. Several of the staff do check in daily, and if something urgent comes up, you can ping them on Discord, so you don't need to worry too much. Drago (talk) 10:39, September 5, 2023 (EDT) Little reply, Drago, but what if no-one online has Discord? Unusual, but possible? Not that I don't partly oppose too, per my above comment, but just questions that pop into one's mind. Thanks, --SunsetBay (Talk) 14:20, September 5, 2023 (EDT) Nearly all the staff (including patrollers) are on Discord. I think it's very unlikely that a major incident would remain unnoticed for long. Drago (talk) 10:37, September 6, 2023 (EDT)
Votes:	Oppose Drago (talk) 10:39, September 5, 2023 (EDT)  Oppose Sorry, sis, but there are more cons than pros here. Thanks, --SunsetBay (Talk) 14:25, September 5, 2023 (EDT)  Oppose Not only is this something that isn't deserving to be under the proposal system, but the fact that your sister is replying with an opposition under your account is making this process as confusing as possible. My bad, I'm the one who got confused. Regardless though, this isn't a thing that should be proposed under this system. -- PanchamBro (talk • contributions) 16:27, September 5, 2023 (EDT)  Oppose Unfortunately, there is no way we could realistically ensure that a member of staff is online at all times. Even if there were, there are no significant benefits to this, as staff and other community members have swiftly and effectively responded to prior incidents of mass vandalism, harassment etc., without the mandation of frequent online activity. The sentiment is noble, but the reality is that such a policy could not be effectively maintained, and its potential benefits are not sufficient enough to compensate for this. ZCJigglypuff(Talk) 00:30, September 6, 2023 (EDT)
Result: (0%)	Opposed.

Voting on this proposal has ended. (refresh)

[Failed] Villager Quotes

Proposal:	Villager Quotes
Nookipedia should go back to having villager quotes at the top of the villager pages. I've started editing a few pages with quotes, but I wanted to get some support before I continue. I know some quotes, like dialogue, are the same within a personality, but picture quotes aren't. It would be useful to the readers to have the quote at the top of the page, and it would be a nice surprise to the readers to see the pages change for the better. Also, we could include villager-exclusive dialogue, such as Muffy's dialogue on her birthday (She's the only villager with a birthday on Valentine's Day.) Opinions? - unsigned comment from Omigpine11 (talk • contribs)
Comments:	About the proposal's suggestion involving picture quotes: I don't think including picture quotes at the top of each villager page will be useful, because picture quotes are already located in the villager infobox, which is on the top-right corner of the page in the "Favorite saying" section. About the proposal's suggestion involving villager-exclusive dialogue: There are actually already 14 pages that include villager-exclusive dialogue as a quote at the top of the page. These are the crossover villagers in Welcome amiibo, such as Chelsea, Epona, and Viché. In New Horizons, along with Muffy's Valentine's Day-birthday-exclusive dialogue, there are a few other pieces of dialogue that are completely unique to specific villagers on New Year's Day. These villagers are of the species mouse, bull, cow, tiger, rabbit, horse, sheep, monkey, bird, dog, and pig, as these are the species that are represented by one of the 12 Chinese zodiacs. No villager species were selected to represent "snake" or "dragon," so strangely, Drago seems to be omitted. Additionally, the villager must be the only species of that personality type present in New Horizons. For example, Wendy is a sheep villager, and she is the only peppy sheep villager present in New Horizons, so she has unique dialogue related to Year of the Sheep on New Year's Day. This combination amounts to 30 unique New Year's Day villagers. These quotes should definitely be included as prose or trivia on each of these 30 exclusive villagers. I wouldn't be against including these holiday-related quotes at the top of the page, but my fear is the quote feels more holiday-centric rather than villager-identity-centric, if that makes sense, which makes me wonder if it would be a good way to represent the villager's identity. HylianAngel (talk) 21:36, March 11, 2023 (EST) Hatnotes are typically used to help disambiguate pages (e.g. Apple), or point readers to villagers who share the same name in a different language (e.g. Penelope). As fun as quotes at the top would be, I think we should avoid adding additional hatnotes to avoid distracting from the main content, and I think we shouldn't mix fun and utility. My other concern is SEO -- the sooner the actual prose of the article starts, the easier it is for search engines to identify what the article is about. I could maybe support quotes in the infobox, where it would be off to the side. ~SuperHamster Talk Contribs 14:24, March 12, 2023 (EDT)
Votes:	Oppose HylianAngel (talk) 21:36, March 11, 2023 (EST)  Oppose ~SuperHamster Talk Contribs 14:24, March 12, 2023 (EDT)
Result: (0%)	Opposed.

Voting on this proposal has ended. (refresh)

2022

[Failed] Axe using event notices at Mediawiki:Sitenotice; delete all pages under Schedule:Months

Proposal:	Axe using event notices at Mediawiki:Sitenotice; delete all pages under Schedule:Months
This is starting to become a problem, especially for me as an editor. We generally have left our site notice around to alert users about events ongoing in the Animal Crossing games, with the latest pages centered being New Horizons. But, on the premise of how it operate, the system now just feels intrusive that it gets in the way not only for editors, but for readers, who cannot remove those site notices on mobile. You might be inclined to propose several solutions, like combining certain events into one template so it outputs events, or make these notices invisible on mobile, but even with those solutions, we might end up having a site notice that still acts intrusive. Whenever there's a very important site notice, such as announcing that NIWA's Cross-Wiki Week has started, or if there are multiple events happening (see Schedule:Months/May/31), all of that crams the actual wiki content down significantly, something that will annoy readers even if solutions like combining these templates into one. Coupled with the fact that this system is basically useless since event info is displayed on the Main Page anyways, this system is overall functionally annoying and outdated. With this proposal, I want the site notices to display these events gone. Period. The Schedule:Months pages will be deleted following the proposal's success, and Mediawiki:Sitenotice will be reserved for Nookipedia-related events, like our birthday, or as I mentioned Cross-Wiki Week. Note that I do not want the entire Schedule namespace removed; the Schedule namespace has birthday pages used on our Main Page and Schedule:New Horizons is being used for cargo purposes. -- PanchamBro (talk • contributions) 17:00, December 1, 2022 (EST)
Comments:	I think the notices are helpful for players (they are at least helpful to me). I encourage combining everything into a single, smaller banner to limit intrusiveness. Mobile users can dismiss site notices on mobile...we're not using MobileFrontend anymore. The current limitation is that anon users cannot dismiss notices, but we can remedy that by setting $wgDismissableSiteNoticeForAnons to true. I would only support axing it all if we have evidence that our readers find it annoying (e.g. a poll on the Discord server), after we've implemented changes (making notices smaller + letting anons dismiss them). If, say, readers find it useful but editors find it annoying, we could implement a gadget that lets editors toggle event banners. I could maybe support removing the event notices on the premise that it has been several years since NH came out, but I would not want to ax the whole system, and I would want the notices to resume whenever the next game came out. ~SuperHamster Talk Contribs 17:26, December 1, 2022 (EST) I agree with SuperHamster, and I think we should implement some of his solutions first (allowing anons to dismiss notices, making the banner smaller, adding a gadget to let editors hide the banners), and see how that goes before giving up on event notices altogether. If problems persist, we can reconsider. Drago (talk) 12:53, December 2, 2022 (EST) Could we not just get rid of notices for the less important events (e.g. "first day of DIY recipes", or whatever), but keep it for major ones (e.g. Toy Day)? I feel like the Main Page covers all those minor ones pretty well now. The banner was never terribly intrusive when it simply informed of a major holiday. I'm inclined to agree that its usage has become excessive in its current form. -- Dorsal Axe (talk) 13:06, December 3, 2022 (EST) I think that's a good compromise. I'm not sure if I can change the proposal a bit to reword it, but if we can trim out the Schedule namespace to only feature major events, I think that would be better. -- PanchamBro (talk • contributions) 14:49, December 3, 2022 (EST)
Votes:	Oppose ~SuperHamster Talk Contribs 17:26, December 1, 2022 (EST)  Oppose Drago (talk) 12:53, December 2, 2022 (EST)  Support for reduced scope version of this proposal, as per my comment (may be best to raise as a new proposal?). -- Dorsal Axe (talk) 13:29, December 8, 2022 (EST)
Result: (33%)	Opposed.

Voting on this proposal has ended. (refresh)

[Passed] Change item capitalization policy to match in-game capitalization

Proposal:	Change item capitalization policy to match in-game capitalization
I am proposing that we change our policy and item capitalization to use the in-game capitalization—which is generally all lowercase except for proper nouns—for all item names. This proposal has been divided into sections for ease of reading: History of our item capitalization policy Right now, our policy for the capitalization of item names defined on our general policy page and in our Manual of Style is to use title case, regardless of the in-game capitalization, as enacted by a 2014 poll. The reasoning behind the decision to make a policy regarding item names was brought forth by the staff largely due to the wiki at the time having inconsistent standards between pages (some pages used in-game capitalization, some used title case), but it was left to a poll because there was no consensus on which system to use. Since the policy's enactment, two discussions (one in 2015 and one in 2020) were started in opposition of the policy and how it was decided. In both discussions, the consensus was that a poll was not a great way to gather the opinions of readers and editors, though neither discussion led to any changes in the policy. Why we should change the policy I am proposing to use in-game capitalization for one main reason: it would be the most official way to present these names. We use official terms as they are in the games for all other subjects, so why should items be any different? I feel that capitalization is just as much a part of a subject's official name as anything else. The capitalization of item names is not just aesthetic; it has practical effects. There are plenty of items that do use proper nouns in-game, and with our system of making everything a proper noun, the actual proper nouns in the original names are lost. Another issue with our current policy is shown with the "Snowman vanity" (uppercase "S") in the North American version of City Folk, which was changed to "snowman vanity" (lowercase "s") in the European version. With our current system, there is no way to convey to the reader that the name was changed without either breaking our policy or having an awkward note. One point that was brought up in the 2015 discussion is that it would be hard to enact such a policy of using in-game capitalization since there was no accurate master item list for all games. Another point brought up in the 2020 discussion is that having item names in title case has stylistic value because makes it clear to the reader that these are actual in-game items and not generic terms. To respond to these two counter-arguments: Today we have spreadsheets for every game in the series that use datamined names, so those would be our sources if this policy were to be enacted. The most common way items are mentioned in articles is through tables or other similar templates which isolate the name from any other text, making it clear to the reader that these aren't generic terms. Also, items should always be linked to their respective item pages, which would make it clear even in the prose that a term is not generic. As a wiki that covers content from the Animal Crossing series objectively and strives to be as accurate as possible, I believe there isn't a place on Nookipedia for a policy that makes us write item names contrary to how they appear in the games, especially for stylistic reasons. Other item-related terms There are also several non-item—but still item-related—terms that are not defined in our MoS, but still follow our item name policy on the wiki; namely HHA genres/themes and variant/pattern names. Any terms like these should be changed to in-game case just like the items themselves, for the same reasons stated above. That being said, I am not proposing any changes to our furniture collection (series/set/theme) terminology in this proposal. Their full names aren't clearly defined via in-game strings like the other terms; the first part (e.g. "blue", "lovely", "modern") is defined, but the "series"/"set"/"theme" part, as far as I can tell, is just an internal property and is never appended to the name in-game. I think these warrant their own proposal to determine what we call them going forward, but at the moment, they can stay at their current names. I also want to make it clear that this policy would not affect item image filenames; the standard for all filenames is title case and I see no need to change that. How we would implement this policy This is the format I am proposing we use going forward: In the prose of an article: write item names exactly as they are in-game, except for (obviously) capitalizing the first letter if it is at the beginning of a sentence. In tables and templates like {{House Info}}: capitalize the first letter; these will be essentially treated as sentences. In item page infoboxes: In the "name" parameter of the template, capitalize the first letter; these will be essentially treated as sentences. This will be what is displayed in the infobox and what is queried in Cargo for item tables. In the "en-name" parameter of the template, write item names exactly as they are in-game. This will be stored to Cargo and can be queried if needed. With thousands of item pages and even more mentions of items across the wiki, it will take a while for everything to be fully updated, but it will certainly be possible. Item pages would be automatically moved and their prose would be updated via text replacements, as would standardized templates such as the villager housing templates. Updating the item pages would in turn automatically update every Cargo item table; for non-Cargo tables, those will be replaced in due course with Cargo tables as item pages for all the games are created. The only thing that I don't think can be updated automatically would be mentions of items in the prose of mainspace articles; however, these take up such a small amount of the mentions of items across the wiki relative to the others I've listed that it could be done manually. This was a long proposal, but for a change as large as this I feel I needed to go into as much detail as possible. Thank you for your time and consideration. ~ AlexBot2004 (Talk) 00:00, November 19, 2022 (EST)
Comments:	I'm kinda conflicted with this notion. On one hand, I think this is accurate, and I'm certain of using the in-game names as best as possible, I understand why this is necessary for us, and if anything it'll probably be better off to use the actual in-game names. On the other hand, I'm not very confident that things will remain functional as it is. I'd have to go through some of the worst cargo tables and change name to en_name, and with how slow some of these pages are, I feel like the worst cargo tables will just break again. If we want to assure we actually abide by the in-game names, I think we need to look into how the item names are being used at a technical point, and see if it'll be able to run without issues. -- PanchamBro (talk • contributions) 00:42, November 19, 2022 (EST) Everything makes sense to me, 100%. Another thing to note that sucks about the current capitalize-everything item policy is that certain items are difficult to discern if they really needed to be capitalized. (For example, we don't capitalize umbrella/gyroid/fossil as a category of item, but some items like "shovel" and "turnip" are both a category of item and an actual item, so they have inconsistent casing throughout the entire wiki, especially on the handheld items page.) And also, it's very difficult when it comes to real-life bugs, fish, and sea creatures, because they are items, so per item policy, they should be capitalized, but there are instances where pages switch between the animal as a concept and the animal as an item, so you have pages like Pascal that go back and forth between capitalizing "scallop." Plus a lot of pages aren't even following the capitalization rule in the first place and have lowercase bugs/fish/sea creatures. I agree with everything stated in Alex's proposal, including the part involving capitalizing the first letter of items in lists/tables/templates/infoboxes, but I just wanted to mention one other thing that needs to be fixed that sort of breaks this mold. A couple of years ago, I capitalized all of the clothing in the {{E-card}} templates, because if I remember correctly, some of it was inconsistent (might be wrong there), and also because item policy states items should be capitalized. But in reality, the transcriptions of these clothings should match what is written on the cards (star signs are capitalized and should remain capitalized, catchphrases are lowercase and should remain lowercase, so the clothing which is lowercase should also be lowercase). This is like a sort of special exception to the lists/tables/templates/infoboxes rule. HylianAngel (talk) 21:18, November 19, 2022 (EST)
Votes:	As long as there are no significant technical issues, I wholeheartedly  Support this proposal for all the reasons AlexBot2004 has outlined. Although it may take some getting used to, I think that the reasons we have the capitalization policy are not very good ones anymore, and that there are only benefits to this (again, as long as cargo, API and other technical things are taken care of). I also think it's worth noting that New Horizons uses sentence case in all cases (e.g. in the catalogue or inventory); while earlier games don't, it obviously makes sense to keep this consistent, and I think using sentence case outside of prose (i.e. in lists, tables, etc.) makes more sense as a universal guideline. Chubby Bub (talk) 03:08, November 19, 2022 (EST)  Support HylianAngel (talk) 04:00, November 19, 2022 (EST)  Support Drago (talk) 11:09, November 19, 2022 (EST) I've taken my time to go ahead and implement several key modules that will be helpful for us for when we move every name to their proper in-game counterpart. The first module I developed was Module:CapitalizationCheck, which should be implemented in the {{I}} template and be used to check if the item name is improperly capitalized. I know it might sound redundant, many tables won't be affected by this change, but this is going off the template's usage in other instances, such as within proses and stuff. Coupled with the fact that I assured that the item name is marked to give attention, and this should help us find all item names without having to resort to a lot of bots to manually figure out what item names need to be changed (and I definitely do not want to continue to use the pywikibot feature and continue to run into more CSRF errors. The second is currently available at Module:Sandbox (though by the time some historical reader might be seeing this, it should be moved to its own module). This will automatically proper case names. Now why do we need this? Since we're also going to change the capitalization of in-game names, it's important that this module is properly implemented to display images. Otherwise, we'd run into issues. I'm sure we could just also remove the need for having a separate parameter for images too, but I'll have to check if the change will impact item pages in the long run. There's still the fear of cargo tables breaking, but if I don't have to change many parameters around, I think it should be good. With that being said, I  Support this proposal for the purpose of making our coverage of these games more accurate. -- PanchamBro (talk • contributions) 15:54, November 20, 2022 (EST)  Support CompuGenetics (talk)
Result: (100%)	Passed. The proposal was enacted by ~ AlexBot2004 (Talk) 00:00, November 26, 2022 (EST).

Voting on this proposal has ended. (refresh)

[Passed] Implement new Nookipedia:Polls policy

Proposal:	Implement new Nookipedia:Polls policy
A couple of months ago, I suggested reviving the idea of polls on the wiki, and a majority were in support of the idea. As such, I've devised a new policy in regards how the main page polls will work from now on here. To summarize: This policy will call for the switching of the poll every 1st and 15th of every month. A poll committee will be established, tasked with selecting the new poll for the main page. They will start a session to discuss what poll to use a week before the poll is switched out. Guidelines on what a poll should be (poll related to the Animal Crossing series; minimum of three choices, maximum of ten; question are straightforward, simple; lighthearted poll only, no controversial ones; users have the option to display their username for suggesting the poll). Guidelines on how to start a poll and how to archive a poll. That's a lot to take in, but hopefully if this system is implemented, our main page poll system would work. -- PanchamBro (talk • contributions) 21:38, September 20, 2022 (EDT)
Comments:
Votes:	Support Drago (talk) 10:48, September 21, 2022 (EDT)  Support Kalina (talk) 19:32, September 21, 2022 (CET)  Support Chubby Bub (talk) 06:55, September 22, 2022 (EDT)  Support ~ AlexBot2004 (Talk) 15:24, September 22, 2022 (EDT)  Support 💜Toadalind💜 (talk) 20:29, September 23, 2022 (EDT)  Support K Kit(talk) 23:42, September 27, 2022 (EDT)
Result: (100%)	Passed. The proposal was enacted by ~ AlexBot2004 (Talk) 18:08, September 28, 2022 (EDT).

Voting on this proposal has ended. (refresh)

[Passed] (Re)separate Doubutsu no Mori+ and Dòngwù Sēnlín

Proposal:	(Re)separate Doubutsu no Mori+ and Dòngwù Sēnlín
Yeah, it's this discussion again. This (well, the first part) was discussed on Talk:Doubutsu no Mori+ since 2018, and the page was merged with Animal Crossing in 2020. However, the wiki has evolved since then, recent as it may seem, and I strongly believe it would be beneficial to have these pages separate again. Though I suspect everyone who will participate in this proposal knows this, a brief overview: Doubutsu no Mori was released for the Nintendo 64 on April 14, 2001, in Japan only. Doubutsu no Mori+ was released for the Nintendo GameCube on December 14, 2001, a port of Doubutsu no Mori with many more features added, again in Japan only. Animal Crossing was released for the GameCube in 2002 in North America, and in 2003 and 2004 in other regions. Although it is the international version of Doubutsu no Mori+, it added new events, characters, and other features. Doubutsu no Mori e+ was released for the GameCube in 2003 in Japan only, giving Japan the new features introduced in Animal Crossing and other new, exclusive features. Dòngwù Sēnlín was released for the iQue Player, a console that ported N64 games– in this instance Doubutsu no Mori– to China, in 2006. Though not much is known about this version due to its obscurity and technical difficulties, we know items were changed/added as well as events and villager houses, at the very least. So first: currently Doubutsu no Mori+ and Animal Crossing are at the same page, the former a redirect to the latter. (This makes sense as this is an English wiki, I can only assume if this were a Japanese wiki we'd do the opposite.) It is correct that Doubutsu no Mori+ and Animal Crossing are two regional versions of the same game. Nintendo has made it clear when they overview the series in Japan that the first three games are Doubutsu no Mori, Doubutsu no Mori+ and Doubutsu no Mori e+. Also, DnM+'s game ID is GAFJ and AC's is GAFE in America. The first letter indicates the system (G - GameCube), the second and third the game (AF/AE - Animal Forest/Animal Forest e+, I assume), the last the region (J- Japan, E - North America). (For reference, DnM's ID is NAFJ (N - N64) and AC in Europe/Australia is GAFP (P - PAL); the iQue Player uses a different system.) So, to be very clear, I am not contending that Doubutsu no Mori+ and Animal Crossing are two different versions of the same game; rather, I accept this and still believe they should have separate pages. Here's why: Nookipedia is an encyclopedia about a video game series. We cover the contents of the games and gameplay. As such, gameplay differences are an important aspect to cover. More recently, through datamining and the creation of the AC Spreadsheets and Item pages, many more differences beyond "they added a couple characters and events" have come to light. This includes, but is not limited to: the way items are obtained, many items being removed and added, most events being changed, the way passwords work, the way e-Reader cards work, songs being added or replaced, character/item appearance changes, and villager house interiors. These may be two different versions of the same game, but major aspects of the gameplay differ significantly. The premise for merging the pages was that they have "relatively few differences" or "minor differences", which is simply untrue. Furthermore, people looking for information on Doubutsu no Mori+ are generally not looking for info on Animal Crossing, and vice versa. The only reason for Template:DnM+ to be used is in comparison to other games with gameplay differences– yet the link redirects you to one of those pages. If a casual reader reads "in Doubutsu no Mori+ x, but in Animal Crossing y" yet both link to Animal Crossing, this serves as a point of confusion. Then, it isn't immediately apparent by looking at that page that the two are regional versions of the same game. Also, I've on occasion seen Doubutsu no Mori+ replaced with something like "the Japanese version of Animal Crossing" or "Animal Crossing (Japan)", which again, while technically true, paints a picture that is not exactly true. Regardless of the outcome of this proposal, I would discourage this type of language. So all of that is why I think the games should be not be not be on the same page. But neither should they be considered separate games, just acknowledged as separate versions. Since this is an English wiki, most users will likely be looking for information on Animal Crossing, and that should still be our primary page for the two, especially where things are the same in-game. But Doubutsu no Mori+ should be its own page detailing its release and gameplay, what it added, etc. As for the Version differences sections on game pages, they should detail the differences added compared to the prior version. This reasoning is also why the PAL version of Animal Crossing does not need to be split; there are no significant gameplay differences, just minor model changes and at most moving the date of a couple holidays. (Well, that we know of...) All of the above is also why I think Dòngwù Sēnlín should also have a separate page. While we know a lot less about it, we do know that it is significantly different from Doubutsu no Mori, and that includes item differences. I also think it should get its own linking template (even if we don't split the pages)– Dòngwù Sēnlín is a pain to type out, and again, I think things like "the iQue Player version of Doubutsu no Mori" should be avoided. The short version should probably be "iQue", since "DS" could cause confusion with the handheld console, and also just seems kind of silly to me. The last part of this proposal is clarifying that this shouldn't only split the game pages, but related pages such as Furniture/Animal Crossing, where there are differences. The way those pages are currently handled is another point of confusion. Dòngwù Sēnlín items should also get their own pages in the Item namespace. I know this was a long post, but well, proposals tend to be, and there was a lot to cover, so thanks for reading it. (Well, I hope you did.) Chubby Bub (talk) 04:51, August 10, 2022 (EDT)
Comments:	Great proposal! Both Doubutsu no Mori+ and Dòngwù Sēnlín have enough differences from Animal Crossing and Doubutsu no Mori, respectively (enough that the regional differences sections take up a large chunk of both pages), to warrant having their own pages to cover said differences (as well as separate item lists and terminology when referring to the games in articles). I also agree with having {{iQue}} as a shorthand for Dòngwù Sēnlín and creating pages for that game's exclusive items (if/when that data is datamined). ~ AlexBot2004 (Talk) 21:48, August 10, 2022 (EDT)
Votes:	Support TimeSword3D (talk) 09:32, August 10, 2022 (EDT)  Support Senor Mexicano (talk) 16:16, August 10, 2022 (EDT)  Support Dr. Peach (talk) 18:02, August 10, 2022 (EDT)  Support ~ AlexBot2004 (Talk) 21:48, August 10, 2022 (EDT)  Support -- PanchamBro (talk • contributions) 08:45, August 11, 2022 (EDT)  Support Kalina (talk) 15:40, August 11, 2022 (CET)  Support The Messenger(talk) 18:19, August 14, 2022 (EDT)  Support 🤓🌸ToadetteFan007 (Talk) 🌸🤓 12:19, August 15, 2022 (EDT)
Result: (100%)	Passed. The proposal was enacted by ~SuperHamster Talk Contribs 01:13, August 18, 2022 (EDT).

Voting on this proposal has ended. (refresh)

[Failed] Namespace for e-Reader and amiibo cards

Proposal:	Namespace for e-Reader and amiibo cards
Nearly a year ago, AlexBot proposed the creation of e-Reader card pages, and many ideas came forward, including the creation of a Card namespace particularly to also add amiibo cards. However, 4 months later, I later proposed that both e-Reader and amiibo pages get separate namespaces for e-Reader cards and amiibo, as the Card namespace would leave out amiibo figurines. Therefore, this proposal will come down to two options: Either we create the Card namespace, or we create the E-Reader Card and Amiibo namespaces. -- PanchamBro (talk • contributions) 07:45, May 19, 2022 (EDT)
Comments:	I think it would be better to create Amiibo and E-Reader Card namespaces. Because it will be easier to tell the cards apart and it will be more convenient than creating a Card namespace. Kalina (talk) 20:12, May 21, 2022 (CET) I haven’t had time to review this proposal in enough detail to render a vote yet, but if we did do a namespace for cards, it would likely need to just be one for both card types. Per MediaWiki docs, namespaces are intended to differentiate pages at a “very high level”, and also require additional backend work to maintain. The scope of a namespace is far too large to be narrowed to just a single type of card, that kind of differentiation would be better handled through the title (as is done with item pages across games) and with categories. -Jake (talk) 20:17, May 21, 2022 (EDT) As a collector of both types of cards, I've been adding some information on them, so I really like this idea for individual pages. On the namespace issue, I recall someone suggested a Merchandise namespace. Examples for such page titles in my mind, similar to what I said on the last proposal: Merchandise:112 Peewee (Doubutsu no Mori+ e-Reader card) Merchandise:044 Faith (Animal Crossing e-Reader card) Merchandise:073 Roswell (Doubutsu no Mori e+ e-Reader card) Merchandise:CP Isabelle (amiibo card) Merchandise:Kapp'n (amiibo figure) The problem with this is we wouldn’t necessarily want individual pages for all types of merchandise as the name implies. While more obscure collectibles like Mori o Tsukurou! figurines and Millefeui Cards could theoretically have their own pages, unlike the interactive e-Reader cards and amiibo they don't really have anything to be documented on pages of their own. I feel like "Merchandise" and "Collectible" are thus misleadingly broad namespace titles. If we document amiibo cards, figures definitely need to be documented too though, because they have unique functionality compared to cards. So personally, I like the idea of two separate namespaces but if this is too difficult or tedious to maintain technically, there could be a single namespace, but it must have a clear and better name. Chubby Bub (talk) 02:59, May 22, 2022 (EDT) Unless I'm mistaken, I don't think having a new namespace would force the general merchandise pages to be split into individual ones, would it? I feel like there wouldn't be much issue with general and individual merchandise articles co-existing under one namespace. Though if that wouldn't work, I was also thinking the new namespace could just be titled "Interactive". Senor Mexicano (talk) 13:59, May 24, 2022 (EDT) I didn't mean it would force other merchandise to have individual pages, just that the name Merchandise would imply that such pages might exist when they wouldn't. In fact, I'd say Merchandise is not a good name because the majority of merchandise is fine being covered in the Main namespace. Unless there are significant downsides to having two more namespaces, I am actually strongly in favor of an e-Reader one and an amiibo one. The way the two work and the data they carry is not all that similar. Chubby Bub (talk) 18:22, May 25, 2022 (EDT)
Votes:	Support Kalina (talk) 20:12, May 21, 2022 (CET)  Support Chubby Bub (talk) 02:59, May 22, 2022 (EDT)  Support ~ Vivian (talk) 12:52, May 23, 2022 (EDT)
Result: (??%)	The proposal received 3 out of 3 support votes, as users generally agree that some namespace(s) should be created to document e-Reader cards, amiibo cards, and amiibo figurines. However, there are multiple suggestions about which namespaces, and multiple suggestions involving their names. Jake has advised against separating them as "Amiibo" and E-Reader Card" due to MediaWiki standards. But the majority community consensus seems to be using these 2 namespaces, in order to avoid excluding amiibo figurines. While I personally that using these 2 namespaces makes sense, given that amiibo cards shares much more functionality with amiibo figures compared to e-Reader cards, Jake's opinion is more important in this matter, as he is the one who is well-versed with MediaWiki docs. 1 namespace involving all 3 types of merchandise has been suggested; this would be the best solution, so that amiibo cards, amiibo figurines, and e-Reader cards can all be documented. In the Nookipedia Discord, Jake has also agreed that this would be an ideal solution. Unfortunately, there are no official names that are inclusive for all 3 types, and users are divided on which one to choose. (Merchandise? Very broad and may be misleading as other types of merchandise may not be documented. Interactive? Scannable? Collectible?) While the initial proposal was very clear with a binary choice, the community is still divisive on certain specifics. Jake has (semi-vetoed) the option that has had the most votes (Amiibo and E-Reader namespaces). So although the proposal "passed" with a 100% vote, the choice with the most votes does not pass. This is a unique situation, as the complexity of this topic has resulted in a slight contradiction of the rule that states the components of the proposal should not be vague. I apologize for denying a proposal that has technically passed, but this may require more discussion in Nookipedia talk:The Roost before it should be proposed again. Due to the (semi-)veto of the most popular choice, consensus seems to be leaning towards choosing 1 namespace that includes all 3 types of merchandise. My suggestion for the next discussion point is a poll involving multiple options on the potential name for the single namespace (Merchandise, Interactive, Scannable, Collectible, Other (specify)) Denying the proposal until a new namespace name is submitted. HylianAngel (talk) 05:53, July 4, 2022 (EDT).

Voting on this proposal has ended. (refresh)

2021

[Passed] New block policy

Proposal:	New block policy
It's time for our first Nookipedia Proposal! To kick things off, I'm going to re-propose a new block policy I wrote a few months ago. Only two votes were cast before the discussion became inactive, so I thought it would make sense to revive it as our first official Proposal (the original discussion is here.) I've made a couple of changes since then (relating to partial blocks and talk page editing), so I'm pretty sure that the policy is complete now. As before, please review it and let me know what you think. Thank you! Drago (talk) 13:24, December 9, 2021 (EST)
Comments:	Great work putting this together, Drago! I've given it a final read and everything looks tip-top. (talk) 21:06, December 10, 2021 (EST) This proposal is well written and certainly more comprehensive than our current policy. There are a few very minor changes I wish to make to the Username and Director Block sections, but those changes do not stand in the way of this proposal in its current form. -Jake (talk) 17:07, December 13, 2021 (EST)
Votes:	Support vmario97 (talk) 14:40, December 9, 2021 (EST)  Support Kalina (talk) 20:46, December 9, 2021  Support ~ Vivian (talk) 15:06, December 9, 2021 (EST)  Support The Messenger(talk) 15:51, December 9, 2021 (EST)  Support ~ AlexBot2004 (Talk) 17:49, December 9, 2021 (EST)  Support -- PanchamBro (talk • contributions) 19:47, December 9, 2021 (EST)  Support -- Elephant Lady (talk)  Support (talk) 21:06, December 10, 2021 (EST)  Support ZCJigglypuff(Talk)  Support -Jake (talk) 17:07, December 13, 2021 (EST)  Support.Deirdre (talk) 11:10, December 14, 2021 (EST)  Support -Lampshade59276 (talk) 18:16, December 14, 2021 (EST)
Result: (100%)	Passed. The proposal was enacted by Drago (talk) 11:28, December 17, 2021 (EST).

Voting on this proposal has ended. (refresh)