MarioWiki:Proposals

From the Super Mario Wiki, the Mario encyclopedia
Revision as of 21:43, January 9, 2016 by NSY (talk | contribs) (Fixing error, honestly coming from the last person who would make those kinds of errors)
Jump to navigationJump to search
Image used as a banner for the Proposals page
Current time:
Friday, May 17th, 19:47 GMT
Proposals can be new features (such as an extension), the removal of previously-added features that have tired out, or new policies that must be approved via consensus before any action is taken.
  • "Vote" periods last for one week.
  • Any user can support or oppose, but must have a strong reason for doing so (not, e.g., "I like this idea!").
  • All proposals must be approved by a majority of voters, including proposals with more than two options.
  • For past proposals, see the proposal archive and the talk page proposal archive.

A proposal section works like a discussion page: comments are brought up and replied to using indents (colons, such as : or ::::) and all edits are signed using the code {{User|User name}}.

How to

Rules

  1. If users have an idea about improving the wiki or managing its community, but feel that they need community approval before acting upon that idea, they may make a proposal about it. They must have a strong argument supporting their idea and be willing to discuss it in detail with the other users, who will then vote about whether or not they think the idea should be used. Proposals should include links to all relevant pages and writing guidelines. Proposals must include a link to the draft page. Any pages that would be largely affected by the proposal should be marked with {{proposal notice}}.
  2. Only registered, autoconfirmed users can create, comment in, or vote on proposals and talk page proposals. Users may vote for more than one option, but they may not vote for every option available.
  3. Proposals end at the end of the day (23:59) one week after voting starts, except for writing guidelines and talk page proposals, which run for two weeks (all times GMT).
    • For example, if a proposal is added at any time on Monday, August 1, 2011, the voting starts immediately and the deadline is one week later on Monday, August 8, at 23:59 GMT.
  4. Every vote should have a strong, sensible reason accompanying it. Agreeing with a previously mentioned reason given by another user is accepted (including "per" votes), but tangential comments, heavy sarcasm, and other misleading or irrelevant quips are just as invalid as providing no reason at all.
  5. Users who feel that certain votes were cast in bad faith or which truly have no merit can address the votes in the comments section. Users can ask a voter to clarify their position, point out mistakes or flaws in their arguments, or call for the outright removal of the vote if it lacks sufficient reasoning. Users may not remove or alter the content of anyone else's votes. Voters can remove or rewrite their own vote at any time, but the final decision to remove another user's vote lies solely with the administrators.
    • Users can also use the comments section to bring up any concerns or mistakes in regards to the proposal itself. In such cases, it's important the proposer addresses any concerns raised as soon as possible. Even if the supporting side might be winning by a wide margin, that should be no reason for such questions to be left unanswered. They may point out any missing details that might have been overlooked by the proposer, so it's a good idea as the proposer to check them frequently to achieve the most accurate outcome possible.
  6. If a user makes a vote and is subsequently blocked for any amount of time, their vote is removed. However, if the block ends before the proposal ends, then the user in question holds the right to re-cast their vote. If a proposer is blocked, their vote is removed and "(banned)" is added next to their name in the "Proposer:" line of the proposal, which runs until its deadline as normal. If the proposal passes, it falls to the supporters of the idea to enact any changes in a timely manner.
  7. No proposal can overturn the decision of a previous proposal that is less than 4 weeks (28 days) old.
  8. Any proposal where none of the options have at least four votes will be extended for another week. If after three extensions, no options have at least four votes, the proposal will be listed as "NO QUORUM." The original proposer then has the option to relist said proposal to generate more discussion.
  9. All proposals that end up in a tie will be extended for another week. Proposals with more than two options must also be extended another week if any single option does not have a majority support: i.e. more than half of the total number of voters must appear in a single voting option, rather than one option simply having more votes than the other options.
  10. If a proposal with only two voting options has more than ten votes, it can only pass or fail with a margin of at least three votes, otherwise the deadline will be extended for another week as if no majority was reached at all.
  11. Proposals can only be extended up to three times. If a consensus has not been reached by the fourth deadline, the proposal fails and can only be re-proposed after four weeks, at the earliest.
  12. All proposals are archived. The original proposer must take action accordingly if the outcome of the proposal dictates it. If it requires the help of an administrator, the proposer can ask for that help.
  13. If the administrators deem a proposal unnecessary or potentially detrimental to the upkeep of the Super Mario Wiki, they have the right to remove it at any time.
  14. Proposals can only be rewritten or deleted by their proposer within the first three days of their creation (six days for talk page proposals). However, proposers can request that their proposal be deleted by an administrator at any time, provided they have a valid reason for it. Please note that canceled proposals must also be archived.
  15. Unless there is major disagreement about whether certain content should be included, there should not be proposals about creating, expanding, rewriting or otherwise fixing up pages. To organize efforts about improving articles on neglected or completely missing subjects, try setting up a collaboration thread on the forums.
  16. Proposals cannot be made about promotions and demotions. Users can only be promoted and demoted by the will of the administration.
  17. No joke proposals. Proposals are serious wiki matters and should be handled professionally. Joke proposals will be deleted on sight.
  18. Proposals must have a status quo option (e.g. Oppose, Do nothing) unless the status quo itself violates policy.

Basic proposal and support/oppose format

This is an example of what your proposal must look like, if you want it to be acknowledged. If you are inexperienced or unsure how to set up this format, simply copy the following and paste it into the fitting section. Then replace the [subject] - variables with information to customize your proposal, so it says what you wish. If you insert the information, be sure to replace the whole variable including the squared brackets, so "[insert info here]" becomes "This is the inserted information", not "[This is the inserted information]". Proposals presenting multiple alternative courses of action can have more than two voting options, but what each voting section is supporting must be clearly defined. Such options should also be kept to a minimum, and if something comes up in the comments, the proposal can be amended as necessary.

===[insert a title for your proposal here]===
[describe what issue this proposal is about and what changes you think should be made to improve how the wiki handles that issue]

'''Proposer''': {{User|[enter your username here]}}<br>
'''Deadline''': [insert a deadline here, 7 days after the proposal was created (14 for writing guidelines and talk page proposals), at 23:59 GMT, in the format: "May 17, 2024, 23:59 GMT"]

====Support====
#{{User|[enter your username here]}} [make a statement indicating that you support your proposal]

====Oppose====

====Comments====

Users will now be able to vote on your proposal, until the set deadline is reached. Remember, you are a user as well, so you can vote on your own proposal just like the others.

To support, or oppose, just insert "#{{User|[add your username here]}}" at the bottom of the section of your choice. Just don't forget to add a valid reason for your vote behind that tag if you are voting on another user's proposal. If you are voting on your own proposal, you can just say "Per my proposal".

Talk page proposals

All proposals dealing with a single article or a specific group of articles are held on the talk page of one of the articles in question. Proposals dealing with massive amounts of splits, merges or deletions across the wiki should still be held on this page.

For a list of all settled talk page proposals, see MarioWiki:Proposals/TPP archive and Category:Settled talk page proposals.

Rules

  1. All active talk page proposals must be listed below in chronological order (new proposals go at the bottom) using {{TPPDiscuss}}. Include a brief description of the proposal while also mentioning any pages affected by it, a link to the talk page housing the discussion, and the deadline. If the proposal involves a page that is not yet made, use {{fake link}} to communicate its title in the description. Linking to pages not directly involved in the talk page proposal is not recommended, as it clutters the list with unnecessary links. Place {{TPP}} under the section's header, and once the proposal is over, replace the template with {{SettledTPP}}.
  2. All rules for talk page proposals are the same as mainspace proposals (see the "How to" section above), with the exceptions made by Rules 3 and 4 as follows:
  3. Voting in talk page proposals will be open for two weeks, not one (all times GMT).
    • For example, if a proposal is added at any time on Monday, August 1, 2011, it ends two weeks later on Monday, August 15, 2011, at 23:59 GMT.
  4. The talk page proposal must pertain to the article it is posted on.
  5. When a talk page proposal passes, it should be removed from this list and included in the list under the "Unimplemented proposals" section until the proposed changes have been enacted.

List of ongoing talk page proposals

  • Split "Team Dinosaur" from The Dinosaurs (discuss) Deadline: May 15, 2024, 23:59 GMT
  • In Template:Species infobox, expand "Relatives" guidelines to include variant-type relationships with significant differences between species (discuss) Deadline: May 12, 2024, 23:59 GMT May 19, 2024, 23:59 GMT
  • Rename Moneybags to Moneybag (enemy) (discuss) Deadline: May 13, 2024, 23:59 GMT May 20, 2024, 23:59 GMT
  • Delete Memory Card (discuss) Deadline: May 23, 2024, 23:59 GMT
  • Add a Composers Subsection to Template:Themes (discuss) Deadline: May 28, 2024, 23:59 GMT
  • Include Rainbow Coaster & Rainbow Downhill back in the Rainbow Road article (discuss) Deadline: May 28, 2024, 23:59 GMT
  • Split the contents of the blimp page (discuss) Deadline: May 28, 2024, 23:59 GMT
  • Create a Rewrite-remove template (discuss) Deadline: May 30, 2024, 23:59 GMT

Unimplemented proposals

Proposals

Merge the Wrecking Crew and VS. Wrecking Crew phases into list articles, Axis (ended February 24, 2022)
Do not consider usage of classic recurring themes as references to the game of origin, Swallow (ended March 9, 2022)
Split Mario Kart Tour character variants into list articles, Tails777 (ended May 4, 2022)
Enforce WCAG Level AA standards to mainspace and template content, PanchamBro (ended May 29, 2022)
Change how RPG enemy infoboxes classify role, Doc von Schmeltwick (ended September 18, 2022)
Trim away detailed special move information for all non-Mario fighters, Koopa con Carne (ended January 30, 2023)
Classify the Just Dance series as a guest appearance, Spectrogram (ended April 27, 2023)
Establish a standard for long course listings in articles for characters/enemies/items/etc., Koopa con Carne (ended June 8, 2023)
Consider filenames as sources and create redirects, Axis (ended August 24, 2023)
Add tabbers to race/battle course articles, GuntherBB (ended November 18, 2023)
Remove elemental creatures categories from various Super Mario RPG enemies, Swallow (ended January 11, 2024)
Standardize the formatting of foreign and explanatory words and phrases in "Names in other languages" tables, Annalisa10 (ended February 7, 2024)
Merge Super Mario Bros. (film) subjects with their game counterparts, JanMisali (ended April 18, 2024)
Remove profiles and certain other content related to the Super Mario Bros. Encyclopedia from the wiki, Koopa con Carne (ended April 30, 2024)

Talk page proposals

Split all the clothing, Doc von Schmeltwick (ended September 12, 2021)
Split the various reissues of Mario Bros., Doc von Schmeltwick (ended April 22, 2022)
Split machine parts, Robo-Rabbit, and flag from Super Duel Mode, Doc von Schmeltwick (ended September 30, 2022)
Expand source priority exception to include regional English differences, LinkTheLefty (ended January 14, 2023)
Add product IDs in game infoboxes, Windy (ended March 18, 2023)
Remove the list of Super Smash Bros. series objects, Axis (ended May 10, 2023)
Split Special Shot into separate articles by game, Technetium (ended September 30, 2023)
Convert the lists of episode appearances for television series characters into categories, Camwoodstock (ended November 22, 2023)
Change the Super Mario 64 DS level section to include more specific character requirements, Altendo (ended December 20, 2023)
Split the Jungle Buddies from Animal Friends, DrippingYellow (ended December 22, 2023)
Make bestiary list pages for the Minion Quest and Bowser Jr.'s Journey modes, Doc von Schmeltwick (ended January 11, 2024)
Merge the ghost Bats and Mice from Luigi's Mansion to their respective organic counterparts from the later games, Doc von Schmeltwick (ended January 20, 2024)
Split Strobomb from Robomb, Doc von Schmeltwick (ended January 20, 2024)
Split the NES and SNES releases of Wario's Woods, SONIC123CDMANIA+&K(B&ATSA) (ended March 27, 2024)
Merge Mii Brawler, Mii Swordfighter, and Mii Gunner to Mii, TheUndescribableGhost (ended March 28, 2024)
Split Mario's Time Machine (Nintendo Entertainment System), or the Super Nintendo Entertainment version along with both console versions of Mario is Missing!, LinkTheLefty (ended April 11, 2024)
Remove non-Super Mario content from Super Smash Bros. series challenges articles, BMfan08 (ended May 3, 2024)
Merge Stompybot 3000 with Colonel Pluck, DrippingYellow (ended May 4, 2024)

List of Talk Page Proposals

Writing Guidelines

None at the moment.

New features

Redesign RPG infoboxes and bestiaries

Having multiple infoboxes side-by-side in stats sections looks terrible, so after months of forum discussion and design drafting in my userspace, I am proposing complete redesigns of all the RPG infoboxes, primarily to allow for them to be able to toggle between vertical and horizontal forms. Vertical forms can be used like normal, at the tops of enemy pages as their main infoboxes: clutter is bad), but now for stats sections, the horizontal forms can be stacked on top of each other instead of haphazardly floating side-by-side and at the whims of varying screen widths. This is the main purpose for this proposal (hence it's in "new features"), but at the same time, various other changes will happen:

  1. All RPG infoboxes will toggle between vertical and horizontal forms - See above. Note that the vertical forms are the defaults so this won't cause mass appearance chaos as soon as the templates are changed.
  2. All RPG infoboxes will use the same colour-scheme as navigation templates (as seen here) - This will create consistency and ensures neatness and easy readability.
  3. All RPG infobox pages will have usage instructions and an input chart - This will make them easier to use.
  4. All RPG infoboxes will use consistent inputs whenever possible - This will also make them easier to use (less memorization and guessing), although it also means some inputs are being renamed and/or combined and will need to be updated on the articles (noted in red on the draft pages below).
  5. Some RPG infoboxes will be expanded with additional info - The infoboxes should have all the stats that we know of present, rather than forcing folks to look up supplemental charts in the bestiaries or elsewhere.
  6. {{pm2enemybox}} will need to be (re)created - Right now, Paper Mario and TTYD use the same infobox, but once all the new stats and featured are added, that won't be possible anymore, plus it's inconsistent and unnecessary to have two games in one.
  7. RPG infoboxes embedded in History sections should be moved to stats sections - If it's not the enemy's overall infobox, it should be in a stats section: it's just inconsistent clutter anywhere else.

It sounds like a lot, but the redesigned templates have all been drafted and are completely ready to go. All that needs to be done is updating the articles themselves by adding inputs to bring the templates up-to-date, and reorganizing the stats sections (including moving some infoboxes down there from History sections). Examples of the templates in action can be found here, and the drafts are as follows:

As seen in the proposal's title, bestiaries are also on the slab here, and the reason why is because, rather than having multiple and/or too-wide-for-1024px-screen tables that force readers to scroll up and down and back and forth, from now on, bestiaries should take the form of multiple stacked horizontal infoboxes. Basically, anyway - as seen on Megadardery's test pages here and here, a slightly different template will be used to change the headers from the game titles to just the enemy names, and the bestiaries will still need to include the templates in an overall table for slightly more compact stacking and uniform column widths. However, the important part is that the bestiaries' inputs will all be the same as the corresponding infoboxes', making it a simple matter of cutting and pasting to move and update information between the bestiaries and the enemy pages, or at least make it easier to use both (even the how-to information is mostly the same). A final note is that the bestiaries will now use colour-coding in the names to denote enemy types (bosses vs. enemies vs. support), as explained in the nice legend at the top of the first test page I liked to in this paragraph.

Unlike the infoboxes, only the Paper Mario bestiary is drafted and ready, but I think it's still better to get the ball rolling on this overall stats project sooner than later and start working on getting those horizontal infoboxes out there: more bestiaries can follow in time.

Proposer: Walkazo (talk) (with input from Bazooka Mario (talk) and others; bestiary work by Megadardery (talk))
Deadline: January 11, 2016, 23:59 GMT

Support

  1. Walkazo (talk) - Per proposal.
  2. LudwigVon (talk) Per proposal.
  3. Baby Luigi (talk) Though I haven't commented, I've been in support of an RPG infobox template overhaul since the day it was suggested. It, at the current moment, is extrmeley unsightly, ugly, and most importantly, horribly formatted to not fit in with the stats and the like. Therefore, I'm in major support with this proposal and I want it to pass ASAP.
  4. RandomYoshi (talk) – Per proposal.
  5. Bazooka Mario (talk) The way the vertical layout of RPG infobox templates are used is utterly miserable. Here are some examples: Dry Bones, Fawful, Lava Piranha, Blooper, Spiny, Buzzy Beetle, Elite Trio, the list goes on, but it's no small sample. They leave behind lots of white space, are extremely cluttery and overall messy, and they're not very reader-friendly. Worse, practically any recurring enemy article from a MaRPG game is doomed to have several of these templates, which are not designed with recurring enemies in mind. I also support moving infoboxes that otherwise clutter the article like in Boo or Hammer Bro. to stats section and get converted to the horizontal design. I'm glad we're going to redesign some of the wiki's biggest eyesores.
  6. Wildgoosespeeder (talk) Very sharp looking compared to the dated templates we are using now.
  7. 3D Player 2010 (talk) per all
  8. Tucayo (talk) - Per Walkazo.
  9. PowerKamek (talk) Per Walkazo
  10. Niiue (talk) Per all.
  11. Tsunami (talk) Per Bazooka Mario and proposal.
  12. Megadardery (talk) Definitely per proposal
  13. MrConcreteDonkey (talk) – Per all, this looks a lot better than what we currently have.

Oppose

Comments

While I'm supportive of the redesign, I have a few suggestions to go with it.

  1. Infoboxes should probably ignore the direction parameter in the mobile version, as it looks pretty bad when vertical there. (I'm not entirely sure yet how that'd work though.)
  2. You should put the CSS that goes into these infoboxes into Common.css to avoid all that clutter.

Lakituthequick.png Lakituthequick 15:48, 5 January 2016 (EST)

The mobile stuff's beyond my abilities, I'm afraid, and I generally prefer not to add stuff to the css if I can help it. Most of the clutter you're highlighting is unavoidable anyway, as things like the widths, colours and underlining aren't uniform for cells, rows and columns, and will always have to be specified in the templates. Other things like the float and margin coding are affected by the switch function, so again, they have to be in the templates afaik. All the ugly-looking border-radius stuff is just because of the use of {{radius}}, so in the actual editing windows, there's not nearly that much clutter up top, and it's not like this small handful of templates will need to be edited often either way (hopefully). - Walkazo (talk) 12:19, 6 January 2016 (EST)
  • I generally prefer not to add stuff to the css if I can help it. – These templates are included in 1046 pages in total as of now. All those pages include the same coding over and over again, which is exactly what CSS files were invented for; styling similar elements with the same code multiple times. Not to mention the loading times and stress on the server by keeping everything self-contained.
  • Most of the clutter you're highlighting is unavoidable anyway, as things like the widths, colours and underlining aren't uniform for cells, rows and columns, and will always have to be specified in the templates. – It is not unavoidable at all, quite the opposite. I have made this page with an example of {{MLinfobox}}. You can see here that the tables and a few special cells where just assigned a few CSS classes, and the rest all gets filled in by the complimenting CSS.
  • Other things like the float and margin coding are affected by the switch function, so again, they have to be in the templates afaik. – These things also can be generalized in the CSS, see the first five selectors in the CSS on the example page, and the align parameter in the Wikicode. (btw, your margin code doesn't work, it needs a default or it will be left empty.)
  • All the ugly-looking border-radius stuff is just because of the use of {{radius}} – Yeah about that, only border-radius: xx is needed, the rest really is unnecessary clutter. But that is a thing that can be accounted for on a different occasion.
Lakituthequick.png Lakituthequick 14:29, 7 January 2016 (EST)

There's not a infobox for Mario & Luigi: Paper Jam enemies or there will be one, but it is not done yet?--LudwigVon Sig.png(TALK) 15:22, 7 January 2016 (EST)

Okay, I switched everything to "border-radius:5px" to get rid of that clutter, and having "horizontal" in the align function rather than its own thing is a good idea too, so I'll convert the templates to that (skips a bit of redundancy and fixes a really trivial irritation I had with the lack of margin in the template pages). But I'm still against outsourcing the designs to the css. Navigation templates are much more widespread, yet we don't bother doing anything more than the series-specific background colours and basic franchise-wide things like the borders, text and link colours. It's just easier to deal with template design when the design's in the template, not off in the css, which the vast majority of users would have no idea how to deal with - including admins. Plus, we're the only ones who can edit the css anyway, adding another level of complication to what should be an accessible operation: wikis are supposed to be user-friendly, but needing to get help to change a column width is not user-friendly. @LudwigVon: There wasn't a M&L:PJ template while I was working on the designs, and not knowing anything about the stats that might be applicable to the game, I didn't want to hazard a guess at a template design - then someone did make a template at the last-minute, which I didn't find out about until after I made the proposal, but its a bit dodgy and currently only in use on one page, so I was going to hold off on making a new draft for it until I've had time to check out the game mechanics myself, or see other users vetting it. - Walkazo (talk) 16:04, 7 January 2016 (EST)
I can see where you are coming from, but I don't agree about keeping everything in the templates themselves. Making it less open may be true to an extend, but infoboxes (and navtemplates too) are things that are supposed to look uniform on the wiki in whole, and I don't suppose there is a lot of reason to change the width of a column any time soon. I think it would protect the design rather than 'closing' the openness.
If not moving to the common css, I would at least suggest updating obsolete code. On your Essay page with all those templates, the W3C's Validator return 329 errors. I was going to bring this up at some point anyway as it is a wikiwide problem, but now is as good a time as any.
Lakituthequick.png Lakituthequick 17:47, 7 January 2016 (EST)
Every time an input needs to be added, it'll potentially force things to be shuffled around, and it'll be easier to design new templates with old ones readily available in full. The only thing I'd concede to for the css is a proper, overall infobox class or two to cover the basics (cellpadding, cellspacing, maybe border and font stuff), the way there's an overall nav template class, but that's a whole other kettle of fish since there are a lot of infoboxes that will have to be dealt with: it's beyond the scope of what this proposal is about. Anyway, I fixed all the non-padding/spacing obsolete coding in my drafts here (and there weren't 329 errors from the templates alone - the essays page had a lot more content on it). You're not the first to voice concerns about the wiki as a whole having a lot of depreciated coding, but no one's ever really cared enough to try to do anything about something that basically seems like an invisible non-issue that's beyond the knowledge of the majority of users. You could try to set up a wiki collab about it if you really wanted to. - Walkazo (talk) 23:15, 7 January 2016 (EST)
If there where at least some base classes that would be a big improvement already (seeing the table opening tag is the worst offender everywhere), but you are right that this is outside the scope of this proposal.
I have been planning on making some form of collab sometime already as 'non-issue' is not really the case but that also is outside this proposal's scope so that's a discussion for then. Lakituthequick.png Lakituthequick 11:05, 8 January 2016 (EST)
Yeah, I was surprised when I checked common.css and found that there actually wasn't an "infobox" class, even though all the infoboxes start out that way: fixing that's definitely on my to-do list now (maybe after the rollout of this proposal's done). - Walkazo (talk) 11:28, 8 January 2016 (EST)

A quick note, regarding the {{spmenemybox}}, the score and card how (under the name: card location) have been added to all the templates, the tattle was changed to card description and the tippi was changed to tattle for better clarity. The draft should be updated accordingly.--

User:MegadarderyUser talk:MegadarderyDashbot signature

05:59, 9 January 2016 (EST)

Alright, updated, thanks. Changing the "tippi"/"tattle" thing was definitely a good idea, although tbh I would've recommended shorthand rather than long "card location" and "card description" inputs, but ah well, too late now. - Walkazo (talk)
pssst, you forgot to change the second card how...--
User:MegadarderyUser talk:MegadarderyDashbot signature
 16:19, 9 January 2016 (EST)

Removals

None at the moment.

Changes

Prohibit the Usage of {{conjecturaltext}} in Headers

Using {{conjecturaltext}} in headers has a couple of issues. For one, it looks ugly and inconsistent with how other headers look like. The only acceptable text formatting in headers should be italicising as to indicate that it's a piece of fiction being talked about. Underlining text in headers is very bad. Furthermore, it breaks the Recent Changes. Using the Recent Changes, a user may jump directly to a section of an article if only a section was edited. However, should the header contain {{conjecturaltext}}, this feature is broken. Having a feature that breaks a vital function of the Wiki should never be allowed. Sure, you could just hop to the section manually, but why would you do that when the Wiki can provide you a function that does that for you automatically?

I do realise and acknowledge that there is an issue with this: how do we notify the reader that these names are conjectural? The solution is simple. 

===Thing that is conjecturally named===
'''{{conjecturaltext|Thing that is conjecturally named}}''' is a thing blah blah blah blah

That way, we get the information that it's conjecturally named across, it doesn't break the Recent Changes, and it makes headers look consistent. This means that all information is preserved, and we don't have to implement a feature that breaks a very vital function of the Wiki. Alternatively and depending on the kind of section being worked with, the text doesn't need to be in a bold typeface. This also gives us the possibility to quickly summarise what the section is about in one sentence before describing the rest of the subject in greater detail. Furthermore, this methodology ensures no unnecessary and ugly notification templates need to be used at all. Additionally, removing {{conjecturaltext}} does not break section linking at all, so all links that already exist and link to headers that already contain {{conjecturaltext}} will not be broken and still work.

But how do we go about finding these? The answer here is also simple. This is how.

EDIT: The old link for finding the instances of the template did not work, so this will be used instead.

Proposer: RandomYoshi (talk)
Deadline: January 11, 2016, 23:59 GMT

Support

  1. RandomYoshi (talk) – Per proposal.
  2. Walkazo (talk) - Per RandomYoshi.
  3. Niiue (talk) Per RandomYoshi.
  4. MrConcreteDonkey (talk) – Per RandomYoshi.
  5. Tucayo (talk) - Per Pi.
  6. Megadardery (talk) - Per π
  7. Super Mario Bros. (talk) — Per RandomYoshi.
  8. Baby Luigi (talk) I hate the use of the conjectural text template in headers, it's time to end that practice once and for all.
  9. LudwigVon (talk) Per all.
  10. Bazooka Mario (talk) Sure thing.
  11. BabyLuigi64 (talk) Per all.
  12. 3D Player 2010 (talk) per all
  13. Roy Koopa (talk) Per all.

Oppose

  1. Wildgoosespeeder (talk) To me, this could just be a MediaWiki bug. Before making changes to pages to adapt around the bug, have Porplemontage (talk) update the software that MarioWiki uses and report the bug to the developers of MediaWiki if the bug persists.

Comments

Unfortunately MediaWiki search is broken, so the link you provided will not help us find the pages. But as far as I've seen, the only pages with conjectural section titles are the Galaxies and list of Glitches, which should be easy enough to track down. Otherwise, how is the suggested workaround going to work in the list of glitches pages? It doesn't seem efficient to specify the glitch name in every section. I think we need a better idea to over all say "Yo guys, these are all made up names so don't quote us on them will ya?".--

User:MegadarderyUser talk:MegadarderyDashbot signature

12:03, 4 January 2016 (EST)

How about making a similar template to Template:Conjecture, but that states something like "The titles of the following sections of this article are conjectural; [and the rest is equal to the base template]"? It could have a "section=" variable that, if set to yes, states "The title of the following subsections of this section [equal to normal]". The first is used in glitch pages, the second in Galaxies pages. YoshiCGicon.pngTSUNAMIArtwork of Plessie with the four playable characters, from Super Mario 3D World.
Having additional notice templates is only going to help in increasing how messy pages look like. It's not going to be the end of the world if we repeat it for every subject we talk about. In fact, it's better to first aptly summarise a subject in one concise sentence before prattling on about the minor details of a subject: that way, readers who only wish to gain an elementary understanding of a topic can choose only to read the first sentence of a paragraph, whilst others that feel like they want a more in-depth analysis can do so by continuing to read about the subject. Because {{conjecturaltext}} is used in the beginning of the sentence and has the subject bolded (or not), the information that they're conjecturally named is still going to be conveyed in the same way it's done at this point, except it won't break the Recent Changes and generate unprofessional-looking headers. To summarise, it won't hurt us, it won't hurt the reader, it won't hurt the page by introducing a whole batch of notice templates, and it certainly won't hurt the Recent Changes. PidgeyIcon.pngRandomYoshi(Talk • PMs • C) 13:47, 4 January 2016 (EST)
No, it would be repetitive to state the nonofficial name of the glitch underneath every glitch section with that exact same title, it seems okay in the introduction of main articles, because you really are introducing the main element of the page, however in glitches' pages, it becomes overly annoying to read the same thing over and over again. It's like going over every section in the Mario article starting it with "[..] is a game that Mario stars in." which would be insane. Don't get me wrong, I support this proposal, because this issue is super annoying when it comes to actual editing and linking. However, the consequences of doing it this way is not something I support. I don't support the idea of the notice template either, it would be an eye catcher. However, adding it to the introduction of the list in one short sentence is not something I'm keen on, but not something I'm against either.--
User:MegadarderyUser talk:MegadarderyDashbot signature
 15:10, 4 January 2016 (EST)
I agree with RandomYoshi at this point. However, I have another idea: if templates are not good, let's just add a sentence just before the various section start. It should say "NOTE: All the glitches'/galaxies' names in this page are conjectural. Fitting names have been given by the editors.". This may seem repetitive, but remember that phone users have no way to read the message shown by hovering the cursor over conjectural text. YoshiCGicon.pngTSUNAMIArtwork of Plessie with the four playable characters, from Super Mario 3D World.

So, I used the link above to track down all the pages that have conjecturaltext templates in at least an header, and oooh boy, there's a very long list awaiting... YoshiCGicon.pngTSUNAMIArtwork of Plessie with the four playable characters, from Super Mario 3D World.

I figured out how we're going to deal with the Super Mario Galaxy and the Super Mario Galaxy 2 Galaxy levels with their planets and such. In each section about a planetoid, a picture of this planetoid should be accompanied. In this picture is usually found a small description of the planetoid. In this thumbnail should the name of the planetoid always be found. This is the instance that can have {{conjecturaltext}} on it. How does this sound? PidgeyIcon.pngRandomYoshi(Talk • PMs • C) 15:59, 5 January 2016 (EST)

It's a good idea. I don't know, however, if everyone reading the Galaxies' pages would stop to read thumbnails. Should we make the planet's name bold in the thumbnail, so it's more apparent? YoshiCGicon.pngTSUNAMIArtwork of Plessie with the four playable characters, from Super Mario 3D World.

So, we're about to settle about how to apply conjecturaltext changes on the various types of pages, but there's still an archetype: 50 pages about Wario Land II pages. Here, the problem is in the Hidden Treasure section: a conjectural name, stating what's the treasure, is in the header. However, the paragraph doesn't ever repeat this name, and we can't do the same thing RandomYoshi proposed for Galaxies because the images are far too small. The only idea I have is removing that name altogheter: I don't think it's even needed. Do you have any other ideas? YoshiCGicon.pngTSUNAMIArtwork of Plessie with the four playable characters, from Super Mario 3D World.

Been mulling it over, and I think just having a "Note: all these names are conjectural." message (in bold, even) at the tops of the "Planets/Areas" sections (on the galaxy and mission pages) would be the most efficient way to deal with the situation, avoiding the use of the specific template at all (or the need to hide the names in the thumbnail descriptions - which would be inconsistent with the rest of the wiki). As for the WLII items, I agree that it'd be simpler to remove them from the headers, and instead just describe them in the body text without having to pass them off as names. For example, Turn off the alarm clock!'s header would be "Hidden Treasure: Viking Helmet" and then the text will simply read "...The treasure of this level is a horned viking helmet that bears some resemblance to the Bull Pot..." (underline showing new content). - Walkazo (talk) 12:38, 6 January 2016 (EST)
There are some areas that are officially named, like Cosmic Cove Galaxy's Twin Falls and Cosmic Cavern. Should we note that these are exceptions to the rule by just saying "NOTE: This area is officially named.", and provide a source for its name? PidgeyIcon.pngRandomYoshi(Talk • PMs • C) 13:10, 6 January 2016 (EST)
Or just say "NOTE: Unless otherwise marked, all names are unofficial." and then for the ones with real names, do specifically mention and bold the names in the text with a ref ("The Twin Falls[1] area consists of..."), and that should be enough to tip readers off that those are the official ones. Then the mission articles could go a step further and say "NOTE: Unless otherwise marked with a reference, all names are unofficial." since there's no headers to worry about gunking up, just thumbnails (of if using refs for the mission pages seems like overkill, asterisks could work instead). - Walkazo (talk) 13:40, 6 January 2016 (EST)
Deal. PidgeyIcon.pngRandomYoshi(Talk • PMs • C) 13:55, 6 January 2016 (EST)

See my opposition vote for details about my thoughts. I don't know what version of MediaWiki MarioWiki is using. --Wildgoosespeeder (talk) (Stats - Contribs) 17:49, 7 January 2016 (EST)

Actually even if this issue persists forever there is an easy workaround. That is, use the template {{Anchor}} under each section. Just sayin, I still agree with this proposal because the look of the hovertext in the section titles.--
User:MegadarderyUser talk:MegadarderyDashbot signature
 09:50, 8 January 2016 (EST)
Like Megadargery states above me, getting rid of the hover text is also one that needs to be done. Even if we were to place {{anchor}}s everywhere, it would be ugly and awful. The solution that is proposed is fine. PidgeyIcon.pngRandomYoshi(Talk • PMs • C) 15:57, 8 January 2016 (EST)

Miscellaneous

Split the Mario & Luigi and Super Mario RPG consumables into separate articles

Remember back in the day when the word "stub" was thrown around like it was going out of fashion and everything smaller than Bowser's article was a stub? This resulted in a lot of articles being clumped together into one superarticle, which is kind of like Superman if he had wear Kryptonite. What I want to bring up today involves several articles merged during that period, including Super Syrup, Ultra Syrup, Max Syrup, Super Mushroom, Ultra Mushroom, Max Mushroom, and plenty more (including subjects that were affected long after the merge). Every article that I want to split will be listed in the comments. So, the reason I want to split these articles is because there's no reason for them to be split. They're individual items with individual names, individual effects, individual buying/selling prices, and individual locations that the games treat like individuals. In some cases, they even have individual appearances, and no, some items having the same appearance is not enough to keep them merged when everything else about them is different. The clumped articles aren't all that pleasant, trying to hop from several topics in rapid succession when that information would be more easily presented in separate articles. Also, having a bunch of Foreignname templates stacked on top of each other is not good in the slightest. I was one of the people who supported those proposals, but looking back, I simply cannot see how the articles are "clearly not working seperate". In light of the recent splits, I thought this would be appropriate.

Proposer: Time Turner (talk)
Deadline: January 17, 2016, 23:59 GMT

Split

  1. Time Turner (talk) Per proposal.
  2. NSY (talk) Per proposal.
  3. RandomYoshi (talk) – Consistency is key. Per proposal.
  4. Walkazo (talk) - Per Time Turner.

Don't Split

Comments

Full list:

I'm tempted to thrown in the Peppers alongside this proposal, but they're not quite in the same boat as the other ones. There's also the Mushroom that the Triplets give, which has a completely different effect to a regular Mushroom, but I don't know how the article would be properly identified if split. Hello, I'm Time Turner.

It most definitely should be Nut instead of Nuts. It shouldn't be renamed right away, but it should be renamed after you've made the different Nut articles. You're allowed to link to just Template:Fakelink even if that would generate a red link. PidgeyIcon.pngRandomYoshi(Talk • PMs • C) 20:17, 9 January 2016 (EST)
Retrieved from "https://www.mariowiki.com/index.php?title=MarioWiki:Proposals&oldid=1935131"