Wikipedia talk:Perennial proposals

Meta-problem with this page

The problem is that many of the standard reasons given against the various parennial proposals are brain-dead or facetious or just plain wrong. So what do we do about THAT? For example, the a reason given against allowing only registered users to edit, is that would-be vandals will merely take 10 seconds to register. But that assumes something that is not so: it doesn't take 10 seconds to register for all articles-- to edit sprotected articles (which are those that get most vandalism from young students) it takes 4 days and the time it takes to do 10 good edits. Even before that, vandalizing non-protected articles as a name-user, you get FAR less slack for your vandalisms than you do as an IP, since at the back of every blocking-admin's mind is the idea that an IP might represent a whole library computer center of information-starved dusty children in a third world school, and THEREFORE should be given a special dispensation to be able to erase pages and and replace them with vulgarity, without consequences. So, in short, it's FAR harder to vandalise all articles as a name-user. In short, the counterargument is no good. So what is the point of having it here? SBHarris 21:39, 21 January 2012 (UTC)

Just to prove the problem, my latest edit pointing out problems with the reasoning for rejection of this idea, have been reverted. >80% of IP edits are good faith ones, says the page, and although 93% of vandal edits are IP edits, requiring registration would not stop these because the vandals could easily register. Left out is that so just as easily could all those good-faith IP editors, too-- by the same argument. This page is a graveyard of bad arguments with no refutation. Ultimately, the reasoning here is basically something like: "We don't do this particular thing, because the Sun rises in the East." Point out that this is not a logical argument and you will be reverted. Welcome to Wikipedia. SBHarris 02:28, 22 January 2012 (UTC)

Did you read the edit summary of the revert? It says These are not "Reasons for previous rejection", these are arguing for IPs to register. I don't think that's appropriate here. That's hardly rejecting additional reasoning.

I don't know about the majority of editors, but I expect proposals and responses are rather widely agreed upon, After discussion. Any moderate to extensive addition or change would require many editors weighing in on the discussion page before anything is added. Your addition was hardly insignificant, so it was reverted in due course. —EncMstr (talk) 05:32, 22 January 2012 (UTC)

You seem to assume that the reasons for rejection given here were one-and-all "widely agreed upon, after discussion." Not so. Somebody stuck in that little bit about how most vandalisms coming from IPs is irrelevent because vandal-IPs could easily register in 10 seconds. Yet the obvious counterargument that well-meaning IPs could then just as easily register (yet are being presumed for the sake of this policy to have great difficulty doing so), has been surpressed. That's it. As for Jimbo's comment, it's mere assertion without any logical or factual backing, and is made ex cathedra and if there is any argument on WP where he has defended it logically against opposition, please cite it. I do not believe it exists, but proof is upon you, since you're making the claim. So I call boloney. SBHarris 19:07, 22 January 2012 (UTC)

This is not the place to re-argue these old discussions or to add new arguments for or against any of these proposals, it is merely a record of past events for reference. You are adding new material without adding any evidence that the positions stated by you were stated in the discussions that led to the rejections of said proposals. The onus is on you to back up your position with diffs from the relevant discussions. You can't just make up your own arguments and add them retroactively to the record here. If you want to re-open an issue so that you can make these points in an actual policy discussion, use WP:WPP or write up a proposal in WP space somewhere and open an WP:RFC on it. Beeblebrox (talk) 19:14, 22 January 2012 (UTC)

I apologize, I wasn't trying to stir up trouble with this edit. Edit summaries only have so much space to explain things on, so perhaps I should have checked here and made an expended note about it here as well. The reason I reverted it, in addition to the basic reason given in my edit summary, is that my understanding of the purpose of Wikipedia:Perennial proposals is to list things that have been proposed and rejected several times, and to list reasons why they were rejected. For this reason, I don't think it's appropriate to have pros and cons listed in a neutral and balanced way (which would be different according to each editor's opinion of the proposal), as that isn't (to my understanding) the point of this page. Rather, I believe the point is to show why various proposals have failed in the past, so that editors seeking to re-propose them can gain an understanding of why they have failed in the past, so that they can (hopefully) determine if they can successfully address these issues as opposed to repeating previous discussions ad infinitum. In that way the page becomes a simple summary "This was the proposal, and here is why it failed previously" as opposed to being an overly detailed pro/con argument, essentially being a duplicate of the original RfC (or wherever the proposal was).

