218

You may have noticed posts getting 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 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 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):

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

17
  • 10
    Most of the mentioned examples are in MSO and I've never knew they existed until seeing bug reports about the changes posted here (e.g. suddenly users could close questions with a bounty, the auto comment for dupe closure changed out of the blue, etc.) . I'm curious why posting this announcement here, and not in MSO? (It's awesome, I'm just not used for good things here.) Commented Jul 1 at 13:08
  • 19
    Because the initiative is not restricted to SO work — it just so happened that in this iteration a good chunk of the posts we addressed were there.
    – JNat StaffMod
    Commented Jul 1 at 13:09
  • 7
    Well then, guess I better start a request/discussion on MSO asking the mods to migrate here bug reports and/or feature requests which are cross network. Anyway, thanks. Commented Jul 1 at 13:12
  • 3
    if they're old enough, can't be migrated anyway :D Commented Jul 1 at 13:16
  • 2
    I was wondering about a better title for this post, but then realized that this really should be two posts. For one, you're (belatedly) announcing the "Community Asks Sprint" initiative, and at the same time you're reporting results of the first such sprint. Then you'd have "New CAS initiative" and "Results of first CAS" instead of.. (dunno, something irks me about that style of headline).
    – Dan Mašek
    Commented Jul 1 at 13:35
  • 5
    Its a little late to announce it no? Commented Jul 1 at 13:39
  • 9
    Also - I think the more informal style 'fits' meta culture better. Good meta is somewhat informal - and the title feels like it tells the story. As somewhat of an active user on meta, I think its fine Commented Jul 1 at 13:59
  • 15
    @ShadowWizard Network policy is that bugs can be reported on any meta site. While it's probably reasonable to migrate in some limited circumstances (e.g., if the bug affects a single site which isn't the the site on which they were reported), that's not the case for bugs which are generally applicable to multiple sites. Yes, that means that bug reports are somewhat fragmented and that watching at least MSE and MSO is really required, due to the volume on both sites. But, no, we don't intend to generally migrate bug reports from MSO to MSE until and unless that network policy changes.
    – Makyen
    Commented Jul 1 at 14:05
  • 3
    What about status review on other sites?? on SO esp we ask for the IA banner 5 months ago.. and still we have no reply about it...
    – gbianchi
    Commented Jul 1 at 14:41
  • 5
    @gbianchi sorry for the delay! I'll reach out this week to get that sorted for you ^_^
    – JNat StaffMod
    Commented Jul 1 at 16:32
  • Fixes aside, I particularly appreciate how y'all are documenting and communicating this work. Any chance we could (eventually) get a complete list of the completed requests from this sprint, analogous to the release notes for a piece of software? That would not only help highlight the work you have done, but would also give us additional information to help us write better bug reports.
    – bta
    Commented Jul 5 at 17:09
  • 1
    The list provided in the post already provides the list of completed items, @bta — like I mentioned in the post, it is the list of issues that are marked as "done" in our internal tracking systems. For that reason, though, some that might still be getting the last touches will be added once shipped to production.
    – JNat StaffMod
    Commented Jul 8 at 9:46
  • 1
    This is good and all, but a hard commitment to spend more than a week each year on this would be nice.
    – OrangeDog
    Commented Jul 9 at 12:35
  • This is great! It's awesome to see some concerted effort poured into this side of the house. That said, somebody better figure out how to describe these efforts as "providing shareholder value" or I suspect we'll never get them again.
    – canon
    Commented Jul 9 at 12:49
  • 2
    Just wanted to say: thank you! That's all. 😄
    – Mentalist
    Commented 2 days ago

9 Answers 9

137

This is a good effort; the uptick in visible development work, even outside the flood of edits to and , 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.

