1019219 - custom bugzilla field for firefox iterative process

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: Administration, task)

Description

[:Gavin Sharp [email: [e-mail]]]

The Firefox team is currently using whiteboard markers for tracking a couple of things:
- the bug's "iteration" code (e.g. s=it-32c-31a-30b.3)
- the bug's point estimate (e.g. p=3)

This is sub-optimal because it results in a lot of hard-to-filter bugspam when such metadata is edited.

I would like to move those annotations to a custom field that will be able to be easily filtered via bug 990980. I don't have a strong opinion about how to best do that - we could just introduce a "process-whiteboard" field that is free-form, and then stick the existing p=/s= markers in there. Having it be free-form makes it potentially useful for other people who want to use it differently, which might be a good thing or a bad thing :)

We would need these fields to be present for the same components as the firefox-backlog flag from bug 989118 (Toolkit, Firefox, Core, Mozilla Services, Firefox Health Report, Testing, Tracking).

Comment 1

[Marco Mucci [:MarcoM]]

The points value can be a drop-down selection to reduce human error input.  The default value for any new bug created should be p=0.  The options for selection should be:  0,1,2,3,5,8,13.

The iteration ID could be a free-form field of 's=' as Gavin suggested.  We will be reducing it to a simple ##.1, .2, .3 tag.

Comment 2

[Marco Mucci [:MarcoM]]

(In reply to Marco Mucci [:MarcoM] from comment #1)
> The points value can be a drop-down selection to reduce human error input. 
> The default value for any new bug created should be p=0.  The options for
> selection should be:  0,1,2,3,5,8,13.
> 
> The iteration ID could be a free-form field of 's=' as Gavin suggested.  We
> will be reducing it to a simple ##.1, .2, .3 tag.

Hey Gavin, would it be possible to have the 's=' update automatically similar to a tracking flag?  I was thinking, if possible, we could just mark '+' as a bug is newly added to an iteration.  When there is carry over, remove the '+' from the current iteration flag and add it to the next one.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

(In reply to Marco Mucci [:MarcoM] from comment #1)
> The points value can be a drop-down selection to reduce human error input. 
> The default value for any new bug created should be p=0.  The options for
> selection should be:  0,1,2,3,5,8,13.

This makes sense.

(In reply to Marco Mucci [:MarcoM] from comment #2)
> Hey Gavin, would it be possible to have the 's=' update automatically
> similar to a tracking flag?  I was thinking, if possible, we could just mark
> '+' as a bug is newly added to an iteration.  When there is carry over,
> remove the '+' from the current iteration flag and add it to the next one.

How about a single dropdown that has e.g. "33.1, 33.2, 33.3" values that get added/removed automatically as we progress through cycles?

Comment 4

[:glob 🎈]

(In reply to :Gavin Sharp (email [e-mail]) from comment #3)
> How about a single dropdown that has e.g. "33.1, 33.2, 33.3" values that get
> added/removed automatically as we progress through cycles?

from a bmo administration perspective, adding values to that field with each release cycle isn't an issue.

Comment 5

[Marco Mucci [:MarcoM]]

(In reply to Byron Jones ‹:glob› from comment #4)
> (In reply to :Gavin Sharp (email [e-mail]) from comment #3)
> > How about a single dropdown that has e.g. "33.1, 33.2, 33.3" values that get
> > added/removed automatically as we progress through cycles?
> 
> from a bmo administration perspective, adding values to that field with each
> release cycle isn't an issue.

Perfect, let's go with a single dropdown with the iteration values that are automatically added as we progress through each iteration.  Note, each release cycle has a ##.1, ##.2 and ##.3.  The label for the dropdown can be 'iteration'

For point selection, the dropdown label can be 'points'.  The default value is 0 and the available options for selection are 0,1,2,3,5,8,13.

Comment 6

[:glob 🎈]

sorry this has taken so long, ran into a few issues while creating one of the fields.

the fields are mostly set up, but i have a few questions:

> points:
> The default value is 0 and the available options for selection are 0,1,2,3,5,8,13

unfortunately we can't set the default value of a field to anything other than "---", nor can we rename or delete this value.  instead of having both "---" and "0" as point values, it may be better to treat "---" as "0", making the list  ---,1,2,3,5,8,13.  do you want to do this, or would you prefer ---,0,1,2,3,5,8,13 ?

> iteration:
> each release cycle has a ##.1, ##.2 and ##.3

what release cycles need to be in the field now?  i've added just 33.1, 33.2, and 33.3.
as the cycle moves forward, do older values need to be retired?

Comment 7

[Marco Mucci [:MarcoM]]

(In reply to Byron Jones ‹:glob› from comment #6)
> sorry this has taken so long, ran into a few issues while creating one of
> the fields.
> 
> the fields are mostly set up, but i have a few questions:
> 
> > points:
> > The default value is 0 and the available options for selection are 0,1,2,3,5,8,13
> 
> unfortunately we can't set the default value of a field to anything other
> than "---", nor can we rename or delete this value.  instead of having both
> "---" and "0" as point values, it may be better to treat "---" as "0",
> making the list  ---,1,2,3,5,8,13.  do you want to do this, or would you
> prefer ---,0,1,2,3,5,8,13 ?
> 
> > iteration:
> > each release cycle has a ##.1, ##.2 and ##.3
> 
> what release cycles need to be in the field now?  i've added just 33.1,
> 33.2, and 33.3.
> as the cycle moves forward, do older values need to be retired?

My preference is:  ---,0,1,2,3,5,8,13

The three release cycles you added are enough to start.  Yes, as the cycle moves forward the older values can be retired from the field.  All that matters is we can run search queries for release cycles that have passed.

Comment 8

[:Gavin Sharp [email: [e-mail]]]

(In reply to Marco Mucci [:MarcoM] from comment #7)
> My preference is:  ---,0,1,2,3,5,8,13

Why? I don't see a useful distinction between "---" and "0" in this case.

Comment 9

[Marco Mucci [:MarcoM]]

If we can search by "---" to identify bugs without a point value then we can omit using "0"

Comment 10

[:Gavin Sharp [email: [e-mail]]]

Yeah, that should work. So to clarify for Byron:
- let's use "---" instead of "0"
- let's keep the current and previous cycle's values current at any given time. That means that on merge day to cycle N, we add the 3 N values (N.1, N.2, N.3), leave the N-1 values, and disable all of the N-2 values.

Comment 11

[:Gavin Sharp [email: [e-mail]]]

(no need to add the 32 values right now, though)

Comment 12

[Marco Mucci [:MarcoM]]

(In reply to :Gavin Sharp (email [e-mail]) from comment #10)
> Yeah, that should work. So to clarify for Byron:
> - let's use "---" instead of "0"
> - let's keep the current and previous cycle's values current at any given
> time. That means that on merge day to cycle N, we add the 3 N values (N.1,
> N.2, N.3), leave the N-1 values, and disable all of the N-2 values.

Works for me.

Comment 13

[:glob 🎈]

cf_fx_iteration and cf_fx_points created, uplift process wiki page updated.