The meaning of status-review is/used to be "under review", not "needs review":

A feature request or bug report with this tag is neither declined nor destined for implementation/fix. When such a decision has been made, the tag will be changed accordingly.

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. There could be insufficient information in the feature or bug report as presented. 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.

The new meaning seems to conflict with this. Perhaps we can split the tags up into status-needs-review and status-under-review?

Additionally,

Questions on child metas (not MSO or MSE) will be addressed as time allows.

Please consider devoting at least a portion of your time to these sites. Some of the issues experienced on non-technical sites would likely never be experienced on sites like MSO and MSE -- where things like MathJax and spoiler blocks aren't widely-used.

One major area we need to work on is being able to respond to and manage community feedback that needs staff response or action.

What exactly do you consider "community feedback that needs staff response or action"?

Is it the over five thousand questions on Meta.SO that are tagged as feature-request, and have not been responded to be SE Inc.?

If not, why not?

The failure of SE Inc. to even acknowledge, never mind action, these requests has consistently been one of the major gripes of the community. If you really want to rebuild trust, start by going through that backlog.

The change to status-review is good. It'll be nice to know whether a meta post is slated to have an official reply or not at just a glance.

But... In what way will you mark questions that have been addressed through this policy by the staff team?

We currently have status-completed for bugs/feature requests that have been fixed or implemented, but that doesn't necessarily cover whether a particular meta post has been addressed by the new scope of status-review. I feel like it would be beneficial to have some sort of tag that acts as an "official reply inside" tag. Perhaps status-addressed or status-answered? Or, perhaps the scope of status-completed should be broadened as well?

Having a tag that notes that a post will be addressed without some sort of policy for marking posts as addressed feels a little weird to me. I recognize this is probably an artifact of moving the review status away from bugs and feature requests, and I'm wondering whether the scope of status tags as a whole should be broadened to fit this change's idea.

• How many have been dropped.

If a question gets dropped from consideration, will this be indicated on the question itself? Will such questions carry a (misleading) status-review tag in perpetuity? Or is there a commitment to remove this tag when questions have been removed from the docket? (i.e. to switch them to status-declined? or, if it's not that bad, Gavin S. Yancey's excellent suggestion of status-reviewed?) If the latter, is there also a commitment to provide some level of explanation about why this was dropped?

I applaud this policy, and love the effort to organize the responses, but point out that the posts I see so flagged fall into two categories. The first, and the largest group is pretty simple support/feature-request/mundane stuff like this

The second, understandably sparser group, goes to much larger policy/environment issues, like this

I, for one, am quite interested in the latter, and not-so-much in the former, so I'd like to see some form of differentiation, so I can appropriately favorite my area of interest.

(Again), first of all: thank you very much for your attempts to be more transparent. I appreciate the detailed content and timeline.

Where I struggle:

new questions asked on any meta will be tagged by staff or moderators with the status-review tag.

What about all the existing "open" requests?! Others have mentioned the any open feature-request posts that sit around since ages. Are they all discarded now, need to be re-asked?!

Beyond that: if you want to be fully transparent, consider using a public defect tracking system (maybe: make it read only for the community). I agree with the other answer, that first of all, one tag status-review isn't sufficient. There should be something like status-accepted and status-rejected, too. But as said, ideally, when you accept some piece of work, you will probably internally track that. It would be really great if (some aspects of) that internal tracker would be visible to the community.

Questions on child metas (not MSO or MSE) will be addressed as time allows.

So, basically never, as it already is anyway

I think it might be worth noting in your process some kind of "feedback to your feedback". Effectively how long will a question be actively in process (i.e. reading responses, commenting for clarification, etc.) is this a simple time frame, say 72hrs? Should your status tags have a Status-In-Process before moving to ones suggested by @Spevacus?

After some time or once the In-Process tag is removed it would also suggest that further clarification might warrant a new question.

RE: Communication

The CM team will also start a question for tracking our monthly participation. It will indicate stats and other information like:

• How many posts were tagged [status-review] each month.
• What types of questions they were (top tags).
• How many we responded to, and what the median response time was.
• How many are in process.
• How many have been dropped.

Can you add a point to the list?

• Posts where progess has been blocked/stalled by something else

It is helpful to know when something is in-flight but is currently blocked.

_{Side Thought: This might be more easily handled by hosting a public Trello/Jira board}

In 2 months, there will be some version of a response to these status-review posts, that will hit caps quarterly until the queue is empty?

Honestly, that doesn't sound like progress. It sounds like internally creating a system to bury feedback.

I understand that the intent here was to create a standard operating procedure to deal with something which seems like a queue based system, but that outlook completely misunderstands the issue of being attentive to the community.

With a diminished team, and considering the historical difficulties with coordinating staff responses on the meta-verse, perhaps it is time to look at the logistics of merging all meta into one place.

In essence, only looking at MSE and MSO does this already, to some degree, through grouping. All splitting the meta seems to have accomplished was to fracture the meta community in general. As well, it has made it literally impossible for the CM team to maintain any sort of effective communication.

When a serious issue arises, needing to respond to each child meta, and MSO, and MSE, is just overwhelming, and leads to the issue quickly getting out of hand. In the current setup, issues which effect the exchange as a whole are more than likely not possible to curtail once they begin. That is a problem worth solving, and a several month queue is not a solution.