# Our Commitment to Responding to Meta and Moderators

As Teresa mentioned in our Q1 roadmap blog post, the company is working on establishing our commitment to responding on our Meta sites and to our moderators, by setting up a new Meta engagement policy. The goal is to increase staff participation on the various Meta sites, particularly Meta Stack Overflow and Meta Stack Exchange.

One major area we need to work on is being able to respond to and manage community feedback that needs staff response or action. This post defines a process for doing that. We also need to find out how many of your questions we can realistically respond to so that we can make a reasonable commitment (both internally and externally). Below is a timeline for testing and formulating these goals.

The new process for managing community feedback:

Staff and moderators will add the tag to meta questions that they feel need to be addressed by staff. This tag can be used on any meta site across the network. Questions with this tag from across the network will be automatically added to an internal tracking system.

No later than March 16th, the CM team will post documentation to MSE to ensure moderators understand when to use this tag and when it should not be used (update: posted on March 12th). Users may flag a post that they believe should be tagged and the moderators or staff will decide whether to add the tag.

The CM team will support the mods so that they feel empowered to make these decisions and give them helpful feedback if they tag questions that we feel didn’t meet the guidance. We will use that information to add detail to moderator guidance or show moderators where they can find answers to these questions.

The CMs will manage and maintain the issues tracked in an internal tracking system as follows:

• The CM team will prioritize questions tagged on MSO (and international MSOs), MSE and the Moderator Team.
• Questions on child metas (not MSO or MSE) will be addressed as time allows.

In this process, the CM team will act as a kind of switchboard operator, making sure the issues escalated get in front of the right team(s) internally. Similarly, the CM team will facilitate the flow of information back to the community from said teams.

Moderators may escalate questions about moderator-specific policies and tooling to staff on the Moderator Team and they will be handled as described above.

The timeline:

• From now until March 15th, the CM team will work on establishing the process outlined above and the internal systems needed to support it, along with defining the commitments needed from other teams.
• From March 16th until April 30th, we will test our process: new questions asked on any meta will be tagged by staff or moderators with the tag. These questions will enter a tracking system, and the CM team will triage and direct them to the appropriate contacts in the company for them to get responses out on meta. Data will be collected on the amount of staff support needed on all of our meta sites.
• On May 15th, the CM team will share the results of this test. Based on this test, we’ll define targets for how many posts we can respond to, and how quickly we can do so.
• The targets will then be reviewed quarterly, to keep them optimized — basically make sure we’re setting realistic targets and meeting them.

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.

Along with the stats, the post will highlight staff responses that are noteworthy, interesting or fun. We hope that being able to see this info on a regular basis will underscore our commitment to engage with Meta and also draw attention to some of the work our staff is doing to improve your experience on the Network.

This is as much a test for us, internally, as for all the communities and moderators. If it turns out that the amount of questions getting flagged for moderator attention in the scope of this process becomes untenable for bigger sites (like MSO and MSE), the CM team will work with the moderators to alleviate that workload, and possibly adjust course mid- or post-test period. In that spirit, we ask that you not bombard mods with tagging requests, particularly for years-old content.

We believe that the process we’ve outlined above is a transparent one that shows our commitment to engaging with the community. If you have any questions, please ask them in an answer and we’ll do our best to clarify. We’re looking forward to being here on MSE and the other metas more often as we work to rebuild our relationship and trust with you.

NOTE: Please don't start flagging questions as candidates for tagging until the test starts.

