Death to Zombies (and the OMG label)

Tech
1

PSA for ourselves internally but I figured I’d put it here in case anyone else wanted to nerd out about such things:

  1. We’re killing the OMG label. I recently found (thanks to my new freshgish goal, discussed in another thread) a gissue marked OMG that was over a year old. Facepalm.
  2. We’re adding a new label ZOM for regressions. Also we shouldn’t tolerate any regressions, so zombies should be shot twice in the head pretty immediately.
  3. Thanks to Mary for adding the NRP label for “needs repro steps”. Bugs kind of don’t count until they have a Proper Bug Report, though it’s worth immediately capturing anything that might count as a bug and worry about properness later.
And finally, mercifully collapsed unless you're reading this in email, here are all the labels we're currently using in our issue-tracker...

(We have a fun (for highly idiosyncratic definitions of “fun”) blog post about the labels we use in our issue tracker – “Our Label Ontology For Issue Tracking” – but it’s a little bit out of date.)

   
BUG Opposite of feature
RFE Request For Enhancement, aka feature request
UVI Will count as a User-Visible Improvement
STY Style/polish/CSS, or think of it as in pigsty or an eyesore
MEN Mendoza = need to resolve before deploying, part of MVP
PEA Easy-peasy
SKY Pie in the sky (would be awesome but not necessarily worth the effort)
ABC Non-technical, like prose or webcopy tweaks
ADO Questions about what to Actually Do (or “much ado about ∅”)
NRP Needs repro steps
ZOM Regression, aka zombie bug
INF Infrastructure, opposite of UVI
   
zap (closed as) Fixed
nix (closed as) Won’t fix or invalid
zzz (closed as) Postponed, aka snoozed
cnr (closed as) Could not reproduce
dup (closed as) Duplicate
aok (closed as) Feature, opposite of bug, by design
3 Likes
2

I realized today that the thing we use the Mendoza label for, GitHub’s Milestones feature may do that better. If there’s a feature you want to ship or some deadline you have, just create a Milestone and associate all the related gissues with it.

So we might be able to get rid of the MEN label. I think @mary hates that anyway. I don’t know if we can stop calling such things mendozas though…

1 Like
3

Why does @mary hate it?

4

Sorry we failed to answer this! I think she just thought the term “mendoza” was ridiculous, or maybe especially abbreviating it “MEN”, which, fair enough.

Anyway, some updates…

Labels we’ve removed:

  • NRP – covered by either BUG + ADO, BUG + help_wanted, or just BUG with “TODO” where the steps to reproduce go
  • aok – use nix + zap for this
  • MEN – replaced by GitHub’s milestone feature

And we’ve replaced zzz, as a reason for closing a gissue, with ZzZ. Same concept, just that snoozed gissues are left open. That was per @mary. (I disagreed at the time but now like her way better.)

And when in doubt between two labels, use both. Common example: PEA + SKY means “no idea how hard this will be”, typically awaiting the assessment of someone more technically clueful, like @bee… Or BUG + RFE means “maybe counts as a bug, maybe just a feature request” – probably for me as chief decider person to decide.

Ok, continuing with things that only @bee and @adamwolf and I care about…

(feel free, Bee and Adam, to skip ahead to the “Maybe let’s just say…” part)

What To Do About Zombies

We have 57 zombies shambling (plus 3 more in Beebrain I mean Beebraaaaiiins). :scream: :zombie:

Many/most aren’t really regressions and are just tagged that speculatively/tentatively just in case, awaiting (dis)confirmation. But still, that’s bad and we’re losing points on the Joel Test. Gulp. Here are things we could do.

1. Do a zombie-only sprint

The point of zombies is that they’re unacceptably bad/embarrassing (see PDP, etc) and when they appear, they preempt other things. So let’s bite the bullet on that and refuse to touch anything but zombies for 2 weeks. Part of that can be removing ZOM tags when we have any excuse to do so. It’ll be pretty great to be at ZOM Zero!

(Open philosophical question: Does a regression not count as a regression anymore after sufficiently much time has passed? In some ways that feels true but also awfully slippery slopey. Like we really, really want to not let that happen in the first place and… game theory something something. I guess I have a Bad Feeling about un-ZOMming something purely for being too stale and am tentatively saying no to that. :cloud_with_lightning:)

2. Philosophical stance: ZOMs are orthogonal to sprint planning

