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.
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
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}}.
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.
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.
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.
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.
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.
No proposal can overturn the decision of a previous proposal that is less than 4 weeks (28 days) old.
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.
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.
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.
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.
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.
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.
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.
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.
Proposals cannot be made about promotions and demotions. Users can only be promoted and demoted by the will of the administration.
No joke proposals. Proposals are serious wiki matters and should be handled professionally. Joke proposals will be deleted on sight.
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 30, 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".
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.
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}}.
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:
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.
The talk page proposal must pertain to the article it is posted on.
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
Create a Rewrite-remove template (discuss) Deadline: May 30, 2024, 23:59 GMT
Decide whether to redesign the Main Page (discuss) Deadline: June 1, 2024, 23:59 GMT
Merge Black Shy Guy and White Shy Guy with Shy Guy, make articles for different Shy Guy colors, or delete the aforementioned pages (discuss) Deadline: November 20, 2017, 11:59:59 PM GMT
Writing guidelines
None at the moment.
New features
Create a template for proposer and deadline parameters
Yet another measure intended to improve how proposals are added to pages. You can find the details here. Basically, my proposal is that we change the parameters for the "Proposer:" and "Deadline:" parameters from hardcoding into a template. This will also (quite obviously) mean that previous archives must be temporarily unprotected to enforce these changes. Proposals like these have received near-unanimous support in the past; we have allofthese, to name a few, so how does this fare?
Time Turner (talk) Why? This just seems like it unnecessarily complicates the whole process. It's perfectly readable as-is and doesn't take up a notable amount of space.
MrConcreteDonkey (talk) - Per Time Turner. This seems to be trying to solve a problem that doesn't exist.
Doc von Schmeltwick (talk) Templates are annoying to use as-is, and what I saw when I viewed the source of that example didn't make me particularly welcoming of this idea. It's just easier to do it the way we've been doing it.
Comments
@MrConcreteDonkey: The problem is that I have seen countless poorly formatted proposer/deadline parameters. (T|C) 17:30, 7 November 2017 (EST)
I haven't noticed anything like that, and even still it's much less hassle to just fix them separately, rather than editing every proposal in every archive.
MrConcreteDonkey 17:39, 7 November 2017 (EST)
Your argument is still flawed; allofthese, to name a few. (T|C) 17:52, 7 November 2017 (EST)
But this doesn't make things any more convenient, and it doesn't provide any added insight for future readers. How is this better than manually inputting it? Hello, I'm Time Turner. 18:24, 7 November 2017 (EST)
It's been fixed. (T|C) 18:44, 7 November 2017 (EST)
You've only added the list from your most recent comment to the proposal, and haven't addressed our concerns. How is introducing more complicated formatting going to combat poor formatting?
MrConcreteDonkey 19:46, 7 November 2017 (EST)
Removals
None at the moment.
Changes
Make "Bestiary" its own namespace
Sure, we have a namespace for galleries, but I don't see why we can't do the same for bestiaries. It's the same kind of "special" article that I would define galleries as as well. Therefore, I propose that we rename every instance of [XX] bestiary to Bestiary:[XX].
Proposer:Toadette the Achiever (talk) Deadline:October 26, 2017, 23:59 GMT Extended to November 2, 2017, 23:59 GMT Extended to November 9, 2017, 23:59 GMT
Camwood777 (talk) - Just because we've got fewer bestiaries than galleries doesn't really give much an excuse. This helps keep the wiki more organized than it would be, and that's more than a good enough reason IMO.
Oppose
Tucayo (talk) - For galleries it made sense because most major articles had one (there are currently 319); for bestiaries, I don't see the point at all. There are 12 proper bestiaries, I don't think this warrants a namespace by any means.
Time Turner (talk) Per Tucayo. I also don't see the benefit of this; it seems like more hassle then it's worth for little payoff when considering the few bestiaries on the page.
Ghost Jam (talk) Per all. I see what's trying to be done here, but it seems overly fiddly considering what is being effected, making this extra work for little reward.
I might just be a bit dumb, but I don't fully understand what this means or what the difference is. Could you give an example?-- 12:15, 20 October 2017 (EDT)
I can only see one problem with this. On every enemy page where the enemy template is placed, transcluding its info from the bestiary page, they look like this:
The bolded part is where we're going to get into some issues. It'll be a simple fix, but we'd have to change the link for EVERY page with an enemy template.-- 12:54, 20 October 2017 (EDT)
Sounds like bot work. 12:56, 20 October 2017 (EDT)
Could we keep the current names as redirects until all of the transclusions are fixed?
@Ultimate Mr. L: Isn't that a standard measure? @Alex95: That was my exact plan for fixing those pages. (T|C) 17:37, 20 October 2017 (EDT)
@Tucayo: "There's too little" is not an argument in and of itself. It's so that normal readers don't get confused into thinking it's an actual article.(T|C) 18:00, 23 October 2017 (EDT)
They are articles, though?? What makes them any different from quote pages, lists of badges, recipes, assist trophies, etc.? Bold + italics doesn't make it true. --™The 'Shroom 22:01, 23 October 2017 (EDT)
Those are actual list articles. Bestiaries are not technically list articles; they are rather pages that are there to have individual sections be transcluded onto actual articles. (T|C) 22:07, 23 October 2017 (EDT)
But they are still articles by themselves. I truly fail to see the point here. --™The 'Shroom 22:09, 23 October 2017 (EDT)
Again, why do you think that they're actual articles? They are not meant to be. (T|C) 08:25, 24 October 2017 (EDT)
If we gonna have them as separate namespaces I honestly think the category should expand to all list articles since they are the very similar to bestiaries. I honestly think having a separate namespace for just 12 pages for something very specific is inconsistent and unprofessional. NSY (talk)
@NSY: Again, bestiaries ARE NOT technically list articles; they are relevant sections of a page transcluded onto other articles, and having too few does not make too much of a difference. Also, could you please elaborate on the "inconsistency" argument? I understand it less so than Tucayo's arguments. (T|C) 15:10, 24 October 2017 (EDT)
Well according to dictionary.com a list is defined as "a series of names or other items written or printed together in a meaningful grouping or sequence so as to constitute a record". Pretty certain an article that has a record of every enemy and their stats falls under that. It's inconsistent because these would the only list articles that got their own namespace, what about the articles listing all the mini games in a Mario Party game, would they also get their own namespace. NSY (talk)
No, because that's an actual list:
Balloon Burst
Bombs Away
Crazy Cutter
Where as the bestiaries are tables:
Name
Location
HP
Items
Bowser
Castle
100
Key
Goomba
Plains
3
Mushroom
Koopa Troopa
Mountains
12
N/A
We don't list out the enemies on a bestiary like we do for every single list on this site. The lists are spilt up into categories, like the Species list, and they only have a name that links to it's main article, ONLY. Nothing else about that link exists on the page.-- 17:32, 26 October 2017 (EDT)
However, there are some "list" articles such as List of enemy formations in Paper Mario that are tables, so the lists are not always simply just a name that links to its main article. I agree that bestiaries are like list articles. --TheFlameChomp (talk) 17:36, 26 October 2017 (EDT)
Didn't know that existed. Is that article necessary? If so, seems like that should be integrated into the Paper Mario bestiary.-- 17:40, 26 October 2017 (EDT)
I feel that there is enough information for it to remain separate (a proposal to merge it could be created though). Even if that and the Thousand-Year Door version were merged with their bestiaries, there are still other list articles that are more than just simply names (see Category:Lists for more examples). --TheFlameChomp (talk) 17:55, 26 October 2017 (EDT)
There is also List of Sammer Guys. The only reason why it is kept separate from Super Paper Mario bestiary is that it is a list of Sammer Guys fought in an optional thing (though the first 20 are required) and they are too similar to each other. As for another this bestiaries are, they are compendiums which is "a collection of concise but detailed information about a particular subject, especially in a book or other publication(not really relevant to these bestiaries, but I am quoting this word for word)" -- definition found by searching compendiums on Bing. The list of enemy formations and others listed here may be the only exceptions, though.
Okay, this just doesn't make any sense at all. How and why in the world would we make this thing its own namespace if there are only twelve of it on the market right now? I don't get it. Lcrossmk8 (talk) 17:49, 27 October 2017 (EDT)
Because it's not really an article. Its main purpose is infoboxes to transclude onto articles. Because it is more than just an article, I feel it warrants its own namespace. It doesn't matter how few of them there are.
Use Lists for the Power Moons instead of Galleries
Porplemontage has indicated that for the Power Moons on the Kingdoms pages, we should use a GALLERY of images relating to the position of the moon, along with the name that links to either a TABLE, or to individual articles, which another proposal will be dealing with. I firmly believe we should use a LIST instead of these galleries, and here's why:
Easier to scroll through on mobile devices and desktop.
Far less vertical space take up on the page, especially with kingdoms with 50-100 moons.
On mobile the entire gallery is one column.
The human eye only needs to move up and down the list
The galleries require looking all over the screen and can disorient.
Many readers will come for help with finding power moons. The list tells them the name and a short description, and if they need more they click the link for the full thing.
The galleries have no way of giving a short description about the moon, and can lead readers to jumping all over the site if they are obtaining info moon by moon.
Having a single page open and being able to look back at it when needed is a huge help and time saver.
Baby Luigi (talk) Having a redundant list on the main body article of, say, Cascade Kingdom is pointless (when things are more easily summed up with Header+Main template+Small paragraph explaining the moon count and other criteria) and unnecessary padding to the article when the information users are looking for is best explained in the list pages itself. The reason we even resorted to using tables in the first place is because some of the moons objectives are short enough to fit in there; we don't need a summary of a summary. Keep the listicle in the actual list article itself, and leave the worse, less useful, less informative list out of the main one. Another point I like to add is that the list also adds a ridiculous amount of redundant links that ALL lead to the main article: we need only one link and that's where the Main template comes in handy. If people REALLY wanted to search for a specific moon, that's why we have Ctrl + F in the first place. My position is to delete the small listings altogether and leave only a header + main template + small paragraph.
The purpose of this is to determine which way is better for displaying the moons on the kingdom page. Whether they link to a table or article, there will be far more information on the linked page, including the images AND an in-depth description/walkthrough type thing for the power moon. The list will just take up far less space and provide an easy overview for readers.-- 15:33, 3 November 2017 (EDT)
I was going through your arguments, and decided to put my thoughts to them.
Easier to scroll through on mobile devices and desktop.
Not by very much. And if you think about the about of time a section loads (at least on a 3DS (I having the 2DS)), not going to be much difference anyway. Galleries on mobile devices like Nintendo 3DS family in general take long to load, but they usually remain black if there is too many.
Far less vertical space take up on the page, especially with kingdoms with 50-100 moons.
I compared your mockup on Metro Kingdom layout (81 moons), and your talking about a whole length of the scroll bar on those pages, which is not a lot.
On mobile the entire gallery is one column.
On which mobile? I use a 2DS, and I don't remember seeing only 1. But that may be due to me using desktop on my 2DS. But, I checked on a desktop mobile view and I only saw one less image per column than in desktop.
The human eye only needs to move up and down the list
I hear that humans like looking at better looking things. But, it is also something to not overdue.
The galleries require looking all over the screen and can disorient.
There is still order in galleries. One can easily look at the system and find the one they are looking for.
Many readers will come for help with finding power moons. The list tells them the name and a short description, and if they need more they click the link for the full thing.
Actually, it's a little quicker finding the moon with a gallery than a list. With a list, readers are going to go to the general area and find it. With galleries, they do the exact same thing. The only difference is that it is found quicker due to there being length. Even in a 1 per column, there are less of the others when this option is done per screen.
The galleries have no way of giving a short description about the moon, and can lead readers to jumping all over the site if they are obtaining info moon by moon.
Just the moon names may be all they are looking for. I don't know how Talkatoo works exactly due to not having the game. Even still, we should provide the info. But, if they're not looking for the name, they will most likely not go to the kingdom page, no matter if the moons stay in another article or if they all become separated, but instead use the search bar to do it.
Having a single page open and being able to look back at it when needed is a huge help and time saver.
We already have another page for that. It can even be convinced to keep it even if all are given articles.
Overall, I am not for having them as lists due reasons above. Yoshi the SSM (talk) 15:49, 3 November 2017 (EDT)
When I refer to mobile, I am talking about phones. If you're playing the game, it's less likely you have a computer/laptop open next to you looking at the wiki, and more likely you are on a phone. Talkatoo works by only revealing the name of the power moon, not the location, and he only gives you three at a time. If you only want the names to figure it out for yourself, you're fresh out of look with the galleries because you can't avoid seeing the picture. With list it's easier to not read the description. The list is also better suited as it's the exact same way the game itself displays the power moons, as a big numbered list with the names and a minimap to the side with icons indicating the positon on the map of each moon.-- 15:58, 3 November 2017 (EDT)
Oh, a phone. But, not everyone has a phone with the ability to look up stuff. You mention that it is hard not to see the image if it is galleries. There are times when galleries don't actually show the picture, but this seems to only happen if there's either low-broadband or takes a long time to load in general. And even if there is a picture, that picture can help them find the moon, but only if the person looking at the picture can tell where it is. They say a picture is worth a thousand words. Compared to descriptions, I have no idea. As for the last point, I don't know how to say something against it and still be in legal grounds. What I do know is that in-game, it shows a picture of the location if you found it. Is there a way to replicate that on the wiki? Or would that be too much? (both questions are only relevant if this passes.) (Scratch that point. I don't think there is especially for long lists. And it would be too much if we found a way to do it.) As of right now, the gallery seem to do the same thing, except in a different way. Yoshi the SSM (talk) 16:20, 3 November 2017 (EDT)
I mentioned the use of a map to Steve but I didn't really understand his response so I didn't pursue it. Now, be reasonable, you're not looking up the power moons for Super Mario Odyssey if you don't have a switch or plan to get one, that information is useless, and if you have that kind of money, you have a smart phone, even if it's low end. A smart phone is a necessity for life at this point, not because of addiction or obsession, but because of work and family, especially work! Anyways, you would want to avoid the picture because the moment you see it, you'd recognize where that is, and you lose all the fun of working out where it is based on the name. I know we don't worry about spoiler's here, but it makes for a better presentation for people who need some help but don't want to be outright told where it is, and for those that do, we have that information too. Also keep in mind that there are 103 moons for Mushroom Kingdom, a page that has existed on the wiki since 2011 and serves a purpose for multiple games in the franchise. It would be completely overrun if the gallery were applied to it.-- 16:35, 3 November 2017 (EDT)
Galleries have visual aspects. This means that people generally find them more attracted. Lists usually have things pretty close to each other. The rest Porplemontage said for me. As for the last point, Mushroom Kingdom doesn't have either. But, it doesn't have a gallery either. But, if you're still not convinced, Porplemontage also mentions that have lists for longer articles. With this proposal, it removes the possibilities of galleries instead of list no matter what, even on shorter articles. Yoshi the SSM (talk) 17:00, 3 November 2017 (EDT)
That's not how this works. This proposal is only for the power moon lists/galleries on the kingdom pages. The ruling wouldn't effect other situations.-- 17:02, 3 November 2017 (EDT)
That's your argument against what I put? Something I already know? If this passes, is guarantees lists for those articles. Since it is support or oppose, the oppose option doesn't necessary mean that we will stick with galleries for all of the articles that are going to be affected. It means that we won't stick with the lists for all of the articles that are going to be affected.
As for the point that I didn't cover in my previous comment, you explained it almost exactly as it is, but sometimes standards aren't always what some people do. But, it's hard to know due to preferences of others. So, generally speaking suits well. Yoshi the SSM (talk) 17:21, 3 November 2017 (EDT)
I misunderstood what you meant. It sounded like you were suggesting that every article would have galleries replaced with lists, not just the kingdoms. My mistake.-- 17:27, 3 November 2017 (EDT)
Why is there no "use tables" option in this proposal? That's the option I'd want to vote for. Ray Trace(T|C) 13:29, 6 November 2017 (EST)
Because they take up far too much space, even more than the galleries would, and are really not mobile friendly at all. Plus, three pages currently already link to a separate page when a table exists. Another proposal will be made soon to figure out how to handle articles for power moons, and I believe the default option is to link to a table.-- 14:23, 6 November 2017 (EST)
After looking through this again and understanding where you're going with this, why do we even need a redundant list in the main body Cascade Kingdom article itself? Just delete the list and let the List of Cascade Kingdom Moon article handle all of the work of describing the details of each Power Moon. Ray Trace(T|C) 14:42, 6 November 2017 (EST)
Because we have to wait for the other proposal to go through first. We don't know if the List of Cascade Kingdom Moon article will stay or not. If the decision is to make an article for every power moon, which I now support, then that page will be deleted. The list on the kingdom page itself will not have an in-depth description of the moons, keeping it simple, because the in-depth part will be on the individual pages.-- 15:03, 6 November 2017 (EST)
Shouldn't you wait for the proposal to go through before starting another proposal about this matter first? Also, I still don't think a summary is necessary, considering some moons can be explained in only a few sentences, which is why we're even using the table format in the first place rather than giving them separate articles. Ray Trace(T|C) 19:55, 6 November 2017 (EST)
One thing that confuses me: the way this proposal is worded doesn't say whether the gallery/list is its own page or part of the main page, but the way you were talking would imply that a gallery would have to be separate while a list would have to be part of the main article, which isn't true at all. Doc von Schmeltwick (talk) 17:12, 7 November 2017 (EST)
Miscellaneous
Make indenting comments during discussions an official rule
You know, when I was just discussing with my good friend Black Lightning when he reminded me to indent my comments, he told me that indenting comments during discussions was an unwritten rule that the wiki abided by. I started to think, why not make this an official rule? So that's the point of this proposal, why not make indenting comments during talk page discussions an official rule? The rule will state that all participants in a talk-page discussion must indent their comments, but after around five to seven colons have been used to indent comments, the bar will reset to zero, and the cycle goes on and on until the discussion ends. This would be a great rule to increase the efficiency and effectiveness of all talk-page discussions. However, unlike most rules, there will be no punishment for violating this rule, as it's more of an official guideline than an official rule, although very occasional reminders will be given. The official rule part is to make it so that all autoconfirmed users do it regularly and get in the habit of indenting their comments early on in their work on the wiki. Proposer: Lcrossmk8 (talk) Deadline: November 11, 2017, 23:59 GMT
Ultimate Mr. L (talk) 1) I strongly disagree with the cycle resetting to zero. It would be better if it just stopped and stayed at seven. 2) It wouldn't really increase the efficiency of talk pages since pretty much everybody follows it anyway. You can't solve a problem that isn't there. If it ain't broke, don't fix it. 3) "Good friend" is really stretching it. "Acquaintance" maybe. Nothing personal, but, as my page says, I don't do internet friends.
Baby Luigi (talk) No. This type of rule works best as a guideline rather than something users can get reminders and warnings for, and I think this veers almost on common sense at this point. To be frank, this isn't something major enough to be addressed, and as Ultimate Mr. L said, most people already abide by it anyway, so there's no point in making this a rule.
MrConcreteDonkey (talk) - Per all. In most instances it's just common sense, and making not following it punishable with a reminder/warning does not sound like a good idea.
THANK YOU! It FINALLY did what I wanted it to do, which is show up as a black header and not a bunch of code. Anyway, you don't need to apologize, Black Lightning. We've all got our opinions, and no one can take them away from us, even if their life depended on it. In the end, that's all that matters. And by the way, I meant "good friend" as in quite literally, "good friend". I didn't mean to use the specific Internet term. Lcrossmk8 (talk) 22:56, 4 November 2017 (EDT)
Not sure what's with that glitch, it seems to happen every other time a new proposal is made. Encountered it at my first proposal and its shown up form time to time ever since. It fixes itself as long as there some code under the section. As for the friend thing, I mean I haven't met you face-to-face and therefore do not consider you a friend. But this really isn't the place for this conversation.
Help:List#Indentation <- Closest thing to a written "rule" I can find. 22:04, 5 November 2017 (EST)
By the way, I should point out that while not indenting comments is not currently a warnable offense, it is equally minor as forgetting italics, which is as it is detailed on this user's talk page. Drawing from that user's example, if not indenting comments were to become a warnable offense at all, it should only get serious after the user in question is reminded about it more than ten or so times. (T|C) 16:28, 7 November 2017 (EST)
(T|C) 17:30, 7 November 2017 (EST)
MrConcreteDonkey 17:39, 7 November 2017 (EST)
12:15, 20 October 2017 (EDT)
TheFlameChomp (talk) 12:18, 20 October 2017 (EDT)
12:56, 20 October 2017 (EDT)
™ The 'Shroom 22:01, 23 October 2017 (EDT)
(--) 19:48, 28 October 2017 (EDT)
Yoshi the SSM (talk) 15:49, 3 November 2017 (EDT)
Yoshi the SSM (talk) 16:20, 3 November 2017 (EDT)
Ray Trace(T|C) 13:29, 6 November 2017 (EST)
Ray Trace(T|C) 14:42, 6 November 2017 (EST)