However, that aside, the section that the information was inserted into (Reasons for previous rejection) seemed inappropriate, as the information was not in any way a reason for a previous rejection, but was an argument supporting the proposal. If the information does belong on this page (which doesn't seem to be the case), I would strongly suggest placing it in its own section, such as Common arguments for the proposal or something along those lines. - SudoGhost 19:41, 22 January 2012 (UTC)

1. There are several separate issues here. One is the purpose of this page, which seems to be to name perennial proposals and the reasons for their rejection. But we could do better. Summaries of legal cases always have summaries of the winning arguments AND the best losing arguments (in the Supreme Court there is a minority decision, and so on). That saves everybody looking at the issue later, a lot of time. The way this page is constructed, it is one-sided. It just has things like "Jimmy Wales says that we'd rather have vandals vandalize from IP addresses" which is ridiculous given the way we coddle IP users, fearing that we're dealing with shared IPs. Truthfully, we'd rather have vandalism done by name-users if we had the choice, since it makes dealing with them very specific to an individual. But you won't read about that here on this page. Why not? You read only the rejection reasons, bad though they may be, but not the reasons for the proposed change, good though they may have been. What is the point? It amounts to near-trollery. And yes, the place for questioning the format and purpose of this article IS here on the TALK page of it. Where else?
2. Then, there is the question of whether even the arguments given for rejection of the proposed change are fairly summarized from the relevent community discussions. In many cases, they are not. But how am I going to show that, without specific examples? And if I give specific examples, I open myself to the objection that this page is not the place for it. Well, it is actually the place for it, if the examples are being used to illustrate a larger problem. See the point? To establish a pattern of abuse you need data points. SBHarris 19:57, 22 January 2012 (UTC)

All words and phrases should be linked

One of the reasons given against linking all words and phrases is "This would create an unsightly sea of blue links", which is nonsense because if every word was linked then obviously the links would not be made blue to identify them. A sensible objection that seems to be missing is that human intelligence is required to identify phrase boundaries and non-literal ("piped") links (I assume that "link all words" would be an automated feature, since no one would want to physically type square brackets around every word). 86.181.173.103 (talk) 12:03, 15 March 2012 (UTC)

Not true. It would not be an automated feature, because a bot to accomplish that purpose would fall close to the category of a spell-checking bot, which is forbidden. Wikipedia:Wikilinks states that only the first instance of a word in an article should be linked, so there would be a need for distinction between linked and non-linked text. Hyperlinks can be made black like this (that "this" is a link), but that requires placement of <font color="#000000"></font> around the visible link, which is even more work. Interchangeable|talk to me 16:32, 15 March 2012 (UTC)

You seem to have the cart before the horse. If it was agreed to implement this feature then it would clearly not be "forbidden", and the rules about Wikilinks would clearly need to be rewritten in many respects. You can't simply cite existing policies as "reasons" why an idea is rejected. Those policies can always change. (Be clear that I am not supporting this proposal. I just think that the "Reasons for rejection" section is deficient.) 86.181.173.103 (talk) 18:02, 15 March 2012 (UTC)

Be bold and edit it yourself, but be aware that you might be reverted. I'm not entirely opposed to your idea, but others (especially Cluebot) might be. Interchangeable|talk to me 23:03, 15 March 2012 (UTC)

Beatles RfC

You are invited to participate in an RfC at Wikipedia talk:Requests for mediation/The Beatles on the issue of capitalising the definite article when mentioning that band's name in running prose. This long-standing dispute is the subject of an open mediation case and we are requesting your help with determining the current community consensus. Thank you for your time. For the mediators. ~ GabeMc ^{(talk|contribs)} 23:41, 22 September 2012 (UTC)

Move maintenance tags to talk pages

Re: Wikipedia:Perennial proposals#Move maintenance tags to talk pages

see also /Archive 1#Move maintenance tags to talk pages

As this has been brought to my attention again, and I notice that no action has been taken since list time I raised it, I am making some alterations so that it describes the situation better. -- PBS (talk) 14:52, 5 November 2012 (UTC)

From the edit summary "Summarize in normal format". This is not adequate in this case as it leads to text that is not a fair summary and is misleading.

"Rejection" is misleading. There has never been a rejection of this proposal just as there has never been an acceptance of it. The MOS guidance is clear that maintenance tags are to be unless they serve a dual purpose and are of direct benefit to readers (as is the case with {{unreferenced}}. The problem is that some editors create a maintenance template often on their own initiative, or after a conversation on some page or other that may involve less than half a dozen proponents can look at this entry and think that there is a consensus for creating such templates. See for example the new template {{Underlinked}} the discussion to create it involved:

• Wikipedia talk:WikiProject Wikify#No more wikify template 13 editors who discussed the mechanics of the process. AFAICT non of them discussed whether the template should appear in article space or on the article's talk page.
• There was a further discussion Wikipedia:Categories for discussion/Log/2012 September 24#Category:Articles that need to be wikified where four editors voiced an opinion (of which two were involved in the previous discussion) and it ended with the withdrawal of the proposed new category, and a statement "Alright, I'll go ahead and create the template. I'll call it {{underlinked}} ..." at 06:49, 29 September 2012
• The template {{underlinked}} was created at 07:01, 29 September 2012 and gave as its reason in the edit history the conversation at Template talk:Dead end#Proposal to re-create Template:Internal links. This thread involved two editors who had taken part in the Wikipedia talk:WikiProject Wikify and neither of them addressed the issues raised by [Wikipedia:Manual of Style/Self-references to avoid|Self-references to be avoided]].

This mean that a new template that currently resides at the top of 4388 articles was created in a discussion that involved about 15 editors (no all of whom expressed clear support for a new template), and not one of them raised the issue of placement and that such templates being placed in article space is not supported by the guidance of Self-references to be avoided.

The wording that uses "rejected" can be seen as justification for creating this template (See Template_talk:Underlinked#This template is a bad idea) so it is necessary to modify the wording to make it clear that

• Outcome: No consensus has ever been reached to implement or reject this proposal

-- PBS (talk) 12:25, 6 November 2012 (UTC)

You're right that no-one discussed where the {{underlinked}} tag should be placed, because we took it for granted that it would go at the top of the article, like every other maintenance tag. Why would this tag be the one exception to the norm? If you want to change the longstanding convention, start an RfC and we'll see where public opinion lies. Attacking one specific template, dragging the argument onto other talk pages, modifying this page to make a point and trying to alter the guidelines to fit your own narrow interpretation... it's just not the appropriate way to bring about a paradigm shift.

Also, regarding your edits to this page, WP:PEREN is not the place to raise new arguments. All it's meant to do is summarise the arguments made in previous discussions. Many of the points you've labeled as "common arguments" haven't been mentioned in any of the linked discussions, as far as I can tell. Can you provide any evidence that these points have been made and supported by others, and aren't just your own opinion? DoctorKubla (talk) 15:46, 8 November 2012 (UTC)

There is a fairly standard format used on this page, and I have to agree that WhatamIdoing's version matches it. I'm not going to comment on the content of the issue, at this time. I will add diffs below, so that newcomers can understand what y'all are talking about without having to research it themselves, though. —Quiddity (talk) 19:43, 8 November 2012 (UTC)

Options:

• the wording as it was until 1 week ago
• PBS's suggested wording/format
• WhatamIdoing's suggested wording/format

That's what they/we're discussing (for the benefit of newcomers). —Quiddity (talk) 19:43, 8 November 2012 (UTC)

There is no reason why the version I have edited in can not be edited further but it is misleading to imply that this proposal has been rejected (as it would be to suggest that it has been accepted). -- PBS (talk) 20:10, 8 November 2012 (UTC)

As an alternative I have removed the arguments for and against leaving the section like this. This allows readers of this page to follow the links to the listed debates to read the arguments themselves and come to their own conclusions. -- PBS (talk) 20:17, 8 November 2012 (UTC)

I don't think that's helpful, and after thinking about it for a few days, I've reverted it.

If there really is no consensus either way, then the item shouldn't be on this page. See the first sentence: "This is a list of things that are frequently proposed on Wikipedia, and have been rejected by the community several times in the past". WhatamIdoing (talk) 19:32, 12 November 2012 (UTC)

Then I will delete it, because the wording to which you have reverted is not representative of the conversations. If it is going to remain on this page, then I think the page must reflect the fact that there is no consensus on this. I think it would be better if the whole page were to be changed to reflect the fact that "This is a list of things that have been proposed on Wikipedia several times in the past" (see also /Archive 1#Standard format change) -- PBS (talk) 12:27, 20 November 2012 (UTC)

The topic belongs on this page. I've reverted your second deletion of it.

*If you dispute the way the topic is summarized, then continue to edit it, or suggest changes here.

*If you dispute the way this entire page is presented, then work on fixing that, as a separate thread/endeavour.

Simply deleting it, is NOT the way forward. —Quiddity (talk) 23:43, 20 November 2012 (UTC)

I am not sure how many points of view are represented here. I am happy to have it included on this page providing the summary states that there is no consensus either way. But how do we square that with WhatamIdoing's "If there really is no consensus either way, then the item shouldn't be on this page."? If you think there was ever a consensus on this then please link to the best example of a debate were a consensus exists. -- PBS (talk) 09:58, 21 November 2012 (UTC)

For the proposal of "Move all maintenance tags to talk pages" - there is strong (near-unanimous) consensus against.

For the proposal of "Move some maintenance tags to talk pages" - there is strong disagreement amongst the supporters, as to which tags would be included, or whether some tags should be moved to the bottom of the articles instead, or to a new meta-page, or just tweaked in size/style/wording. Some even suggest moving items such as {{Todo}} from the talkpage to the articlepage (or at least adding an article-tag that links to the Todo list).

Everybody agrees that tags in general are often-overused. A majority of editors agree that they benefit readers by signalling/reminding of Wikipedia's radical transparency, and of specific problems in specific articles/sections. Tags encourage readers to think (about the work that goes into an encyclopedia), and also increases the probability of them becoming editors (which we sorely need).

For the page as a whole: Almost every section summarizes an issue which has a significant number of supporters/critics, or a high frequency of suggestion. That's the whole point of this page. There is still a "consensus" against the proposals, at this time. - If consensus were split, then the arguments would be continuous and we would all be forced to compromise with each other in some way (for whatever the issue was).

Also: The November 2009 discussion isn't directly about moving tags anywhere. It's about improving the tags, by tweaking the wording to link to and encourage usage of talkpages. Which was done. —Quiddity (talk) 23:01, 21 November 2012 (UTC)

• "Move all maintenance tags to talk pages" That depends on how you define "maintenance tags". Where do you think that has been proposed and rejectd?
• "There is still a "consensus" against the proposals, at this time." Which proposal?
• The wording says "Reasons for previous rejection" (of all proposals listed and that includes only some for specific types of maintenance templates).

The section then goes on to list "Reasons for previous rejection" while not including reasons for acceptance. This section does not represent a fair summary of the debates that have taken place. -- PBS (talk) 17:03, 27 November 2012 (UTC)

"while not including reasons for acceptance" - The "proposal" section lists the reasons for acceptance - That's the format used throughout this page. If you think it is missing critical points, then add them (in as condensed and neutral a fashion as possible). Here, I'll help:

The current proposal lists:

• "...reduce self-references to Wikipedia, reduce clutter, and reserve article space for information about the subject." - 3 points

Your suggested overhaul from earlier, lists these points:

• 1) "…Self-references…" 2) "Article space is for information on the subject", and "moving editor to editor messages … to the talk page" 3) "…clutter article space…" - 3 points!!!!

Implementation difficulty was never a core objection, so it's not necessary to even mention that. (Change is always complicated, and ALL the proposals on this page would be slightly-somewhat difficult to implement. If something is worth it, then we manage to find a way.)

Now, what points are we not mentioning in the summary, that don't fall into those 3 basic concepts? —Quiddity (talk) 22:23, 27 November 2012 (UTC)

There are retorts to the points made in the paragraph "Reasons for previous rejection" (see for example here). However that is not the major issue which is that as there was no consensus, the bold phrase "Reasons for previous rejection" is incorrect and misleading. -- PBS (talk) 10:59, 28 November 2012 (UTC)

The last discussion was over 2 years ago. If you really believe that there was "no consensus" against the proposal, try bringing it up again.

See how many editors agree in general, and on what points they agree, and on which specific tags they agree are only useful to people who are already editors.

You'll need to present a clear case on how to distinguish which tags are which. (A {{wikify}} tag is what converted me into a regular editor).

Before posting, it might help if you re-read the past discussions, with those problems in mind. —Quiddity (talk) 20:24, 28 November 2012 (UTC)

Your proposal seems to be putting putting the cart before the horse (because starting such a conversation to prove a no consensus result could be seen as pointy). Do you think that the last conversation or any of the others produced a consensus one way or the other? Unless you can show that there is a consensus for rejection then either the wording of the section needs to be modified to indicate that there is no consensus or the section needs to be removed. Perhaps the place to start is: of the conversations listed which one do you think clearly shows a consensus for rejecting the proposal? -- PBS (talk) 17:32, 2 December 2012 (UTC)

Re-reading through the last 5 threads linked in the section... I think the editors who try to simplify the issue, all agree that something needs to be changed (but very few of them agree on what, or how). I think the editors who see all the perspectives, agree that it is more complicated than that. Yes, drive-by-taggers are (sometimes, but not often, and definitely not always) annoying-more-than-helpful. Yes, maintenance tags tend to linger for too long. Yes, not all readers are going to become editors, and us imploring them to do so is unnecessary. Yes, the radical transparency of "announcing all our flaws" improves our reputation and trustability in some ways, and decreases it in other ways. Yes, it is complicated. Yes, you should find someone else to discuss this with, because I'm feeling like this is a waste of time that could be better spent editing the damn articles and fixing the flaws that the maintenance tags are trying to draw our attention to.

Plus, there is consensus in this thread, that the proposal DOES belong on this page. It's also frequently mentioned in most of the past discussions as something that IS, or SHOULD BE listed on this page. As someone else said, it's time to Drop the stick. –Quiddity (talk) 03:34, 3 December 2012 (UTC)

I do not think that Drop the stick is an appropriate link and it is not helpful in trying to reach a consensus.

I have no objection to it being on this page but the presentation must not be biased (which including the bold wording "Reasons for previous rejection" makes it so), or it ought to be removed. As to your assertion that there is a consensus for it to remain on this page (in the current format). How do you draw that inference from the four people who have expressed an opinion two of whom (for different reasons) have suggested that it can be deleted, the other did not object to a change in the wording. AFAICT we have a Mexican stand-off. I want the phrase changed, but failing that it should be deleted, WhatamIdoing wants the wording to remain, but failing that it should be deleted, you want the wording to remain and the section not to be deleted. You seem to accept from you last posting that the proposal has not been rejected so why not agree with a wording such as this:

Move maintenance tags to talk pages

• Proposal: Move maintenance tags such as {{cleanup}}, {{orphan}},and {{POV-check}} from the head of article pages to the article talk pages.

• Previous discussions: Sept 2010, Jan 2009, Nov 2009, Oct 2008, December 2008, March 2008, October 2007

• Outcome: No consensus has ever been reached to implement or reject this proposal

If that wording is not acceptable to you then please explain why so that we can work towards a consensus version that does not include the misleading and inaccurate phrase "reasons for rejection". perhaps we could alter the outcome to include your wording:

• Outcome: No consensus has been reached because while all agree that something needs to be changed, very few of them agree on what, or how.

-- PBS (talk) 10:45, 3 December 2012 (UTC)

There is nothing that "all agree" on, in the previous discussions of the proposal.

There is a firm split between those who demand change, and those who think the status quo is complicated but acceptable. Of those who demand change, "very few of them agree on what, or how."

If you want to create the possibility of forward-motion for this proposal, I'd suggest that you start by discovering a way to achieve some consensus amongst the supporters of change; perhaps by clearly delineating which tags would be moved to talkpages, and which deserve to remain on articlepages.

(struck out unwarranted commentary Sorry to all.) –Quiddity (talk) 21:14, 3 December 2012 (UTC)

TL;DR: The lead currently says that the proposals listed have "been rejected by the community several times" (ie. not implemented) which is true in this case, and "has been discussed before and never met consensus" which is true in this case. It has been rejected in the past, and there is no consensus. EOD. –Quiddity (talk) 21:14, 3 December 2012 (UTC)

"Rejected" and "no consensus" are not the same thing. When there is "no consensus" to move a page or to delete a page it is marked as such. That is distinct from a consensus to move or retain, or a consensus to delete or keep. As many editors are familiar with that terminology they naturally assume that if there is a "rejection" instead of "no conensus", that there must have been a consensus against a proposals. The proof of this is people linking to this section as if it proves that the community has rejected this proposal. -- PBS (talk) 08:24, 12 December 2012 (UTC)

As I said above, "If you dispute the way this entire page [ie the lead] is presented, then work on fixing that, as a separate thread/endeavour." FWIW, this page covers a variety of things (it's a collection of perennial proposals that have not been implemented), and if a language change in the lead will make that clearer, then let's discuss and tweak it. –Quiddity (talk) 03:24, 14 December 2012 (UTC)

I've seen people assert that "all" maintenance templates ought to be moved to the talk pages. Presumably they don't mean that {{fact}} and the like should be moved, but that is what they've said. I don't think it's reasonable to put forward PBS's proposal as if it were the only one.

I also think that it might be worth noting if any specific templates started out in the mainspace and then were later relegated to talkspace. I don't know the history, but {{Photo requested}} might be one such maintenance template. While the general proposal has been rejected, it's possible that specific templates have been approved. WhatamIdoing (talk) 01:01, 4 December 2012 (UTC)

The problem WhatamIdoing is there is no precise definition of what "maintenance tags/templates" means, and when you question people on this they would not usually include such things as {{fact}} which are primarily a warning to readers. What they mean by maintenance template things like this: {{new page}} (a truly awful example as it will usually be placed on a small stub) -- PBS (talk) 08:24, 12 December 2012 (UTC)

The problem, PBS, is that none of the advocates of the proposal have ever put together a comprehensive list of what "maintenance tags/templates" means. They just mention a specific example or two, and expect everyone else to understand intuitively/completely what the rest of the list of tags comprises [those that are obviously just for maintenance and deserve to be moved to the talkpage].

To repeat myself: I strongly recommend that you put together a list, of exactly which templates you/anyone is including in the proposal, for the next go-round. It's the only way the idea will get traction. WAIM's suggestion of researching/listing any specific templates that used to be in mainspace but are now placed on talkpages (ie, precedent), is also very good. –Quiddity (talk) 03:24, 14 December 2012 (UTC)

Speaking of which, whether {{Orphan}} belongs on talk or article pages is currently under discussion at Wikipedia:Templates for discussion/Log/2013_January_5#Template:Orphan_placement_discussion. WhatamIdoing (talk) 22:06, 7 January 2013 (UTC)

This is a timely heads up for User:Quiddity (in case you are not aware of the conversation and want to join in). There is a new discussion at Wikipedia:Village pump (proposals)/Archive 108#Proposal to move the Orphan tags to the talk page which is close to SNOW, and not just for {{Orphan}} but for maintenance tags in general. Once that discussion is closed it will be time to make large alterations to the wording of the section in this page under discussion. -- PBS (talk) 22:53, 8 December 2013 (UTC)

@PBS: (1) Thanks for the ping :) (2) I see consensus for change regarding the orphan tags (which I've added to), but no consensus (there's barely any mention) of changing anything regards "maintenance tags in general". This is an inch not a mile. –Quiddity (talk) 23:33, 8 December 2013 (UTC)

"Technologically unfeasible without further development."

The top of this page says

"This is a list of things that are frequently proposed on Wikipedia, and have been rejected by the community several times in the past." and "...discussed before and never met consensus."

Yet several of the perennial proposals are marked

"Reasons for previous rejection: Technologically unfeasible without further development."

This is contradictory. It could very well be that that the proposal has an overwhelming consensus in favor of it, but is also so very difficult (many, many man-years and many, many dollars) that it hasn't been implemented despite the consensus.

In the above case, the answer to someone who proposes it again should not be "Consensus can change, and some proposals which remained on this page for a long time have finally been proposed in a way which reached consensus" but rather something like "don't bother trying to reach consensus; we already have that. The problem is resources. Here is a link to a place where you can add your voice if you think that more resources should be devoted to this issue".

The developers would then be able to make intelligent tradeoffs. Something that requires a day of work and a week of testing would need less support than something that requires a week of work and a month of testing. Or the answer might very well be "we are pretty sure that this is so technologically unfeasible that no level of projected resources can make it so, but Here is a link to a place where you can add your voice. If a million of you want this, we will look at the feasibility again". --Guy Macon (talk) 07:52, 1 March 2013 (UTC)

(Sound of Crickets...) --Guy Macon (talk) 02:03, 5 March 2013 (UTC)

Broadly I agree with you, though I'd say it is a little more complex than that. IT resources come broadly in three kinds, software such as developer time, hardware such as extra processing that would need even more powerful servers at the datacentre, and user load - extra processing required of our editors or readers. It is vital to understand which of the three, or more usually what combination of the three is involved, and then put that into the context of when the request was considered. Something that would have needed several days of developer time a few years ago might well be worth reviving now as I understand we have more devs available, but if the rationale was "the benefit doesn't seem to justify the necessary month of developer time" then that isn't likely to change. Whilst any proposal that was going to require too many extra servers in the IT centre needs to be put into the context of Moore's law and be declined with a rational such as "too much server load as of 2013 - happy to reconsider in 2018". The third is the most difficult for us as one of the things that differentiates us from commercial sites is that we care equally about the editors in the slowest third world Internet cafe or dial up users on obsolete technology as we do about affluent broadband subscribers, so any proposal that would bloat the information that we send the readers along with the information they requested should get resisted as it would slow things down for all readers. In practice this didn't seem to get considered re AFT, but arguably it should have done. ϢereSpielChequers 09:33, 7 March 2013 (UTC)

Require or prefer free, online sources

Should we add a wikilink to WP:RX in this section? Many don't know it exists but it may also increase the workload over there. Should we bring it up at RX talk as well?--Canoe1967 (talk) 15:49, 2 March 2013 (UTC)

1.7 Define reliable sources; discussion

This is the statement from 1.7, "Define reliable sources":

"Reasons for previous rejection: Assessing the reliability of sources requires sound editorial judgment, not strict adherence to a list of rules. Whether a source is reliable depends on how the source relates to the material: a very weak source may be reliable for a very small claim, such as "this source was published", while a very strong source will be deemed unreliable if the claim is unrelated to the source's contents (e.g., a source about electricity being cited for information about a celebrity). Although it may be possible to define a minimum threshold below which sources are never acceptable as reference for Wikipedia content, it appears presumptuous to define all sources above that threshold as "reliable". For this reason, a universally applicable (or: policy-level) definition of reliable sources is impractical. Furthermore, strict rules about what type of source is permitted amount to instruction creep."

This reasoning seems like it's attacking a strawman. Any reasonable proposal to define a list of reliable sources would not be an activity divorced from considerations of how the sources relate to the material. It would begin with categorising material, and then listing reliable sources for each category of material. There would be no time limit to such a project (things would not have to be completed all at once), and it would easily amendable (for good reason, as Wikipedia is not a crystal ball). The stated reasons for rejection create this conception that defining reliable sources would involve simply creating a list of sources and saying that all of these are reliable, with no mention of for what they are reliable. This is absurd. Reliable sources, for good reason, are normally treated as reliable only with regards to a particular or type of claim. So, naturally, defining reliable sources in policy would involve defining them as reliable in this regard. So then, I sincerely ask, what is the proper reasoning for rejecting such a proposal?

I suspect a contradiction in any such rejection. I see it this way: We judge frequently what are reliable sources and what are not. We have to, or else we wouldn't be able to apply Wikipedia:Verifiability. So then it's agreed: We know (to some extent) what are reliable sources and what are not. So then a rejection of every guideline which defines reliable sources implicitly or explicitly supposes that merely by writing down our knowledge of reliable sources into a guideline, we commit some error. That is, we have the knowledge, and we communicate it when we reject or accept certain changes to articles, but if we communicate it in the form of a guideline, we, by some mysterious force, err. But there is nothing different about writing down our knowledge of reliable sources in a guideline compared to writing down such on an article talk page. The mystery is pure myth.

Take etymology sections. These are ubiquitous in the encyclopedia and infrequently based on nothing, but frequently based on decent but still ultimately, non-reliable sources, like etymonline.org, or much worse. Making a guideline for what are reliable sources for English etymologies would not be that hard. For example, while you don't say that the Oxford English Dictionary or Klein's Comprehensive Etymological Dictionary of the English Language is a reliable source for just any claim, it would be a good guideline to treat them as reliable sources for etymological claims. You flesh out the treatment with other reliable sources.

You proceed in defining reliable sources on a topic by topic basis. If some reliable source escapes notice at first, it can be added when it is noticed. If some previously thought reliable source is discovered by the scholarly community to be faulty or for whatever reason can no longer be considered reliable, it can be removed; and this is no fault of the Wikipedia, as we just report the state of scholarship. --Atethnekos (Discussion, Contributions) 02:10, 11 March 2013 (UTC)

Creating a reasonably comprehensive list would require listing tens of thousands of sources, and then maintaining the list as sources age or are superseded. However, on a much smaller scale, some WikiProjects make a list of general reference works that their members have found particularly useful. If you're interested in etymology, then you could talk to WP:WikiProject Linguistics about whether they'd like to produce such a list. WhatamIdoing (talk) 22:10, 19 April 2013 (UTC)

Gender identity

Any discussion on whether trying to change the gender-related rule in section 16.6 of WP:MOS should be added to this page?? Georgia guy (talk) 00:38, 31 March 2013 (UTC)

Inappropriate timeframe in which to even consider this. The Jenner media frenzy has resulted in waves of activism (both pro and con) on the issue. Village pump is awash in this stuff, and it's not at all certain what the consensus will eventually be, nor how long it will last. What looked like a stable consensus is actually turning out to have some unforeseen consequences that not everyone is okay with.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  11:57, 19 June 2015 (UTC)

Share buttons

Hi all, I'm curious as to why this is needed. Having share buttons is not related to watchlists or SuggestBot. Thanks, Ed ^{[talk] [majestic titan]} 21:43, 18 April 2013 (UTC)

I guess in my mind I thought that a "like" button would be used to create a selection of articles for personal use. This is exactly what a watchlist is. Maybe I am missing the point here, how do you see it? meshach (talk) 22:12, 18 April 2013 (UTC)

The section in question, Wikipedia:Perennial proposals#Share pages on Facebook, Twitter etc., is to do with requests that we add "a button for [service X] that allows me to post any article to [service X]". It's entirely about integration with outside Social networks. It has nothing to do with editors keeping personal lists of favourite articles. Click the links to the VillagePump and HelpDesk threads at the end of the section, to see examples. –Quiddity (talk) 01:33, 19 April 2013 (UTC)

Okay - I see now; thanks for clarifying. If you readd it I will not touch it. meshach (talk) —Preceding undated comment added 04:54, 19 April 2013 (UTC)

Yes, Quiddity said what I was thinking. Thanks to you both! :-) Ed ^{[talk] [majestic titan]} 18:03, 19 April 2013 (UTC)

Possible Resolution to Spelling Argument?

I know that Wikipedia supports the use of multiple dialects of a certain language within that language's version of the site, but the links provided by the section that mention a perennial proposal to standardize spelling in the terms of only one of these kinds of dialects provide evidence that editors dislike the current conventions because of how they might sow potential confusion among Wikipedia's readers. Could this problem be resolved by creating a template that serves up one version or another of specific words based on the dialects favored by various users when such words' placement in articles might betray such users to the fact that multiple users with differing dialectal tendencies have contributed to the content in their immediate surroundings? Such a template, possibly in the format of {{word variation picker|language-dialect1=regionalvariant1|language-dialect2=regionalvariant1|…}} (as in {{word variation picker|en-us=color|en-gb=colour}},) could work by choosing one of two or more regional variations on a word inside itself based on a user's preferences if these were to include additional language options for dialects not currently available under the MediaWiki software environment. Such new language options for the accommodation of dialects could be presented either as new options alongside the existing ones in the language-selection pop-up menu visible in general preferences or as a second pop-up menu to the right of this currently-existing one that allows users to choose a dialect that exists as part of their selected language.
Just a thought, 
RandomDSdevel (talk) 19:17, 10 May 2013 (UTC)

Templates have been suggested before, but it doesn't really simplify things - it opens up new problems, such as: imagine an English reader, looking through an article about an American color theorist (eg) - what would/should be displayed? Repeat that, for all words / combinations / contexts...

It would also greatly complicate the wikicode of any effected articles.

Hence, we've settled on MOS:ENGVAR and its subsections, as the most practical way forward. –Quiddity (talk) 02:26, 11 May 2013 (UTC)

As I attempted to explain previously, applying the suggested template message to an article would cause the page's scripts to pick from this template's values based on users' preferences, and users could alter such new settings, which could be placed within the 'Internationalization' section of user preferences' 'User Profile' tab in addition to the current language settings, from their location-based defaults if he or she chose to do. I assume that such a modification to this part of Wikipedia's interface would probably require initial consensus prior to a request for comment, but the new interface elements should settle in nicely with the current ones. After all, the 'Language' pop-up menu could just have any dialects that currently reside within each of the languages which users can currently select form it separated into an adjacent, contextual 'Dialect' pop-up whose contents would vary depending on the language selected in its neighbor. And users could always choose a 'Custom' dialect to set their own preferences if they live in a certain country but use some of its lesser-known conventions. Besides, such a template's use would, of course, be optional due to the fact that it would be a template. Personally, though, I think that it would most likely percolate throughout most of Wikipedia because of its usefulness. For example, the template's existence could be used to consolidate multiple versions of Wikipedias written in the same language but in different dialects into one Wikipedia for that language. And even though the wikicode might be a little overwhelming at first, I bet that everyone would get used to it in the end, especially since it would give templates more visibility for everyday users.

— RandomDSdevel (talk) 17:24, 21 May 2013 (UTC)

See the hatred for automatic date formatting. This proposal is equally putrid. Jc3s5h (talk) 19:39, 21 May 2013 (UTC)

Find an automatic dialect translation system (other than humorous) and we will think about it. Let me know when we can read the user's language setting through a template (I think it can be done through the API). --  Gadget850 ^talk 20:26, 21 May 2013 (UTC)

National varieties of English

There are dozens of articles that use colour and color, honour and honor, etc. Help:Using colours uses colour 44 times and color 27 times, and the spelling differences exist peacefully within the same article. They don't even argue or edit-war. Honor Guard also is an excellent example. The last time I looked at it, there were several infoboxes that used honor for a country that uses honour. I do not know how to change that. I am best at spelling and grammar. The ENGVAR issue is slowly resolving itself. Most of the colour/color articles use both varieties of spelling. My recommendation would be to get rid of the British flag/American flag on the Discussion page. Makes me cringe each time I see it because it looks like ownership. Respectfully, Tiyang (talk) 08:02, 30 June 2013 (UTC)

I'm not sure what you'e proposing. Is it to do away with ENGVAR because it's not being followed? To apply it more programmatically so that it's being used consistently? I won't common on the "flags on the discussion page" point, since I'm delivering a neutral notice about a related RfC below.

Related RfC

Anyone interested (pro or con) in what User:Tiyang said above will probably want to weigh in at WT:Manual of Style#Proposal to deprecate Template:English variant notice.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:02, 19 June 2015 (UTC)

Censor offensive images

Whilst I appreciate that wikipedia is an encyclopedia, I can understand the gripe that the inclusion of certain offensive images offer little improvement to the article in which the image has been embedded and that they may only have been posted by another editor for deliberate shock/entertainment value. Would it not be sensible to add something to that section to suggest that an editor might consider removing the image from the article if they do not feel that the image is appropriate/has no benefit to the articles content? Badanagram (talk) 20:45, 15 July 2013 (UTC)

Covered bt WP:CENSOR. --  Gadget850 ^talk 22:14, 15 July 2013 (UTC)

Additional reason for rejection of the Advertising proposal

I think the following should be added into the Advertising section: ads sometimes cause a web page to be really slow to load, and people sometimes have to wait a really long time to read the text on the page, because the large number of ads, which they did not open the page for the purpose of, contain images which take for ever to load making it impossible to scroll. Blackbombchu (talk) 03:39, 16 October 2013 (UTC)

I don't think anyone has made that argument against including advertising. Anomie⚔ 11:37, 16 October 2013 (UTC)

Include successful proposals which went nowhere?

By focusing on rejected proposals, this article misses out on perennials which are approved by the community but which still produce no action. This article provides a valuable research pivot point; one hopes it could assist future proposers in avoiding pitfalls present in both the failed and successful-but-failed proposals. Specifically, "Userspace drafts" concepts like Allowing users to keep private drafts of their work and its current followup WP:VPR#Proposed new Draft namespace. Is there room here for these, and a little rewriting in the lead? These aspirationals could be in a separate section. --Lexein (talk) 01:01, 12 November 2013 (UTC)

Bump? --Lexein (talk) 09:53, 18 November 2013 (UTC)

Myself I do not see that as the purpose of this page. This page just lists rejected proposals; once a proposal is accepted it is taken off this list. meshach (talk) 16:36, 9 December 2013 (UTC)

Ah. Useful to know. --Lexein (talk) 17:38, 9 December 2013 (UTC) I contend that approved but abandoned has the same outcome as rejected. --Lexein (talk) 00:50, 30 December 2013 (UTC)

USPLACE

The most recent in a long series of unsuccessful proposals to change WP:USPLACE was followed in March by a conditional moratorium in which the administrative closer said, "consider this another perennial proposal." Would it be appropriate to consider it for formal inclusion in the list? Proposals to apply minimum disambiguation to USPLACE have certainly been long-running and unsuccessful; at the same time I'm sure there are many things that get repeatedly discussed and rejected, and not all may fit the list. Either way, I just wanted to raise it and get others' thoughts. ╠╣uw [talk] 23:02, 2 May 2014 (UTC)

