How do I get attention for old, unfixed bug reports and feature requests without official responses here on Meta?

Question

I posted a question here on Meta Stack Exchange, or on a per-site meta, regarding a bug I found in the system. I got no comments, or a few comments stating that this is a legitimate bug (and not by design). However, it's been quite a long time, and no official response was ever posted there.

Or, I had an idea for a new feature, but realized it's already requested, either by searching or posting a request myself only to have it closed as a duplicate of the existing one. It's been a while since the original request was filed, but no official response has been made.

I'm aware that staff members are accepting escalation requests for some bug reports and feature requests, but either my post isn't about one of the indicated topic areas for which they're accepting escalation requests for that month, or I already flagged to request escalation but it was declined, so the instructions there don't apply for my post.

What can I do to draw attention to meta questions for the SE team, so they can give an official response, and possibly implement the bug fix or feature?

Note: This is different from other general questions which ask for how to get attention for unanswered questions, since the procedures on meta sites are different, and getting an official response isn't necessarily the same as getting a good answer.

Answer 1

Use the official process.

There's an official process to get staff attention for bug reports and feature requests. Follow the instructions there to escalate a question to staff attention.

Note: When this official process was introduced, moderators were initially strongly discouraged from escalating older posts which didn't fit the current quarter's priorities. However, that is no longer the case. Now, moderators can add status-review to any question, regardless of age, at the moderator's discretion. Questions which don't fit the topics for the current quarter are likely to be assigned a lower priority, but SE staff will at least be aware of them.

If your flag requesting the addition of status-review was declined, then you can follow the tips below.

First of all, it's worth mentioning that an official response from the team is not guaranteed. However, there are a number of things you can do to increase the chances that a bug report or feature request (overall, "request") receives an official response, whether it's your own or someone else's. (An official response can range from completing the request to declining it or dismissing it as by design; this post outlines what you should do if it doesn't get any sort of response from the team.)

If it's someone else's question, one thing you should definitely do is upvote it. Vote scores on such questions indicate how widespread the bug's effect is, or how many people are interested (or not) in a certain feature.

Another thing you can do to anyone's question (yours or someone else's) is edit it for grammar issues, further reasons why a certain request should be completed, or changes made to the system that make the request even more relevant today. This was something I did a few times as the anonymous editor (examples 1 2 3). Just as it does on main Q&A sites, editing a question will bump it to the homepage.

Third, if it's someone else's question, and you have a thoughtful explanation as to why the request should be completed (longer than would fit in an edit without changing too much in the post), answer it and provide your explanation there. Answering will also bump the post, and will increase the perceived interest in the request. (Note that your answer should expand upon the original request, and not be redundant to it.)

A final option, as a last resort for any type of question by anyone, is to contact SE. While this is more of an abuse of the contact form in my opinion, it was actually suggested by an employee as a good way of getting official attention for a request that slipped through the cracks. Personally, I wouldn't recommend doing this unless you tried everything else and failed, and you should refrain from doing this on a frequent basis (only do it very occasionally).

---

I'd also like to point out what you should not do, as well as give some tips to make your future requests more likely to receive official responses.

Don't repost the request, if it's already been made before. Your question will definitely be closed as a duplicate of the older request without a response, even though yours is phrased better or contains more info. (I personally disagree with this practice, but right now, it exists.) In a similar vein, don't simply ask "when will [existing request] be implemented", as it will also be closed as a duplicate (and lead to no official response).

Don't post a simple, one-line answer asking why the request hasn't been completed yet, without supplying any good reasons for it. This is very likely to just get deleted as a non-answer. Similarly, don't post a multi-line answer that is merely redundant to the request, and doesn't add anything new.

Finally, a little controversial, but purely my opinion: don't put a bounty on it. While this is a great way to get attention for questions on main Q&A sites, from what I've seen, it isn't a good way to get official attention for bug reports and feature requests, which means the bounty rep you spend would be wasted. According to this answer, it's a good way to get community input, but not official input.

And now some tips for increasing the chances your future requests get official answers:

• Phrase your request clearly. A good feature request or real bug report is less likely to get an official response if it doesn't clearly explain what the feature or bug is. Be sure to clearly explain it when initially posting your request.

• Try and ask for alternate fixes. (This doesn't really address the question, but is a good alternative.) Some bug fixes and new features can be implemented client-side as user scripts, and there are a few users who are adept at writing such scripts and provide them in answers or in a larger collection of scripts consolidated into one.

• Post your request when the SE team is active and working. This is approximately Monday-Friday 9am-6pm in U.S. Eastern Time, or 14:00-23:00 UTC (13:00-22:00 UTC from March-November), excluding U.S. public holidays. Posting at a different time will at best delay an official response, and it's likely that other questions posted in between yours and the start of the work hour will swamp the team and your request will fall through the cracks.

---

Addendum 1: requests relating to specific features that are unlikely to be handled

As development work and priorities continue to develop and change throughout the Stack Exchange network, the following features of SE aren't currently receiving very much development work. As such, even if you follow the steps above, you may not be successful in getting an official response if your request is about one of the following features:

• Chat (all servers)
• Area 51
• iOS and Android apps (no longer officially supported)

Feel free to update this list with more features if they come to mind.

Addendum 2: undesired design changes and other long-time features of the site

As of February 2020, a lot of design changes are being made to the system to better align it with newer Stacks standards, as well as other improvements. Some of these changes may end up removing features of the site that have long been present, and so it's jarring to see them go away.

However, if you file a request to revert a design change just shortly after the change is made, it's likely that your request will end up ignored. It's often the case that you may get used to such changes some time after they are made, and the team is aware of this. (I learned this with the new 2018 mass design changes as well as the 404 polyglot removal on Stack Overflow: while I quickly filed a request to change the latter back, despite lots of community support, it was declined.)

If you want to increase the chances that a request to revert a design change will be granted, wait some time before filing the request. It might be possible that you'll get used to it after a while. However, if you've waited a while and you're still unsatisfied, be sure to clearly state objectively why you prefer the old style, instead of just saying "I liked the old way better".

Answer 2

For issues raised here on Meta.SE, the advice in Sonic's answer about editing to clarify or answering to strengthen the argument is sound. Especially for feature requests, sometimes the actual request (in the question) is poorly-argued but a strong answer can help. Requests or arguments based on actual data seem to particularly impress the team, so brush up on your SEDE skills. (For general advice on writing good feature requests, see this answer from Shog9 on Meta.SO.)

Bug reports and feature requests can also be made on per-site metas. That's OK too; while you may sometimes see comments there saying "you need to ask this on Meta.SE", that's not strictly true: the team is supposed to monitor per-site metas too. That said, there are times when it makes sense to bring it up here, which I'll get to in a moment.

For an issue raised on a per-site meta, particularly for a bug report or site-specific feature, if you're not getting any response from SE and the meta request has decent support from the community, then you can ask a local moderator to escalate. That part about support is important; get your community to show up and vote on meta. How much voting you need depends on the magnitude of the request. When moderators ask employees to do things like burninate tags, add a new migration target, or increase the number of custom close reasons, the CMs pretty much always respond with a request for a meta link. As a moderator, I've been able to get site-specific things like these addressed by escalating a per-site meta request to the CMs.

Don't bring things here to Meta.SE that only concern one site, like the examples I just gave; people here will just close it as "only applicable to one specific site". However, sometimes, a request has broader implications: either other sites might be interested in the fix too, or making the change would somehow affect other sites and not just your site. In those cases, you can get more input (both positive and negative) by bringing it here. When you do:

• Do the stuff in Sonic's answer to present the problem clearly and persuasively.

• Cite past discussions. If a request here on Meta.SE arose out of a problem already discussed on your site's meta, link to that and summarize the discussion.

• Explain why this has broader application than just your site -- why are you bringing this to Meta.SE other than that you didn't get a response from SE on your own meta?

• Show some understanding of the impact and effort. Is this a big change but you think it's really important? Show us your analysis. Do you think it's a small, harmless change? Why? (If you're wrong, you'll learn something that way.) What alternatives (for FRs) or workarounds (for bugs) did you try first, and why didn't they work?

None of this guarantees action, of course; you can get more attention for old issues and add strong arguments to support them, but in the end SE will decide.

Answer 3

In March 2020, the Community Management Team came up with a new process by which the community and moderators can escalate posts that need staff attention.

We tested it for 6 weeks, and found the results to warrant keeping this new process going.

For as long as this process is in place, you can find the guidance on how to get attention to old posts that need a response from staff at this post. That guidance will be updated regularly, as the post notes, so using the "follow post" feature might be a good idea if you wanna be up-to-date on the latest guidance.

That being said, the general "dos and don'ts" advice provided on both Sonic and Monica's answers (with regards to how to post about these, how to make your case on someone else's post, how you shouldn't repost these, etc.,) are still mostly applicable and worth reading.