Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Dealing with operational bugs.
13 views
Skip to first unread message
Jean-Yves Perrier
Sep 22, 2014, 2:30:24 AM9/22/14
to mdn-drivers
Hi!
Since we introduced triaging of new bugs earlier this year, we see a big
improvement in bug fixing. A lot more bugs are fixed and big ones get
attention. It isn't perfect but it is a big improvement with what we had
before.
Nevertheless we have a class of bugs that are often forgotten: the
operational bugs.
These are not bugs in the underlying software but bug in its
configuration. Example of such bugs are adding a new language to the MDN
or fixing a DB problem that prevent 50 pages to be displayed.
During the triage meetings, these kind of bugs often got low priority
and just get forgotten. These are never blockers, we don't want devs to
stop all work to take care of these. Nevertheless, when time passes, the
important of these gets greater: we have volunteers or writers waiting
on these to be fixed to do some job
We are waiting for several months for Serbian to be created or we have
50 add-ons related page inaccessible in French for three weeks. In both
cases, we have volunteers waiting on these to be fixed.
How can we get more attention to these operational bugs? Should we set a
much higher severity (blocker?) when we do the initial triaging? Should
we bump the severity of these after a few weeks if nothing happens?
(Does this have any effect?) Or should we maintain a separate list (or
component) for these bugs so that we can track these more precisely.
--
Jean-Yves Perrier
Staff Technical Writer / Mozilla Developer Network
Since we introduced triaging of new bugs earlier this year, we see a big
improvement in bug fixing. A lot more bugs are fixed and big ones get
attention. It isn't perfect but it is a big improvement with what we had
before.
Nevertheless we have a class of bugs that are often forgotten: the
operational bugs.
These are not bugs in the underlying software but bug in its
configuration. Example of such bugs are adding a new language to the MDN
or fixing a DB problem that prevent 50 pages to be displayed.
During the triage meetings, these kind of bugs often got low priority
and just get forgotten. These are never blockers, we don't want devs to
stop all work to take care of these. Nevertheless, when time passes, the
important of these gets greater: we have volunteers or writers waiting
on these to be fixed to do some job
We are waiting for several months for Serbian to be created or we have
50 add-ons related page inaccessible in French for three weeks. In both
cases, we have volunteers waiting on these to be fixed.
How can we get more attention to these operational bugs? Should we set a
much higher severity (blocker?) when we do the initial triaging? Should
we bump the severity of these after a few weeks if nothing happens?
(Does this have any effect?) Or should we maintain a separate list (or
component) for these bugs so that we can track these more precisely.
--
Jean-Yves Perrier
Staff Technical Writer / Mozilla Developer Network
Eric Shepherd
Sep 22, 2014, 10:55:34 AM9/22/14
to mozilla-m...@lists.mozilla.org
On 2014-09-22 06:30:24 +0000, Jean-Yves Perrier said:
> We are waiting for several months for Serbian to be created or we have
> 50 add-ons related page inaccessible in French for three weeks. In both
> cases, we have volunteers waiting on these to be fixed.
>
> How can we get more attention to these operational bugs? Should we set a
> much higher severity (blocker?) when we do the initial triaging? Should
> we bump the severity of these after a few weeks if nothing happens?
> (Does this have any effect?) Or should we maintain a separate list (or
> component) for these bugs so that we can track these more precisely.
This is a good and important question, and it's something that comes up
> We are waiting for several months for Serbian to be created or we have
> 50 add-ons related page inaccessible in French for three weeks. In both
> cases, we have volunteers waiting on these to be fixed.
>
> How can we get more attention to these operational bugs? Should we set a
> much higher severity (blocker?) when we do the initial triaging? Should
> we bump the severity of these after a few weeks if nothing happens?
> (Does this have any effect?) Or should we maintain a separate list (or
> component) for these bugs so that we can track these more precisely.
often. There's a class of bugs which are not necessarily a urgent, but
they have an intangible kind of importance to them because of the way
they impact a particular subset of our users or contributors.
As Jean-Yves says, these bugs don't need to be fixed within hours of
being filed, but should be fixed reasonably promptly in order to (a)
let our contributors or readers continue to work, and (b) let them know
we care about their problems.
We need to find a way to help make these get done in a reasonable
amount of time without overly disrupting ongoing work.
--
Eric Shepherd
Developer Documentation Lead
Mozilla
Blog: http://www.bitstampede.com/
Twitter: @sheppy
Luke Crouch
Sep 26, 2014, 3:13:55 AM9/26/14
to Jean-Yves Perrier, mdn-drivers
On 9/21/14 11:30 PM, Jean-Yves Perrier wrote:
> Hi!
>
> Since we introduced triaging of new bugs earlier this year, we see a big
> improvement in bug fixing. A lot more bugs are fixed and big ones get
> attention. It isn't perfect but it is a big improvement with what we had
> before.
>
> Nevertheless we have a class of bugs that are often forgotten: the
> operational bugs.
>
> These are not bugs in the underlying software but bug in its
> configuration. Example of such bugs are adding a new language to the MDN
> or fixing a DB problem that prevent 50 pages to be displayed.
>
> During the triage meetings, these kind of bugs often got low priority
> and just get forgotten. These are never blockers, we don't want devs to
> stop all work to take care of these. Nevertheless, when time passes, the
> important of these gets greater: we have volunteers or writers waiting
> on these to be fixed to do some job
>
> We are waiting for several months for Serbian to be created or we have
> 50 add-ons related page inaccessible in French for three weeks. In both
> cases, we have volunteers waiting on these to be fixed.
>
> How can we get more attention to these operational bugs? Should we set a
> much higher severity (blocker?) when we do the initial triaging? Should
> we bump the severity of these after a few weeks if nothing happens?
> (Does this have any effect?) Or should we maintain a separate list (or
> component) for these bugs so that we can track these more precisely.
Yeah, it seems like these bugs are very case-by-case basis for
> 50 add-ons related page inaccessible in French for three weeks. In both
> cases, we have volunteers waiting on these to be fixed.
>
> How can we get more attention to these operational bugs? Should we set a
> much higher severity (blocker?) when we do the initial triaging? Should
> we bump the severity of these after a few weeks if nothing happens?
> (Does this have any effect?) Or should we maintain a separate list (or
> component) for these bugs so that we can track these more precisely.
priorities, but I have some thoughts on these suggestions ...
Higher priorities during initial triage will create more
interrupt-driven workflows.
We should only bump severity if the severity actually changes - e.g., if
the issue starts to affect more users or more data. Age of bug should
not increase severity, or the oldest bugs in the backlog will always be
the most important.
A comment ping on a bug is a good way to get a dev to look at them
again. Especially a comment with any new info and/or a :needinfo? for a
specific update request.
-L
>
> -- Jean-Yves Perrier Staff Technical Writer / Mozilla Developer Network
> Mdn-d...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/mdn-drivers
>
--
Q: Why is this email five sentences or less?
A: http://five.sentenc.es
0 new messages