Zombies are beeminded and redqueened and that’s just one of the background things like beemails and meetings and kvetching about noobs in #supsup or whatever that happens in parallel with the sprints. It could simplify sprint planning and gissue curation to trust that all zombies are being dealt with separately, maybe?

3. I’m overthinking this. All gissues are fair game in sprint planning.

The bigger the ZOM backlog the more bias we should have for including more ZOMs in the sprint but other than that, what we’re doing is fine.

Maybe let’s just say with 57 zombies shambling, we need about 10 in this sprint – one per weekday. To that end, I just added some more ZOMs to the IDEAS column on the sprint board. Feel free to swap them for better ZOMs!

One way or another, we do need to work our way to ZOM Zero and stay there.

Corpora animatus delenda est!

2 Likes
5

I don’t remember hating it (…or even noting that it was abbreviated “men”). I just remember that the only thing that “Mendoza” brought to mind for me was the How I Met Your Mother reference to the hot/crazy scale. (The term is still an empty sound to me as far as what you actually use(d) it for! Something deadline-related it seems, given the context above.)

1 Like
6

It’s a great term! Andy (@apb)'s the one who coined it (in the sense we use it). A Mendoza is … wait, I can quote the blog post (also pro tip: just google “beeminder mendoza” if you forget):

The idea with marking issues as Mendoza (MEN) is that if it’s part of a new feature branch or a new product, it can’t be merged or released until all the Mendozas are done. The Mendoza Line is a baseball term referring to a minimum threshold of acceptability. It’s similar to the notion of a Minimum Viable Product. (Which is what we mean by ‘MVP’, not to be confused with the baseball term ‘MVP’ which means ‘Most Valuable Player’. This is what we get for mixing baseball and software metaphors!)

Anyway, marking something Mendoza is kind of like an OMG label for really important stuff. We used to use OMG but we ruined that one with overuse so we settled on the idea of a Mendoza line since it has a more specific meaning than “definitely do this”. Namely, we’re agreeing not to launch this new thing until everything tagged MEN is resolved (or we relent and un-Mendoza it). In the past we’ve also used the Mendoza label after deploying something. We’d mark all the issues that needed to be resolved before we felt we could shift gears and focus on something else. It turns out that’s a slippery slope. It devolves into an endless sea of “definitely do this” items, just like with an OMG label. So we’ve learned not to do that anymore.

I guess in How I Met Your Mother they were adapting the baseball term in a similar way that we/Andy did.

2 Likes
7

Update!

This is still just an internal memo but some of you nerds like nerding out with us about such things so…

Terminology reminder:

The actual memo:

We’re dispatching ZOMs at a pretty good rate, just that it’s exactly matching the rate at which we’re creating new ones. We’re quite liberal about calling things ZOMs though, so it’s not as bad as it seems. Lots of these just need to be scrutinized and decided they don’t warrant the ZOM label after all.

In any case, it’s important that we get the current number (58) inexorably decreasing, no matter how slowly. We did manage to hit ZOM-zero in the Beebrain repo and I believe that’s true for Beedroid and BeemiOS as well. Yay us!

8

An update on this thread (repeated from a recent daily beemail):

After some improvements to our SMS bot today, we’re down to 8 regressions in our bug tracker. That’s out of 585 issues total. A regression refers to something that got worse about Beeminder. Like a violation of the Pareto Dominance Principle – The Pareto Dominance Principle for Apps and Websites | Beeminder Blog

Also we call regressions “zombies” for some reason. (And for some reason we didn’t settle on “zombees” – too obvious, I guess?) Or zoms for short. (Or “zombs”, with a mostly silent b, adds @bee.)

Anyway, a while back we decided that we need to treat any regression as a five-alarm fire and started beeminding our way to zombie-zero. We were up to 50some or higher (!) at some point – though some turned out not to count as zombies – and at 23 zoms outstanding we started beeminding them. I think that’s around when the low-hanging fruit was picked clean.

In case you’re curious, here are the 8 that are still shambling:

  1. some dumb daylight savings bug
  2. some dumb thing about rounding in the ratchet UI
  3. some other dumb thing with rounding in the data tab
  4. a very rare burgle bug with premium double charges that we’re able to shirk-n-turk
  5. some weird cornercase in Fitbit goal creation
  6. autodata landing pages even wonkier on mobile than they used to be
  7. some excruciating race condition mostly causing rare BeemiOS duplicate datapoints
  8. another weird race condition with entering data at just the right moment after the deadline but before we’ve processed the derailment

If you’ve personally noticed any of those – or know of a regression not on that list! – please let me know.