1001202 - expose time tracking UI by default for users with can-edit privs

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: User Interface, enhancement, P1)

Description

[Brad Lassey [:blassey] (use needinfo?)]

We're duplicating this functionality with whiteboard flags right now, I think exposing it by default would be a better solution.

Comment 1

[:glob ✱]

i don't think that exposing the time-tracking ui to all users with editbugs is the right thing to do.  the UI is confusing and isn't applicable to most users.

exactly what group/team of users that you interact with need the timetracking fields?
can you provide examples of the whiteboard flags you currently use?

Comment 2

[Brad Lassey [:blassey] (use needinfo?)]

b2g is currently using [ETA MM/DD] and [ETA Needed] in the whiteboard. Other projects are using google docs mapping bug numbers to dates or bug numbers to estimates.

I understand the UI being a bit rough, but I've had it in my default view for a while now and it certainly doesn't get in the way. I don't agree with it being not applicable to most users, engineers are being asked for estimates of bugs fairly consistantly. Having that info maintained and requested out of band or ad hoc is more disruptive than having the UI in place. Also, hopefully with more eyes on it, things can be improved more quickly.

Comment 3

[:glob ✱]

> b2g is currently using [ETA MM/DD] and [ETA Needed] in the whiteboard.

eww.


it's probably applicable to most firefox/b2g engineers, however bugzilla tracks much more than that.

i'm not against enabling built in time-tracking on a group basis, however editbugs _is_ the wrong group for that, and i don't see any existing suitable group which covers firefox/b2g engineers (this would be easier if time-tracking was per-product, not per-user).


bmo already has a "due date" field, which can be enabled on a per-product or per-component basis.  we could enable that for the appropriate products, and if required add a new date field for tracking an ETA.  do you think that would be suitable?

Comment 4

[Brad Lassey [:blassey] (use needinfo?)]

I'd like to get a better solution... an ETA is more of an estimate than a due date. Also, as I said, people are tracking estimates for various projects in other forms (scrumbugs, google docs etc) and anything we can do to keep that info in bugzilla is a win IMO.

Why do you think edit-bugs is the wrong group? My assertion is that the vast majority of people using bugzilla are dealing with time estimates in some way. Bugzilla has a feature that handles that, so lets open it up to them. Do you disagree with the original assertion (that most users deal with time estimates)?

Comment 5

[:glob ✱]

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #4)
> Do you disagree with the original assertion (that most users deal with time estimates)?

i don't think that *all* users with editbugs deal with time estimates, and i have concerns about the UI noise this will add to an already confusing show_bug.

i'll raise this for discussion in our next bmo meeting.


suggestions:
- eta field (as per comment 3)
- hide the timetracking ui by default, behind an (edit) link
- add a user preference to opt-in to the timetracking ui
- code a simple ui hack to change the visibility of the timetracking ui to a per-product basis

we also need to consider products which use the current 'due date' field - if timetracking is enabled for editbugs users there will be two separate due_date fields on a bug.  this problem makes my forth suggestion of per-product visibility somewhat appealing.

Comment 6

[David Lawrence [:dkl]]

(In reply to Byron Jones ‹:glob› from comment #5)
> - hide the timetracking ui by default, behind an (edit) link

fwiw, this is the one that i would like to see.

dkl

Comment 7

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to David Lawrence [:dkl] from comment #6)
> (In reply to Byron Jones ‹:glob› from comment #5)
> > - hide the timetracking ui by default, behind an (edit) link
> 
> fwiw, this is the one that i would like to see.
> 
> dkl

yes, out of the four suggestions, that sounds best

Comment 8

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

I know story point estimates have come up as a request from EPMs, would exposing those on an as-needed basis per project/component be what we want here?

This is not the original scope of the request but something we could do during a change window.

Comment 9

[Brad Lassey [:blassey] (use needinfo?)]

Sorry, I don't manage a team at Mozilla anymore so I don't have useful information about how this is being used currently.

Comment 10

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Joel, which teams are looking for this? I can see about enabling it on a per-product/component basis.

Comment 11

[Joel Braddock :jbraddock]

Emma - I know some members of the Fx PMO group have looked for story point functionality. If you need specific names, please ping me.

Comment 12

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

I'm going to propose we enable the fields for people in the staff group, and for specific product/components who request it.

Later we should have it as a self-service configuration option.

Comment 13

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Do we want non-staff users to be able to see the field, but not edit it?

Comment 14

[Joel Braddock :jbraddock]

(In reply to Emma Humphries, Bugmaster ☕️🎸🧞‍♀️✨ (she/her) [:emceeaich] (UTC-8) needinfo? me from comment #13)

Do we want non-staff users to be able to see the field, but not edit it?

Yes, I think it should be visible to all, I don't see any harm in the data being visible, but not editable.

Comment 15

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Story points are already turned on for Firefox related products. They are editable by anyone (we'd need to convert the field to a flag to restrict editing.)

I'm going to close this for now, and if we want a different approach to time tracking, let's open a new bug.