• What's going to happen with the current usage of [status-review] - as in the issue is being reviewed by staff? – ChrisF Mar 4 at 16:17
• The Community Dev Team already uses the tag to put bug reports into their bug board, @ChrisF, basically to build a backlog/queue. The tag doesn't mean that we're promising to look at it or that there will be any resolution, unfortunately: we just don't have the manpower to actually review and fix all of the bugs we have. This is an extension of that usage. The goal is that we will have better internal tracking of issues on meta and be able to prioritize and respond to them - even if the response is just "this seems to be a bug, it's on our backlog now, thanks!". – JNat Mar 4 at 16:25
• Please consider responding to this related question: meta.stackexchange.com/questions/317271/… – Sonic the Anonymous Hedgehog Mar 4 at 17:16
• Wouldn't all the feature requests (or at least those with a positive score) fall into the status-review category? What is the idea regarding past highly upvoted, frequently duplicated, not yet implemented not declined feature requests? Should they be tagged? – Trilarion Mar 4 at 21:40
• @Trilarion: I had exactly that question, so thanks for asking it first! I feel like most not-terrible feature requests on site metas, at least outside of MSE and MSO, are seen as "a good way to solve a problem our community deals with" and thus I see very few cases (e.g. on the RPG.SE meta) where I wouldn't want the staff to at least consider it and implement it. – V2Blast Mar 5 at 0:44
• This complete 180 on the company's approach to Meta engagement is both remarkable and pleasing. – Asteroids With Wings Mar 5 at 11:46
• Thank you for including a hard set date for this initiative. That alone shows dedication to the effort, and it's appreciated. – Sterling Archer Mar 5 at 13:46
• Ideally there would be a less coarse way to prioritise by number of users affected, but I appreciate the honesty of "Questions on child metas (not MSO or MSE) will be addressed as time allows". – Nemo Mar 5 at 14:36
• You want to increase dialogue with the community, then almost literally in the next sentence you launch site changes without any prior dialogue with the community. Kindly tell me how this makes any sense. Do you want to have a dialogue or not? – Amarth Mar 5 at 17:27
• @JNat you say "new questions asked on any meta will be tagged by staff or moderators with the status-review tag." - what about old requests/bugs etc? Could sites come up with their 'top 5' or 'top 10' old unanswered bugs/requests to be reviewed? – Robotnik Mar 5 at 22:40
• Just wanted to chime and say (again) how much I appreciate the shift in direction, and these concrete steps towards transparency and consultation. These are great steps in the right direction. – Steve Bennett Mar 6 at 0:51
• Does this mean that the plan to phase out Meta (in favor of other sources of feedback) has been changed? – laur34 - inactive Mar 7 at 11:38
• What is good for the goose is not good for the gander, one has to honk while the other has no such requirement; many see that as fairly equal, for them. – Rob Mar 8 at 17:59
• As I noted here, @Trilarion, that should be clarified in the upcoming guidance for the test period. – JNat Mar 10 at 19:25
• Edited the first "we" to clarify, @tkruse. Along with a previous edit, I think that disambiguates all the "we"s present in the post. – JNat Mar 10 at 19:28

## 10 Answers

The meaning of 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 and ?

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.

• JNat's comment on the Q: "The Community Dev Team already uses the tag to put bug reports into their bug board, @ChrisF, basically to build a backlog/queue. The tag doesn't mean that we're promising to look at it or that there will be any resolution, unfortunately: we just don't have the manpower to actually review and fix all of the bugs we have. This is an extension of that usage. The goal is that we will have better internal tracking of issues on meta and be able to prioritize and respond to them - even if the response is just "this seems to be a bug, it's on our backlog now, thanks!"" – Catija Mar 4 at 22:29
• @Catija Then that should be reflected in the tag wiki and excerpt of every meta site that that principle applies to. – S.S. Anne Mar 4 at 23:32
• Updating the tag description/excerpt is part of this, yes. – Catija Mar 4 at 23:35
• I think the point is that yes, it might have been supposed to mean "Under Review", but realistically there were so many posts tagged with it that it would be impossible to actually review them all. This resets expectations back to how the tag is currently being used. – Geoff Griswald Mar 5 at 18:01

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.

