I am not worried about this potential problem. It doesn't have to be perfect, some folks (release managers, qa, etc) will check that the values are correctly set. In parallel, you probably noticed that we have a bot (autonag) which automatically set/update a bunch of values.
@Felipe: yeah, the team classified by hand a lot of bugs to evaluate that. This is the main case for which it is hard to differenciate task & enhancement. However, don't think it is a big deal (as long as they aren't marked as defects). Le mar. 12 mars 2019 à 20:56, Dan Mosedale <dmosed...@mozilla.com> a écrit : > I've looked at the UX spec and Sylvestre's announcement, and I have > some relevant experience here working on teams which have used the > "enhancement" value of the "severity" field with the intent of using > that information to monitor our rate of defect introduction. > > That workflow has turned out to have a footgun that has polluted our > usage, which appears to me to be replicated here, and which I think > has a simple fix. I'd be curious to hear thoughts: > > In particular, the severity field defaults to "normal", which we'd > like to use to mean a "normally severe defect". Unfortunately, > because the default is set to "normal" and because Bugzilla has such a > large number of fields, what it actually means in practice is either > "normally severe defect" or "bug-filer was in a hurry or not paying > attention", with no easy way to tell the difference. And that happens > a non-trivial amount of the time. > > Some fields in bugzilla have a "---" value (including severity, but > it's not the default). This can be used to mean "not-entered" or > "untriaged", completely eliminating the "hard-to-detect-bad-data > issue". > > I'm concerned that the Type field as currently proposed (i.e. no --- > field as default) has effectively the same footgun, which will make > the data we gather with it less useful. > > Thoughts? > > Dan > > Am Di., 12. März 2019 um 12:10 Uhr schrieb Felipe G <fel...@gmail.com>: > > > > Does performance work count as "enhancement" or "task"? > > On one hand, it's not strictly refactoring.. On the other hand, it is not > > development of a new feature, per the proposed description of > enhancement. > > > > On Tue, Mar 12, 2019 at 3:20 PM Onno Ekker <o.e.ek...@gmail.com> wrote: > > > > > On 12/03/2019 18:59, Sylvestre Ledru wrote: > > > > Le 12/03/2019 à 17:48, Andrew McCreight a écrit : > > > >> <snip> > > > >> Secondly, to bikeshed a little, could there be some name besides > > > >> "task" for > > > >> that third category? Like I said above, everything we work as > > > >> developers is > > > >> a developer task. "Refactor" seems like a clearer name, though maybe > > > >> it is > > > >> a little limiting. "Side grade"? :) > > > > > > > > This is more than just refactoring. It is more "as an engineer, here > is > > > > what I have to do". > > > > > > Maybe call it "Engineering"? "Maintenance"? > > > _______________________________________________ > > > dev-platform mailing list > > > dev-platform@lists.mozilla.org > > > https://lists.mozilla.org/listinfo/dev-platform > > > > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
