Jump to content

Template talk:Failed proposal

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
(Redirected from Template talk:Failed/doc)

old discussion

[edit]

OK, do we actually have anything that has been superceded? The Uninvited Co., Inc. 02:02, 15 May 2005 (UTC)[reply]

Things like Quickpolls, no? I think we should include "ignored" ;-) Grace Note 00:20, 16 May 2005 (UTC)[reply]
  • Somewhat doubtful, but WP:ASS superseded the "limit to VFD nominations" thingy. However, supersession should probably not be tagged by this. Radiant_>|< 14:03, July 18, 2005 (UTC)

New discussion

[edit]
  • Reword and doc. The previous language shut the door too firmly on a rejected proposal. While sometimes we may want to nail the door shut, if not shove the entire thing into the river, it's important that we permit others to entertain the possibility of so editing a proposal that it meets community needs. John Reid 05:16, 5 October 2006 (UTC)[reply]
    • Not a bad idea, however I would suggest amending the wording to clarify that a proposal does not need "consensus to reject" to be rejected. >Radiant< 15:28, 5 October 2006 (UTC)[reply]
      • Should we make a distinction between proposals which have been explicitly rejected (ie. there was a consensus to reject them) and proposals which are simply inactive? This is the old version from a few days ago, which would seem directed at the second case. The current form of the template seems directed at the first case. --bainer (talk) 01:32, 6 October 2006 (UTC)[reply]

I suggesting a change to the wording of {{No-consensus}}. The "inactive" word is silly. There is typically great activity associated with a failing consensus. Therefore, "inactive" effective prevents the use of {{No-consensus}}, and it steers frustrated debaters to opt for the more dramatic {{rejected}}. It is also silly because a label is not required as the level of activity is plain to see in the history and the talk page. SmokeyJoe 12:17, 12 March 2007 (UTC)[reply]

For new wording I suggest:

This is a proposal has failed to achieve a consensus. If you want to revive discussion regarding the subject, please use the talk page. If discussion is inactive, consider seeking broader input via a forum such as the village pump.

SmokeyJoe 12:17, 12 March 2007 (UTC)[reply]

Recent changes are unclear to less experienced users

[edit]

My purpose for making the source of the tag's authority more clear is that it was misunderstood in several applications. I'm all for brevity, but sometimes it goes to far. I think that the current version makes it very clear where someone should go to see the actual policy. I would like a more specific description, but am willing to compromise for the sake of brevity. --Kevin Murray 18:56, 26 April 2007 (UTC)[reply]

I'm not sure what the objection is to having the tag be more specific in citing its source of authority, the policy page. I have found that less experienced users have had less objection to the rejection process if they understand the policy. My original attempt months ago was to have a more involved quote within the template, making the authority crystal clear. However, that size of template encountered a lot of opposition. I'm marginally satisfied with having a clearer link to the policy. Please consider my position. --Kevin Murray 19:02, 26 April 2007 (UTC)[reply]

I wasn't not considering your position. Indeed, I merged your intentions with the existing text, and hopefully it's clearer for all. But removing the link to a specific spot on the policy page, to just generally linking to the policy page just leads to confusion. I think even the newest of newbies knows how to scroll up or down a webpage for further information. And just as I'm considering your position, I'm attemnpting to consider others' concerns of length. - jc37 19:13, 26 April 2007 (UTC)[reply]
I agree that linking to the actual spot is better. Still I don't see a disadvantage to making it very clear where the link goes. --Kevin Murray 19:32, 26 April 2007 (UTC)[reply]
I put your link into my format so that the link goes to the section of the policy page. Should it go directly to the rejection paragraph? --Kevin Murray 19:36, 26 April 2007 (UTC)[reply]
Yes. (see below) - jc37 19:50, 26 April 2007 (UTC)[reply]

Clarification

[edit]

Let me make sure what we're talking about. You want added:

