In reviewing Should we have a policy about "too much downvoting"?, I noticed that it was of type discussion but also had status declined. The documentation on How does Meta Stack Exchange work? says parenthetically that this status is usually used for feature-requests. I can understand how this status might also be used for bug or even support, but I'm not sure what to make of it for discussion. Can you help me understand the conditions under which moderators would "decline" a discussion question?

  • 6
    That discussion carried an implicit proposal for a new feature (an upper limit on the downvote to upvote ratio of a user), which will not be implemented.
    – user200500
    Commented Aug 19, 2013 at 17:10
  • 1
    I'm soooo tempted to downvote just for the abuse of tags in this question...
    – Arjan
    Commented Aug 19, 2013 at 17:13
  • Also, it was a discussion started by the team, asking for input. (Rather than a feature request from a user, asking the team to implement it.)
    – Arjan
    Commented Aug 19, 2013 at 17:15
  • @Arjan I've had numerous MSO questions edited by others to replace my plain text references to tags with actual tags. Is there some documentation you can point me to as what is appropriate? Should they never be used? Only be used the first time in a question? They're a pain to type, relatively speaking, and I think they interfere with the flow, so I'd prefer not to use them given a choice. Commented Aug 19, 2013 at 17:49
  • @Asad You and a couple of others have indicated that any reference to a potential change in the system within a question, even in the context of "what if" or "what are the pros and cons", should be treated as a "feature request" for all intents and purposes. If I understood you correctly, how would you go about asking for information about the impact of a hypothetical change without having it treated as an actual request to change the system? Would you have to do it in comments? Commented Aug 19, 2013 at 17:51
  • I'd only use them if you want to link somewhere. (Like when asking about a specific tag, which people might want to click to see all posts related to that tag.) Above, I don't think you want to link to anything? (Unrelated: for the very same reason I dislike linking to Wikipedia for very common terminology. Just makes folks wonder what's to see when following the link. Which is even worse on mobile, as many touch devices don't support hover.)
    – Arjan
    Commented Aug 19, 2013 at 17:58
  • (And as an aside: I roll back edits made to my posts, that add <kbd> or tags.)
    – Arjan
    Commented Aug 19, 2013 at 17:59
  • @Arjan So this is just a matter of personal preference as far as you know? Do you do anything to denote the tags (quotation marks, italics, etc.) or just leave them plain text? Commented Aug 19, 2013 at 18:04
  • @PeterAlfvin 'You and a couple of others have indicated ... for all intents and purposes.' That isn't what I've said at all. To quote the question we're talking about: 'Based on this data I am leaning towards enforcing a "no more downvotes may be cast" if...' I'd hardly say that is an airy fairy hypothetical scenario, and is actually a proposal that might get implemented. It just happens to be mis-tagged discussion instead of feature request, and you seem to think that magically exempts it from any of the behaviors associated with a proposed change to features (eg. status declined).
    – user200500
    Commented Aug 19, 2013 at 18:13
  • Hmm. I guess we just look at this very differently. I'm not suggesting that discussion items should be "airy fairy". Indeed I would think that most discussion questions would be about things that someone has seriously considered. I just think there's a difference between trying to have a dialog about a possible change (my view of "discussion"), even if you express your opinion, and actually making a formal request for that change (my view of "feature request"). Commented Aug 19, 2013 at 18:23
  • @PeterAlfvin A "formal request" for change (aka a feature request) is an invitation for discussion and dialog on the merits and consequences of the change. Most answers to feature requests are tweaks, criticisms, insights etc. [discussion] is for discussions that don't fall under one of the narrower tag categories: it even says so in the description. I really hope the team implements the proposed change of making feature request questions immune to the effect of downvotes so that people finally stop mistagging feature proposals as bug/support/discussion out of fear of downvotes.
    – user200500
    Commented Aug 19, 2013 at 18:29
  • @Asad Thanks for clarifying your view. Ironically, it seems like we're looking for a similar end result, namely the free flow of ideas regarding improvements. I certainly think what you're proposing would be better than what we're experiencing today, but I think there's value in sometimes "preprocessing" feature request ideas as discussion items before submitting them, in order to separate the wheat from the chaff. In part, that's because I think responding to feature request, bug and support question is somewhat "mandatory" while responding to discussion questions is entirely optional. Commented Aug 19, 2013 at 18:42
  • @PeterAlfvin You can certainly submit feature proposals as discussion when you want to emphasize that the idea is half baked (possibly upgrading to feature request following input), but please don't try to demand that people don't vote on the merits/flaws of the idea, simply because you've disclaimed that you actually want it implemented. For example, here's a feature that I think needs to be changed, although I'm not sure on the best course of action. I've tagged it both FR and discussion.
    – user200500
    Commented Aug 19, 2013 at 18:49
  • Again, I respect your view, although personally I like the policy as revised this month, namely that votes of agree/disagree should only be applied to feature requests. Whether those votes count against rep is a separate matter. Commented Aug 19, 2013 at 18:59
  • 3
    Note that it was Jeff -- founder/CEO -- who both authored the question and added that tag. This isn't a case of "moderators declining discussion" from a lay member.
    – jscs
    Commented Aug 19, 2013 at 19:18

4 Answers 4


The tag itself is often used as a "disguise" of sorts for a when the author isn't quite sure if the feature should be implemented and wants discussion from the community on whether it is a good idea or nailing down the specifics of the feature.

Sometimes the tag is omitted simply on the basis that it takes up another tag, and there are other, more prevalent tags that the author would rather use. Other times it may just be that the author didn't want to attach two required tags to their question. Generally speaking, the tag refers to the body of the question. If the question itself is requesting a feature in some way (even implicitly), then the question is subject to a tag like any other feature request.

  • 2
    I don't know if it was your intent, but the term "disguise" makes it sounds as there is subterfuge or misrepresentation involved when inviting discussion on a hypothetical change to the system. Other terms I've seen are "masquerading". When someone is genuinely unsure about the impact of some potential change, is there no way to neutrally collect feedback about it without it being treated as an actual request for that change? Commented Aug 19, 2013 at 18:01
  • @PeterAlfvin Yes, there is. Present the proposed change neutrally, and consider both the pros and cons of the change in your question.
    – user200500
    Commented Aug 19, 2013 at 18:20
  • So, for example, in meta.stackexchange.com/questions/193762/…, would you say that my explicit request for "pros and cons" was simply inadequate and that I should have had to come up with some "cons" to balance my one sentence of "pros" or removed the "pros" entirely? What if I'd given no "pros" and just left the request for "pros and cons"? I frankly think I would have gotten the same reaction. Have you seen examples where a change was "presented", pros and cons offered, and people didn't vote based on agreement/disagreement? Commented Aug 19, 2013 at 18:32
  • @PeterAlfvin If you describe a change to the site, then expect the community to critique it: that's what is supposed to happen in a feature-request anyway. There is literally no difference besides the tag you've used and the fact that you've highlighted the change is hypothetical (as all proposed changes are). What I was suggesting is that you examine both sides of the picture yourself.
    – user200500
    Commented Aug 19, 2013 at 18:35
  • @Asad So to simplify this, if I just say "What are the pros and cons of 'x'?", I'm making the equivalent of a feature request and I should expect to get agree/disagree votes. If I say "'x' seems to have <...> pros and <...> cons, what do you think?" then I'm not making a feature request and I should be free of agree/disagree votes relative to 'x'. If I've got that right, then a corollary would be that you can't have "just" a discussion about something unless you can argue both sides effectively from the start. Commented Aug 19, 2013 at 18:50
  • 1
    @PeterAlfvin "If I've got that right ... effectively from the start." No, you can totally have discussions that aren't about feature changes without "agree/disagree" votes (mostly). The Meta community has become accustomed to using votes to express a trivial "yes please", "no thanks" response to discussions involving feature changes, regardless of what you tag them, especially when discussion of those features has already been played out extensively and/or there are existing answers that express why they feel the changes would be beneficial/harmful.
    – user200500
    Commented Aug 19, 2013 at 19:20
  • @Asad Sorry, in all of this I've been referring solely to discussions about potential changes in features. I understand there is generally no issue with other types of discussions. Commented Aug 19, 2013 at 19:28
  • @Asad See my answer below for my attempt to explain some of our disconnect. Commented Aug 19, 2013 at 20:33

The mis-tagging here is that the question is marked as "discussion" despite the fact that it's a "feature-request".

