Review Milestone-related fields
Categories
(bugzilla.mozilla.org :: Bug Creation/Editing, enhancement)
Tracking
()
People
(Reporter: emceeaich, Unassigned)
References
Details
(Keywords: feature)
Reporter | ||
Comment 1•6 years ago
|
||
Several teams have requested the ability to schedule future work.
An example is sprints within a release cycle. Another would be program milestones.
We have the iteration
custom field which can be associated to a product/component, but the field has one set of values.
That field is used by the Activity Stream components in Firefox, so the values are specific to this team.
There's a number of ways we could do this:
- Create additional custom fields for other iteration formats
- No backend programming needed
- May require custom programming to expose field in bug modal UI
- Use the tracking-flags type to create iteration formats
- No new programming needed
- Field is exposed in bug modal UI
- Tracking-flags UI is painful
- Create a new field type and UI
- New backend needed
- New UI needed
Of these, #2 may be the best path forward. In order to set up milestones for the Fission project, we used a tracking flag. See bug 1523620.
Reporter | ||
Updated•6 years ago
|
Comment 2•6 years ago
|
||
We already have the Target Milestone field, right? However itβs kinda misused.
The Target Milestone field is used to define when the patch landed first. Relying on status flags is usually safer.
But the original purpose is, as the name suggests:
The Target Milestone field is used to define when the engineer the bug is assigned to expects to fix it.
We have Status fields like cf_status_firefox65
to track βwhen the patch landedβ and Target Milestone is being used redundantly for Firefox bugs. I feel itβs time to use the field in the right way :)
Comment 3•6 years ago
|
||
More thoughts:
- Target Milestone is a plan/goal/expectation/hope. It usually has to be set when the assignee starts working on the bug or even when the bug is filed, not after the fix is landed.
- Stop using Firefox versions as milestones. It might be useful in the past, but it doesnβt fit the current rapid release model that ships periodically with thousands of bugs fixed. I know VS Code uses monthly milestones but it does work because there are
only handfulnot a huge number of issues. - Start using milestones more on Bugzilla. On GitHub, milestones are heavily used depending on the repository. Examples: Firefox Accounts, Firefox Add-ons, Common Voice
- Use milestones for any project tracking purposes such as Fission M1, Quantum Extreme Season 2 or whatever.
- Need a milestone dashboard page like GitHub so people can grasp the progresses at a glance.
- Let product owners (new concept) add/remove/edit/close milestones, including the description and deadline.
Comment 4•6 years ago
|
||
By the way, if the Target Milestone field is used wisely, we donβt need meta bugs. I see having meta/tracking bugs as a UX failure due to unusable milestones (no dashboard; only admins can edit.)
Comment 5•6 years ago
|
||
Ryan is a heavy user of the Target Milestone field :-) He might have something to say.
Reporter | ||
Comment 6•6 years ago
|
||
Allowing people to manage milestones as they do on GitHub would be a huge win for users.
Updated•6 years ago
|
Comment 7•6 years ago
|
||
I think this bug to add a new field can be WONTFIXed? The Iteration field, Fission Milestone field, and Whiteboard-written milestones... All have to be eventually merged to the UX-improved Milestone field, and we donβt need yet another one π
Reporter | ||
Comment 8•6 years ago
|
||
I'd rather not close this, but we can turn it into a bug to cover what we need to do with existing fields and field types. Would you mind if I reopen this so we don't lose the conversation?
Comment 9•6 years ago
|
||
Iβve filed Bug 1527001 to analyze all the existing fields (and shared my draft doc with Emma et al.) but letβs continue dealing with Milestone-related fields in this bug then π
Reporter | ||
Updated•6 years ago
|
Reporter | ||
Comment 10•6 years ago
|
||
You're right, :kohei, I think we did reach a conclusion here. We'll investigate using existing fields and I'll track that in bug 1527528.
Description
•