Nookipedia Proposals allow the community to vote on sitewide changes that would affect a large number of pages or users. This process is not a replacement for community-wide input (see:The Roost) or talk page discussion. Rather, it takes the final product of those discussions (in the form of a proposal) and puts them to a vote.
Rules
- Proposals are only necessary for changes that would affect a large number of pages or users. Some examples: rules/policy changes, adding/removing namespaces, making major modifications to/replacing templates that affect 1000+ pages.
- Proposals are for voting on fully worked out ideas. They should be a binary yes/no choice and not have any yet-to-be-determined components: no 'option a, b, or c'. Proposals may be submitted without prior public comment or feedback, but should not receive major edits or changes once voting has started. If a proposal does not follow these rules or is otherwise deemed unfit, it may be vetoed at the discretion of a Bureaucrat.
- Proposals can only be submitted and voted upon by registered users. Comments or votes from unregistered users will be removed immediately. Furthermore, all votes or comments must have a signature attached (
~~~~). Users are not allowed to vote on their own proposal, but may respond to comments.
- Proposals will be open for seven days. This voting deadline can be extended upon request, at the discretion of a Bureaucrat.
- At the end of the voting period, if the proposal has at least a 2/3 majority (66%) support and five total votes it will be considered successful. A Bureaucrat will then officially close the proposal, and either enact it themselves, or coordinate with other staff members to make sure the proposal is completed.
- If the proposal does not have five votes at the end of the voting period, the voting period will be extended for seven days.
- Once a proposal has been enacted, the staff member responsible will make a note here and move the proposal to the Archives.
How to make a proposal
All proposals must be made using the template provided below, posted under the "Current Proposals" heading:
{{proposal
| title = A short, one-sentence description of the proposal.
| description = Additional proposal details/explanation.
| comments = User commentary on proposal.
| votes = User votes on proposal: {{Support}} or {{Oppose}} + signature (~~~~).
}}
Current proposals
There are no active proposals. For a record of past proposals, visit the Archive.
| 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)
|
| Votes:
|
|
|
|
| Result: (??%)
|
To be determined.
|
Voting on this proposal has ended. (refresh)
