This is something I've been curious about since starting this whole 'meta' thing a couple years back.

Let's say a user posts a feature request.

  • Under what circumstances is the feature-request read by staff?
  • If staff decline to do anything (I'd guess it's some sort of triage), under what circumstances is the feature-request re-evaluated by staff?

Let's say a user posts a bug.

  • Under what circumstances is the bug tested?
  • What generally determines whether a verified bug is actionable? (And/or what are the criterion for deciding what to do?)

For both of the above, would it be possible to see a general-but-relatively-detailed flow for what happens to these questions?


1 Answer 1


It's a bit of a patchy system, but in a nutshell:

  1. The community team patrols each per-site meta as they check in on individual sites. They (we) regularly do the following:

    • Bring bugs that haven't been seen to the attention of the core team
    • Bring feature requests that we find interesting to a feature meeting that we hold weekly, responding to the request afterward
    • (Depending) Just fix / implement whatever is being requested, if it doesn't require a code change to do (activate MathJax, copy changes, etc)
  2. The developers have a special view to see all bug / feature tags across the network. The person on bug duty basically picks up the patrol from the last person, and works on them. Note that:

    • This can often circle back to features the community team might be working on
    • Sometimes things 'block' while product design-ish stuff is going on and we know we're going to be touching a lot of code in the vicinity soon anyway

Most testing / etc happens on our side (trying to reproduce it), which might lead to us going to the development tier and trying there, or ultimately going to an internal chat room and seeing if someone else can reproduce or figure it out.

Pretty much all bugs are tested, even the ones where we don't quite have enough information from the person reporting to test it - we still look. It's also quite common to see bug reports coming from our contact form (often the path of least resistance for someone that just wants to be helpful but has limited time)

What does not happen, which we hope to find a way to automate, is some kind of 'presence' indication that something has at least been seen by staff and when. While we do occasionally leave a comment like:

Leaving a comment to let you know this has been seen, but it might be a while before anything else moves here

... that's not always possible or practical especially if you're working from a special filtered view.

In essence, the developers are (more or less) the primary patrol, followed by folks on the community team checking on their assigned sites, followed by your appointed / elected moderators sending us a ping if something is forgotten, followed by folks in the community reaching out if they think something fell through the cracks.

It's not a perfect system, and occasionally things that we really do wish we had seen sooner don't come to light as quickly as they should have. But, given our size and sort of loosely-coupled organization, we do pretty well for the most part.

There's also the bug and feature fairy, but you have to code PHP at midnight in a dark bathroom in footed pajamas in front of a mirror in order to summon her and the last person that tried it hasn't been quite right since.

  • 3
    TL;dr: a bunch of monkeys mashing buttons until it works :O
    – Braiam
    Jan 16, 2015 at 13:50
  • 2
    I wouldn't say mashing, it's more like ... cautiously punching.
    – user50049
    Jan 16, 2015 at 18:43
  • 1
    TBQH I think bugs and feature requests should be on a issue-tracker-like site. I don't think the SE format works well for it but it's been shoehorned in due to metaness. Jan 22, 2015 at 10:11
  • @Lightness Nothin' quite like literal user stories.
    – user206222
    Jan 22, 2015 at 10:39

You must log in to answer this question.