We spent a sprint addressing your requests — here’s how it went

Question

You may have noticed posts getting status-completed at an unusually high rate last week — there’s a reason for that, which I’ll get into further down. But first, some context for those who might need it.

Back in 2020, we introduced a process that allowed y’all to escalate issues that require staff attention by applying the status-review tag. If you’ve been keeping up with the reporting on those, you’ll have noticed the backlog has been accumulating, which resulted in clean-up efforts such as this one in 2021. Additional cleanup efforts to address posts with the tag from before the introduction of the process have also taken place in 2023. You may also have seen CMs removing some status-deferred tags from posts where it’s definitely no longer relevant over the past month as part of preliminary survey work to estimate the true size of our backlog.

These cleanup efforts have generally served two purposes: to do (internal) backlog cleanup, and to ensure the status on the Meta post reflects the internal state for those issues. But the fact that we need to resort to those efforts also highlights the current process’s shortcomings: it is not as effective as we’d like it to be at producing responses to the posts you’re escalating, nor at ensuring good backlog hygiene — at least not without regular coordinated clean-up efforts.

Introducing the Community Asks Sprints

For the past couple of months, leaders from the Community Management (Rosie), Product (Ryan Polk and Des), and Engineering (BMatt-Stack) departments have been working on a key piece of how we address these concerns. In addition to our work on projects to meet business objectives, and larger undertakings to develop and implement new features on the platform, our plan is to dedicate time, across all our public-facing developer teams, to work exclusively on requests that have come in from the community. We are calling this concept the “Community Asks Sprint.”

Before we go any further, and in case you’re wondering: we’ll continue to work on community requests outside the Community Asks Sprint. This does not take away from regular bug duty efforts, nor does it impact the Community Management department’s ability to work with Product Managers and make requests throughout the quarter. We are also, of course, still going to work on community-facing features as usual. The Community Asks Sprint, however, allows us to prioritize work on requests and reports that could otherwise remain backlogged for long periods of time because they may be outside the scope of roadmap priorities.

During these quarterly sprints, members of the Community Management, Product Management, Engineering, and Design departments will work collaboratively to triage, prioritize, estimate, scope, and build/fix your requests. Each quarter, there will be a rotating core group, comprising members of all the departments mentioned above, to work on prioritizing and refining the issues prior to the sprint. Once issues are split across various cross-functional teams, they will work on the issues assigned to them.

In addition to the benefits the Community Asks Sprint brings to the community, there are also some internal benefits: this is an opportunity for engineers, product managers, and designers to work on issues they may not get to encounter on a regular basis and to touch on areas of the product they wouldn’t normally touch.

In order to decide which issues we’d be working on, we started by looking at posts that had a status tag on them. Slate put together a query that tried to balance the overall post scores with their community engagement since time of posting: in other words, a recent popular post doesn’t necessarily jump the queue, but an older post would only climb the queue if it kept getting community attention despite its age. The intention was to balance age and score, so that we could ensure we are looking at issues that you still care about, now.

Here are some highlights from the issues we were able to work on as a part of this initial sprint (note that while all of these have an internal "done" status, some might still not have a public resolution from staff, so bear with us as we get those responses out):

• ​​Allow bountied questions to be closed by regular users
• "Does this answer your question?" duplicate comment text is silly and confusing
• Julia syntax highlighting
• Tell users when their edits are rejected
• "Mostly code" is rejected but "mostly screenshots" goes through
• The "Describe why you would make a good moderator" box uses "►", creating less-accessible "lists" and The "What are Tag Wikis?" editing help uses "►", creating less-accessible "lists"
• Inbox notifications not consistently marked as read after clicking title and I'm clicking the same message multiple times to get it to clear, is it broken, or is something else happening?
• Stuck greyed out audits and non-upvotable comments bugs in review queues
• The review queues are even more broken now--claiming normal items are audits
• Gold tag badges don't apply to synonymized tags
• Could we revisit WebP support with the new uploader?
• Edit conflicts should categorize as "cancelled" instead of "rejected"
• Please catch no alt text in the automated question review process
• Indicator on Meta next to the display name of former Staff and/or Mod users for actions performed with that status (partly completed; more to come)
• Automatically resize images if their file size is too large

