Bringing clarity to status tag usage on meta sites

Question

Let’s talk about the status tags. Every single user who visits a Meta believes status tags mean something. They’re not wrong, of course. But what, really, do the status tags mean? Do users’ beliefs about status tags match how they’re used? What steps do we need to take to ensure status tags are reliably accurate, trustworthy, and clear? Riveting questions like these - and more - await!

This is going to be one of those boring, mechanical posts. I’m going to talk about process, definitions, meanings, reliability, expectations, and all the viscera that enable us to get work done. I’m going to do my best to write well enough that your eyes don’t glaze over, but… I’ve written and read enough of this stuff to know that’s a bit of a vain hope. So instead I’m going to try and impress upon you the importance of this part of our operations, in the hope it will see you through to the end.

To aid understanding, I’m going to write as directly and to-the-point as I can. No fluff, extravagant bonus language, unnecessary tautologies, or redundant prolixity.

Problem we’re trying to solve: Status tags are not consistently used to mean the same thing by all people in all situations. When they are used consistently, users do not necessarily understand them to mean what was intended. Because their definitions are loose, it is also sometimes unclear what status tag should be applied or what changing a status tag is intended to communicate to users. Similarly, we lack clear and appropriate internal guidance on how and when to use status tags.

Goals of this post:

• Introduce a proposal for clear status tag definitions.
• Introduce a conceptual difference between “process tags,” where staff input is still necessary, and “outcome tags,” where it isn’t.
• Clarify when status tags should and shouldn’t be used.
• Clarify and refine user/employee expectations (rather than introduce major changes).

Non-goals of this post:

• Make commitments about the way we are going to handle posts with process tags (defined below) or commit to perfect usage on a specific timeline.
• Develop a public plan for ensuring the correctness of posts with status tags.
• Tell moderators how to use status tags.
• Provide copy to update tag wikis for status tags. (Feel free to make any changes as appropriate, but this post wasn't written with that in mind.)
• Clarify how to interpret status tags on posts predating their modern usage.
• Clarify what a user or moderator should do if a status tag is in an erroneous condition.
• Achieve perfect clarity for all readers. (It would be nice, but I prefer to set more realistic goals.)

---

We have eight status tags today. They can be divided into “process tags” and “outcome tags.”

We currently have eight status tags on each per-site meta: status-completed, status-bydesign, status-declined, status-norepro, status-review, status-deferred, status-planned, and status-reproduced.

All of these are actively used, save one – status-reproduced. For reasons that are not relevant to this discussion, usage of status-reproduced has essentially fallen to zero. I’m not going to seek to change that here, and won’t discuss its usage further. (If we’re being honest, this proposal probably kills it implicitly, too). (Small update: I reviewed all the posts in status-reproduced and determined that all of them belong in other states. I retagged all of them, so now usage is actually zero.)

Of the seven remaining tags, they can be divided into two classes:

1. Process tags serve to indicate that there is a need for staff attention on that report that has not yet been fulfilled.
2. Outcome tags serve to indicate that the post does not need (or no longer needs) staff attention.

These definitions are mostly complete, bar two scenarios. First, moderators use status tags differently than this - but clarifying this usage is under “non-goals of this post” above, so let’s set that aside.

Second, some folks might object to the language of “outcome tags” here, and those folks would be right to object. We’ve historically told users that tags like status-declined aren’t permanent, and we can / will revisit them as appropriate. This language has introduced substantial user confusion in the way our processes work. While it is technically true that a post in status-declined can later be picked up and worked on, the reality is that users should never expect posts in status-declined to see further work. Exceptions do exist, however, and a pathway must be maintained for a report with a “outcome tag” to regress to a “process tag.” But this should be considered a regression, rather than a designed outcome. In most cases, the standard guidance and process for re-raising declined issues should apply.

Let’s sort the existing tags into bins.

Process tag	Outcome tag
status-review	status-completed
status-planned	status-declined
status-deferred	status-bydesign
	status-norepro

We have three process tags and four outcome tags. Posts should never have more than one status tag at a time, whether process or outcome. Any post with multiple status tags is in an erroneous state and must be corrected.

Clearer definitions for each status tag and how it should be interpreted

This section is just tables. No exposition here. The tables are written from an employee’s perspective - from the perspective of someone actually sitting down to use these tags in practice.

Let’s start with the process tags:

Status tag	What it expresses	When to use it	When not to use it
status-review	Staff support is needed to resolve the issue, but the post has not yet been evaluated by staff	Use this tag to move any public report into our internal processes	Do not use this tag if the post as described cannot be handled by existing processes
status-planned	Users should expect a solution to be deployed reasonably soon	Use this tag when we know approximately when work on an issue will finish, e.g. it is in an upcoming sprint	Do not use this tag if the work has not been scheduled, or if the work is speculative and may not ultimately reach a completed state
status-deferred	Staff are interested in solving the problem, but users should not expect a solution soon	Use this tag when we are interested in the proposal but do not currently have resources to complete it	Do not use this tag to avoid sensitive discussion or to ‘soften the blow’ of work we are unlikely to do

And now the outcome tags:

Status tag	What it expresses	When to use it	When not to use it
status-completed (any post type)	We have done all the work we intend to do	We took every action we intend to	An issue resolved without any action on our part
status-declined (feature requests only)	We aren't going to do any work on this request	As far forward as we can determine, we won't work on this request	We see merit, but don't currently have resources to do the work
status-bydesign (bug reports only)	This report reflects intended, designed system behavior	The system is behaving as it was intentionally specified to	We decided a behavior that wasn't originally specified should be accepted
status-norepro (bug reports only)	We cannot reproduce the bug, so cannot fix it	The bug is too transient to evaluate, or not described clearly enough	A simple request for information could enable work on the bug
status-wontfix (bug reports only)	The bug is legitimate, but we won't ever prioritize fixing it	We've decided we will live with the bug as-is	We would eventually like to fix the bug

"Hey, wait, what’s up with that fifth thing? Where did that come from? And why is status-declined only for feature requests?"

Introduce status-wontfix

To develop this plan, I spent a long time in the salt mines, reviewing, reading, retagging, classifying, and evaluating posts. It became obvious from historical context and usage that there is a critical hole in our ability to communicate. (In before “this is just status-declined again” - I promise you I’ve put more thought into it than that!)

Currently, status-declined has an overloaded meaning. In broad strokes, status-declined means that we evaluated the request but decided not to pursue it, generally boiling down to some variation on “we decided it’s not worth it to do.” However, the space of meanings is different for feature requests and bugs.

For feature requests, the meaning includes the possibility that we evaluated the request but did not find that it had enough merit to pursue. In other words, we might (for example) feel that the problem is legitimate, but the request doesn’t solve it, or the reverse - if the problem existed, the request would solve it, but the problem doesn’t actually exist. It can mean that the proposed fix isn’t ready for work and needs longer community discussion or any number of such cases.

Bugs, on the other hand, are either legitimate or not. Either the bug actually takes place, or it does not. If it’s real, then in nearly every case, it would be optimal to fix it. But sometimes, we will choose not to fix a real bug intentionally. (Usually this will happen because the bug is too much work to fix and not really worth the effort.)

This overloaded meaning isn’t terrible, but it does introduce some confusion. What we don’t want is for users to question the legitimacy of the bug report on the basis of a status-declined tag. It obfuscates whether a given status-declined post was declined on its merits or for another more mundane reason. We also want to ensure that the intuitive meanings of the status tags remain relatively clear for staff members.

status-wontfix is intended to address three communications problems:

1. Allow staff members to simultaneously acknowledge the validity of an issue and move it off their desk if it isn’t worth fixing.
2. Make it so that status-declined posts have more homogeneous meaning and applicability.
3. Make it easier for staff in the company to know which status tag applies to bugs intuitively.

How exactly is status-wontfix defined? By contrast! It’s not status-norepro - we must be able to reproduce the issue. It’s not status-bydesign - the system must be behaving in an incorrect or unintended manner. But we’re still not going to work on it for one reason or another. Maybe it’s too expensive to bother fixing, or maybe someone simply drew the eight of swords that day. Regardless, the meaning is far more precise than lumping it into status-declined ever would be. And on the upside, employees are going to know roughly what it means just by looking at it.

Posts normally move between tags along predictable pathways

We can now sketch out some claims about how posts transition between status tags. Posts come to staff attention when a staff member or a moderator applies the status-review tag. This causes a ticket to be created for the post within our internal records. While posts that have never had the status-review tag might still be seen and reviewed by staff, you can only expect posts with status-review to occupy a place in our planning processes or backlog.

(Historically, we’ve asked moderators to use discretion when applying status-review and even provided moderators with lists of topics we are actively working on. While the exact recommended usage of status-review should be expected to change from time to time, our request for moderators to use discretion and best judgment when applying the tag remains. It is worth acknowledging, however, that we have not yet posted new status-review usage guidance during 2024.)

Therefore, when attempting to understand how posts move through our processes, we can and should treat status-review as the universal entry point. Staff can of course be aware of posts without a status-review tag, but posts only enter the process when they receive that tag, thereby creating a paper trail.

With this, we can draft up a quick transition table to describe how posts move through the process:

Process tag	May move to process tag	May move to outcome tag
status-review	status-planned or status-deferred	status-completed, status-declined, status-wontfix, status-norepro, or status-bydesign
status-deferred	status-planned	status-completed, status-declined, or status-wontfix
status-planned	In exceptional cases, planned work that is canceled may return to status-deferred	status-completed only

Notable omission: status-deferred should not normally move to status-bydesign or status-norepro. If the issue is not reproducible or is an intentional part of system design, it should not be deferred, as deferred signals to users that we are (at minimum) interested in working on the request. This does not generally make sense to communicate if we can’t reproduce the bug or if we believe it is by design and does not need to be changed.

Exceptions to this workflow exist, and I will never present the above tables as hard rules that employees or moderators must obey. Sometimes, work is just not going to proceed as expected, or conversations internally are going to fall out of sync with what’s in public, or someone will leave the company with a loose end left over, or someone’s just going to make an earnest mistake, or… the list goes on. However, under normal circumstances, the above transition table should accurately reflect tag changes that take place on the platform.

Note that posts with outcome tags should almost never move, either to another process tag or between outcome states. The two most common cases where this might sometimes happen are:

1. We originally status-declined a feature request, but later reconsidered (without a more recent post to attach that work to - see the process for re-raising declined requests here).
2. We originally status-norepro’d a bug, but due to changing circumstances, we can now reproduce that bug.

But these are, and should be, exceptions; I won’t explicitly cover what to do in these situations because these, and other similar exceptions, are all atypical and depend on judgment calls to handle correctly.

Wrapping up: We’re not done here.

Even accounting for status-wontfix, the goal of this post is not to change anything so much that it can’t be recognized. I hope that you’ll see the shape of what’s familiar in the language laid out above, even if it will shift ever so slightly.

This project is a part of the nexus of work surrounding the community asks sprint, and has spun off from our efforts to clean up Stack Exchange’s long public backlog. We hope you see the merit in this change. And if you don’t, we hope that you’re willing to allow us the room to play around with systems to find what works best!

This also shouldn’t be the last time you’ll be hearing from us about how status tags are managed. Just like our recent effort to retag old posts with erroneous status tags, this isn’t a cut-and-run endeavor. Nor is it the only moving piece related to cleaning up how we do work in public. More on this later.

I’m open to small corrections, clarifications, and the like - but I want to say upfront that what I’m really watching out for are serious objections to the plan laid out here. I consider this primarily an internal-facing project, the goal of which is to clarify and render consistent status tag usage by employees network-wide.

I’m also going to request that folks stick to one topic per answer. For a post this involved, managing more than one clarification per comment thread is going to be… a bit challenging. I’ll appreciate your judiciousness here too.

Some of the details might change between now and a final draft, but unless y’all feel I’m about to make a horrifying mistake, this is gonna to be the shape of things. Let me know below!

Answer 1

Somewhat tangential, but since we're talking status tags...

Can we make status tag changes (or any moderator-only tag changes) raise a notification to the author and followers?

Currently, users are not notified when status tags are changed on their post, because tag-only edits don't trigger notifications. However, in most cases, someone adding or changing moderator-only tags on their post is as good as answering the question, and users should be notified when their post changes status.

To quote from this long-standing feature request:

I think it is helpful to know if your bug got fixed, or it was declined to be fixed or wasn't reproduced. While most of the time staff also post an answer or comment when tagging, in some of those cases they don't leave a response, so the user is never notified of the decision.

[...]

To quote Tim Post in a prior discussion:

[The current behavior is] not good design, mostly because it's based on assumptions that we'd leave a response when putting a status tag on something. But practically speaking, that's not always possible, especially when putting status tags on posts closely related to others that warrant receiving them after a bug was fixed, or new functionality, or whatever.

Alternatively, can we make it protocol for moderators and staff members to always post something that triggers a notification - either a comment or answer - when changing a status tag on a post?

Answer 2

I appreciate the outline... a small caveat that I'd like to make...

In many cases, I don't really think status-completed makes much sense on discussion questions. This is likely my own nit-picking but a discussion can't be completed. It can have a staff response, which feels like a separate outcome to consider but using that tag on a discussion that's open to anyone on the site tells people that the "discussion" is somehow closed, even if users disagree with the staff response.

For this reason, when discussion questions got a status-review tag and I responded, I just removed the tag and didn't add the status-completed tag. It's fair for y'all to decide to shift how you handle these, I just worry about how using the tag will be interpreted by community members in some situations.

One thing I frequently see is that questions are sometimes directed at staff but given a discussion tag, even if only staff can really answer. A more appropriate option would be to use a support tag in that case, as support questions make more sense with a status-completed tag and if only staff can answer, it's not really a "discussion" - it's a request for the official answer.

Out of curiosity, I looked at the count of questions with both status-completed and discussion tags - there's about 900... which may seem like a lot but when I review those questions, the discussion tag seems like the wrong choice. Many of them are really bugs, support requests, or feature requests that weren't correctly tagged - and if you exclude questions that also have one of those tags, the count drops below 700.

So, I guess one thing I'd recommend is that staff using outcome tags also review the required tag to see if the question was tagged correctly in the first place.

Here's a couple of recent examples of cases where the status-completed is confusing or the question should have been retagged:

• Cookie consent going down hill - should have been retagged bug
• Does the Code of Conduct prohibit content justifying war crimes? - Status tag is confusing, "staff-answer" might be better or retagging to support
• With Stack Overflow Teams moved, where do Meta questions about it belong? - should have been retagged support
• Some sites are offline, but no blog or Twitter information. Is all OK? - should have been retagged bug
• Please add a corresponding hat for casting downvotes - should have been retagged feature-request
• What is the future for Imgur and SE? - should have been retagged support

The bulk of discussion tags I see that get marked completed but don't have a better option than discussion is a group of questions that support the argument for a fifth (staff-only/mod-only ?) required tag - announcements. This includes things like planned maintenance, upcoming changes to the platform, etc.

In the end - failing adding or re-categorizing a few tags - there are situations where it's reasonable for both tags to appear but I support minimizing it as much as possible by:

• retagging when the discussion was used in error
• avoiding use of status-completed when discussion is appropriate if staff is only adding to the discussion

Hopefully, these seem like reasonable adjustments to this process. I appreciate that staff time is limited but if you're already editing tags, a quick check and adjustment of the existing tags seems like a minimal ask.

Answer 3

Is the intent for the status-wontfix tag to remain grey, or will it match the other status tags’ red colour scheme?

---

status-planned

Answer 4

What about status-reproduced?

While you/we are thinking about the [status-*] tagging process...this tag seems to virtually never get used (9 questions on MSE, and 5 on MSO), and I'm not totally clear whether it's actually useful.

Perhaps it communicates something like "We are aware of the issue, and we have confirmed that we have all the information we need, but further analysis (perhaps regarding the amount of effort required to fix it) is needed to decide whether it should be fixed now, deferred, or marked status-wontfix. That analysis is the next step in the process."

On the other hand, that's sort of a subset of status-review. It might create more confusion by adding another tag into the mix of tags that need to be managed, eliminating any of that intuitive sense of what tag to use that you're trying to create here.

Answer 5

Wontfix is a bit of an interesting one - what might be an example of the sort of bug that's annoying enough to get into the system but innocuous enough to let scurry around the codebase?

Answer 6

There should be a tag for when a post has been subsequently reviewed by a staff member after being escalated

When a post is tagged status-review, the next possible tags as you mention are either an outcome tag or one of the tags status-planned or status-deferred. There's still a gap here: if a moderator (not staff member) has escalated a request using the first tag, a staff member has to review it and decide whether it's worth planning it for implementation or deferring it for later. This decision requires staff to review over the request fully, which may take time for some requests.

In fact, this explains the former usage of the tag before the 2020 introduction of the escalation process (taken from its extended tag wiki):

There are multiple factors that may leave a report under review. There could be consideration of whether the proposed feature or bugfix is feasible or useful. There could be investigations on the complexity of the necessary solution. [...] Site developers may provide additional comments to request more information or to provide status updates as appropriate to the status of the review, until such time as the decision for approval or decline is made.

There's also a similar situation where a non-developer staff member (e.g., CM or support staff) escalates a report, but then a developer has to reproduce it and review over its complexity.

To summarize, once the tag has been applied, there's no way for people to know whether a (relevant) staff member has actually reviewed it. For all we know, it could just be hanging in the ticketing system. In fact, there are many posts that have had the tag for years - are they really taking long for staff to review, or are they just somehow getting passed over in the ticketing system?

---

The tag status-reproduced was useful in that it did provide some such window for bug reports. It basically stated that a developer had reviewed over the report and was able to reproduce it on their end, and that they're evaluating how complex it is to fix it. In fact, before I started writing this answer, I meant it as an argument towards retaining it, but as I started writing this, I realized that the same window is also valuable for feature requests.

One possible way to resolve this issue is to make a new tag status-escalated or status-ticketed for escalating reports (the post has been added to the ticketing system but has not been reviewed by relevant staff yet), and repurpose status-review for its originally-created purpose and that of status-reproduced (a relevant staff member is reviewing or has reviewed over the request - and if a bug, managed to reproduce it - and is making a decision on its subsequent outcome). There may be other ways too.

Answer 7

Why is status-deferred a process tag? It seems to be both an outcome and a process step. It's been reviewed, confirmed to be a problem, there's interest in fixing it, but it's not going to happen in the short term and there may not be a good approximation of when it will be finished.

Which brings me to my next point. I don't understand the introduction of status-wontfix. Specifically, it's not clear how this is distinct from status-declined or status-deferred. I think that using status-deferred addresses all of the problems with using status-declined without introducing a new tag - it lets people know that it's legitimate but there's not currently enough reason or resources to go after fixing it.

How do these fit into support requests? Things that aren't feature or bug requests. Questions about policies, for example. There's nothing other than status-completed so would we expect every policy question to be answered eventually, and move to either planned or deferred and then completed?

Saying that status-deferred shouldn't move to status-bydesign or status-norepro may not make sense. If something is deferred for months and years, other changes may invalidate it. When it comes out of deferred, someone may try to reproduce it and fail or design decisions confirm that the bug is actually what was desired all along.

Answer 8

I don't understanding the "Don't Use" copy for status-review, what would be an example of a post that as described cannot be handled by existing processes?

Do not use this tag if the post as described cannot be handled by existing processes

Would this just be things that are simply not bugs/features?

Answer 9

Just thought I'd add that the whole purpose for this seems to be clarity and understanding for everyone. So with that in mind, why not add an extra descriptor to the status outcome tags - another layer defining bugs and features?
Because, after all, the clearest tags are instantly definable to the observer. We can't expect everyone to spend half an hour reading and link-surfing posts for clarification - only for a deeper understanding if you're a great mod/user ;).
So things that aren't immediately obvious (if possible) need to be made so.
For example;

status-feature-declined
status-bug-bydesign
status-bug-nonrepo
status-bug-wontfix

Ideally, you shouldn't need to infer by contrast. Doing so could lead to misinterpretation and misuse. "But how do you decline a bug report..?" Well...

(btw, I don't think status tags are that hard to decipher once you know their collective purpose, it's pretty self-explanatory for the most part - especially for mods who just need to get things rolling. Their (our) only effective input being "to tag or not to tag". Complexity is the enemy of understanding, and understanding is the foundation of an efficient system. Simplicity.)

Just a thought :)

Answer 10

"Hey, wait, what’s up with that fifth thing? Where did that come from? And why is status-declined only for feature requests?"

Introduce status-wontfix

Except status-wontfix is only for bug reports, so it isn't a complete replacement.

What do we use for burninations and synonym requests (among other things) now that [status-declined] can't be used, and the newly introduced [status-wontfix] also can't be used?

Aside tag curation, certain support questions also get status labels, and now have no way to signal a declined status anymore. This particularly applies to requests for some moderation action against individual posts (specific-question, specific-answer, and various other support questions).

Answer 11

It feels like the tagging system as documented is very much leaning towards 'meta as a bug triage system' - Would these work similarly with feature requests ?