• Have to agree - "sorry, can't go into detail now but we're probably never going to do this" is better than silence. It may sound like an unreasonable request because of the sheer number of requests but, say, committing to responding to those with a certain vote count would go a long way – Pekka Mar 5 at 12:39
• They could sort them by score and then work they way from the top to the bottom with a steady speed. – Trilarion Mar 5 at 15:44
• That's exactly what this aims to do? Anyone can raise a feature request. Just because they have, doesn't mean its a good idea or deserves more than a passing glance. The idea is that Moderators perform the initial "crap filter", and promote feature requests worthy of review with this new tag. Any which sit there and don't get tagged with status-review, you can assume are not worth looking at. – Geoff Griswald Mar 5 at 18:06
• @GeoffGriswald Except... this isn't a new tag. It's been around for nearly a decade. There simply hasn't been any point for moderators to use it because SE Inc. has studiously ignored user (including moderator) requests, and staff haven't used it because... they're the people ignoring user requests. The cynical part of me says that this new policy is simply going to be used to change the excuse for not actioning requests from "we don't care" to "oops we have sooo much on the backlog, sorry but your request isn't a priority", hence my pointed question. – Ian Kemp Mar 6 at 7:55
• The feature requests you mention can fit into this process, yes. We're not committing to actually implementing them, but rather to respond as much as possible, even if the response is just "this seems reasonable, we're adding it to our backlog." After the testing period we'll have a better notion of the total number of posts, how many we can commit to answering, and possibly implementing. We'll also be able to see how many still go unanswered. And we'll be as transparent as possible with those numbers. I get your frustrations, but this is just a first step in, I hope, the right direction. – JNat Mar 6 at 12:16
• @Ian Kemp potato potato, what you see as "ignored" others might see as "read it, don't agree with it, won't add value, moving on to the next thing". Again, anyone can raise a request for a new feature, doesn't mean it's worth doing. In fact, the vast majority of feature requests raised by users aren't worth doing, just as most bug reports aren't actually bugs. So yes, I'd expect SE inc has been ignoring the vast majority of user requests, with good reason to! If they hadn't, I'd be worried. – Geoff Griswald Mar 6 at 12:48
• The reason why they won't, and shouldn't, individually respond to every request is because the person that raised it will surely think it's a great idea. Going back to them with a comment like "Hey, we looked at this and we don't think it's worth spending time on", is simply inviting them to respond with "Oh but my idea IS actually good, you must just not understand it properly. Allow me to go into lots of detail about why it is actually a good idea". Imagine that conversation happening literally 5,000 times, and you'll understand why developers don't respond to feature requests from users. – Geoff Griswald Mar 6 at 12:51
• @JNat As Pekka noted, those are exactly the kind of responses we've been hoping to hear for so long. Even if you merely groom the top 10 feature requests (by vote), that would go a long way towards assuaging some of the worries around platform neglect that many have. – Ian Kemp Mar 6 at 12:53
• @GeoffGriswald There are feature requests with hundreds of upvotes. Considering the small population of meta compared to the main site, that's a strong indication those should at least be looked at. And just because there are over 5k FRs not addressed, does not mean any one is worth discarding - if SE Inc. had actually spent the last half-decade responding to FRs as they came in instead of sitting with their collective thumbs up their collective you-know-whats, they would not have over 5k to go through! – Ian Kemp Mar 6 at 13:00
• In some ways the FR is probably not the best solution. What I’ve realized is that in many cases, what a product manager or dev needs to really understand and think about is the problem - what’s making you want to break your keyboard across your monitor - and a lot of FRs don’t include that. Great ones do... but a lot don’t. Knowing what problem people are trying to solve gives PMs the flexibility to solve the problem without feeling shoehorned into a specific implementation request. – Catija Mar 6 at 13:16
• Anyone can upvote. Just because a feature request gets upvoted doesn't mean its any good. It also doesn't mean it's legal, makes business sense, is worthwhile doing, represents a good use of developer time and effort, or is even possible. All that upvotes tell developers is that a request is popular. The site is not a democracy, your votes are meaningless. – Geoff Griswald Mar 6 at 14:25
• @Catija That's a fair point, but a fair counterpoint is that a lot of those FRs would never have been needed (and hence posted) if SE Inc. had treated the Stack Overflow platform as a product needing continuous improvement, as opposed to something that only needs a single big new feature once a year. That's compounded by the fact that those big new features almost never had anything to do with what the community had asked for - i.e. there is a massive disconnect between what SE Inc. wants and believes is good for the platform, vs what its actual users want. – Ian Kemp Mar 6 at 14:52
• @IanKemp i think another disconnect is that the whole SE network probably doesn't make a ton of revenue for the company as compared to careers and teams, so it feels like it has been shunted to the side where it's occasionally looked at, rather than being a higher priority. – DForck42 Mar 6 at 17:42
• There are surprisingly many FR with lots of upvotes and not a single downvote. I would strongly suggest that the company looks at them and tries to address them one way or another. No tag is really needed, all you need is a custom filter. Of course they come from years of inactivity, it's not possible to address them in a few weeks, but starting to do that, even if it takes a year, would be the right thing imho. – Trilarion Mar 9 at 10:04
• Dismissing feature requests because they are A) Not popular, B) too popular, or C) something something mumble mumble. Yep, makes sense. – barbecue Mar 9 at 19:02