10
  • 2
    Isn't it pretty much a universal thing in the corporate world that "good faith efforts" don't mean squat unless you have proper communication along with them? A good share of the blame for increasing tensions also go to the piss-poor communication strategy used by SE (i.e., no strategy at all)
    – muru
    Commented Jul 1 at 16:30
  • 29
    @muru In this case, the strategy they've tried is: "Here's a list of things that you've asked for that we were able to get to recently", with links to the reports on MSO/MSE. How exactly is that "no strategy at all"? Seems rather effective to me, and that's in addition to the responses and tags on the individual items as well. Do you have a more constructive suggestion for how you'd like communication of bug fixes to be different? Or, if SE remains a corporate entity, is it not possible for them to communicate to your standards? Commented Jul 1 at 16:40
  • 2
    @BryanKrause as the mentioned complaints state, most of these changes happened network-wide, and the first staff-authored Meta SE post announcing many of them was ... this one. The rest of the network outside of SO was just blindsided by these changes. If that's effective to you then we fundamentally disagree on how communication should work.
    – muru
    Commented Jul 1 at 16:44
  • 27
    @muru Not every change is worth a full press release. Would you rather staff spend their time fixing bugs or communicating with you every time they move? Gold tag badges are now applied to synonymized tags, and you found out about it today...are you sure "blindsided" is an appropriate way to communicate how this change has impacted you by not learning about it ahead of time? Commented Jul 1 at 16:51
  • 24
    @muru - The company is required to give advance notice for changes that "...substansively impact the user experience". I wouldn't classify any of the changes made here as meeting that definition. Most of the changes were also made known by changes to status tags as the changes were made. I don't think there's a problem with how it was done. It would have been nice to know about the overall effort ahead of time, but that shouldn't get in the way of recognizing the positives.
    – Mithical
    Commented Jul 1 at 16:55
  • 3
    While I refrained from negative comments, I did share my pessimism in chat, and I sadly stand behind it. There is nothing assuring us the company will keep this going. On the contrary: all past attempts started with bells and whistles, giving lots of hope and.... vanished into thin air, usually when the involved staff found themself outside of Stack Exchange. I do hope to be wrong, and to see SE actually listening to the users and keeping those Sprints going, but I just can't cling to such a faint hope. A tiger does not become a lamb just like that. Commented Jul 1 at 17:14
  • 12
    @ShadowWizard The long-term outlook is that everything we've ever done will be gone and forgotten. It's okay to appreciate good things, not only the second derivative of goodness.
    – wizzwizz4
    Commented Jul 1 at 17:26
  • 1
    @wizzwizz4 what muru said in the first comment also holds true. There's still no proper communication, they pick random requests and do them. Yes, I do appreciate the effort, and I never had anything against the developers or CMs themselves. The direction in which Stack Exchange is going is still wrong, the core problems are still there, unattended to. One might ask "OK. Shadow, so what do you want? What will satisfy you?" and the answer is, and I say it with sadness, is: nothing. I lost trust in the company already, and it's shattered beyond repair. Commented Jul 1 at 18:00
  • 20
    @ShadowWizard If it's beyond repair, why are you still here commenting? I wouldn't assume that the requests that were addressed were "random", and I also don't want them wasting time creating too detailed of a priority list. It seems like they've set aside some time to just crunch through the stuff that's been lingering. That's a good thing. Commented Jul 1 at 20:13
  • 8
    To answer your question, @Mithical: maybe it got lost in translation, but when I said "public-facing developer teams" in the initial paragraph of the "Introducing the Community Asks Sprints" section, I meant the teams that currently work on the public side of things — which is to say, Teams developers, for instance, didn't take part in this. The effort does, however, encompass folks who normally work on things related to ads, brand awareness projects, collectives, etc.
    – JNat StaffMod
    Commented Jul 2 at 14:54
66

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.

1
  • 6
    Re relying on votes and recent activity - for sure. Keep in mind that our goal is, in part, to trial this entire process from start to finish. This quarter's selection process was focused on producing a list of uncontroversial and readily recognizable community requests. The goal was to do just enough triage to get us started - other quarters might use a different process!
    – Slate StaffMod
    Commented Jul 2 at 14:40
36

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.

2
  • I'd argue for 'triage' activity is a reasonable sign. One potential downside is though folks tactically bumping, or rerequesting things - if its even a downside. I mean I do sometimes do this when the staff are working on something ancillary to my big wishlist :D Commented Jul 1 at 23:41
  • 10
    The prioritization method used this quarter was a rough cut at creating a list of uncontroversial and relatively recognizable community requests. It was just enough to get us started, and try out the associated processes, without worrying too much about how these action items would be received. Future quarters may use different methods as we play around to find what works best, as well.
    – Slate StaffMod
    Commented Jul 2 at 14:47
13

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.

1
  • 18
    To respond to why we didn't communicate beforehand: to put it simply, "undersell and overdeliver." Which really meant "don't sell it at all." We honestly weren't sure how much work we'd be able to get through, and so we made a decision to not mention it beforehand, lest we get everyone worked up and in the end fix one bug or something. Granted, we were aware that y'all might say "why didn't you tell us before," but given the context it seemed like there was little benefit in doing so, and little risk in foregoing it. In the end, we decided to show, not tell. Possibly different next time.
    – JNat StaffMod
    Commented Jul 2 at 15:00
12

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:

thank you Carrot, jkm, JNat, Slate, and Troy

