Closed Bug 1525202 Opened 5 years ago Closed 5 years ago

Review Milestone-related fields

Categories

(bugzilla.mozilla.org :: Bug Creation/Editing, enhancement)

Production
enhancement
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: emceeaich, Unassigned)

References

Details

(Keywords: feature)

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:

  1. Create additional custom fields for other iteration formats
  • No backend programming needed
  • May require custom programming to expose field in bug modal UI
  1. 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
  1. 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.

See Also: → 1523620

We already have the Target Milestone field, right? However it’s kinda misused.

By Mozilla’s definition,

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 :)

Flags: needinfo?(kohei.yoshino)

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 handful not 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.

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.)

Ryan is a heavy user of the Target Milestone field :-) He might have something to say.

Flags: needinfo?(ryanvm)

Allowing people to manage milestones as they do on GitHub would be a huge win for users.

See Also: → 1527001

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 😅

Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(ryanvm)
Resolution: --- → WONTFIX

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?

Flags: needinfo?(kohei.yoshino)

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 😀

Status: RESOLVED → REOPENED
Flags: needinfo?(kohei.yoshino)
Resolution: WONTFIX → ---
Summary: Planned Milestone Field → Review Milestone-related fields

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.

Status: REOPENED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.