The change to 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 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 . I feel like it would be beneficial to have some sort of tag that acts as an "official reply inside" tag. Perhaps or ? Or, perhaps the scope of 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.

• [status-planned], [status-deferred] – Mithical Mar 4 at 16:50
• If we're talking bugs or feature requests, status-completed should still do the trick. If we're talking support requests or discussions, the fact that there's an answer from staff should be a clear indicator that it's been addressed, no? :) – JNat Mar 4 at 16:52
• I suppose you're right, @JNat. I was just looking for the same at-a-glance visibility that status-review will now provide. – Spevacus Mar 4 at 16:54
• @JNat Technically at least, another solution might be to publish be a read-only view/summary of the bug-tracking database: to show the current status of everything. – ChrisW Mar 4 at 16:56
• @JNat Given that a Q&A on Meta can have a lot of answers, it seems to me this suggestion is a good idea. When opening the question someone can see at a glance whether there's been an "official" response without having to scroll through everything to check... – Cindy Meister Mar 4 at 16:58
• Also, calling a discussion "status-completed" kinda... I don't know... scares me. One of the great things about discussions is that they are a place for open collaboration and expression of ideas. status-completed sounds so final and seems like "closing" the subject, which I don't really think is appropriate and I think could look (and get mocked) like a certain "Mission accomplished" banner. – Catija Mar 4 at 17:09
• @Catija maybe [status-responded]? – George Stocker Mar 4 at 20:48
• @GeorgeStocker May as well be status-from-the-horses-mouth That kinda implies that all meta questions need or deserve an official response... and they don't. The community is great at this and what we need to do is make sure that stuff that really can only be answered by us is getting answered... but I don't know why a tag that calls attention to that answer is needed I'm going to need some strong arguments for why we need tags for this sort of thing... and, if so, how do we keep it simple? What if someone's just quoting staff? What if staff is just commenting on an answer "yes, this"? – Catija Mar 4 at 20:56
• @Catija I know that we all kind of do it and answer in comments but maybe staff should not put important information in comments. It doesn't feel like the best solution to me. What would be wrong about answering with "we agree with answer X" or editing the answer instead? – Trilarion Mar 4 at 21:47
• @JNat - an official response from SE is easy to spot while that CM/employee has their diamond, but loses it's impact a bit if they leave the company (as there is no other indication that the user was once an employee). Perhaps a rule to preface any 'official' communique with a "Hi, I'm [name], a [job title] at Stack Exchange" so that the response carries the same weight whether the user account is de-diamonded or even deleted entirely. – Robotnik Mar 4 at 21:56
• @Trilarion I... really really really don't like the idea of ... "endorsing" someone's answer by writing a new answer that just points at it. I think it's a terrible use of the platform and a waste of space... and if the answer gets deleted at some point, the staff answer is now link-only. I'd rather come up with an actual feature that lets us indicate "official" or "endorsed" answers. – Catija Mar 4 at 22:21
• @Catija "Mark as solved by company" then. The problem with using comments instead is that they seen as second class, doesn't need to be read. Information there is not that visible. – Trilarion Mar 4 at 22:26
• @Catija "One of the great things about discussions is that they are a place for open collaboration and expression of ideas" - it's great to see a member of staff saying this. For months the message (from the company) has been something like "Discussions are toxic. The only feedback we'll listen to is 1-1s with individuals we hand-pick; the rest of you are simultaneously too many to have time to listen to or think about, and, too few to care about and would fit in my living room". It's great to see open discussion being valued again. – user56reinstatemonica8 Mar 4 at 23:01
• Perhaps simply [status-reviewed] would be helpful, to indicate that the question has been reviewed by SO staff and they have taken whatever response they feel is appropriate? – Gavin S. Yancey Mar 4 at 23:24
• You make a good point, @Robotnik, and ideally we'd have something tied to the answers that indicates that they're "official" in some sense, rather than having to look at who wrote it, and try to backtrace whether or not they are or were employees at some point. – JNat Mar 6 at 12:05
• 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) 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 ? or, if it's not that bad, Gavin S. Yancey's excellent suggestion of ?) If the latter, is there also a commitment to provide some level of explanation about why this was dropped?