What’s next?

This first sprint was experimental, and we tried to focus more on making progress on some issues, and test-driving the basic processes by which we triage and split work fairly across teams — especially teams that normally have more specific areas of focus. Over the next quarter, we’ll focus on how we can turn this into a repeatable, efficient process that we can use in subsequent quarterly sprints.

In conjunction with this initiative, Slate and I have also been working on how to evaluate, report on, and measurably improve the effectiveness of the whole status-review process, as well as on synchronizing status-tag usage internally and externally — expect to hear more from us on those two topics in the near future.

---

Internally, this was a week of fast-paced cross-team collaboration, and a good experience that allowed us to target our focus on your requests. We’re hopeful this will become a way for us to address inconveniences, bugs, and requests around the network that might otherwise struggle to see the light of day — bearing in mind that some prioritization always needs to take place. We’re looking forward to future iterations, and hope you are too!

Please let us know below what you think of the Community Asks Sprint. Moderators - don’t forget to use the status-review tag to make sure these work items end up on our board. And users - don’t forget to vote! While we won’t ever rely solely on voting to determine our priorities, votes are a critical signal that lets us evaluate how much you want us to implement a feature on the network.

Additionally, please join me in thanking all the participants of this initial Community Asks Sprint (a total of 32 people across departments), with a special callout to the department leaders, and the core group that worked on the logistics to make it happen: Carrott, jkm, myself, Slate, and Troy Gould.

Answer 1

This is a good effort; the uptick in visible development work, even outside the flood of edits to status-review and status-deferred, was noticed and appreciated. This is pretty much exactly what we've been asking for a long time - more attention to community requests. This is a major step in the right direction.

In addition to the benefits the Community Asks Sprint brings to the community, there are also some internal benefits: this is an opportunity for engineers, product managers, and designers to work on issues they may not get to encounter on a regular basis and to touch on areas of the product they wouldn’t normally touch.

I'd love to hear a bit more about what the impression was of perhaps the more niche parts of the system. For instance, there was work on the election nomination page, and the review queues, neither of which are relevant to e.g. Teams and don't see much work on a regular basis. Did people learn a bit more about how the public system works?

---

One final note is that I was a bit disappointed by the initial set of comments on this post. They were, by and large, much more negative than I was expecting or felt was deserved. This was a major effort, involving over 30 different people, towards working on things that we've asked for, the lack of which has in the past been blamed for increasing tension between staff and community. So when steps were taken to fix that on the staff end, it was disappointing that it wasn't reciprocated with some positivity - or at least not outright negativity - in the initial community response.
If we want to see improvements to the platform and the community/company relationship, we need to be recognizing good faith efforts and responding in kind, not being immediately negative and potentially jeopardizing future similar efforts. Hopefully we can do better.

Answer 2

