DOM/Triage

< DOM
Revision as of 20:07, 21 January 2016 by Overholt (talk | contribs) (Move from User:Overholt to here)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Let's ensure newly-filed bugs in a variety of DOM-ish components are actionable as soon as possible after their filing. This doesn't mean we're going to fix them sooner but that they'll be fixable when we get around to attempting to fix them. Inspiration taken from Platform/GFX/TriageSchedule.

New bugs

  • is this bug in the correct component?
  • ask for any missing information (ex. platform, URL, STR)
  • do we need a regression range?
  • CC people who should be CC'd
  • if this is a bug you think we should fix soon, assign or needinfo the person
  • if this is about a low-frequency intermittent bug that isn't on the top orange list, it's probably ok to ignore it
  • note: an assumption here is that bugs with non-nobody assignees are progressing toward a fix in some way

New "DOM" bugs filed in the past 48 hours

Orange bugs

  • are any of these in areas you can fix?
  • are any of these in DOM-ish components that aren't getting traction? can you politely nudge someone on the team to take a look?
  • are any of these obviously in the wrong component and moving them would help get closer to a resolution?

Top orange bugs

Chipping away at bugs that may have been forgotten

  • is there anything needed to make this bug actionable?
  • is this bug even valid anymore?

25 "DOM" bugs (there are more, this is just 25 of them) that haven't been touched for at least 4 weeks