Having a "status-*" tag is appropriate, because it is indeed proposing a new feature.

  • Actually, Jeff explicitly said he was considering a change, which sure doesn't sound like a request. In any event, I'd be interested in your thoughts on my comment on the other question. Commented Aug 19, 2013 at 18:10
  • @PeterAlfvin Just because the poster isn't 100% positive that the feature should be implemented doesn't mean it's not a feature requests. All feature requests should be made by someone willing to consider alternate solutions to the problem, modification of the suggestion, etc. In short, all feature requests should result in a discussion of that feature request. Feature request is, by definition, a subset of discussion. Tagging it discussion alone is an insufficiently specific, using both is just redundant.
    – Servy
    Commented Aug 19, 2013 at 18:18
  • @PeterAlfvin Note that such "discussion" questions are treated as feature request questions anyway, so they may as well be tagged appropriately. It's pretty clear to the readers that there is as feature being requested, so removing the FR tag clearly isn't creating the behavior you're describing, it's just causing confusion.
    – Servy
    Commented Aug 19, 2013 at 18:20
  • In many cases what's "clear to the reader" isn't in fact reality. I contend most discussion questions are just that, with the questioner just looking for information. While I agree that all feature requests ought to be subject to review and feedback, that doesn't mean that all discussions ought to be treated as requests. Commented Aug 19, 2013 at 18:56
  • @PeterAlfvin I'm not saying all discussions are feature requests. I'm saying that a noticeable number of people choose to tag their feature requests as discussions, even though they really are feature requests. This is one example of it. That doesn't mean that there aren't actual discussions out there.
    – Servy
    Commented Aug 19, 2013 at 18:58
  • I think I've got a handle on the disconnect here and I'm going to try to make a diagram ... Commented Aug 19, 2013 at 19:11
  • See my answer below. No diagram, but a table. Commented Aug 19, 2013 at 20:32
  • @PeterAlfvin What about it. It wasn't really unclear to begin with. I see no distinction between your options. Every feature request brought up is intended to be discussed. I see nothing to gain from tagging a feature request as "discussion", even if you aren't 100% sure that it should be implemented. There is nothing to gain, and a fair bit of confusion created. The post should just be tagged "feature request" and all of a sudden everything's better.
    – Servy
    Commented Aug 19, 2013 at 20:38
  • So you're saying that I'm alone in thinking the in The intent takes precedence interpretation is what we should be operating under, or rather, is how the current system was designed? Commented Aug 19, 2013 at 20:45
  • @PeterAlfvin I'm saying that feature requests should be tagged as feature requests, and that any existing feature request posts that aren't actually tagged as feature requests are mis-tagged, and should be fixed. Trying to figure out why some people choose to use the improper tag doesn't seem like a productive discussion, just fix it when you see it.
    – Servy
    Commented Aug 19, 2013 at 20:52
  • Only the person asking the question knows their intent and I believe their intent is what should determine whether it's tagged/treated as a discussion or an implementation request. This will in turn determine how it's treated by tag-specific policies. I understand you view it differently. Commented Aug 19, 2013 at 20:57
  • @PeterAlfvin All feature requests are, by definition, discussing a feature request. It's not that there is nothing being discussed, it's that it's redundant to add it. To omit a key tag, namely "feature request" when requesting a feature is something that makes it harder to find the proper content for those who are looking for it. Also note that tags are very frequently edited by users other than the author, mostly because most people don't do a good job of tagging their questions.
    – Servy
    Commented Aug 19, 2013 at 21:01
  • let us continue this discussion in chat Commented Aug 19, 2013 at 21:04

Summary: If this discussion item really morphed into a feature request at some point, then it should have been retagged as such and the status declined tag was appropriate. If the intent of seeking feedback did not change, then no matter what Jeff's role or "leaning" was, it should not have been given the status-declined tag.

Background: I think a lot of this and related consternation is traceable to different views of the discussion tag as it relates to questions about feature changes and, to help with the illustration, bug fixes.

Consider the following matrix with "topics" as rows and "intent" as columns:

                 | Just want dialog  | Requesting implementation |
| Bug fix        |                   |                           |
| Feature change |                   |                           |

The question is, what tags do you associate with questions that fall into each of the cells above? I contend there is no controversy regarding the "Requesting implementation" column. Everyone seems to agree that the bug fix cell should get the bug tag and the feature change cell should get the feature-request tag. I think also that there is no controversy around the fact that although users should be prepared for some "discussion" when submitting either of those, these should not also be tagged with discussion.