Per [[Wikipedia:Policies and guidelines#How are policies started?|Wikipedia:Policies and guidelines]]:

Rather than simply having that link on the word "rejected"?

This seems minor, and I would think having the link on the word "rejected" would actually be more clear, and less "wordy". (And Radiant! - and others - may laugh at hearing me say that : )

What other reasons do you have for wishing the link drawn out rather than direct linking?

(Note, I added syntax at Wikipedia:Policies and guidelines#rejected, so that we can now link directly to the appropriate text.) - jc37 19:50, 26 April 2007 (UTC)[reply]

I agree. I must have been unclear above. I just linked to where you had it linked in the prior version. This is much better. --Kevin Murray 19:53, 26 April 2007 (UTC)[reply]

Until you pointed it out above, I did not notice the more specific target of the other link. I think that the more specific targeting and more specific explanation of the link is a great combination. Thanks. As to being wordy, I think that these are a few words well spent. --Kevin Murray 20:00, 26 April 2007 (UTC)[reply]

Why? Are we presuming that users don't know how to click on a link? And just to be clear, adding the "Per..." phrasing splits up the initial statement from its definition, which is actually "less clear" in sense and tone. - jc37 20:05, 26 April 2007 (UTC)[reply]
I'm not saying that they don't know how to click on a link. I'm saying that the target of the link is unclear. I'm OK with another form of linking which is explanatory but less disruptive to the flow. --Kevin Murray 20:10, 26 April 2007 (UTC)[reply]

Try:

  • This proposal has been rejected by the community. A rejected page is any proposal for which consensus support is not present, and seems unlikely to form, regardless of whether there is active discussion or not. Further explanation is available at: Wikipedia:Policies and guidelines
  • Which is "too wordy" again. You said above: "I'm OK with another form of linking which is explanatory but less disruptive to the flow." So how about:
  • This proposal has been rejected by the community. A rejected page is any proposal for which consensus support is not present, and seems unlikely to form, regardless of whether there is active discussion or not.

We have a direct link to "rejected" which shows why the word is even used. We have direct correlation between the word and the definition. And the definition is clear. Why do you feel that we need the words "policies and guidelines" directly in the text? - jc37 20:21, 26 April 2007 (UTC)[reply]

Hmm, actually let's move the link out of the bolded text. And by doing so, really make it clear where this definition comes from.

  • This proposal has been rejected by the community. A rejected proposal is any for which consensus to support is not present, and seems unlikely to form, regardless of whether there is active discussion or not.

This should resolve it? - jc37 20:27, 26 April 2007 (UTC)[reply]

Initially I'm not satisfied, but let's allow some time to think. It is better and may be a good compromise. Thanks! --Kevin Murray 21:02, 26 April 2007 (UTC)[reply]

Discussion of change from "rejected' to "failed"

[edit]

The discussion supporting recent edits changing the wording from "rejected' to "failed" is at Wikipedia talk:Policies and guidelines/Archive 8#Rejected changed to Failed. --Kevin Murray (talk) 13:56, 18 May 2008 (UTC)[reply]

[edit]

Kevin, I disagree that the linking the first instance of "failed" in the template is better. Linking via the second instance ("A failed proposal") is less cryptic (it's clear that it will link to an explanation of failed proposals) than the first "... failed to attain consensus", and I feel emphasizing it in the way you advocate in the first line disrupts the flow of that sentence.

Hopefully you will see what I'm saying; if not, oh well.--Father Goose (talk) 05:56, 19 May 2008 (UTC)[reply]

I like having the link early in the sentence and in bold, as it ties to the title of the template rather than having the first blue link being consensus. If you really see a benefit otherwise, just have two links. I left the other link in originally to avoid stepping on your toes. --Kevin Murray (talk) 06:01, 19 May 2008 (UTC)[reply]

Proposed change: forbid use outside Wikipedia space

[edit]

In light of this, I move that this template's use be restricted to the Wikipedia namespace. Failing that, at the very least it should be disallowed (along with {{proposed}}, of course) from pages userfied by or with the consent of their creator. Works in progress don't benefit from pile-on reject !votes, and slapping "rejected" signs on people's incomplete but sincere efforts is unnecessarily punitive. Thoughts? Skomorokh 11:37, 27 July 2008 (UTC)[reply]

I'm going to go ahead and disagree. This proposal will make it so no one can propose a change in their own namespace, and keep it for historical significance as rejected. But if we do decide its best to regulate where rejected proposals are located, we will need to remove all userfied proposals that have been rejected from this categeory. Synergy 12:00, 27 July 2008 (UTC)[reply]
At a glance, I'd say about five percent of the rejected proposals are in userspace; it would not, then, be an earth-shaking change in norms, and it would not necessarily have to be retroactive, certainly not immediately. If you like, we could allow editors who wanted the tag on their own proposal to keep them. What I am talking about is establishing a norm to respect the right to withdraw and develop without having hasty and damning judgments of the previous version sticking to your work.Skomorokh 12:09, 27 July 2008 (UTC)[reply]
Another proposal can be drawn up if thats the issue. Regardless, we shouldn't ignore community consensus for the sake of one day it might work. Your example is too recent to establish a need to reform the common practice. It was a proposal to kill RfA and let the crats figure it out. This is one proposal I see a need for the {{rejected}} template (that is of course until there is consensus to use such a policy/guideline/process). Synergy 12:21, 27 July 2008 (UTC)[reply]
I started a discussion to test consensus; if we had to wait for it to catch up to our proposals unaided we would never get anything done. I'm proposing establishing a norm; if consensus is against it, fine; but absent a discussion I'm not going to concede. By way of analogy, it was fine to unload on n00b's at RfA saying "not enough experience, no edits in WP space, completely ignorant of admin duties etc." until someone pointed out that it was unnecessary and unhelpful to treat all RfA applicants the same, and now we have WP:NOTNOW which everyone seems to have come around to, and the result is better informed editors and a more pleasant editing environment. I propose that treating userfied proposals in a similarly different fashion to WP-space proposals, so when someone's proposal gets rained on, they can withdraw and tinker with it until they are ready to put it before community scrutiny again. Skomorokh 12:29, 27 July 2008 (UTC)[reply]
I understand. Your suggestion is reasonable and noble. But if nonvocal wants to start over, he can blank the page, archive the talk, and start it all over again. Problem solved in my eyes. Synergy 12:54, 27 July 2008 (UTC)[reply]
  • I don't like this restriction. I think that it is going to make a safe-harbor for perenial proposals, where they can never be rejected if they hide in userspace, until someone can claim that they have had consensus. The process for going from proposal to policy/guideline is so weakly defined and gamed so much already. I think that wioth the best of intentions you will muck-up and mucky system. --Kevin Murray (talk) 15:15, 27 July 2008 (UTC)[reply]
    • I'm afraid I don't understand your objection Kevin; under the proposed system, userspace proposals cannot claim to have consensus, they are works in progress until moved to the WP space where consensus or lack thereof will be decided. It makes things less mucky, and more transparent.Skomorokh 15:18, 27 July 2008 (UTC)[reply]
      • I'd be happy if that were plainly made clear somewhere, but I'm not familiar with any specific guidance on where proposals need to be made and how long they need to be vetted before a decision is made. If this were to be made clear, I would be likely to support your position and say "hands off to userspace." --Kevin Murray (talk) 16:39, 27 July 2008 (UTC)[reply]
        • I don't think time is a relevant metric, and I would be surprised if there were any specific guidance on where proposals need to be made. By this initiative I am trying to establish a norm. My idea is just that we have two states for proposals; "protected", where it is a work in progress, not to be judged in straw poll fashion by outsiders, and "open", where it is more or less stable, and put up for judgement by the community (who may deem it {{failed}}, {{historical}}, {{guideline}} etc.). The decision to switch is up to the editor(s) of the proposal. Does this clear it up any? Skomorokh 16:49, 27 July 2008 (UTC)[reply]
          • I support a clarification and don't object to your overall goal -- it's just the logisitics and potential for gaming that is a problem. But, unless we have a very clear system of steps for evaluation post-protection, I will object. I've seen to many proposals worked on in "secret" then declared accepted as there is consensus among the participants. There is also a strong force of editors who beleive that processes can be declared without being vetted, as they believe that they are capable of divining the consensus of the community and then etching stone tablets. As it stands, we have too many rules and far too many proposals for even more rules. Any process which promotes the generation of more proposals is a sep in the wrong direction. Go write some articles! --Kevin Murray (talk) 17:08, 27 July 2008 (UTC)[reply]
            • The way I imagined it, you don't get to declare something consensus as guideline/policy etc. until you've moved it to the Wikipedia space and advertised it for scrutiny. Then the mob will decide whether it's {{rejected}} or not. My proposed system does admittedly make it easier to create proposals, but that's the point! If we're going to have proposals, we might as well have a streamlined, efficient way of shepherding them; the current ambiguity and muddledness adds no value to the encyclopedia. On that note, I'm off to write some articles...Skomorokh 18:26, 27 July 2008 (UTC)[reply]
              • If we develop a clear and well defined process, then I have no problem. I would prefer that no proposals be allowed in userspace, but that these be called sandbox or development pages. --Kevin Murray (talk) 21:18, 27 July 2008 (UTC)[reply]

Restricting the use of this tag to Wikipedia space is an attempt to solve a problem that really calls for a different solution. I respect the right of an editor to pitch, discuss, and develop an idea (i.e., a proposal), even if it falls flat on its face in its first iteration. Tagging something as "rejected" while one or more editors are still developing it causes completely pointless wikidrama. Further, the concept of "rejecting" it is needlessly confrontational; this is why we renamed the tag to "failed", since it reflects the same fate, but with less implied hostility.

{{Failed}} is best used on proposals that have not met with consensus, and are not progressing in any fashion (i.e., not being discussed or further modified in good faith). Disrupting continuing discussion (even if it seems impossible that it will lead to eventual consensus) is in all respects negative. People are free to develop their ideas even if they're not going to be adopted -- it's a way to learn more about Wikipedia, if nothing else, and you never know: maybe alternative ideas will arise from the discussion which meet with greater approval.

Let's work on some wording that reflects the above, and add it to the template's documentation.--Father Goose (talk) 18:43, 27 July 2008 (UTC)[reply]

This would address my main concerns; that proposers be allowed withdraw their proposal from judgment once it runs into difficulty and work on it undisturbed. Skomorokh 19:02, 27 July 2008 (UTC)[reply]
Well, you never "withdraw from judgment" -- if people think something is a bad idea, they can and should say so. That shouldn't preclude others from continuing to develop or discuss the idea, however. The {{failed}} tag does disrupt continuing discussion and development, so it should be never be applied in a case where such discussion and development is taking place, even if the proposal is unpopular. (Mind you, mere advocacy does not count as "discussion and development"; if a few people are championing an unpopular proposal that isn't evolving in response to the criticisms, it's dead.)--Father Goose (talk) 21:53, 27 July 2008 (UTC)[reply]

Discussion on how this template should be used

[edit]

Copied from Sebwite's talk page

[edit]

I think that essay has been around a good while, and is respected enough to possibly be made into a guideline, and I would support such a proposal; however, I restored the tag to simply say essay, as I couldn't see any discussion on the proposal, nor any attempt to draft such a proposal and get support. When an essay has been proposed as a guideline and then doesn't get consensus it may be tagged as {{Failed}}, which then confuses people who wonder if the essay's contents are no longer valid. I have known edit wars over the placing and removing of {{Failed}} after a proposal for guideline didn't get support. If you wish to put together a proposal to upgrade the essays status to guideline, let me know and I'll support it. Regards SilkTork *YES! 12:22, 24 January 2010 (UTC)[reply]

Personally, I am in favor of limiting the {{failed}} template to project pages mostly in which consensus widely opposes the proposal. It ends up on lots of proposals that simply have gotten no comment over a period of several months, and I oppose that because there is no deadline, and finding people to comment is not easy. Sebwite (talk) 15:45, 24 January 2010 (UTC)[reply]
Personally I'm not in favour of using {{failed}} at all. It feels like a punishment for those who dared to attempt to improve Wikipedia, and it's entirely inappropriate to slap it on a long-standing essay. But some people use it, and will edit war with those who remove it. Sad, but true. SilkTork *YES! 17:04, 24 January 2010 (UTC)[reply]
Perhaps, if you feel that way, you can propose it under TfD. Maybe not for deletion, but to discuss its uses. Sebwite (talk) 17:08, 24 January 2010 (UTC)[reply]
I've encountered that problem as well.--Father Goose (talk) 08:43, 2 February 2010 (UTC)[reply]
I'm copying this discussion to Template talk:Failed, where it can continue. Sebwite (talk) 15:09, 2 February 2010 (UTC)[reply]

Continued discussion here

[edit]

We should discuss uses of this template. In my opinion:

  • It should be used if there is clear consensus against a proposal
  • It should not be used when there has been little or no comment on a proposal for a long time, per WP:DEADLINE
  • If there are comments split about equally in favor of or against a proposal, and consensus cannot be determined, its use is questionable

Sebwite (talk) 15:16, 2 February 2010 (UTC)[reply]

Include date

[edit]

I'd like to add an optional "date=" parameter, so editors can see at a glance when a proposal was deemed to have failed. Thoughts? Swpbtalk 19:49, 21 May 2015 (UTC)[reply]

"Template:Failed" listed at Redirects for discussion

[edit]

A discussion is taking place to address the redirect Template:Failed. The discussion will occur at Wikipedia:Redirects for discussion/Log/2020 October 17#Template:Failed until a consensus is reached, and readers of this page are welcome to contribute to the discussion. Soumya-8974 talk contribs subpages 17:52, 17 October 2020 (UTC)[reply]