First and foremost, this sprint was great--all sprints should be like this (I know they can't really all be about shipping long-desired features or bug fixes, but still)!

Please convey to company leadership how happy users are that dev hours are being committed to bugs and feature requests your customers/users care about! The network's image and reputation among developers as still the go-to place for programming (or any specific topic) Q&A will only improve as more dev hours are dedicated to clearing the back-log of long-standing community requests.

I am especially heartened by this bit:

this is an opportunity for engineers, product managers, and designers to work on issues they may not get to encounter on a regular basis and to touch on areas of the product they wouldn’t normally touch.

Hopefully this means not only a greater appreciation for the complexities of the existing core product, but also will lead to a lower barrier to entry for devs to start addressing other issues that previously may have seemed too thorny to tackle.

---

but an older post would only climb the queue if it kept getting community attention despite its age.

I would urge you to be wary of this; just because a bug report does not have recent activity does not mean it is not still an important issue. Users can only make trivial edits to a post so many times before it becomes clear that we're basically just bumping it, which serves little purpose and is annoying to other users. Constant activity should play much less importance compared to age and score.

There's also, you have to admit, the large period of time where it seemed like SO staff was not interested in fixing bugs/implementing features that users asked for, which may have discouraged users from even trying to report on them in the first place. I know I have held off on posting a bug report before because I felt it wasn't worth the effort to provide detailed reproduction instructions when it was unlikely to ever even be acknowledged by devs, let alone worked on and fixed.

Answer 3

our plan is to dedicate time, across all our public-facing developer teams, to work exclusively on requests that have come in from the community

This is awesome and I can't find words to express how pleased I am :)

I really look forward to what this will produce, and I wholeheartedly agree on the internal benefits of getting staff exposed to the public sites.

My personal thanks to each staff member who participated in this first sprint.

I'm also glad that this is regularly scheduled (quarterly is great imo! honestly- more than I hoped for) and defined as a sprint (that is- it has a defined duration- whatever duration your sprints are). It gives me confidence that there's a plan and commitment to keep this going. And I'd really love this to keep on going long-term.

On prioritization

an older post would only climb the queue if it kept getting community attention despite its age

What kind of activity contributes to this? Like Tyler, I'm a little skeptical of whether this will produce a prioritization reflecting what we care about and how much we care about it.

This platform and its culture are pretty anti-noise. For example, we can be pretty disciplined about not piling on "I'm having this too" comments years after a bug was reported. I can only upvote once, and even if a post gets bumped enabling me to un-upvote and re-upvote to signal that I still care, that's not how I want this system to work. In other words, the system doesn't have a proper mechanism for me to say that I still care about something. And I personally think it's fair and workable to assume that if I cared about something X duration ago, I still care about it now.

Also, on the subject of prioritization, I wonder if (and that is my polite way of communicating personal values) a better way to start this off is to first focus on lower-hanging fruit that affects a lot of our quality of life. Stuff that's easy and non-controversial to implement, and maybe seems insignificant at a glance, but where the small improvement affecting a large group of users, or a relatively smaller, but highly actively helpful set of users results in a large net benefit. There are quite a few small rough edges that I face every day in my use of this platform and I can't help but feel like many of them shouldn't be too difficult to address, and that if they were addressed, my user experience would be much more pleasant.

If you're looking for ideas on mechanisms to see what users currently want prioritized, I'm not saying this is necessarily a good model (but just that it came to mind as something that stood out from systems where you just upvote once for all time), webpack has a thing. I don't know exactly how it works but it looks like there's some sort of mechanism for using more or less of your voting power on individual requests. Not sure if votes are movable at any time.

Answer 4

Firstly - whoa, quite a lot of old requests across the network were looked at, and retagged. The effort is appreciated. I do feel like there could have been better visibility, as Dan Mašek alludes to in the comments that - it had been announced first, and a follow-up posted to let folks know of the outcome

In general, while it occasionally makes sense to knock off a whole load of work/technical debt at one, it's also stuff that's accumulated over time. It is heartening to see the issues on hand are understood by folks, but there's also a matter of considering the core issues

it is not as effective as we’d like it to be at producing responses to the posts you’re escalating, nor at ensuring good backlog hygiene — at least not without regular coordinated clean-up efforts.

In a sense, many parts of the public platform are somewhat 'mostly' bugfixes at best, duct tape and good intentions at most. Since I was a MSE mod for a good chunk of the time since the current process started - I'd say to a significant extent, non 'bug' escalations were on the company's roadmap.

I'd note with no roadmap at the moment (Unless I missed it) - folks would be less inclined to bring up non bugfix issues, and practically, if things haven't changed, they wouldn't be escalated through these channels.

Working on these things ideally shouldn't be a sprint, it should be more of a distance event so to speak. I do realise that this is above the paygrade of the community team or developers but a lot of our current woes, everywhere are cause people have good ideas, it's done and not followed through.

I am pretty sure from the (few) employees I am and was in contact with that they're doing their best, so I'd argue almost that it is really a matter of sufficient resources to do the thing and prioritisation.

In addition to the benefits the Community Asks Sprint brings to the community, there are also some internal benefits: this is an opportunity for engineers, product managers, and designers to work on issues they may not get to encounter on a regular basis and to touch on areas of the product they wouldn’t normally touch.

I feel like this is a significant weakness - while admittedly it was a smaller organisation, and somewhat more focused, having an intimate understanding of the issues is useful - not an encyclopedic knowledge, but there's probably some dark, musty corners of the codebase ignored for years cause either the person working on it got realigned/retrenched/downsized/retired, or it didn't quite fit.

Likewise, there's a bit of mumblings about rarely seeing staff around any more (though I swear least one of my chatrooms got invaded by devs this week) - familiarity with the platform, and folks being familiar with you is likely to make some processes easier.

In a sense - that they don't encounter these things and certain parts of product on a regular basis seems to be something that makes things harder, not easier.

I'd like to see less of these - not because it's not appreciated, but because there are sufficient resources and will to focus, and not let these things pile up.

All in all, I appreciate the effort now, but I do hope there's more to this than the occasional backlog mitigation.

Answer 5

Not much to add to existing answers here, so I'll focus on a concern I have.

You said:

Over the next quarter, we’ll focus on how we can turn this into a repeatable, efficient process that we can use in subsequent quarters.

It does not say "the next Sprint will be in the next quarter", but rather something more... vague.

This makes me fear this might end like the Mentorship project that was also experimental and did not continue beyond the experiment stage.

So, is there a more clear ETA for the next Sprint? Or, worse case, chance it was a one time effort? I'd be glad for any official update. Thanks!

As a small token of appreciation, I made something for y'all who've worked hard on that:

Answer 6

Can there be some focus on reviewing the older status-planned posts as well? There appear to be only 19 questions with this tag, and some of them have been "planned" for a very long time. The oldest one I see was tagged in 2015! Some of the bugs and feature requests are probably obsolete, but others may be fairly easy to address but just have been forgotten. (My personal pet cause is moving the bounty button.)

Answer 7

First of all, thank you all for this effort! It genuinely feels good to see SE Inc. rebuilding trust with the community through their own initiative!

I take it the Community Ask Sprint is also the answer to my question here, asking why the recent change of the auto-comment for voting to close a question as a duplicate wasn't announced here (but on MSO)?

Similarly to that question, I believe it would be worthwhile to have network-wide requests and changes that were voiced elsewhere get a mention here on Meta, as well (most of the examples mentioned by the OP were actually posted on MSO).
For bugs this would be appreciated but not necessary (as Makyen points out in a comment here, bugs can and may be reported on any site, anyway), but for planned feature-request changes (like changes in auto-comments), this would allow for a proper meta overview and centralized feedback before these changes go live.

Depending on the amount and of changes, this could take the form of separate posts or of a single consolidated (Community Asks Sprint) post.

Answer 8

This seems like a useful and desirable effort to improve the UX. Thank you. I would suggest one of the two things, the latter of the two most likely more manageable and digestible.

• When a post is tagged status-completed and there is a reasonable question as to how you got to complete, add a follow up answer. A simple, "change the link to red" would not require follow-up but Does this answer your question duplicate comment text is silly and confusing) would benefit from some explanation (i.e. did you change the original text back, use suggested text, or change the UX in some other way). Just so we know.
• Roll up all the completed items into a single highlighted meta post, e.g. 2024Q2 Community Asks Released or some other title. This is reminiscent of software release notes we're all used to. If there's 5000 items, you can call out highlights like you did in your post and group and simplify the long tail (e.g. "various minor usability improvements").

Answer 9

While I appreciate the work the team has done recently, it does seem like a lot of routine work had to be done manually.

If instead there was a public bug/feature tracker (as we have asked for so many times over the years), then a bot could just post after a year of no activity "Is this still an issue?", and if there is no response, close it after a week.