Triage Process for New Feature / Meta Bugs

[J. Ryan Stinnett]

The triage process we've been trialing so far seems to break down a
bit for new feature work and meta bugs used for planning. The current
priority assignments for triage are mainly focused around bugs for
things that are broken.

For the case of meta bugs specifically, should they be excluded from
the process by changing our dashboard to ignore them? It seems a bit
silly to mechanically set P3 or something just so that they leave the
dashboard...

For the case of new feature bugs (bugs that are not regressions or
problems with current features), do they basically all get P3
according to the triage rules? Or should they have special handling?

There has also been some discussion of these issues on firefox-dev[1].

[1]: https://groups.google.com/d/topic/firefox-dev/Amae2YVf-S8/discussion

- Ryan

[Brian Grinstead]

> On Apr 11, 2016, at 1:14 PM, J. Ryan Stinnett <jry...@gmail.com> wrote:
>
> The triage process we've been trialing so far seems to break down a
> bit for new feature work and meta bugs used for planning. The current
> priority assignments for triage are mainly focused around bugs for
> things that are broken.
>
> For the case of meta bugs specifically, should they be excluded from
> the process by changing our dashboard to ignore them? It seems a bit
> silly to mechanically set P3 or something just so that they leave the

> dashboard…

I’d rather have the dashboard modified to ignore these than need to do the bookkeeping in bugzilla.

> For the case of new feature bugs (bugs that are not regressions or
> problems with current features), do they basically all get P3
> according to the triage rules? Or should they have special handling?

This isn’t clear to me either. I’ve been filing a lot of bugs for devtools.html planning that don’t fit in the normal triage/prioritization process. And, once we start working on them, we may want to use ‘P1’ to mean 'it’s being worked on within the next couple of week’ (which is different than the expected value of P1 for the new triage process). So maybe they should all be P3 all the time, with some other means for tracking what’s being worked on. (I don’t know if that’s a good idea or what, but I do feel bad about filing new development bugs and then having people ‘triage’ them, so maybe I’ll preemptively set as P3). Another thing we could do is use a whiteboard tag to get bugs to be removed from dashboard.

Brian

[Patrick Brosset]

I've started to use the "enhancement" [1] flag on bugzilla for those (at
least for some of them).
You're right, P1, P2, P3 for a new feature does not have the same meaning
as for something that's broken. If we flag those new feature bugs as
"enhancements", then we can still use those priorities any way we like and
use this flag to ignore them from whatever triage tool/process we use.

Patrick

[1] https://dl.dropboxusercontent.com/u/714210/enhancement.png

On Mon, Apr 11, 2016 at 11:49 PM, Brian Grinstead <bgrin...@mozilla.com>
wrote:

> _______________________________________________
> dev-developer-tools mailing list
> dev-devel...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-developer-tools
>

[Joe Walker]

I've updated the triage sheet [1] to ignore bugs that have an importance
set to 'minor', 'trivial' or 'enhancement'. i.e. anything below the default
of 'normal'.

It seems reasonable to use 'enhancement' for much of the devtools.html work.

[1]:
https://docs.google.com/spreadsheets/d/1ZsZiCLN_nvEdaw1iTz54_b7I1uzo0Dt4bwrJgdMD75U
<https://docs.google.com/spreadsheets/d/1ZsZiCLN_nvEdaw1iTz54_b7I1uzo0Dt4bwrJgdMD75U/edit#gid=45619545>



On Tue, Apr 12, 2016 at 8:15 AM Patrick Brosset <pbro...@mozilla.com>
wrote:

[J. Ryan Stinnett]

On Tue, Apr 12, 2016 at 9:01 AM, Joe Walker <jwa...@mozilla.com> wrote:
> I've updated the triage sheet [1] to ignore bugs that have an importance set
> to 'minor', 'trivial' or 'enhancement'. i.e. anything below the default of
> 'normal'.
>
> It seems reasonable to use 'enhancement' for much of the devtools.html work.

Okay, great! And for meta bugs, should those be ignored by the "meta"
bug keyword, or should we set one of these low severity settings on
them?

- Ryan

[Joe Walker]

I think we can use 'enhancement' for those?
Sometimes meta bugs use the summary too, sometimes they're not marked. I'm
thinking that having a standard 'enhancement' marker for new things is
simple, and doesn't rusk running hugely expensive bugzilla queries on a
regular basis.

Joe

[J. Ryan Stinnett]

On Tue, Apr 12, 2016 at 9:27 AM, Joe Walker <jwa...@mozilla.com> wrote:
> I think we can use 'enhancement' for those?
> Sometimes meta bugs use the summary too, sometimes they're not marked. I'm
> thinking that having a standard 'enhancement' marker for new things is
> simple, and doesn't rusk running hugely expensive bugzilla queries on a
> regular basis.

Seems reasonable to me, I'll clean up a few I've noticed recently.

- Ryan

[J. Ryan Stinnett]

Should we change the triage dashboard to ignore meta bugs and enhancements then?

I'll make an attempt assuming it sounds like a good plan.

- Ryan

[Joe Walker]

I've changed the functions in the triage dashboard to ignore 'enhancement'
bugs already. I've also found 4 bugs, 3 with [meta] in the summary, and one
other that I marked as enhancements.

Happy for you to check my working, but I think we're ok

Joe.

[J. Ryan Stinnett]

Yes, everything looks good, thanks for making those changes.

I had actually sent the previous message you just replied to several
days ago (before you had made any changes), but it got trapped in some
email hell because one of Google's email servers is on a spam list.
And then it went through today, by which time it no longer made any
sense.

Sorry for the confusion!

- Ryan