4
  • I do agree. In my initial readings, it's been easy for me to assume from the phrasing that the sprints and traging will both be quarterly, but in a more critical reading, it doesn't seem to be spelled out that way here, unless I missed it. OTOH, upcoming initiatives peer post links to this Q&A with the text "Community Asks quarterly event"
    – starball
    Commented Jul 3 at 21:05
  • 6
    There were some mentions of "quarterly" up there — "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." — but I recognize they mention prioritization will happen quarterly, but don't explicitly mention the sprints themselves will. That is completely by lapse, and not because we're deliberately being vague. Made some edits that hopefully make it clearer. The plan is, indeed, to do these every quarter. Feel free to make edits to make that more explicit.
    – JNat StaffMod
    Commented Jul 4 at 8:46
  • @JNat thanks. So to nitpick even further, "each quarter" means once every three months, give or take couple of weeks, right? (i.e. not e.g. in June, then only in November which is technically still in the next quarter) Commented Jul 4 at 8:50
  • 7
    The plan is that the last sprint of each quarter is a community asks sprint, yes.
    – JNat StaffMod
    Commented Jul 4 at 8:54
8

Can there be some focus on reviewing the older 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.)

2
  • 3
    Yup! Planning on going over all the stale status tags ;)
    – JNat StaffMod
    Commented Jul 3 at 15:11
  • 8
    We actually went through a significant number of these already. Only four weeks ago, there were 190 posts in [status-planned] network-wide; today, there are 46!
    – Slate StaffMod
    Commented Jul 4 at 23:14
5

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 s 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 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.

3
  • 2
    If I'm reading you correctly, the concerns you have are more easily addressed by redirecting posters from local Metas to MSE, when they're reporting bugs or requesting features that are likely to have a network-wide impact — that would ensure _ community discussion_ happens in a broader stage, rather than a staff announcement.
    – JNat StaffMod
    Commented Jul 3 at 12:38
  • 3
    Part of the challenge of the sprint is its short nature, which is somewhat at odds with doing a lot of pre-comms, and back and forth (doesn't mean "ship and forget" of course) — see Slate's comment here for a note on how we tried to pick issues that were relatively uncontroversial in terms of solutions, because they'd already been discussed and had seemingly reached a community consensus.
    – JNat StaffMod
    Commented Jul 3 at 12:38
  • Thanks, @JNat, that makes a lot of sense.
    – Joachim
    Commented Jul 3 at 16:59
3

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 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").
2
  • 2
    They usually do add an answer, but sometimes in case there are other answers, the answer is lost among them and isn't trivial to find when the OP doesn't mark it as accepted. In your example, here is the answer. If you can find other examples please edit, but IMO in that aspect they're doing fine. Commented Jul 12 at 12:38
  • Thanks for pointing that out! I do agree it requires a bit of effort to find. Obviously, I didn't in this case. I really think option 2 is a better fit.
    – Kit
    Commented Jul 12 at 12:52
-13

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.

7
  • if it's just a comment, that'd require the person who posted it to interact in one way or another. but i think it also wouldn't make much sense if it posted an answer that wasn't an answer
    – Kevin B
    Commented Jul 1 at 14:25
  • 2
    @KevinB I'm proposing using a tracker that is actually designed for the job, rather than shoehorning it into the SE Q&A software. They're already using a tracker anyway! It's just private. If it was made public, and configured effectively, then old requests no one cares about anymore would be taken care of automatically. Commented Jul 1 at 14:42
  • 2
    meta.stackexchange.com/questions/401033/… vaguely asks for that. I do feel like where some feature requests are pending for extended periods of time though, autoclosure might mean community requests occationally end up dying of neglect and old age Commented Jul 1 at 15:06
  • 1
    @JourneymanGeek I've seen it work well on Github where anyone can respond to keep the ticket alive. If it's configured like that then even if the original poster disappears the ticket won't have to be closed. Commented Jul 1 at 15:15
  • 17
    "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." I don't intend to try and reproduce errors for the whim of a bot. Some of the bugs I've found are tricky to capture and report - they take time and effort. If SE are not willing to invest it by looking into the bugs, then it's better to purge the whole of [bug] rather than make users jump through hoops: "It reproduces the bug or it gets closed again!" is not what I want a bot to be telling me for taking the time and effort to report something.
    – VLAZ
    Commented Jul 1 at 16:53
  • 6
    One of the more frustrating experiences of interacting with issues on GitHub, which is a formal tracker, is dealing with "stale issues" bots. I strongly oppose bringing such a system here; time alone is pretty much orthogonal to whether something should be addressed, and it penalizes longer-lasting, harder to diagnose issues. Age might make it less important, but I don't think it's a very strong indicator in of itself.
    – zcoop98
    Commented Jul 2 at 15:54
  • 9
    Honestly, while a lot of the posts we reviewed were routine (concerned decomissioned products, e.g.), most required actually sitting down and reading the issue to decide whether it was still relevant, and whether it still/ever needed staff attention. Fully automated bulk actions are always a bit of a risk when it comes to issue reporting. If you're curious, here's a picture of the flowchart I created for folks to use when validating open issues. (We didn't stick strictly to this; more meant as a helpful guide than a rigid process.)
    – Slate StaffMod
    Commented Jul 2 at 19:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .