How do I write a good feature request?

Question

I have a feature that I am interested in proposing.

• How do I draft a good feature request?
• What things do I need to include?
• What should I not do?
• How do I know if the feature will be implemented?

Return to FAQ index

Answer 1

First, some preliminaries regarding feature requests, in general...

A feature request typically stems from a selfish need: Yes, something that you feel should change to benefit your usage of the site. And, they may be very subjective - what you think might be a feature, others could consider a drawback. Regardless, this is a community-driven Q&A, and therefore feature requests should have a far bigger scope than just one person. Have that in mind when considering/writing up your request.

One view of a feature requests is similar to pitching a Shark Tank proposal: You're putting yourself in front of an audience who may be willing to spend time implementing your request free-of-charge (however mundane, simple or extravagant it may be). Not only that, you should be ready to face criticism (or favouritism) towards your request.

Agreement with (or against) a feature request is typically done through voting, with a positive [negative] score representing a bias in favour of [against] the request. It may take some time to refine a feature request as dictated by comments, chat discussion and/or voting.

Now, on to the specifics...

What things do I need to include?

• A feature request should be specific. For example,

  The colour of the Meta.SE banner should be inverted to black-over-orange, rather than white-over-blue:

  

  is far better than

  Could we change the colour of the Meta.SE banner to something other than white-over-blue:

  

• Include images that would make the request tangible. A picture is often worth around 1,000 words, give or take a few.

• Reference factual content in support of your request. Perhaps it's based on statistics of site usage (so, spend the time drawing up queries on SEDE); perhaps you've had some conversation with folks in a chat room about it and there seems to be majority support (provide links to the chat); ... Rather avoid hearsay as your foundation.

• Tag the feature request appropriately (feature-request and possibly others).

What should I not do?

• Avoid being vague about the benefits (or possible drawbacks).

• Don't leave the specifics up to the community. While this is your feature request, it should clearly outline the scope. Unclear requests may be subject to closure as being too broad or... unclear.

• Avoid emotional discussions or motivations.

• Don't ask for the moon; be realistic.

How do I know if the feature will be implemented?

• A positive score on the request is a good sign. However, total votes and views may also indicate the popularity of such a request, and therefore influence implementation.

• Feedback from moderators (via comments, or as an answer) will indicate some form of consensus about implementation. A request may be retagged to

  • status-review The request is currently under consideration, or needs further investigation

  • status-planned Coming soon to a Stack Exchange Q&A theatre near you

  • status-deferred This suggestion has merit, but it isn't the very next thing on our list. We'll try to get to it.

  • status-declined The feature request will not be implemented or fixed at the present time.

  • status-completed A feature request has been implemented, or a request has been processed.

  • status-bydesign The request will not be implemented because the current behavior is not a drawback but was made intentionally for a purpose.

  • status-norepro A suggestion to change or remove an existing feature, but there's no evidence of the feature existing or behaving in the way it's described in the request.

  • status-reproduced The behavior reported was reproduced, but cannot be addressed at this time

---

A good place to start with a feature request would be in your local chat room. There you can solicit feedback from your peers about interest in support of (or against) your request. If the request seems viable, you could consider soliciting more general feedback by posting a question on the per-site Meta before posting to Meta.SE. However, this is not necessary.

Ultimately, a good feature request is very similar in scope to writing a good question/answer.

Answer 2

I've personally found that there's a few elements to a well received feature request. Typically, after roughly a decade of operation, the Core Elements of Stack Exchange's flavour of Q&A have been tweaked, and attempts to change something fundamental like downvotes or forcing comments when downvoting don't go well. Good feature requests trim the foliage, not move the rock garden. When you do find something that needs to be changed, there's a few elements that work well. I'm posting this concurrently as I work through how I'd ask a question

• Your title. Without a good title, no one's going to bother to read your question. I know a few folks manage to effectively merge clickbait with content in a title, but I've always gone for a clear. Its your thesis.

Could we have teams included in the site switcher?

Anyone who reads see the title on the front page knows exactly what I'm talking about

• a call to action. I like to start with this in the body of a question. I often go with the current situation and why its not so great

At the moment, you can only access teams through stack overflow. Not everyone is on stack overflow, and needing to click through SO through the site switcher, then using another site switcher or the sidebar is clunky

• Support for the idea

We can already see notifications for Teams when on other sites, so a simpler, low friction alternative to access the sites would be good. The site list on the site switcher is user specific anyway.

• a little extra support if it works

While teams is integrated into SO, not all organisations that might benefit from teams might be dev teams

• optionally restate what you need

I tend to try to end my questions in a slightly open ended manner

Could we have better, easier UX for accessing teams from elsewhere on the network?

in this case I suspect a more focused approach may work better

Could we include teams on the site switcher?

I typically don't go into specific implementation details - tending to leave that to the folks actually building it. You could suggest things, but leaving implementation details to SE makes sense.

we might be able to select these the same way we show and hide regular sites from our site switcher, adding them in explicitly if we chose

Answer 3

Always include how your feature-request will make Stack Exchange better.

Write a feature-request that others can agree with. Write a feature-request that other people would appreciate if it's implemented. If you think it's a good idea, but you think of many disadvantages, it's probably not a good feature-request.

Make sure the Stack Exchange people are able to do it. As the name suggests, it's a request. A request needs to be possible. If the request is to suggest a big learning curve, it's not good.

Do prior research to make sure it's not already asked. I've run into this issue, too. See https://meta.stackexchange.com/questions/259064/search-for-comments (10k only) which is one of my questions that I didn't do prior research on. Moderators voted to get it marked as a duplicate of another question!

Write it based on facts and the community's experience. Don't base your question on a small amount of opinions, as they say. Don't complain about an existing Stack Exchange feature that other people are already used to.

If it's declined, don't ask it again. You can get a question-ban if you keep posting the same question to get attention, especially feature-requests.

Make it easy to understand while using correct grammar.

Here's what not to do:

This S.E. feature-request, abbreviated for 'Stack Exchange,' is addressing the very depressing issue of this bad feature: the down-vote arrow, which is a clickable button that you can use to bring enemy users to a disadvantage in reputation points. I will strongly advise you to consider this S.E. feature-request, abbreviated for 'Stack Exchange'...

Well, duh! Be clear and concise, but use easy language. Note, I've exaggerated it on purpose.