• Those are the bits we're still working out, but ideally yes to both: we should be able to both indicate that a certain issue is not on our radar any more, and provide at least a basic explanation as to why not. This should be clearer on the guidelines to be published on the 16th. – JNat Mar 6 at 12:18
• You should avoid giving any negative feedback in this way. I know it seems counter-intuitive, or perhaps callous, but actually the best way to respond to a feature request you have no intention of acting on is to ignore it. If you actively say "no, we're not doing this" or close the request or tag it with Declined or whatever, 9 times out of 10 the person that raised it will simply raise it again, but worded slightly differently. This creates untold churn. Best to let it sit there and give them the false hope that one day it will be gotten around to. – Geoff Griswald Mar 6 at 13:03
• There tags status-deferred and status-declined already exist. – gerrit Mar 6 at 14:40
• @JNat Many thanks for the feedback - it is keenly appreciated. – E.P. Mar 6 at 15:28

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.

• Maybe you can achieve that by a filter on all tags: status-review but not bug nor feature-request. – Trilarion Mar 4 at 21:50
• You can set up filters, as noted. They'd produce results similar to this search. – JNat Mar 6 at 12:17

(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 tag.

What about all the existing "open" requests?! Others have mentioned the any open 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 isn't sufficient. There should be something like and , 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.

• Aren't status-completed/status-planned (for accepted) and status-declined (for rejected) enough? – MEE - codidact.org Mar 6 at 15:34
• Knowing "will be worked on at some point in time" + "rejected" ... is for sure better than nothing. But an open defect/story tracker would help the community to understand the "capacity" for example. When you see how much works gets done on average, that really helps you to appreciate the progress "your" request is making. An open tracker simply helps with transparency. – GhostCat salutes Monica C. Mar 7 at 8:02
• Re the "new" questions confusion: basically, we don't wanna not look at those at all, but we also don't want to be flooded by all of them: it's something we need to balance, and the guidelines to be published by March 16th should shed some light on that. – JNat Mar 10 at 17:34

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

So, basically never, as it already is anyway

• Come on, now, that's not quite fair. I've reported bugs on child metas before and had them get fixed promptly. Admittedly, I pretty much had to rickroll the SE staff to make it happen, but still, they fixed it in less than two hours. :) – Ilmari Karonen Mar 5 at 20:20
• Well - that's something I hope changes as a small site moderator. Especially if it means more practical resources towards the community site. SE has fallen way short in the past. This could be an opportunity for change. – Journeyman Geek Mar 6 at 13:49

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.

• I think for the time being we may wanna stick to existing tags, but it can make sense to create new ones in the future, sure. Regardless, you make a good point, and ideally we'll be open to feedback and possibly request clarifications (if needed) during the stage in which the issue is actively being reviewed. We'll see how this fits in to the guidelines to be published on the 16th. – JNat Mar 6 at 12:22

# 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

• I think this could make sense as a sub-point to "How many are in process," yes. I'm not sure if we have plans of sharing more than stats in a Meta post for the time being, though (as a response to your side thought). – JNat Mar 6 at 12:24

In 2 months, there will be some version of a response to these 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.

• This is more of a backlog than a "monthly queue," and I don't foresee it ever going down to 0. The idea isn't to bury feedback either, but instead to make sure the teams that can respond to issues being brought up by the communities on their Meta sites are actually seeing those issues as they arise — the point is that we try to respond to as many of these as possible. – JNat Mar 10 at 17:38
• @JNat - I know the idea isn't to bury feedback, but that seems like the direction this will go in. The main reason I saw for the drop off between interactions between the community and staff / CM's was that the staff and CM team were overwhelmed. Lowering the amount of team members only made that process more difficult. I understand the point here is to respond, which is honorable, but the mechanism being used is not the right tool for the job. Even if this does work in the near term, its expanded use will more than likely lead to burn out because of the issues noted in this answer. – Travis J Mar 10 at 18:20
• @JNat - Honestly, if the amount of internal effort that was spent organizing the right way to respond to the community was instead spent simply responding, it probably would have been more effective. I obviously have no access to the internal Stack Overflow Teams site, but I would assume.. well really I would like to know how many posts there are related to meta / community and if there has been any discussion with regards to perhaps just having that dialog be public instead of buried. – Travis J Mar 10 at 18:23