MarioWiki talk:Proposals/Archive

Some of the boxes' colors are really bright. May they be dimmed down? 21:25, 3 June 2014 (EDT)
 * They're not that bright. Besides, dimming them down any further than they are makes them look faded and/or downright sucky (ever tried dimming yellow?), not to mention harder to tell apart (blue-green; pink-red-orange), especially for colour-blind folks. It took the admins a while to settle on a colour palette with all that in mind, and I think it's fine as is. - 15:31, 4 June 2014 (EDT)

TPP: Create a separate color for joke proposals
This coloring system looks fine and all, but I would like to make a separate color for joke proposals, for many reasons. First, it distinguishes the joke proposals from the rest. This would give users and administrators an easier task of looking for joke proposals. Second, it occurs to me that users are complaining how bright this page's color code is. Luckily, I'm proposing that the new color be black. Be sure to contact me in the Comments section about what color you would like, other than black.

Here's what the page will look like if the proposal passes.

Proposer: Deadline: June 24, 2014, 23:59 GMT.

Support

 * 1) Per proposal.

Oppose

 * 1) Making a color for proposals that are inherently discouraged from making isn't a good idea in the first place. It's much better if we applied the words "(Joke Proposal)" or something rather than create a separate new color for this. Most other joke proposals are deleted. The ones that are archived...well....are exceptions and the latter pie proposal served a purpose rather than be nonconstructive and generally stupid. Exceptions don't make a rule, and this sort of change is very unnecessary. Besides, you missed a joke proposal in your work page
 * 2) Per Baby Luigi. And I think the PIE proposals are archived because of how many people voted on them.
 * 3) Per Baby Luigi. Very few joke proposals make it to the archive without being outright deleted (in 8 years, precisely two have made it in and those were due to exceptions outlined by me in the comments). Being that the number is so low and likely to stay low, I'm more in favor of adding (Joke Proposal) to the title on the table of contents. Perhaps removing them from the formal archive altogether, moving them to userspace or BJAODN.
 * 4) Per Baby Weegee and the supernatural jelly.
 * 5) Per Ghost Jam, it's unnecessary to create a color for Joke proposals that are supposed to be deleted on sight.
 * 6) Well joke proposals kind of have there own little section. Its called the BJAODN.

Comments
But... joke proposals aren't allowed. They're deleted on sight, so they don't get archived. 17:09, 10 June 2014 (EDT)
 * Ghost Jam's PIE proposals are both archived. 19:03, 10 June 2014 (EDT)
 * Oh, right... forgot about those. 19:01, 11 June 2014 (EDT)
 * Mine are exceptions due to administrative flam-foolery. I archived the first one myself, in my userspace. The second was archived as part of the yearly April Fools archive of jokes. These exceptions don't apply to every joke proposal made. -- [[Image:Shyghost.PNG]]Chris[[Image:Shyghost.PNG]] 13:25, 15 June 2014 (EDT)

I don't think black is the best color. The other colors are kind of soft, so black really sticks out like a sore thumb. I use a custom CSS, so, unfortunately, I can't see the colors as readily as most users. White isn't used yet, so try white...? Or cyan? 16:16, 13 June 2014 (EDT)

Yeah... in my opinion, they shouldn't even be archived normally. They should be in BJAODN rather than grouped with all these "normal" proposals. 17:34, 13 June 2014 (EDT)

The Bandit Proposal
I can't seem to find the Bandit proposal anywhere on this. Am I being stupid, or should someone archive it? (I can't, because of protection stuff) 12:46, 23 June 2015 (EDT)
 * Oh, and my own Talk:Nintendo 3DS proposal isn't there either. 12:53, 23 June 2015 (EDT)
 * We don't archive talk page proposals. Once they're done, they stay on the talk page, they appear in the Settled Talk Page Proposals category, and that's it.
 * Oh, whoops. Okay, that's fine then. 14:13, 23 June 2015 (EDT)

Split Archive Page by Year
is getting quite long being at around 127,958 bytes at the time of this proposal create date. If you are going to the page with a cleared browser cache, it takes a few seconds to process the page. The problem gets worse because  is being called hundreds of times. All you want to do is archive your proposal. I think it would be a good idea to create subpages and have the main archive page link to each subpage. This is something that policy would definitely support but can it apply to a namespace like this? Here's an example:


 * /2007 #FF0000
 * /2008 #FF0000
 * /2009 #FF0000
 * /2010 #FF0000
 * /2011 #FF0000
 * /2012 #FF0000
 * /2013 #FF0000
 * /2014 #FF0000
 * /2015 #FF0000
 * /2016 #FF0000
 * /2017 #006600

Here is a page mock-up how I envision the change (notice usage on the subpages and Magic Word usage on the main page):
 * User:Wildgoosespeeder/MarioWiki:Proposals/Archive

The proposal is about reducing server load and processing on the user's end without sacrificing current functionality. The mock-up isn't absolute. The proposal is about creating subpages only; division by year and a special search page. The mock-up is an example of the presentation. It can be tweaked later to meet the needs of. Pages that can be tweaked:


 * 
 * /Header (trancluded on the mock-up subpages)

Proposer: Deadline: May 27, 2017, 23:59:59 GMT

Support

 * 1) Per Proposal
 * 2) Sounds like a good plan. Per Proposal.
 * 3) This definitely sounds like a good idea; anything that reduces the loading strains on slow computers. Per all.

Oppose

 * 1) Per my comments below.
 * 2) Per the comments in opposition. It's unnecessarily complicated.
 * 3) Per all.
 * 4) The system we have now is simpler, and the benefits of splitting aren't enough to warrant this, at least not at the size the page currently is.
 * 5) Per Lakituthequick's comments below. I do not see the point of having what is shown on the User:Wildgoosespeeder/MarioWiki:Proposals/Archive page if we would have a search page that is very similar to what we have now.
 * 6) This sounds like a great idea, but I think it is overcomplicated. In the time it takes to load the page, think about where to go, and load the correct archive, the page we currently have would load. I also don't see any reason for splitting them by year because when you look for a proposal you usually don't know what year it was. It is also very easy to load the big page and hit Ctrl+F without clicking on other pages. This would also disturb the edit history

Comments
So link to an archive separated by year, which in turn will link to an archive with the proposals itself? Seems like unnecessary archive linking. Or are you proposing the proposals be placed on the yearly archive as well, with the proposal boxes acting as a sort of Table of Contents? 14:18, 13 May 2017 (EDT)


 * I made a mock-up to show you how I am envisioning the change. Each subsection's contents will be moved to the appropriate page (see 2017 mockup). -- 14:36, 13 May 2017 (EDT)

I don't think the inverse situation is much better, with a bunch of lists being inconveniently divided between pages. None of them are even the same size; giving 2016 a page all to itself seems wasteful. 14:28, 13 May 2017 (EDT)

I personally find it very convenient to have every proposal title in one page, it makes searching for proposals easier. -- 14:31, 13 May 2017 (EDT)
 * Hmm, didn't think of that. I think we have a problem here. I guess we can't have the best of both worlds. -- 14:36, 13 May 2017 (EDT)
 * Wait a minute. I have an idea to solve this issue. Create a special search page and transclude the subpages I am suggesting. and should help this along. -- 14:43, 13 May 2017 (EDT)
 * User:Wildgoosespeeder/MarioWiki:Proposals/Archive/search should fix this issue that and  expressed. -- 14:51, 13 May 2017 (EDT)
 * Um... isn't that just the same thing as how the archive is currently? 15:15, 13 May 2017 (EDT)
 * Not exactly. The idea is to be less intensive processing the pages for the archival process, being lighter on bandwidth, especially for mobile users. Since people were concerned about easily searching, I created a special search page which will transclude the subpages I am proposing the archive be split into. To put it simply, it's more efficient by putting in the extra pages without sacrificing the ease of searching for past proposals. -- 15:23, 13 May 2017 (EDT)
 * Yes and no (for the search). It is the exact same thing, however, it doesn't take as long as it is transluded from the Yearly Archives. 15:21, 13 May 2017 (EDT)
 * So then is there a point in having the proposed page listing each year and then a separate search page? Couldn't the search page be the main Proposals/Archive and then have users edit the transcluded pages instead of the main archive? -- 19:30, 13 May 2017 (EDT)
 * The idea is to only download the entire archive of proposals when necessary rather than every time the link is clicked from Proposals. Most of the time, we just want to archive proposals. Sometimes we need to refer back to an older proposal, but it isn't as often as archiving. -- 19:54, 13 May 2017 (EDT)

Wouldn't it be better to divide it into several years, i.e. a page with 3 years of proposals? 18:21, 13 May 2017 (EDT)
 * That just makes it more complicated. Keep it simple. There is just something more satisfying by dividing it yearly compared to triennial. Also it would break the pattern of each header containing each year's proposals. Yearly pages would be around 10,240 bytes (10 kilobytes) based on my mock-up subpages. Your idea would triple it to around 30,720 bytes (30 kilobytes). The PHP to HTML conversion, over half a megabyte currently for (for me, 574.5KB). My page is roughly less than a 30KB and subpages are around 100KB. With the excluded text due to it being surrounded by (Proposals/Archive/Header), subtract 25KB for just the. That means 75KB an archive page. Subtract 10KB more because of non-content parts of a page when the transclusion takes place (sidebar, top toolbar, and bottom toolbar). -- 19:14, 13 May 2017 (EDT)

Isn't creating multiple pages to serve one single purpose (including one that is identical to what we have now) just over-complicating things? Having to wait a bit for an archive to load isn't really a problem, and editing a section doesn't require loading a full page on preview anyway. Also, to go over the whole bandwidth point, while it is correct that the page is about 572 KB, that isn't actually what is send over the wire. The page is compressed before being send, and because it is fairly repetitive, it compresses to a little under 64 KB (mobile: 561 KB and 62 KB respectively). It would be better to improve instead of trying to solve the problem elsewhere. 14:09, 14 May 2017 (UTC)
 * I fail to see how it would be over-complicating things. It's one additional step for either archiving or finding a past proposal, after the initial setup is complete. Also, when you edit a section, the whole page needs to be regenerated, wasting another half-megabyte. If you edit the subpage, the impact is greatly reduced. -- 15:17, 15 May 2017 (EDT)
 * I'd like this idea if we had the proposal boxes at the top of the page, with the actual proposals from that year on the same page. But as it stands, splitting and moving the numbered archives would disturb the original page history.


 * 20:14, 14 May 2017 (EDT)
 * I'm not sure how my idea disturbs anything. The subpages will still link to the numbered archives. No red links are accidentally generated if this were transitioned to proposal specs. Do you mean the years appearing in the same location as the numbered archive pages? The mock-up I created isn't absolute. It's just an idea that can be tweaked later. The proposed idea is to create subpages mainly. If you want years along with numbered archives in the same place, just edit Proposals/Archive/Header and it will appear like that on every page that transcludes that page. The subpages will transclude the header, as you can see in the mock-up. -- 15:17, 15 May 2017 (EDT)

Orange vs Brown
Don't "no quorum" and "tie" essentially mean the same thing? If the proposal ties, it's a no quorum and nothing happens, correct? 16:38, 15 October 2017 (EDT)
 * "No quorum" refers to there being a lack of voters. 16:40, 15 October 2017 (EDT)
 * So, then, proposals like this makes no sense to me. There are voters, but it isn't a tie. 16:43, 15 October 2017 (EDT)
 * That one was my mistake, when I thought that "no quorum" and "failed to reach consensus" essentially meant the same thing. 16:44, 15 October 2017 (EDT)
 * Okay, but still, "tie" wouldn't work here, either. 16:46, 15 October 2017 (EDT)
 * Pardon, but why are you bringing up that proposal? It was archived with orange (which is wrong, but still not brown). 16:49, 15 October 2017 (EDT)
 * I just chose an example. I'm really just trying to figure out the proper color to use for the Power Suit proposal you and Toadette are having trouble deciding on. Perhaps a different color created is in order, or maybe a reexplaination. 16:52, 15 October 2017 (EDT)
 * Red. The proposal didn't pass. 16:53, 15 October 2017 (EDT)
 * Red'll work. 16:57, 15 October 2017 (EDT)

Proposals that failed to reach a consensus
Why don't we have a unique color for proposals that ended before a consensus could be reached (not to be confused with ties, which are no longer applicable)? Currently, we lump them in with the reds, which makes them impossible to tell apart from proposals that failed by consensus without clicking on them. This seems like an unnecessary inconvenience. 22:44, 5 January 2019 (EST)
 * Wouldn't that be one of these?

16:59, April 20, 2020 (EDT)

Shouldn’t we merge white, brown and orange together?
All three mean the same effect of “the proposal didn’t pass or fail, and no one canceled it”

How does a proposal count as “no quorum” anyways?