In various parts of the network I've been active at - there's occasional complaints of bug-fix requests, such as the Autocard Feature being bugfixed and the one here where lowered meta thresholds are broken

These requests have certain things in common - they're pretty low priority, and either further down or unlikely to be on the road map, but the impact that fixing these on their respective communities would be high.

Folks have also been... distinctly unhappy over them, and while they don't affect the broader network, they can be seen as quality of life issues for the respective sites. They are... nice things, even if they may not be essential in the wider scheme of things.

In both these cases the causes seem understood or well documented - they're just not high enough priority to get far enough up the roadmap to actually fix.

While I am aware of a few potential pathways to get these fixed, and that the public platform team's resources are limited, it seems that fixing these older issues where time/resources permit somewhat quicker would be welcome by the communities in question

What would be the process to get these requests revisited? Who's involved, and what would be the best ways to work with folks to get these issues triaged and sorted out?


2 Answers 2


Realistically, you shouldn't have to, and shouldn't want to.

Background: a scheduler-based model for evaluating effectiveness

Even if there was a way to do this (and there probably is - squeaky wheel gets the grease and all), squeaky-wheel-driven-development is something of a race to the bottom, pitting folks against each other over limited resources and ultimately rewarding those who both make the most noise and care the least about collateral damage.

Ultimately, this is akin to a scheduling problem: while there are numerous developers and designers working at SO, their time is managed by a handful of people based on a fixed set of priorities, which effectively limits what can be considered and the granularity with which time can be allocated. IOW, it's not enough to convince someone that a task is "important" - you effectively need to convince someone that it is more important than one of a handful of big chunky strategic projects. Which is why so many past examples of this strategy have involved massive Twitter polemics and the like...

What we're seeing now is actually an improvement over how it worked for years, when the algorithm was effectively "all resources go toward whatever project needs to be done tomorrow" and everything else was left to fight over resources that didn't officially exist. Meaning, stuff like bug fixes for Autocard effectively depended on a MTG fan on the dev team getting bored, and there was no way to report a meaningful status!

That said, it's clear from the data that the current scheduler is still very naive and unfair - and of course, this jibes with the sort of gut reaction we see in ourselves and others in response. Just as with early '90s operating systems (and, uh, 2010's Android) that seemed slow and unresponsive in spite of theoretically solid algorithms driving scheduling, the current process used at SO is at best a stop-gap until time can be devoted to something that actually works.

Actual answer

So to get back to your question: what's most needed here isn't pushing on individual tasks, it's more feedback on the perceived experience for all of them. Everything from little annoying bugs to big chunky world-breaking problems. Encourage folks to speak up, everywhere, every time - politely, but stridently. Give feedback on the roadmaps, point out when little things are overlooked and big things are just... not done.

Be the equivalent for SO of us grouchy Android users who finally motivated Google to stop screwing around with excuses after a decade+ and produce a usable phone.

And most of all... Don't get bogged down in minutia. There are literally thousands of things that should be being worked on here right now - and folks at SO whose job it is to make sure that they are. Don't try to do that job for them, just make sure they don't forget that they still need to do it!

  • 2
    Don't try to do that job for them, just make sure they don't forget that they still need to do it! Best line I've seen in a long time.
    – Chindraba
    Mar 24, 2021 at 22:02

This is a really thoughtful question. I know that it can be frustrating to see bug-fix requests lingering for a while without a response. As the team grows we're working to improve our timeliness. The Public Platform and Community Teams have been going through some of these older fix requests and have been evaluating and prioritizing them. As you can see in the two examples listed, one was recently completed and the other was recently deferred, meaning it's something we are planning to investigate and hopefully fix once we're able to get to it.

As you've mentioned the team's resources are limited so squashing bugs can take time. All of these bugs that are deferred are part of a backlog that the team is working hard to get through. If new bug fixes are reported and are determined to be a high priority due to their impact that takes time away from the backlog.

All of this being said there are a few things moderators and community members can do when reporting bugs that can help us prioritize some fixes so they don't fall through the cracks. As mentioned we do have a Roadmap which guides the requests that get prioritized (you can also refer to the accepted answer on this question, which will generally link to the most recent roadmap). It's worth noting that bugs are a bit different than feature requests. If a bug is severely impacting the functionality of a site or sites we do our best to make that a higher priority. That being said if you notice that a bug is potentially impacting something that is on the roadmap it's worth including that in your report or comments. If you notice a bug on one site and see that it may be impacting other SE sites as well that is also worth bringing to our attention since that would also play into its prioritization.

Bringing these insights won't guarantee that a bug will get fixed right away as other factors including resources, complexity, impact to SE overall play into prioritization, but they will help bring things onto our radar so we can triage them quicker.

You must log in to answer this question.

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