MarioWiki:Proposals

Current time: May 25, 2026, 23:11 (UTC)

Proposals can be new features, the removal of previously-added features that have tired out, or new policies that must be approved via consensus before any action is taken. Voting periods last for two weeks, but can close early or be extended (see below). Any autoconfirmed user can support or oppose, but must have a strong reason for doing so. 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.

If you would like to get feedback on an idea before formally proposing it here, you may do so on the proposals talk. For talk page proposals, you can discuss the changes on the talk page itself before creating the TPP there.

How to

If someone has 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 other users, who will then vote on whether or not they think the idea should be implemented. Proposals should include links to all relevant pages and writing guidelines. Proposals must include a detailed description of the proposed changes and may link to a draft page. Any pages that would be largely affected by the proposal should be marked with {{proposal notice}}.

Rules

1. Only autoconfirmed users may create or vote on proposals. Proposals can be created by one user or co-authored by two users.
2. A given user may author/co-author a maximum of five total ongoing/unimplemented proposals. Any new proposals over this limit will be immediately canceled.
3. Anyone is free to comment on proposals (provided that the page's protection level allows them to edit).
4. Proposals conclude at the end of the day (23:59) two weeks after voting starts (all times UTC).
   • For example, if a proposal is added at any time on Monday, August 1, 2011, the voting starts immediately and the deadline is two weeks later on Monday, August 15, at 23:59 (UTC).
5. Proposals cannot contradict an already ongoing proposal or overturn the decision of a previous proposal that concluded less than four weeks (28 days) ago.
6. Proposals must have a status quo option (e.g. "Oppose", "Do nothing") unless the status quo itself violates policy.
7. Users may vote for more than one option, but they may not vote for every option available. Keep in mind that we use approval voting, so all of your votes count equally regardless of preferred order.
8. Every vote should have a strong, sensible reason accompanying it. Agreeing with a previously mentioned reason given by another user is acceptable (including "per" votes), but tangential comments, heavy sarcasm, and other misleading or irrelevant quips are just as invalid as providing no reason at all.
9. 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(s) at any time, but the final decision to remove another user's vote lies solely with the wiki staff.
   • 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.
10. 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 "(blocked)" 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.
11. If one week before a proposal's initial deadline, the first place option is ahead of the second place option by eight or more votes and the first place option has at least 80% approval, then the proposal concludes early. Wiki staff may tag a proposal with "Do not close early" at any time to prevent an early close, if needed.
    • Tag the proposal with {{early notice}} if it is on track for an early close. Use {{proposal check|early=yes}} to perform the check.
12. 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.
13. If a proposal reaches its deadline and there is a tie for first place, then the proposal is extended for another week.
14. If a proposal reaches its deadline and the first place option is ahead of the second place option by three or more votes, then the first place option must have over 50% approval to win. If the margin is only one or two votes, then the first place option must have at least 60% approval to win. If the required approval threshold is not met, then the proposal is extended for another week.
    • Use {{proposal check}} to automate this calculation; see the template page for usage instructions and examples.
15. Proposals can be extended a maximum of three times. If a consensus has not been reached by the fourth deadline, then the proposal fails and cannot be re-proposed until at least four weeks after the last deadline.
16. After a proposal passes, it is added to the appropriate list of "unimplemented proposals" below and is removed once it has been sufficiently implemented.
17. 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 should ask for that help. Proposals that result in changes to policy pages or general guidelines must be cited accordingly.
18. For sizeable projects, a proposal author or wiki staff member may create a PipeProject page to serve as a portal for an unimplemented proposal. This is linked from the unimplemented proposals list and can contain progress tracking, implementation guidelines, resource links, a list of users working on the project, etc.
19. All proposals are archived. Please note that canceled proposals must also be archived, including their date of cancellation.
20. Proposals can only be rewritten or canceled by their proposer within the first four days of their creation. If a proposer cancels their own proposal, they must provide a reason and wait three days before submitting any new proposal.
    • A proposer cannot cancel their proposal and then implement it anyway. Only wiki staff can cancel a proposal and immediately put it into effect.
21. Proposers can request their proposal be canceled by a wiki staff member after the self-cancellation cutoff, but they must provide a valid reason for doing so. In most cases, the proposal should simply run its course.
22. If the wiki staff deem a proposal unnecessary or potentially detrimental to the upkeep of the Super Mario Wiki, they have the right to cancel it at any time.
23. 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.
24. Proposals cannot be made about promotions and demotions. Staff changes are discussed internally and carried out by the bureaucrats.
25. No joke proposals. Proposals are serious wiki matters and should be handled professionally. Joke proposals will be deleted on sight.

Basic proposal formatting

Copy and paste the formatting below to get started; your username and the proposal deadline will automatically be substituted when you save the page. Update the bracketed variables with actual information, and be sure to replace the whole variable including the square brackets, so "[insert info here]" becomes "This is the inserted information" and not "[This is the inserted information]". Proposals presenting multiple alternative courses of action can have more than two voting options, but the objective(s) of each voting option 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|{{subst:REVISIONUSER}}}}<br>
'''Deadline''': {{subst:#time:F j, Y|+2 weeks}}, 23:59 (UTC)

====[option title (e.g. Support, Option 1)]: [brief summary of option]====
#{{user|{{subst:REVISIONUSER}}}} Per proposal.

====[option title (e.g. Oppose, Option 2)]: [brief summary of option]====

====Comments ([brief proposal title])====

Autoconfirmed users will now be able to vote on your proposal. Remember that you can vote on your own proposal just like the others.

To vote for an option, just insert #{{user|[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 simply say "Per proposal".

Poll proposal formatting

As an alternative to the basic proposal format, users may choose to create a poll proposal when one larger issue can be broken down into multiple subissues that can be resolved independently of each other. Poll proposals concerning multiple pages must have good justification for using the poll proposal format rather than individual talk page proposals or else will be canceled (for example, in the case of the princesses poll proposal, there are valid consistency concerns which make it worthwhile to consider these three articles simultaneously, but for routine article size splits, there is no need to abandon using standard TPPs for each).

In a poll proposal, each option is essentially its own mini-proposal with a deadline and suboption headings. A poll proposal can have a maximum of 15 options, and the rules above apply to each option as if it were its own proposal: users may vote on any number of options they wish, and individual options may close early or be extended separately from the rest. If an option fails to achieve quorum or reach a consensus after three extensions, then the status quo wins for that option by default. If all options fail, then nothing will be done.

To create a poll proposal, copy and paste the formatting below to get started; your username and the option deadlines will automatically be substituted when you save the page. Update the bracketed variables with actual information, and be sure to replace the whole variable including the square brackets, so "[insert info here]" becomes "This is the inserted information" and not "[This is the inserted information]".

===[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|{{subst:REVISIONUSER}}}}

====[option title (e.g. Option 1)]: [brief summary of option]====
'''Deadline''': {{subst:#time:F j, Y|+2 weeks}}, 23:59 (UTC)

;Support
#{{user|{{subst:REVISIONUSER}}}} Per proposal.

;Oppose

====[option title (e.g. Option 2)]: [brief summary of option]====
'''Deadline''': {{subst:#time:F j, Y|+2 weeks}}, 23:59 (UTC)

;Support
#{{user|{{subst:REVISIONUSER}}}} Per proposal.

;Oppose

====[option title (e.g. Option 3)]: [brief summary of option]====
'''Deadline''': {{subst:#time:F j, Y|+2 weeks}}, 23:59 (UTC)

;Support
#{{user|{{subst:REVISIONUSER}}}} Per proposal.

;Oppose

====Comments ([brief proposal title])====

For the purposes of the ongoing proposals list, a poll proposal's deadline is the latest deadline of any ongoing option(s). A poll proposal is archived after all of its options have settled, and it is listed as one single proposal in the archive. It is considered to have "passed" if one or more options were approved by voters (resulting in a change from the status quo), and it is considered to have "failed" if all options were rejected by voters and no change in the status quo was made.

Talk page proposals

Proposals concerning a single page or a limited group of pages are held on the most relevant talk page regarding the matter. All of the above proposal rules also apply to talk page proposals. Place {{TPP}} under the section's heading, and once the proposal is over, replace the template with {{settled TPP}}. Proposals dealing with a large amount of splits, merges, or deletions across the wiki should still be held on this page.

All active talk page proposals must be listed below in chronological order (new proposals go at the bottom) using {{ongoing TPP}}. Include a brief description of the proposal while also mentioning any pages affected by it, a link to the talk page housing the discussion, the proposal author(s), 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.

List of ongoing talk page proposals

Deletions

None at the moment.

Moves

• Move Luigi's Mansion organ game to "organ game" (discuss) by Nelsonic; Deadline: May 25, 2026, 23:59 (UTC)
• Move Captain Shy Guy (Mario & Luigi series) to Captain Shy Guy (discuss) by Wilben; Deadline: June 7, 2026, 23:59 (UTC)

Merges

• Merge Star (Mario Party series) with Star (Mario & Wario) and treat the item as a genericized version of the Super Star (discuss) by Dive Rocket Launcher; Deadline: June 6, 2026, 23:59 (UTC)
• Merge Ken Masters into the List of fighters debuting in Super Smash Bros. Ultimate (discuss) by Brett; Deadline: June 8, 2026, 23:59 (UTC)

Splits

• Split King Hisstocrat and Queen Hisstocrat (discuss) by Mariuigi Khed; Deadline: May 29, 2026, 23:59 (UTC)
• Split Coin Bandit from Bandit (discuss) by Sorbetti; Deadline: May 31, 2026, 23:59 (UTC)
• Split the segments of Frizzy's Silly amiibo Theater (discuss) by Rykitu; Deadline: June 1, 2026, 23:59 (UTC)
• Split objects appearing exclusively in browser games into their own articles (discuss) by Nelsonic; Deadline: June 5, 2026, 23:59 (UTC)

Miscellaneous

• Reconsider the relations the Baseball Bros, Zeus Guy, and Grunt have with Bandit (discuss) by FanOfYoshi; Deadline: June 08, 2026, 23:59 (UTC)

Unimplemented proposals

Proposals

Break alphabetical order in enemy lists to list enemy variants below their base form, EvieMaybe (ended May 21, 2024)

Standardize sectioning for Super Mario series game articles, Nintendo101 (ended July 3, 2024)

Note: Not yet integrated for the Super Mario Maker titles.

Use the classic and classic link templates when discussing classic courses in Mario Kart Tour, YoYo (ended October 2, 2024)

Split major RPG appearances of recurring locations, EvieMaybe (ended December 16, 2024)

Note: Implemented for all except Bowser's Inside Story's Bowser's Castle and Kingdom Battle's Peach's Castle

Retool the Names in other languages section into a more general etymology section, EvieMaybe (ended March 7, 2025)

Allow English Super Mario Bros. Encyclopedia names to be mentioned on articles where they are not the title, Hewer (ended March 27, 2025)

Split every song from the "List of (show) songs" articles, Zing Zang Zote (ended May 31, 2025)

Note: Not yet implemented for List of The Super Mario Bros. Super Show! songs

Overhaul sponsor pages, Seandwalsh (ended June 26, 2025)

Reorganize recurring theme articles to use history sections, Ahemtoday (ended July 2, 2025)

Revamp colorful tables, Camwoodstock (ended August 14, 2025)

Make articles for the licensed songs in The Super Mario Bros. Movie, Sargent Deez (ended September 17, 2025)

Note: Articles for "Battle Without Honor or Humanity" and "Mr. Blue Sky" have not been created yet

Change game quote lists to game scripts, Scrooge200 (ended September 21, 2025)

Create an article for Gourmandise, Sargent Deez (ended October 4, 2025)

Stop using icon-based level names for Super Mario Bros. 3, PopitTart (ended October 21, 2025)

End the use of "new course" and "classic course" as universal definitions within the Mario Kart series, Polley001 (ended January 26, 2026)

Make all release dates use individual flags (if possible), Yoshi18 (ended February 8, 2026)

Have game navboxes and categories cover all music appearances rather than just debuts, Ahemtoday (ended February 20, 2026)

Create "recycled assets" sections for asset re-use, and move examples of asset re-use to those sections, Camwoodstock & Yoshi18 (ended March 5, 2026)

Prioritize whole integer upscaling for sprite displays, Scrooge200 (ended March 13, 2026)

Make an article for the New Super Mario Bros. series (Draft page), Yoshi18 & Sargent Deez (ended March 18, 2026)

Establish a consistent format for non-game enemy and obstacle lists, Illuminoid (ended March 22, 2026)

Allow screenshot in infobox for subjects with an updated design when no proper artworks exist, Brett (ended April 17, 2026)

Create articles for Toad Brigade Training Camp and Attraction variations of courses in Super Mario Bros. Wonder – Nintendo Switch 2 Edition + Meetup in Bellabel Park, Illuminoid (ended April 23, 2026)

Use manga chapters rather than volumes for subjects' first and last appearances, Brett (ended May 9, 2026)

Decide if medias that mention a subject before their first appearance or after their last appearance should be included in their infobox, Brett (ended May 14, 2026)

Decide how to handle reissues in the History sections of musical theme articles, Wilben (ended May 22, 2026)

Talk page proposals

Make bestiary list pages for the Minion Quest and Bowser Jr.'s Journey modes, Doc von Schmeltwick (ended January 11, 2024)

Allow separate articles for Diddy Kong Pilot (2003)'s subjects (Draft page), Doc von Schmeltwick (ended August 3, 2024)

Create articles for specified special buildings in Super Mario Run, Salmancer (ended November 15, 2024)

Note: Missing Rainbow Bridge, Red Bonus Game House, Blue Bonus Game House, and Yellow Bonus Game House articles.

Give the Cluck-A-Pop Prizes articles, Camwoodstock (ended January 31, 2025)

Split the Animal Crossing series (now Crossovers with Animal Crossing) (Draft page), Zing Zang Zote (ended February 12, 2025)

Restructure Yoshi's Island (series) article into Yoshi series, PopitTart (ended March 19, 2025)

Note: Not yet implemented in articles that still use the Yoshi's Island series and still have separate Yoshi's Story, Yoshi's Woolly World, and Yoshi's Crafted World sections

Split Super Luigi subjects into a dedicated list article (Draft page), EvieMaybe (ended April 3, 2025)

Clean up Prohibited Command, PrincessPeachFan (ended May 13, 2025)

Determine which subjects belong in Category:Aliens, Technetium (ended June 14, 2025)

Note: Not yet implemented for Super Mario Galaxy and Super Mario Galaxy 2 subjects.

Split A Magical Tour of Yoshi's Island from Super Mario World 2: Yoshi's Island, Rykitu (ended July 9, 2025)

Decide how to handle hammer-based moves in Category:Hammers, SolemnStormcloud (ended July 21, 2025)

Treat Pyoro as a series, janMisali (ended September 1, 2025)

Determine whether a Final Smash is one of a fighter's special moves, Salmancer (ended September 13, 2025)

Split Challenge, VS. Game/You VS. Boo, the Album and the Toy Box + its individual toys from Super Mario Bros. Deluxe, Snessy (ended December 23, 2025)

Decide whether to use title case in English meanings of foreign names where applicable when not present in the source language, PaperSplash (ended December 26, 2025)

Treat courses that debuted in Mario Kart Tour and Mario Kart 8 Deluxe as Mario Kart Tour and Mario Kart 8 Deluxe courses respectively, Polterpup (ended January 1, 2026)

Consider "LUCKY" misses from the Paper Mario series to be a game mechanic, Pizza Master (ended January 13, 2026)

Move Wakkiki info to Akiki, FanOfYoshi (ended January 17, 2026)

Determine which clothing and other gear deserves individual articles, Doc von Schmeltwick (ended January 21, 2026)

Note: Currently split clothing should be merged back

Determine what qualifies as a game (and create appropriate categories in the process), SuperGamer18 (ended February 2, 2026)

Declare Super Smash Bros. - Gameplay & Quest for the amiibo! a guest appearance and delete Jack (Quest for the amiibo!), Salmancer (ended February 22, 2026)

Add music types to track tables (SSBU Sound Test), The Eggo55 (ended February 27, 2026)

Determine whether discontinued media counts as lost media, Pizza Master (ended February 28, 2026)

Make articles for the licensed songs in The Super Mario Galaxy Movie, SuperGamer18 (ended April 3, 2026)

Clean up the Mini Boo page, Sorbetti (ended April 25, 2026)

Move level categories to use game-dependent terminology, Illuminoid (ended May 24, 2026)

Writing guidelines

Standardize the timezone used for internationally-synchronized release dates

As of publishing this proposal, it is about 2AM EST on March 20th, 2026, or 6AM UST on March 21st, 2026. Yoshi and the Mysterious Book has only just released in North America for 2 hours... But it has been out for several more hours in other parts of the world, namely Japan. And in some more western parts of North America, namely in Alaska, the game technically isn't even out! Late yesterday/earlier today, a bit of a conundrum happened on the pages for a few things featured in Yoshi and the Mysterious Book, where their infoboxes were updated to use that game as their "latest appearance" despite the game not being out in neither EST nor UTC... but, it was available in Japan at that point in time.

The original proposal that has been used as a precedent for this sort of thing from 2008 does not specify a timezone, only stating to use the "latest released appearance", putting the emphasis on when the game was released rather than announced, but not when in terms of timezones. We've seen this cause conundrums before; discounting the case with Yoshi and the Mysterious Book that incited this proposal, it's happened recently with The Super Mario Galaxy Movie, Donkey Kong Bananza, with Mario Kart World, with Super Mario Bros. Wonder... Really, any substantially large or dense game will inevitably see at least one over-zealous editor adding these games to infoboxes a few hours too soon, and people feel the need to either debate whether or not they should be reverted, or try to revert them themselves, all over the same lack of a "when" in terms of the timezone.

In this era where more and more Mario games are getting synchronized international releases for most of their release countries, we think it's high time to finally codify a timezone for these. Or in other words, when a game is set to release internationally at the same time for its first release, what time zone should we use? We've got three options here:

• JST (GMT+9): Japan's time zone. If we took that original 2008 proposal literally, this is what we would be doing as a technical status quo, even if, in practice, this usually isn't what we do by a magnitude of literally 13 entire hours.
• UTC (GMT±0): The gold standard for wiki affairs. Proposals use it, signatures use it, edit histories use it (by default, anyways), UTC has been a growing time standard on the wiki.
• EST (GMT-4): This is the de-facto status quo right now. As an American English wiki, it makes sense that the wiki would, on occasion, use the earliest timezone in North America for dates like this.

Edit: Per request, we've added Hewer's suggestion of "whatever country the game first releases in". We kind of don't like this, as it's... Not really a timezone? But, it was requested, and someone else said they would've voted for it if it was there, so, sure.

It was tempting to include NZST (GMT+12) as that is the earliest time zone in a country that sees frequent support from Nintendo (sorry, Kiribati), but we feel like the actual practicality of this is dubious, so we decided to relent. If this is somehow an unpopular stance (beyond just "it'd be fun to put it on the proposal" reasons), we could be swayed to add it as an option.

Proposer: Camwoodstock (talk)
Deadline: June 4, 2026, 23:59 (UTC)

Use Whatever Country The Game First Releases In

1. Hewer (talk) As argued in the comments, this is the option that allows for the most consistency and accuracy. If a game has been released in any region, then it has been released, and not considering it as such would just be incorrect.
2. Sorbetti (talk) Per Hewer.
3. Jdtendo (talk) Per Hewer.
4. WACCA Lily R (talk) Same reasons I voted for JST, also per Hewer.
5. Arend (talk) Makes sense (for the record, this seems about using the timezone of whichever region gets it first; e.g. JST is used if Japan gets it first, CET or EET if Europe gets it first, EST if the USA gets it first. For worldwide releases, we just use JST or AEST, since Japan and Australia move on to a new day first or I guess NZST, forgot about New Zealand)
6. Dive Rocket Launcher (talk) This makes the most sense to me. I like using UTC as the basis for internal wiki matters, but that doesn't mean it needs to apply to the entire wiki with articles included. We already use completely different writing and formatting from content articles for our behind-the-scenes matters, so there's no need to try to keep these consistent with each other. And as Hewer said, if a game released in any region, then treating it as if it has not yet released in our articles, just because it hasn't rolled out in one specific time zone, would be objectively inaccurate.
7. LinkTheLefty (talk) It always bothers me when other wikis arbitrarily list Japan first, even when it doesn't make sense to, and then I have to do a double-take when I get my date info wrong. It happens often enough that I'd rather we standardize a flat-first across the board. Hopefully it'll catch on.
8. Doc von Schmeltwick (talk) - Seems to be self-evidently the best option.
9. SuperGamer18 (talk) Honestly, this is just what makes the most sense out of everything discussed so far.
10. Camwoodstock (talk) We generally prefer the idea of parity with UTC, but this is at least a defensible deviation from UTC, favoring accuracy of "when the game literally releases globally" to "when the game releases to the day".

Use JST (technically the status quo)

1. SeanWheeler (talk) If Japan-only games would count for latest appearances, I don't see why we'd have to wait when international worldwide releases would be Japan-exclusive for a couple hours. We covered games that came to Japan first and were scheduled with a different release date for America, right? If the "simultaneous" releases drops at each time zone at their respective midnight, I don't see how that's different.

#WACCA Lily R (talk) I think running with the earliest time here will just save any headaches with people who come along and change the template because it's out in another regions. No need for arguments or revert wars and telling people that they're technically wrong, the page just gets edited once because it's out in a region and is treated as such.

Use UTC

1. Camwoodstock (talk) We've gone on record to be skeptical on UTC before, but as of recently, we've kind of changed our tune, especially after Porplemontage proved the transition from EST to UTC really wasn't that difficult to implement. UTC is late enough in the day for folks in North America that it doesn't really (even in Alaska, you'd only get it "early" insofar as we'd consider the game released at their 4PM), and above all else, UTC is consistent with so many other things on the wiki.
2. Illuminoid (talk) Since most things on the wiki use UTC time, it would seem really weird if this one thing did not.
3. Rykitu (talk) Per all.
4. EvieMaybe (talk) per Illuminoid.
5. LadySophie17 (talk) We've switched to UTC almost everywhere, makes no sense to stop now.
6. Nelsonic (talk) Per.
7. Yoshi18 (talk) If we use UTC, the game has released in at least half of the world and that this is arguably the best option. Also per Camwoodstock, Illuminoid and LadySophie17. I was about to give their exact reasoning as well.
8. WACCA Lily R (talk) I have nothing against UTC either, while less practical in my books, I love the sound of consistency.
9. Wilben (talk) Per all.
10. Lastro (talk) Per all.

Comments (it's about time!) (...zones)

I'm confused. If a game has released in Japan (or any region), then it is a released game and should count for the "Latest appearance" in the infobox regardless of any other parts of the world, right? Not to mention that Japan-only games count for the latest appearance too (like in the months between the Japanese and international releases of Hello, Mario!). Hewer (talk · contributions · edit count) 16:21, May 21, 2026 (UTC)

The proposal already states that this applies to simultaneous worldwide releases only. If a Japanese release significantly predates the international one, then yes, we would go by it, but we can be a little patient and wait 9 hours for the release date to roll around in UTC. — eviemaybe (talk) 15:24, May 22, 2026 (UTC)

I don't understand the benefit of deliberately being inaccurate for those 9 hours. If a game has released, there's no reason for it to not count as a released game. I would support an option of "use whichever time zone has the earliest release". Hewer (talk · contributions · edit count) 18:55, May 22, 2026 (UTC)

UTC is arguably the best option here as well he game has released in at least half of the world by then and not just one country. If we're gonna look at it like it's inaccurate the moment we don't update the appearance tables when a game releases in Japan, then we might as well already change the appearance table when the game releases in New Zealand. Yoshi18 (talk/contribs) 09:53, May 23, 2026 (UTC)

I'm with Hewer on this one. If we already count Japan only games, and we don't even wait for a game to be released in America when it was released in Japan months prior, why should the time matter for these same day worldwide releases? If someone made an edit a couple minutes before it's time and the admins found it after it was time, there would be no point in reverting, so that rule would be difficult to enforce. SeanWheeler (talk) 21:28, May 23, 2026 (UTC)

As I said, I would support an option of "use whichever time zone has the earliest release", as anything else is just purposefully being inaccurate. So yes I do think it should be listed when it's out in New Zealand. Why shouldn't New Zealand count? Hewer (talk · contributions · edit count) 23:44, May 23, 2026 (UTC)

Because the game has been released in just one country. Only a handful of people can play it. In some countries it may even be a day (and 2 hours) before the release. The reason I think UTC is the best option is because the game has then released in at least half of the world, instead of solely one country. Also, the fact our wiki has been converting a lot to UTC lately. It would only make things more accurate. UTC is the standard timezone of the world. That one should count the most. Yoshi18 (talk/contribs) 08:45, May 25, 2026 (UTC)

As has already been discussed, games that aren't released worldwide (e.g. Japan-only games) do count, so being released in only one country doesn't (and shouldn't) disqualify a game from counting as released. Also, Japan has the world's 11th-largest population, so that's hardly "only a handful of people". Hewer (talk · contributions · edit count) 11:17, May 25, 2026 (UTC)

Games that aren't released worldwide (mainly Japan-exclusive) can have an exception, since they're only released in one country anyway. Yoshi18 (talk/contribs) 13:27, May 25, 2026 (UTC)

Why bother making an exception when you can just have a consistent rule that works in all cases? Hewer (talk · contributions · edit count) 14:31, May 25, 2026 (UTC)

Hey @Camwoodstock, just to correct you, the earliest timezone of a country that sees active support from Nintendo (New Zealand) is technically NZDT (GMT+13). And the earliest timezone in North America is technically EDT (GMT-4). Yoshi18 (talk/contribs) 09:53, May 23, 2026 (UTC)

@SeanWheeler, could you explain your reasoning? Just wondering but what do Japan-exclusive games have to do with this? I mean, we can make exceptions for them since they’re only gonna be released in one country (Japan) anyway. Yoshi18 (talk/contribs) 08:45, May 25, 2026 (UTC)

@Camwoodstock I would like it if you added an option for "use whichever time zone has the earliest release", as I have been arguing in support of. Hewer (talk · contributions · edit count) 11:21, May 25, 2026 (UTC)

Shouldn't there then be a timezone for the latest release as well? As the game has then be released in the whole world and not just one country (New Zealand isn't that big of a country)? Yoshi18 (talk/contribs) 13:27, May 25, 2026 (UTC)

What do you mean? Hewer (talk · contributions · edit count) 14:31, May 25, 2026 (UTC)

I'd support Hewer's option too BTW. LinkTheLefty (talk) 14:05, May 25, 2026 (UTC)

Is there any way for it to use the timezone set in the user's preferences? --Illuminoid (talk) 18:41, May 25, 2026 (UTC)

What would the benefit of that be? It would just be giving some users less up-to-date information than others. I think the wiki should, as much as is possible, use an objective viewpoint not tied to a particular region (i.e. a game is released if it has been released anywhere), and showing different information to different users depending on region goes against that. Hewer (talk · contributions · edit count) 19:06, May 25, 2026 (UTC)

Ignoring the fact that we don't even know if it's possible, to what end would that even be for? From UTC+12 to UTC-12, we replace the "latest appearance" parameter with some dynamically-updating template that cross-references your own user preferences to determine what timezone to use, and then after UTC-12, we just change the recent release to just... The game itself? ~Camwoodstock ( talk ☯ contribs ) 22:15, May 25, 2026 (UTC)

I don't understand why time zones are being considered part of the discussion at all. A point in time has either passed or is in the future, regardless of time zone. From my understanding, this proposal focuses on the qualification for media listed in the "latest appearance" field of infoboxes rather than how dates are written out in fields such as the "release date" field of game infoboxes. As a result, I don't think time zones should be considered in this proposal.

That being said, games have multiple release dates because Nintendo operates in multiple regions, and different policies are used in each region. In the United States, for example, the specific time of a given release date is midnight in the Eastern Time Zone across the entire country, as confirmed by a support article. These policies apply to Nintendo eShop launches in addition to in-person launches, as those who were part of the Nintendo Switch 2 launch can attest to. Since these different policies are documented and consistent, I don't see any reason to invent a time zone-based approach rather than simply considering a game launched when it first launches in any region. B700465189a9 (talk) 21:22, May 25, 2026 (UTC)

We mean, time zones are a factor because the original debacle that caused this (when to update pages to say Yoshi and the Mysterious Book was the most recent appearance) was rooted entirely on editors disagreeing which time zone to use for counting the game as "released". Some argued that it being out in Japan meant it was fine, some argued it should wait until it released in UTC, some argued it should wait for midnight EST. This is kind of just already mentioned in the lead of the proposal, though. ~Camwoodstock ( talk ☯ contribs ) 22:15, May 25, 2026 (UTC)

I'd like to understand whether this proposal applies only to games or to release dates for any kind of media. It has long annoyed me that Nintendo Music soundtracks are listed as having released on the American dates and not that of both Japan and UTC (which I believe have aligned universally aside from the service's launch), especially in cases where the date is relevant to what is being added such as upon a game's release. Polley001 (talk) 21:34, May 25, 2026 (UTC)

That feels a bit out-of-scope for what we're trying to do here. This is very specifically about when to count a game as "released" for the sake of the "latest appearance" parameter, not "should we list any date fluctuations caused by a unified global release in the release date parameter". ~Camwoodstock ( talk ☯ contribs ) 22:15, May 25, 2026 (UTC)

Removals

None at the moment.

Additions

Restore PipeProjects

This image is clearly a remnant from 2009. I would love to see it be updated to represent the multitude of PipeProjects that I hope will arise from this proposal.

PipeProjects are portals for major projects that often branch out into multiple articles. With the Super Mario Wiki growing day by day, the need for a system that allows like-minded editors to effectively cover select parts of a franchise that spans decades of history and a variety of mediums is clear.

However, PipeProjects were abandoned fourteen years ago. As such, this proposal aims to restore PipeProjects as a wiki-centered space for collaboration. I will also propose the creation of a new PipeProject, which will serve as an inaugural example of how PipeProjects will benefit the wiki.

PipeProjects will serve as spaces to host discussions, communal drafts, resources, and links to relevant discussions and proposals. Rather than scattering this information around various talk pages and user pages, PipeProjects will work as a centralized hub where interested editors can reasonably keep up to date with the project's latest developments. Specifically, PipeProject pages will provide the following sections in order:

• an introduction providing an overview of the project and its goals;
• a curated list of links to relevant proposals, talk page proposals, and unimplemented proposals;
• a curated list of links to relevant;
• an overview of the resources provided by the project, including subpages and passed proposals; and
• a non-signature list of editors who actively affiliate themselves with the project.

While PipeProject pages will generally follow this structure, they may also feature images and other elements as personal touches from the projects' contributors.

Project subpages will be encouraged to host specific project resources as an indication that the pages serve the project and are free to edit. Many valuable pages hosted by other editors already are open to edits, but I believe that moving these pages to common ground would provide even more benefit to editors.

PipeProjects will be created by proposal rather than the supporter-based process currently indicated by the PipeProjects page. Proposals should focus on whether projects will be worked on by many editors and have lasting utility outside of changes to a select number of articles. Most unimplemented proposals will not result in the creation of PipeProjects.

Of course, no project is guaranteed to last forever. Starting a year after the creation of a project, if editors determine that the project is not active enough to continue, the project may be considered closed for inactivity. The year-long delay is intentionally set as a barrier to discourage the creation of projects that may not have sufficient evidence that they would last beyond that year. Subpages for closed projects will remain editable, but the project page will generally be considered archived, and the proposals and discussions lists will not be kept up to date. The existing projects from the previous iteration of PipeProjects will additionally be considered closed. Contributors to a project may close the project earlier than a year via proposal, assuming that the project's goals have been met. Contributors are permitted to reasonably expand a project's scope via consensus, allowing projects to focus on one priority (for example, documenting a portion of the mainline Super Mario series) before continuing with another (doing the same for the broader Super Mario franchise).

As an optional addendum to the restoration of PipeProjects, I recommend that a forum channel be created in the affiliated Discord server, where each post in the channel corresponds to an open PipeProject. I have observed that a system of project-focused channels works well in other wiki communities such as WiKirby, and I believe that implementing these channels would not detract from the ideal of discussions taking place primarily on the wiki.

---

Now that I have introduced my thoughts for PipeProjects as a whole, I would like the propose the creation of PipeProject Music. Over the past few years, a variety of editors including myself have developed the wiki's coverage of music. This progress shows no signs of slowing down, and the resources available and discussions needed would serve well under the structure of a PipeProject.

Specifically, I would like to nominate the following editors who I have seen work on music coverage and the relevant resources that they have contributed:

• Myself (harmonization)
• @Bel2004
• @Conradd (Eligible themes, jingles and sound effects)
• @Dominoes
• @EvieMaybe (draft proposal)
• @MarioMaker99
• @OngoingTalent13
• @Polley001 (Nintendo Music spreadsheets)
• @The Dab Master (Mario Kart World soundtrack, Mario Kart World multimedia)
• @The Eggo55
• @Vivavivi004
• @Wilben

If created, the project's scope would cover articles, sections, templates, and categories for musical themes, sound effects, soundtracks, sheet music, live performances, streaming services such as Nintendo Music, composers and other sound artists, and references to these topics in media, as well as any other music-related topics covered by the wiki.

---

Finally, I would like call out @Nintendo101's work on citations and mainline subjects. While I will not propose for those projects to become PipeProjects on Nintendo101's behalf, I believe both stand out today as incredible examples of the wiki's collaboration that PipeProjects could further enrich.

Proposer: B700465189a9 (talk)
Deadline: May 30, 2026, 23:59 (UTC)

Support: Restore PipeProjects

1. B700465189a9 (talk) Per proposal.
2. SuperGamer18 (talk) I was NOT around when this was a thing, but we should absolutely bring this back. I even have an idea for a new banner if the PipeProjects name is kept.
3. Camwoodstock (talk) Pardon our excitement, but... WE'VE BEEN SAYING THIS FOR YEARS!!! While the Discord and the Boards are adequate for organized efforts, having something on the wiki itself to coordinate these things would go a long way, both for accessibility and making sure those efforts don't get easily lost in the flotsam and jetsam of Actual Conversation. It clearly spells out what is actively being organized, who is working on it, lets people better determine who's handling what, and most of all, puts it in a very obvious space for it that editors are likely to actually see. We could even bolster it with our more recent infrastructure; something like a widget on the main page to show ongoing Pipe Projects to editors akin to the To-Do Bar (and maybe even listing a count of active Pipe Projects on the To-Do Bar itself for good measure), or using a variant of the {{todo}} templates to show that a page is being handled by a specific Pipe Project. We have a lot of options to bring Pipe Projects up to more modern standards, is what we're getting at! (A bit more pragmatically, this will also hopefully offload some of the long-standing "proposals to implement" from that list, by opening them up to more editors willing to pitch in. If this passes, we definitely plan to turn our "reused assets" section proposal in particular into a Pipe Project.)
4. PopitTartProjects (talk) Yes, please. I can't even count the discussions on the Discord server that have culminated in "It sure would be nice if we had the infrastructure to do a big project like this." It has reached the point of being a sarcastic in-joke.
5. Spencer PK (talk) The wiki really needs some way for large projects to be managed so stuff can get done. I left a talk page topic at the main page detailing how the wiki's current documentation of locations in RPGs are poor, but without the ability to orchestrate a project, I could only really just say "there is a problem with the wiki" and leave it at that. The ability to make a project for that would lead to that discussion getting resolved, begin discussion for how RPG location articles should be improved, and would be a natural place for discussion on handling issues as they come up.
6. Aomaf (talk) Per proposal.
7. PipeProject:Nelsonic (talk) Per proposal. I was actually considering proposing this myself at some point.
8. Reese Rivers (talk) Per all. I especially like the idea of the Discord forum channel to go alongside the projects, which I think would be very helpful for realtime collaboration.
9. PipeProject:Rykitu (talk) Per all. I always wondered why a perfectly good idea like that was deprecated, and I'm glad it's returning. My only complaint is Discord, which I don't have (and I don't want one after recent events), but I have a Boards account so that could be a good substitute if I ever decide to start one.
10. EvieMaybe (talk) It's nice to see this finally happen.
11. Sorbetti (talk) Per proposal and Rykitu.
12. TheDabProject (talk) PER ALL!!!
13. DominoProjects (talk) If this gives a good way to organize large-scale projects, I don't see why not.
14. PaperSplash (talk) Per all.
15. ThePowerProjects (talk) Per all. About time.
16. SONIC123CDMANIA+&K(B&ATSA) (talk) Per all.
17. Polley001 (Nintendo Music spreadsheets) (talk) Sounds good to me. I recently brought up a certain grievance with music coverage on Discord, but have not pursued doing something about it largely because bringing attention to it at scale would pretty much require jumping into a massive proposal, which is... not fun. Having a dedicated space to discuss music coverage as a whole would definitely help there.
18. Brett (talk) Per all.
19. Dive Rocket Launcher (talk) Would love to have a way to coordinate with other wiki editors without having to join the Discord server or forum.
20. Illuminoid (talk) Per all.
21. Nintendo101 (talk) I respect the long-term concerns of our compatriots in the opposition, but, TBH, I have long been a bit wary of the community divide between wikispaces, Mario Boards, and Discord. I think PipeProjects can be a potential supplemental for coordinating general wiki-wide projects. I do know a few excellent users of the wiki who I would like to collaborate with that are not interested in Discord or Mario Boards. I can see the infrastructure of PipeProjects being a potentially good avenue for things like that. And even if it does not work out in the long-term, I don't think there's any harm in trying.
22. TT9200 (talk) Per all.
23. YoshiProjects (talk) Per all.
24. Roserade (talk) Although I do understand having concerns overall, I'm a bit confused by the staunchness of the opposition. From how I read this proposal, I imagine the goal is about organization and coordination, and ensuring that all relevant information is in one place. If a helpful conversation is had over Discord, I imagine logs or a summary would be provided on the relevant PipeProject page. This sounds like a huge boon to me and bridges the gap between venues well. As someone who edits this wiki once every two years, I would feel much more compelled to participate if I saw an identified project I cared about, with all of the relevant information in one place so I'm not scratching my head trying to figure out where to "begin". And if this doesn't have a decade of longevity? I mean, that's fine? I'd rather see this approach be given a shot on the chance that it does maintain interest and engagement moving forward. I don't think we're going to be causing a future dumpster fire by giving it a go now.
25. Shoey (talk) Per all. I mean what's the worst that happens? It flops and gets shut down again no harm no foul!

Oppose: Flush PipeProjects

1. Stache (talk) Honestly, I don't really get the hype for this (not that I was active when it was still a thing). I understand that some people are not keen on having a Discord and/or forum accounts, but wouldn't having another place to coordinate on wiki subjects makes the situation on its fragmentation worse, unless we choose to deprecate the use of Discord server and Mario Boards for that?
2. Xiahou Ba, The Nasty Warrior (talk) Per Stache, but I'll further elaborate his points because, as very long-time, old user with much experience who has been here for a decade and a half, who has seen what happened when stuff like this happened (PipeProjects died, moved to the Wiki Collaborations forum with its threads, which had plenty of steam at first, and then also ended up dying over time as interest faded out), this is a vote that voices criticism and concern of this idea, with hints of cynicism (pardon me for that) with the long term prospects of trying to revitalize such a thing that died, without really knowing why it died to begin with than it really is amount to changing anything or persuading anyone to stop despite the surrounding hype I observe, but I honestly don't think this will take off in the long term (and I'm talking many years long term, not months, most voters who voted support here have only been around for a few years), once the initial steam dies off. None of us are paid editors who are under any obligation to do something like this, we are all drive-by using our free time to edit as we see fit, and I think attempting to organize editors something with a cool fancy sounding name and all of this oh my god, cool official sounding organization shit and all, notwithstanding that all of us with schedules and off-site responsibilities to focus on something particular is wasted effort for little gains other than the illusion to make people believe they actually are doing something. People who have the skills and goals to coordinate are already talking to other editors in other venues, such as the Discord channel, which is honestly a better outlet at promoting fast, quick chats with active editors than here. Look at the PipeProject page itself, there are only a few "completed" PipeProjects, take a look at the PipeProject:Super Smash Bros. one, how many editors signed up with the promise of completing these pages, and how many of them you think actually did anything substantial other than a few handful of them, who are likely were already improving these pages before the PipeProject got organized. On the flipside of the "completed" ones, the vast majority of earlier PipeProjects are incomplete, and they languished like this for most of the PipeProject's history, and some got migrated to MarioBoards before also being abandoned (like PipeProject:Unstubify, a problem we still have of this wiki to this day and frankly, we will still have long after we have exhausted our interest editing here). I'm not saying that any of this is a bad idea, and yes, I do see there is interest in this organization...initially, because PipeProjects was also proposed with initial interest and passion, but where will this end up in, say 5 years, when many editors who wanted this moved on and new editors come in and not really know about this or how to deal with this, which is unnecessary convoluted for the sake of it? It is also concerning to me that zero of the concerns that Glowsquid and other voters who had voiced support and their reasons had written up in the initial scrapping the PipeProjects are completely unaddressed, and they are criticisms that I think are still extremely relevant to this day, there is a history of this being attempted many times already. Another massive concern of mine is a heavily reliance on Discord, which is a massive issue in of itself, such as being unsearchable and relatively inaccessible for some users (imagine there being a Discord outage or Discord did something that is extremely cancelable and a chunk of the enraged userbase migrates to another platform out of protest, further splintering collab between communities, now what?)
3. LadySophie17 (talk) Honestly I wasn't gonna vote so I wouldn't be raining on anyone's parades, but since others have voiced their concerns, I'll share mine. From my personal experience in trying to coordinate effort between people (specifically for bringing our Mario Tennis Fever coverage up to snuff), I can barely get people to cooperate by directly asking for help. I don't think creating a dedicated space where I can post my requests and passively wait for people to come by would yield better results, or any results at all. Maybe I'm wrong. I hope I am wrong. But I don't think I will be using this feature in my future projects in lieu of directly getting in contact with people I know would be interested (if there are any).
4. Mario4Ever (talk) Per Xiahou Ba.
5. Hewer (talk) Personally I don't think I fully understand what the benefit of this is meant to be. If you want to improve a particular area of the wiki, you can go and do that. If you want to coordinate with other editors (or even just point out that a certain area of the wiki needs improvement), you can use talk pages or the Discord server. I don't see how adding an extra namespace requiring extra maintenance and providing extra complications is supposed to help in getting anything done. I also don't understand why this is being presented as some sort of way to unite the whole community in one place with even those who aren't on the Discord...when the proposal itself says that PipeProjects would be coordinated on Discord. And coordinating with other editors on Discord is something you can already do. So what is this actually achieving?
6. Wandering Poplin (talk) Per all.
7. Sargent Deez (talk) It's a cute idea, but on top of the concerns other editors have already raised, is it really necessary? Many users already allow others to work on their sandboxes and drafts. Only those have an owner to settle disagreements, whereas this may lead to free-for-alls.
8. Ahemtoday (talk) My biggest concern is that I don't like stuff being organized offsite. I don't have an account on the Boards, and I'm not in the Discord server, and even if I did have the inclination to change that, I think I would stop being able to keep up with them fairly quickly. Currently, the only real ways to organize with other users are talk pages (which do not always lead to results) and proposals (and jumping into a major proposal with no discussion beforehand can be a high-stress affair). Theoretically, PipeProjects counteract this, being a focused discussion space where you don't have the pressure to get everything right immediately when you post it. But as proposed here, I worry that it will not counteract that. In fact, I worry it will be quite the opposite when the proposal ends on the note of PipeProjects possibly having associated Discord channels. I'm sure that's useful in a very front-facing way if you're in the Discord, but I'm not, so from my perspective it sounds a bit like it defeats the entire point. Why would I join or make a PipeProject if I'm not in the Discord and am therefore not able to participate in an unknown percentage of the discussion of it, a percentage which for all I know could be the vast majority of it? I'm just worried that this proposal isn't pushing hard enough for having discussions on the site itself and might wind up incentivizing the opposite instead.
9. Salmancer (talk) This is going to sound crazy. But I think in the quest to make PipeProjects v2 a guaranteed success, we've put in so much bureaucracy that while it won't fail, I think it's success would be meaningless. Worse than meaningless actually, but we'll get there. A PipeProject can only exist if enough people are already working on the manner for a sustained period of time, granting those people a dedicated hub space on the wiki and a discord thread/channel/whatever. But... the primary stopping points for anything is the starting gate and the first few hurdles. Essentially, this creates a system which empowers established editors who already have friend groups and already know how to coordinate without the advantages of PipeProjects with additional structure. Structure that those people likely don't need because they've already been coordinating for a sustained period of time anyhow. Sure, it'll help, but only in a "rich get richer" sense. And thus, everything that becomes a PipeProject will succeed, not because of the additional strength of PipeProjects, but because the requirements select for the best editors already. Meanwhile, editors who aren't as good look at PipeProjects and either A) balk at the requirements or B) try to reach the requirements but come up short. B) could happen for many reasons. Maybe they just can't drum up support, or they're not great at parsing and applying all of the rules for PipeProjects, or maybe they just aren't the best at editing. Heck, maybe the problem isn't even " drum up support", it's "attempting to drum up support and get consistent enough edits requires a higher time commitment than they have, mobile game style". Because of A) or B), projects which could really benefit from a discord thread or a dedicated wiki page from the jump, because the jump is the hardest point of any project, won't get those things. And if people don't even attempt to start because they do not see or cannot attain a route that leads to a PipeProject, while established collaborators keep doing what they already did without the advantages of PipeProjects by using PipeProjects, then we're worse off with PipeProjects than we are without them. I'm not going to "Per everyone", since I've typed for long enough but I think the opposition is pretty solid here.

Comments (PipeProjects)

I am very interested in this, but I want to ask: is the name "PipeProjects" an integral part of the proposal? I think it could be a good idea to come up with a new name, both to make it more obvious what its role is, and to avoid having to reuse the now-deprecated PipeProject: namespace. — eviemaybe (talk) 16:49, May 16, 2026 (UTC)

We personally like the "PipeProjects" name, but we can understand the concerns of rebooting an archived namespace like that. Maybe everything currently on it could be moved to some bespoke archival namespace? OldPipeProject or something, though we're open to pitches on that. ~Camwoodstock ( talk ☯ contribs ) 18:13, May 16, 2026 (UTC)

A new name to not touch the old deprecated PipeProject namespace sounds like a really good idea, but I don't have any name ideas. Camwoodstock's idea of just moving the old namespace seems like a solution that could work, but I'm not sure if that is the best idea. --Spencer PK (talk) 18:48, May 16, 2026 (UTC)

I didn't have any specific alternatives in mind, but I do like the alliteration aspect of the current name. There aren't many pages in the namespace to begin with, which is why I think reusing the namespace would be alright. B700465189a9 (talk) 20:57, May 16, 2026 (UTC)

Regarding the creation by proposal, would a new header be placed on this page for these PipeProject creation proposals? --Illuminoid (talk) 17:31, May 16, 2026 (UTC)

In general, I think that the current sectioning of proposals is more confusing than helpful, but under the current structure, I would say that the project creation proposals should be organized under "Additions." B700465189a9 (talk) 20:57, May 16, 2026 (UTC)

Since they can go under Additions, can large proposals incorporate a PipeProject if needed? --Illuminoid (talk) 21:48, May 16, 2026 (UTC)

I would recommend that dedicated proposals to create projects for existing efforts are given, but if needed, other proposals under the section would be able to include the creation of a project. B700465189a9 (talk) 12:51, May 18, 2026 (UTC)

"Proposals should focus on whether projects will be worked on by many editors". If you need people to already want to make edits relating to the project in order to propose the project, then you already have supporters for the proposal. I feel like this will cause the proposal establishing a Pipe Project to just be a formality, and then we're wasting time waiting for proposals to pass. Time where the idea driving the PipeProject is losing momentum as it waits for approval. I really don't think a PipeProject should require a proposal short of it guaranteeing a corresponding discord thread/channel. Salmancer (talk) 21:05, May 22, 2026 (UTC)

Projects don't need approval to exist, as indicated by the several successful projects that already exist on the wiki. The kind of project that would lose momentum as a result of PipeProject approval being sought is not the kind of project covered by the scope of this proposal. B700465189a9 (talk) 20:12, May 23, 2026 (UTC)

Not in love with this proposal

Okay, so the reason I didn't comment earlier was that I didn't want to be the mean old editor who shoots down ideas and wants to stick with status quo as much as possible and I was like, okay, I don't support this really but then again, maybe give it a chance. But then I actually read the proposal and the more I see these provisions the more I dislike them.

Some of these particularly stand out

• Specifically, PipeProject pages will provide the following sections in order: [list]

This is already a bad sign. This puts up a significant barrier of entry that shouldn't have to be there. The requirement that editors comb through proposals and keep up with the current ones, decide which proposals are relevant to the PipeProject, which ones are no longer needed because it was overturned, needs active engaged editors which most will not do or want to bother doing. It's not sustainable. One can say it's not necessarily the responsibility of the PipeProject creator to keep up and others can fill in, but this is the expectation being put in place for possibly interested editors and it can and it will repel newer editors. In most cases, new editors that do want to join will simply leave their name there. The final part requiring a list of editors will either have a lot of no longer active editors or will also have to be actively kept up to date on who's still there on a project which further compounds the issues of long term prospects of PipeProjects. Either way, since anyone can simply leave their name there without significantly contributing to the pages, and most will, the amount of editors between 4 and 40 editors is practically meaningless IMO.

• PipeProjects will be created by proposal rather than the supporter-based process currently indicated by the PipeProjects page.

Very bad idea. There shouldn't be a weekslong process to vet a PipeProject. Users should be able to create PipeProject pages and then editors should be able to judge if this sort of thing is worth following or not. If one thinks this will lead to abuse of the namespace, I will point to Marioboards[1] Wiki Collaborations where anyone can create an account and basically create a new thread on whatever Wiki project needs to be brought attention to. This lower barrier of entry has not led to low quality threads. Also see point above, where there is a remarkable contrast in requirements of creating a PipeProject versus creating a thread in the forums. I am not advocating users create a Marioboards account. Most newer edits have signaled no interest in creating new accounts, much less posting in a largely deprecated community space. However, I just am illustrating this contrast.

• Starting a year after the creation of a project, if editors determine that the project is not active enough to continue, the project may be considered closed for inactivity.

How is this determined? Are users in Project Music editing a couple sentences in Slow and Steady considered active members or not? Should something like Project Music ever be retired because this project is effectively going to be unfinished for decades? This is another layer of maintenance that's practically avoided when it used to be Wiki Collaborations from Marioboards handling all these projects. When projects fall inactive, they sink to the bottom. If there is renewed interest, new posts will pop up. There doesn't need to be community vetting whenever something is worth maintaining or not.

• As an optional addendum to the restoration of PipeProjects, I recommend that a forum channel be created in the affiliated Discord server

MarioWiki Discord is straightforward to navigate and its sort of minimalistic channel count is a design I do enjoy over other servers that have 20 different channels for me to forget where a discussion has taken place. I'm not saying PipeProjects will lead to a lot of channels being created but I also do not want to invite the possibility there will be a maze of threads and channels from creation of a PipeProject. The provisions are not clear if that'll be the case, but even in the best case scenario where only one will be created, why is this different from #mariowiki or #wiki-editing (the second channel is already fairly redundant)? This looks just more like #mariowiki-2. "where each post in the channel corresponds to an open PipeProject" -> What does this even mean? Do you have to be a PipeProject member to partake in this? If not, what's the point?

I don't think PipeProjects will take off with this sort of design. There will be certainly interest when it's new, but once the novelty wears off, I don't see how the trajectory will change. The most successful ones are going to be far and few in between. The proposal does not seem to address reasons for PipeProjects getting mothballed, maybe there was an assumption that with a bigger editor base today there will be renewed activity feasible for PipeProjects; nor are there design choices being made to alleviate the original problems. Another reason for my skepticism is that we can't even coordinate users to expand parts of the wiki that needs expansion such as with Mario Strikers Battle League costume pictures that STILL don't have basic images or Mario + Rabbids (for the longest time, it didn't even have a basic gameplay section). If we can't even coordinate on basic aspects of a wiki, what will a PipeProject do? Be a name in a long list? Have a userbox in a userpage?

I'd like to be proven wrong, maybe this will take off. But some of these provisions are very unwelcome to me and I'd at least rather trim some of these, which will probably require another proposal, probably (to add to the ballooning amounts of proposals over the years which I think has led to the notion that these PipeProjects require literal wiki historians to assist in their creation and maintenance), and I believe will detract from the aims of PipeProjects. I really want to see how this thing will pan out 5 years from now but I have a strong suspicion most of the ~20 (if not more after the time of this post) support voters won't be active and won't see these cumbersome PipeProject pages risking falling to the wayside again. It's me, Mario! (Talk / Stalk) 21:20, May 22, 2026 (UTC)

@Ahemtoday While I understand your concerns, the entire reason for PipeProjects to exist is so projects DON'T have to be coordinated offsite. A Discord channel existing for it is for brief discussions that would be impractical to have in a talk page or a forum thread, as is the Discord's job already, and any information should be mirrored and logged onto the PipeProject itself (as per Roserade's comment). — eviemaybe (talk) 14:58, May 23, 2026 (UTC)

If the point is to not use Discord for the coordination, then Discord shouldn't be used in the coordination, lest the point be defeated. Logging the Discord conversations would help I guess but it's still excluding certain users from actually taking part in those discussions, which is the whole thing this is supposedly trying to avoid. And if you do want to use the Discord to collaborate, you can just do that already without the need for a PipeProject, as I said in my vote. Hewer (talk · contributions · edit count) 23:53, May 23, 2026 (UTC)

Changes

None at the moment.

Miscellaneous

None at the moment.