|
|
| Line 21: |
Line 21: |
| *I challenge the statement that the screenshots addressed by this proposal are not high quality. See [[:File:KSqS Gamble Galaxy Stage 1.jpg|these]] [[:File:KSqS Cushy Cloud Stage EX Chest 2.jpg|three]] [[:File:KSqS Cushy Cloud Stage 5.jpg|images]] for examples of what I am talking about. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 15:43, 2 March 2022 (UTC) | | *I challenge the statement that the screenshots addressed by this proposal are not high quality. See [[:File:KSqS Gamble Galaxy Stage 1.jpg|these]] [[:File:KSqS Cushy Cloud Stage EX Chest 2.jpg|three]] [[:File:KSqS Cushy Cloud Stage 5.jpg|images]] for examples of what I am talking about. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 15:43, 2 March 2022 (UTC) |
|
| |
|
| {{clear}}
| |
|
| |
| ==Proposal Rules Overhaul 021922—030522==
| |
| '''Notice: This proposal has multiple changes to vote on, and therefore multiple support/oppose/neutral headers to vote for.'''
| |
| Welcome to the PRO, the Proposal Rules Overhaul. Having observed discussions in the Shiver Star discord, as well as have some quarrels of my own, this proposal serves to overall update the general rules of the proposal system. There are multiple mini-proposals here so that each proposed change has it's own vote, so that only the suggested changes the community wants is passed.
| |
|
| |
| Thanks! [[User:Trig Jegman|Trig Jegman]] - 00:54, 19 February 2022 (UTC)
| |
|
| |
| ===Rule Change 1===
| |
| '''Develop structures for multiple option proposals.''' Currently, the wiki is only really designed to have yes or no style proposals work in the system. In recent matters, however, several proposals (including this one!) would benefit or would have benefitted from the ability to set different parameters for passing, for more specific options to vote on. If this rule passes, work will be made to set up any extra rules necessary, as well as determining an appropriate structure for multiple-option proposals.
| |
| {{Support}}
| |
| #Agreed. We've had unofficial multiple option proposals already, and those were a bit confusing due to lack of official rules for them. {{User:Pinkyoshifan/sig}} 13:38, 19 February 2022 (UTC)
| |
| #I agree, however I still feel that a proposal like this would should instead just be treated as five different proposals. A similar recent event we had was with the UserLang templates, where we first got rid of the general one, then we got rid of the game ones. They are related, sure, but they are two different suggestions, and I feel they work best as two different proposals. However, for proposals with changes that are less black and white, I do agree we need a good set of rules to organize them better. A recent example is [https://wikirby.com/wiki/WiKirby:Proposals/Archive-2021#Smash_Bros._Coverage_110221%E2%80%93111621_EXT:_112521 the ''Smash Bros.'' content proposal]. {{User:Gigi/sig}} 16:37, 20 February 2022 (UTC)
| |
| #I agree that work should be done to make a more intuitive multiple-option proposal template. Ideally, any and all such templates should have an option that serves as the equivalent of "Oppose", in which nothing is changed. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 17:04, 20 February 2022 (UTC)
| |
| #Ofiicial flexibility towards more options is good, but I do think there shouldn't be any more multiple proposals cramped into one. {{User:Superbound/sig}} 19:57, 27 February 2022 (UTC)
| |
| #Sounds pretty good to me, as long as we don't cram proposals which should be apart into each-other. I've been confused in the past by some larger proposals because we've not had an official structure for said larger proposals. -- {{User:MetaDragon/sig}} 02:19, 1 March 2022 (UTC)
| |
| #I agree on this, it would ease a lot various proposals in where just a "Support or Oppose" alone doesn't suffice. I have seen a few proposals on [[mariowiki:|Super Mario Wiki]] that use a variety of options to vote from aside from "Yes or No", and they really benefit from doing so. Just pass a bit through some of [[mariowiki:MarioWiki:Proposals/Archive|their proposals]] and you will see what I'm talking about. As stated, in this wiki, past proposals would have benefited from this, and future proposals surely will. I don't see any downside here.<br> Now, I don't know if that "(including this one!)" is referring to that this proposal would have benefited from having more voting options than a "Yes or No", or if that is alluding that "multiple option proposals" are the same thing as having multiple proposals in one, like this one. If the latter, I am with Gigi, Superbound and MetaDragon in that a multiple proposal like this one should be counted as various separate ones, and not merging them in one. There is a difference between a proposal which options are more varied than "Support or Oppose" and a proposal that is essentially various proposals in one. -[[User:Kirbeat|Kirbeat]] ([[User talk:Kirbeat|talk]]) 07:46, 1 March 2022 (UTC)
| |
| #I support more or less for the reasons above. The amount of proposals that were different from what the current rules define has risen these past months. Having extra rules for them can't hurt. [[User:Infinite Possibilities|Infinite Possibilities]] ([[User talk:Infinite Possibilities|talk]]) 07:23, 5 March 2022 (UTC)
| |
| {{Oppose}}
| |
| {{Neutral}}
| |
| ====R1 Discussion====
| |
|
| |
| ===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}}
| |
| #Even if someone is blocked, that doesn't neccesarily mean their ideas are bad. {{User:Pinkyoshifan/sig}} 13:38, 19 February 2022 (UTC)
| |
| {{Oppose}}
| |
| #There's nothing to sponsor or adopt; either the proposal passes or it doesn't. Just don't remove it. {{User:Vipz/sig}} 05:33, 21 February 2022 (UTC)
| |
| {{Neutral}}
| |
| #I really don't have strong feelings either way here, personally, mostly because I believe this case would be very unlikely to happen. {{User:Gigi/sig}} 16:37, 20 February 2022 (UTC)
| |
| #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. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 17:04, 20 February 2022 (UTC)
| |
| #I agree on the above. Decent idea, but no need for so many steps, especially with how unlikely this is to happen at all. -- {{User:MetaDragon/sig}} 02:19, 1 March 2022 (UTC)
| |
| #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 [[WiKirby:General content policy|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.<br> 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.<br> 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. -[[User:Kirbeat|Kirbeat]] ([[User talk:Kirbeat|talk]]) 07:46, 1 March 2022 (UTC)
| |
| #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.[[User:Infinite Possibilities|Infinite Possibilities]] ([[User talk: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. {{User:Pinkyoshifan/sig}} 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. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 19:15, 25 February 2022 (UTC)
| |
|
| |
| ===Rule Change 3===
| |
| '''Early proposal endings.''' A chief complaint for some is that two weeks can be a substantial time for something that is either timely or minor. This change suggests the following: In the even a proposal has seven (7) unanimous support votes OR ten (10) support votes and no more than two neutral votes, as well as the support of a bureaucrat, a proposal may pass in only one week instead of two.
| |
| {{Support}}
| |
| #Yes. This would help speed up good proposals (although it seems like a high bar, but with proposals that's probably a good thing). {{User:Pinkyoshifan/sig}} 13:38, 19 February 2022 (UTC)
| |
| #Sounds fair enough. Since we we will always have an active crat because we will always have an EiC, it's unlikely that a proposal wouldn't end early just because a crat didn't support it. {{User:Gigi/sig}} 16:37, 20 February 2022 (UTC)
| |
| #This seems like a reasonable set of parameters for a fast-track. No objections from me. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 17:04, 20 February 2022 (UTC)
| |
| #Sounds like a decent guideline that should improve proposals overall. Support. -- {{User:MetaDragon/sig}} 02:19, 1 March 2022 (UTC)
| |
| #It is something that will reasonably speed up the right proposals. I do think that the number may be a bit high, but still I think that it is low enough to be reachable, and high enough to not be exploited. Nothing to argue here. -[[User:Kirbeat|Kirbeat]] ([[User talk:Kirbeat|talk]]) 07:46, 1 March 2022 (UTC)
| |
| #The required unanimous votes does it for me. That way this is guaranteed to only happen for things that the community at large agrees on. Not much else to say, support. [[User:Infinite Possibilities|Infinite Possibilities]] ([[User talk:Infinite Possibilities|talk]]) 07:23, 5 March 2022 (UTC)
| |
| {{Oppose}}
| |
| {{Neutral}}
| |
| ====R3 Discussion====
| |
|
| |
| ===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}}
| |
| #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. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 17:04, 20 February 2022 (UTC)
| |
| #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. -- {{User:MetaDragon/sig}} 02:19, 1 March 2022 (UTC)
| |
| #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.<br> 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.<br> 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.<br> 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. -[[User:Kirbeat|Kirbeat]] ([[User talk:Kirbeat|talk]]) 07:46, 1 March 2022 (UTC)
| |
| {{Neutral}}
| |
| #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. {{User:Pinkyoshifan/sig}} 13:38, 19 February 2022 (UTC)
| |
| #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. {{User:Gigi/sig}} 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. {{User:Superbound/sig}} 19:57, 27 February 2022 (UTC)
| |
|
| |
| ===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}}
| |
| #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). {{User:Pinkyoshifan/sig}} 13:38, 19 February 2022 (UTC)
| |
| {{Oppose}}
| |
| #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. {{User:Gigi/sig}} 16:37, 20 February 2022 (UTC)
| |
| #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. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 17:04, 20 February 2022 (UTC)
| |
| #Yeah, keeping it up would be more difficult than it's worth it. {{User:Superbound/sig}} 19:57, 27 February 2022 (UTC)
| |
| #Yes. With the third rule change in this proposal, this is unnecessary and loosens things up a bit too much for comfort. -- {{User:MetaDragon/sig}} 02:19, 1 March 2022 (UTC)
| |
| #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.<br> 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.<br> 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. -[[User:Kirbeat|Kirbeat]] ([[User talk:Kirbeat|talk]]) 05:45, 4 March 2022 (UTC)
| |
| {{Neutral}}
| |
| #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. [[User:Infinite Possibilities|Infinite Possibilities]] ([[User talk: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. -[[User:Kirbeat|Kirbeat]] ([[User talk:Kirbeat|talk]]) 07:46, 1 March 2022 (UTC)
| |
| {{clear}} | | {{clear}} |
|
| |
|