• I added a sentence about how including the state makes it clear that the article is about an American town. I think that's an important aspect personally. Thoughts are appreciated. AgnosticAphid talk 16:08, 25 February 2015 (UTC)
  • Why is it important to note that it's an American town and not a Canadian, Irish, or Liberian town?  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:06, 19 June 2015 (UTC)

Finally resolved issues

“ Some proposals which remained on this page for a long time have finally been proposed in a way which reached consensus ”

What are these? We should list them on this page. There might be some lessons about how to solve vexing problems. Oiyarbepsy (talk) 05:14, 7 November 2014 (UTC)

A bit late but seconded. Darkfrog24 (talk) 18:10, 9 February 2016 (UTC)

Add the MOS FAQ points

The perennials listed at WT:Manual of Style/FAQ should probably be added here.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:04, 19 June 2015 (UTC)

Forgot about this. Given that no one's objected, I'll work on it.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  17:33, 16 January 2017 (UTC)

WP:FLOW

As WP:FLOW work seems to be discontinued, shouldn't the references to FLOW be changed from "FLOW is expected to affect ...." to "FLOW would have affected ...."? — Arthur Rubin (talk) 02:43, 18 April 2017 (UTC)

Social media buttons

It may be of interest to readers of this page that I have started an idea lab discussion regarding social media buttons. Sam Walton (talk) 13:18, 27 April 2017 (UTC)

Move maintenance tags to talk pages

see also Wikipedia_talk:Perennial proposals/Archive 1#Move maintenance tags to talk pages (October 2010)

I have re-written the section to state that there is no genera consensus over maintenance templates.

Prior to my edit it stated "*Reasons for previous rejection: Every reader is a potential editor and the maintenance tags give potential editors ideas of how to improve an article." this is clearly untrue. It is much more accurate to say There is no consensus on this issue. I have also highlighted what is to the best of my knowledge the only major RfC to take place over this issue Wikipedia:Village pump (proposals)/Archive 108#Proposal to move the Orphan tags to the talk page in the last quarter of 2013. If anyone knows of any other large scale RfC (say involving 20 or more people) then please add then to this section. -- PBS (talk) 11:06, 15 October 2017 (UTC)

I've reverted your edit, with the exception of the added link to the orphan tag RFC. It seems to me that you are coming perilously close there to trying to water down the wording that is counter to your own minority POV that tags should be moved to talk pages. I also see you tried to so this same sort of thing here a few years ago and were reverted then too. Anomie⚔ 00:02, 16 October 2017 (UTC)

@User:Anomie what is your evidence that the current wording is accurate? -- PBS (talk) 08:13, 16 October 2017 (UTC)

Consensus last time seems to support the current wording. It seems to me that you're trying to define "large scaled RfC" to exclude almost every past past discussion so that you can cast doubt on the fact that the community has consistently rejected such proposals. Anomie⚔ 18:48, 16 October 2017 (UTC)

@User:Anomie. You say "community has consistently rejected such proposals"

1. What do you mean by "community?"
2. If "consistently [rejected]" then how do you explain away the Orphan RfC?
3. If rejected then you will have examples where there has been rejection as opposed to no consensus. Please list some with links to the archive or diffs.

-- PBS (talk) 12:58, 20 October 2017 (UTC)

Please give some linkgive diffs or links to RfCs where there has been "rejection" as opposed to no consensus. -- PBS (talk) 12:58, 20 October 2017 (UTC)

US places

The section on US place names currently addresses proposals to loosen WP:USPLACE so "unambiguous" place name articles no longer carry the state name (e.g. changing Missoula, Montana to Missoula. I think it should also address proposals to make the convention stricter and apply it to all or most articles. Every now and then, someone proposes a title like "New York, New York" or "Chicago, Illinois". I think the usual arguments are that all place names are inherently ambiguous or that there are historical or sociopolitical reasons for a stricter comma convention, such as maintaining the federal character of the United States. How about this?

State name in US place names

• Proposals:
  • Change WP:USPLACE (the "comma convention") to remove the state from the titles of articles about unambiguously-named US places. Example: Missoula, Montana → Missoula.
  • Make the "comma convention" stricter: require the state name in all or most titles, even widely recognized cities with unambiguous names. Example: Denver → Denver, Colorado.
• Reasons for previous rejection:
  • Reliable sources commonly append the state to US place names, but do so less often for widely recognized places.
  • Appending the state name for lesser-known cities, and omitting it for major cities, is common usage and sufficiently natural that it may be considered part of American English.
  • Repeated or otherwise ambiguous place names are very common in the US; a majority would require disambiguation regardless of WP:USPLACE. Appending the state produces a consistent and predictable set of titles.
  • Not disambiguating by state would affect the titles of articles about places in other countries, such as the United Kingdom and Ireland, where disambiguation is not common (see for example Manchester, England; and Manchester, New Hampshire).
  • Including the state makes it clear that the article is about a US municipality, which can be helpful with lesser known places.
  • Twenty-nine significant US cities do not carry the state name per AP style. In the early days of Wikipedia, all US place names carried the state name; even the New York City article was at "New York, New York". When the state was removed from a few major cities' article titles, contentious move request discussions and page move wars arose. After years of discussion, consensus finally arose to use the AP Stylebook as a reference, and to limit the removal of the state name only to those cases.