The disagreement seems to rest with the "Just want dialog" column. I'm aware of two different positions on this:

  1. The topic takes precedence - That is, if you just want to talk about a bug fix, tag it with bug and if you just want to talk about a feature change, tag it with feature-request. The discussion tag should be reserved for discussions of other things.

  2. The intent takes precedence - That is, if you just want dialog and you're not actually requesting implementation at this point, tag it with discussion.

There's a third possibility, namely that both the topic and intent tags should be included, but I haven't found that view promoted yet.

Perhaps I'm an outlier here, but until this is clarified, I think it's going to be difficult to have meaningful discussion about policies that are specific to these tag types.

As a final aside, I'm not aware of any controversy regarding the tagging of support questions or the tagging of discussion questions not related to bug fixes or feature changes.

Update: Just had a long chat with another user who is squarely on the "Topic takes precedence" side. For the record, I'm on the "Intent takes precedence" side. Their primary argument was ease of finding questions related to features and was based on the assumption that people would agree/disagree vote feature-related discussion items anyway. My primary argument concerned promoting free exchange of ideas and was based on the assumption that we'd figure out a way to greatly reduce agree/disagree voting on discussion questions.


As far as I'm concerned, the tag should be reserved for actual feature requests. You know, ones that you've put a lot of thought into, have a proposed implementation, and really think are in a finalized ready-to-be-implemented state. You're not really angling for community consensus, you're essentially demanding that the feature be implemented. (Although "demanding" sounds like a bad word, I don't mean it that way or to imply anything bad.)

On the other hand, a question is one where you are looking for community input and trying to solicit a discussion. That discussion can be on anything related to the Stack Exchange network, including ideas for possible new features that have not yet been fully fleshed out. These are basically feature requests that are still in the incubator—you have a glimmer of an idea, something that you think should be done, but you're not entirely sure if you're right, and you have no ideas on how it should be done, but you want to open up a discussion about it anyway. Answers to this type of question would disagree that anything needs to be done, disagree that anything needs to be done now, propose a solution to the problem, provide additional data in support of the problem, etc. etc.

For example (and I pick on my own questions because they're handy and I know what I was thinking when I wrote them), this question is a lot like a feature request—I want something on the site to change. But I'm not proposing a concrete implementation, I'm just throwing an idea out there for discussion about something I'd like to see changed. I'm open for input from the community on my ideas, and hoping to get some good ideas on how to implement it. As such, I've tagged it simply .

This one, I was pretty certain that I was right. I had a concrete feature I wanted to see implemented, and I knew exactly how I wanted it to work. It was simply a matter of writing the code and unit tests. In my mind, there wasn't any need for discussion about how it should work, just whether it will happen. Consequently, I tagged it . (And then that Shog9 guy came along and shattered my dreams.)

Of course, even questions tagged still often elicit discussion. It is perfectly reasonable for people to disagree with the inherent validity or proposed implementation of your feature request. They can post answers that explain the rationale behind their disagreement or propose alternative implementations, and they can downvote the question to signify their disagreement. This is a common and (in my mind) perfectly acceptable use of downvotes.

Both of these are perfectly valid uses of the tags. You could tag a question with both tags if you like, but you are not required to do so.

As far as the particular question you linked, it appears to fall into the second category: when originally posted, it was the beginning of a feature request, but not yet a full-fledged request. After the discussion took place, an actual feature proposal crystallized, which was subsequently declined. It would have probably been appropriate to substitute the tag with a tag when it was marked , but that didn't happen—not a big deal in my mind.

The tagging system is not absolute. Just about every question here could be tagged because this is a discussion site. Lots of discussion questions contain feature-request-like elements. Others are actually support requests in disguise (because someone doesn't know or assumes that a feature does not exist). Some even turn out to be bug reports. Categories are fluid, and that's why we allow questions to be retagged. Don't read too much into them. The content of the question itself—and the answers—is where the real magic happens.

  • +1 Per my answer below, I think the way to look at discussion tags and the rationalization for not adding them everywhere is that they mean just discussion. Commented Aug 20, 2013 at 13:12
  • 1
    What is the advantage of tagging some feature requests as "discussion" instead of feature requests? How will it [positively] affect how other people find, view, or respond to the question, instead of tagging it "feature request"? I, as someone responding to the proposal, don't really care if you think it's ready to be implemented or not; if I see problems with the feature I'll point it out, if I see a way it can be modified or improved I'll point it out, and I'll point out what I expect the consequences of it being implemented might be. I would do exactly the same thing for either tag.
    – Servy
    Commented Aug 20, 2013 at 13:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .