Bug 495985

Summary: [RFE ] Hide Severity/Priority field from everyone except the maintainer/developer
Product: [Community] Bugzilla Reporter: Jóhann B. Guðmundsson <johannbg>
Component: Creating/Changing BugsAssignee: David Lawrence <dkl>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.2CC: awilliam, emmanuel, itamar, jlaska, kevin, markmc, mcepl, nelhawar
Target Milestone: ---Keywords: FutureFeature, Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://bugzilla.mozilla.org/show_bug.cgi?id=81457
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-06-19 15:39:40 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
Patch to disallow editing of priority/severity for non 'fedorabugs' members (v1) nelhawar: review+

Description Jóhann B. Guðmundsson 2009-04-15 16:21:58 EDT
Description of problem:

Given the simple fact that the only person(s) truly capable of assessing the 
severity/priority of a report and thus adjusting an existing workload accordingly and to prevent confusion among both reporters and triagers.

Hide these fields from everyone except the person(s) that are directly responsible for either maintaining or developing the component.  

Note the severity/priority settings of this report has been intentionally 
set to urgent to prove a point. 

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 seth vidal 2009-04-15 16:55:34 EDT
+1. Owner/Maintainer-only field. To help us sort our bugs.
Comment 2 Emmanuel Seyman 2009-04-16 04:42:06 EDT
(In reply to comment #0)
> 
> Given the simple fact that the only person(s) truly capable of assessing the 
> severity/priority of a report and thus adjusting an existing workload
> accordingly and to prevent confusion among both reporters and triagers.

I question this (although I'll admit this is highly dependant on how much your triagers are able to ascertain the priority of a bug).

> Hide these fields from everyone except the person(s) that are directly
> responsible for either maintaining or developing the component.

Hide ??? I'm strongly opposed to hiding this information. In the case of an open source project, priority and severity can be used by users to choose which bug to focus on should they want to become contributors.
Comment 3 Emmanuel Seyman 2009-04-16 06:08:52 EDT
(In reply to comment #0)
>
> Note the severity/priority settings of this report has been intentionally 
> set to urgent to prove a point. 

Changing.
Comment 4 Jóhann B. Guðmundsson 2009-04-16 06:44:18 EDT
(In reply to comment #2)
> (In reply to comment #0)
> 
> Hide ??? I'm strongly opposed to hiding this information. In the case of an
> open source project, priority and severity can be used by users to choose which
> bug to focus on should they want to become contributors.  

If some one wants to become an contributor to a project I would have expected
the first thing that person would do would be to establish communication with
the owner(s)/maintainer(s) who then would direct him to which parts of the code
needs most attention.

After communication link has been established the owner(s)/maintainer(s) would
grant access or enable if you will the severity/priority to that person.

Not that it really matters if it's hidden or not as long as owner(s)/maintainer(s) controls who have access to do so.
Comment 5 Jóhann B. Guðmundsson 2009-04-16 07:05:58 EDT
(In reply to comment #3)
> (In reply to comment #0)
> >
> > Note the severity/priority settings of this report has been intentionally 
> > set to urgent to prove a point. 
> 
> Changing.  

Another point.. 

I could change the severity/priority back to urgent because I as some new reporter might think or feel that this is an extremely urgent matter and should be resolved asap ( common view amongst new reporters their bug is the N1 bug ) and thus this would end up being a change severity/priority status war between owner(s)/maintainer(s) and the reporter..
Comment 6 Emmanuel Seyman 2009-04-16 08:17:38 EDT
(In reply to comment #4)
> 
> If some one wants to become an contributor to a project I would have expected
> the first thing that person would do would be to establish communication with
> the owner(s)/maintainer(s) who then would direct him to which parts of the code
> needs most attention.

In my experience, the directions are usually "Go to the bugtracker, search for bugs with the keyword 'intro bug', start swinging" but YMMV. Not having access to
the priority or severity field 

> After communication link has been established the owner(s)/maintainer(s) would
> grant access or enable if you will the severity/priority to that person.

On a person by person basis? Sounds time-consuming (amongst other problems).

> Not that it really matters if it's hidden or not as long as
> owner(s)/maintainer(s) controls who have access to do so.

So something like the letsubmitterchoosepriority parameter but valid throughout the bug's life-cycle ? I can imagine upstream accepting this request for the priority field but not the severity one (the latter being much more user oriented than the former). See bug #81457 on bmo for details.

(In reply to comment #5)
>
> I could change the severity/priority back to urgent because I as some new
> reporter might think or feel that this is an extremely urgent matter and
> should be resolved asap ( common view amongst new reporters their bug is
> the N1 bug ) and thus this would end up being a change severity/priority
> status war between owner(s)/maintainer(s) and the reporter..

Editwars on a bugtracker are exercises in futility for all bodies involved.

The correct value in the priority and severity fields is the one that best matches the definitions in fields.html, nothing else If you want to indicate the bugs you most want fixed, you should use the voting system. That's what it's there for.
Comment 7 Jóhann B. Guðmundsson 2009-04-16 10:45:39 EDT
> On a person by person basis? Sounds time-consuming (amongst other problems).

Person by person or group(s) depends on what the owner/maintainer wants.

For an example the default could be be to grant access to everyone that has completed the necessary steps required to join the Fedora Developers Team. 

Not sure how fine grained nor what is the current status regarding access control in bugzilla is. 

Looking at #90619 on bmo it looks like it's not in that good shape.. 


> Editwars on a bugtracker are exercises in futility for all bodies involved.

Agreed. 

> The correct value in the priority and severity fields is the one that best
> matches the definitions in fields.html, nothing else If you want to indicate
> the bugs you most want fixed, you should use the voting system. That's what
> it's there for.  

Having a voting system is just as futile attempt as allowing end user playing with severity/priority fields in trying to get a bug fixed faster.

Afaik the only way to get bug fixed faster is to provide patch(es) money or sex... 

And as I see it the severity/priority are tools strictly for owners/maintainers to keep track of bugs in context with several other bugs on the component(s) they maintain.
Comment 8 Emmanuel Seyman 2009-04-22 09:05:12 EDT
(In reply to comment #7)
> 
> For an example the default could be be to grant access to everyone that has
> completed the necessary steps required to join the Fedora Developers Team. 

This is Fedora-specific. We can't do this in the bugzilla package.

> Having a voting system is just as futile attempt as allowing end user playing
> with severity/priority fields in trying to get a bug fixed faster.

Occasional contributors have been known to use votes to decide which bugs
they focus on.

> And as I see it the severity/priority are tools strictly for owners/maintainers
> to keep track of bugs in context with several other bugs on the component(s)
> they maintain.

I agree with regards to priority but severity is very much a reporter-oriented field.
Comment 9 Jóhann B. Guðmundsson 2009-04-22 11:09:17 EDT
(In reply to comment #8)
> (In reply to comment #7)
> This is Fedora-specific. We can't do this in the bugzilla package.

I just used Fedora as an example.. 

More general sample would be default hide( or show ) from all then 
whitelist either per user ( login name ) or per domain.. 
(john@example.com, *@redhat.com, *@bugzilla.org etc.. )

> 
> > Having a voting system is just as futile attempt as allowing end user playing
> > with severity/priority fields in trying to get a bug fixed faster.
> 
> Occasional contributors have been known to use votes to decide which bugs
> they focus on.
> 
> > And as I see it the severity/priority are tools strictly for owners/maintainers
> > to keep track of bugs in context with several other bugs on the component(s)
> > they maintain.
> 
> I agree with regards to priority but severity is very much a reporter-oriented
> field.  

In a bugzilla instance where only experienced reporters live then this indeed can be considered an reporter-oriented field that is used in useful manner and
thus could be beneficial to the maintainer(s)along with the ability to vote.

In the case where bugzilla instances are open to everyone ( or has as minimal threshold in joining like this one ) as in anyone can report regardless of their technical knowledge then this cannot be considered useful because you will always have a large set of users basing the severity on their gut feeling/state of mind rather than the technical knowledge/relevance of the bug they encounter which will then eventually lead to the maintainer(s) to ignore the severity status of the report(s) and thus render the severity status existence useless...
Comment 10 Adam Williamson 2009-05-26 12:56:46 EDT
This will mostly be done as part of the bugzappers team's severity / priority project: severity will be accessible only to bugzappers and maintainers, priority only to maintainers. if the bugzappers trial does not go well it would make sense to limit severity only to maintainers as well.
Comment 11 Adam Williamson 2009-05-27 19:27:41 EDT
At David's request, here's exactly what we in QA/Bugzappers would like to see:

the "severity" field should be settable by members of the 'fedorabugs' group and maintainers.

the "priority" field should be settable by maintainers of the component on which the bug is filed only.

obviously, we only care about Fedora bugs, here. If this could be applied only to Fedora bugs, that would be ideal. If not, it may need to be adjusted for the RHEL process, so everyone who requires the power to set priority/severity in the RHEL process would have it.

anyone who usually has the sort of superpowers that allow them to do whatever they like to bugs could be allowed to set these too, I suppose. I don't know exactly what the normal situation is there. but that's our basic plan.
Comment 12 David Lawrence 2009-06-03 13:59:56 EDT
(In reply to comment #11)
> At David's request, here's exactly what we in QA/Bugzappers would like to see:
> 
> the "severity" field should be settable by members of the 'fedorabugs' group
> and maintainers.
> 
> the "priority" field should be settable by maintainers of the component on
> which the bug is filed only.
> 

When you say maintainers of the component in relation to Bugzilla, do you mean the current assigned_to of the bug report or the components default assigned_to person even if the bug report had been reassigned to someone else in the past?

> obviously, we only care about Fedora bugs, here. If this could be applied only
> to Fedora bugs, that would be ideal. If not, it may need to be adjusted for the
> RHEL process, so everyone who requires the power to set priority/severity in
> the RHEL process would have it.
> 

We should be able to limit it to Fedora product only in the code. All other products would get the default restrictions.

> anyone who usually has the sort of superpowers that allow them to do whatever
> they like to bugs could be allowed to set these too, I suppose. I don't know
> exactly what the normal situation is there. but that's our basic plan.  

There is the group 'editbugs' that is normally allowed by default to make any change to any bug. This group currently automatically inherits those in 'redhat' and 'fedora_contrib' groups. If the user is not in 'editbugs' group, then only reporter, assigned_to, and qa_contact can edit the bug. Except for adding cc and comments which anyone can do as long as they are logged in and can see the bug.

Dave
Comment 13 Adam Williamson 2009-06-03 16:48:17 EDT
"When you say maintainers of the component in relation to Bugzilla, do you mean
the current assigned_to of the bug report or the components default assigned_to
person even if the bug report had been reassigned to someone else in the past?"

That's a good question. Probably both of those should have access.

"There is the group 'editbugs' that is normally allowed by default to make any
change to any bug. This group currently automatically inherits those in
'redhat' and 'fedora_contrib' groups. If the user is not in 'editbugs' group,
then only reporter, assigned_to, and qa_contact can edit the bug. Except for
adding cc and comments which anyone can do as long as they are logged in and
can see the bug."

Hmm...so, basically anyone who's a maintainer can edit any attribute on any bug? Well, if we follow that policy, the 'editbugs' group should have access to these fields, I guess, though that makes the "only the maintainer of the actual component" restriction in the proposal a bit pointless.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 14 Mark McLoughlin 2009-06-04 05:57:22 EDT
(In reply to comment #13)
> "When you say maintainers of the component in relation to Bugzilla, do you mean
> the current assigned_to of the bug report or the components default assigned_to
> person even if the bug report had been reassigned to someone else in the past?"
> 
> That's a good question. Probably both of those should have access.

Anyone who can commit to the package? i.e. those with the commit ACL or in either of the provenpackager/sponsor groups
Comment 15 David Lawrence 2009-06-04 09:41:53 EDT
(In reply to comment #14)
> (In reply to comment #13)
> > "When you say maintainers of the component in relation to Bugzilla, do you mean
> > the current assigned_to of the bug report or the components default assigned_to
> > person even if the bug report had been reassigned to someone else in the past?"
> > 
> > That's a good question. Probably both of those should have access.
> 
> Anyone who can commit to the package? i.e. those with the commit ACL or in
> either of the provenpackager/sponsor groups  

Currently Bugzilla has no connection with any build systems, scm's or other external database's so we would need to go on what Bugzilla knows about a bug report. Such as reporter, assigned_to, qa_contact, cc members, component owners, and user's in specified groups.

Dave
Comment 16 Adam Williamson 2009-06-04 15:12:56 EDT
actually I would say "anyone who can commit to the package" would _not_ make sense: just having commit rights doesn't imply you're in a position to prioritize work on the package. It implies that we believe provenpackagers somehow are able to prioritize the workload on any package in the distribution, which I don't think is an accurate assumption. Hence my suggestion that it be restricted to the actual assignee / default assignee.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 17 Kevin Kofler 2009-06-09 19:12:19 EDT
Why do we need to be so restrictive? If the problem is that random users set priorities, can't we just let everyone in fedorabugs set them? I think having overly strict ACLs on these fields buys us nothing, it just hinders our work. The person fixing the bugs is not necessarily the default assignee (in KDE, more often than not it isn't, we're maintaining the packages as a team, there's no one maintainer who can define the priorities on his own).
Comment 18 Adam Williamson 2009-06-09 20:29:30 EDT
I was trying to be considerate to maintainers by ensuring no-one else would screw with your preferred priority ordering, but that's a good point - several groups work by assigning bugs to lists, so it would be a pain in that case. It feels like trying to solve that by defining which bugzilla accounts are in each group would be a pain, so maybe it should just be anyone in fedorabugs after all. Matej, as this was your proposal, what's your take? would that be OK, as long as the policy stated that only involved maintainers *should* set the priority?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 19 Matěj Cepl 2009-06-10 10:42:29 EDT
Well, I thought that priority is something which is no business of anybody else than the real maintainer of the package how she organizes her work on packages (unless she has some stooge ... like me ;-) ... to do it for her), so for me it couldn't be even visible to anybody else than maintainers. Which would actually decrease the pain for reporter of seeing a bug being moved from urgent to low ;-).

As concerning severity, I would be on the other hand very relaxed ... basically any bug triager should be able to fix them. Just reporters should not be able to do anything more than hopelessly fuming over their most precious bug being set to severity low.
Comment 20 Adam Williamson 2009-06-10 12:24:44 EDT
sure, but see kevin's post - he points out that it's actually quite hard to reliably define who's a "maintainer" in that context for each package. I think it'd probably be safe to just restrict it to fedorabugs, but note in the appropriate policy pages that only maintainers of the package should set it. I don't think we'd get people acting in bad faith.

I'm not sure it's practically possible to hide the fields from non-fedorabugs members, but David can explain that I guess.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 21 David Lawrence 2009-06-10 16:26:32 EDT
(In reply to comment #20)
> sure, but see kevin's post - he points out that it's actually quite hard to
> reliably define who's a "maintainer" in that context for each package. I think
> it'd probably be safe to just restrict it to fedorabugs, but note in the
> appropriate policy pages that only maintainers of the package should set it. I
> don't think we'd get people acting in bad faith.
>

Making it just based on product == 'Fedora' && in_group('fedorabugs') would make this a trivial change so I lean toward that myself from a BZ maintainer perspective. 
 
> I'm not sure it's practically possible to hide the fields from non-fedorabugs
> members, but David can explain that I guess.

Custom fields as we use them can be made invisible as we do that quite a bit for internal processes. Priority/Severity on the other hand arecore BZ attributes and are not easily hidden but can be made read-only quite easily.

Dave
Comment 22 David Lawrence 2009-06-16 13:48:42 EDT
(In reply to comment #21)
> (In reply to comment #20)
> > sure, but see kevin's post - he points out that it's actually quite hard to
> > reliably define who's a "maintainer" in that context for each package. I think
> > it'd probably be safe to just restrict it to fedorabugs, but note in the
> > appropriate policy pages that only maintainers of the package should set it. I
> > don't think we'd get people acting in bad faith.
> >
> 
> Making it just based on product == 'Fedora' && in_group('fedorabugs') would
> make this a trivial change so I lean toward that myself from a BZ maintainer
> perspective. 
> 
> > I'm not sure it's practically possible to hide the fields from non-fedorabugs
> > members, but David can explain that I guess.
> 
> Custom fields as we use them can be made invisible as we do that quite a bit
> for internal processes. Priority/Severity on the other hand arecore BZ
> attributes and are not easily hidden but can be made read-only quite easily.
> 
> Dave  

So, I just need to know what the final design will be. Should I just make the priority field only editable by those in the 'fedorabugs' group if the bug is filed against the product Fedora?

Thanks
Dave
Comment 23 Adam Williamson 2009-06-16 21:12:21 EDT
Yes, I think that's fine for now: both severity and priority editable only by those in 'fedorabugs'. We can revisit tightening it up if we get people editing priority in bad faith, but I don't envisage that happening.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 24 David Lawrence 2009-06-17 16:41:02 EDT
Created attachment 348343 [details]
Patch to disallow editing of priority/severity for non 'fedorabugs' members (v1)

Thanks Adam.

Noura, could you please review this patch please?

Thanks
Dave
Comment 25 Noura El hawary 2009-06-18 08:18:38 EDT
Comment on attachment 348343 [details]
Patch to disallow editing of priority/severity for non 'fedorabugs' members (v1)

Hi Dave,

Patch looks good, tested on bz-web2 and works fine only couple of things inline:


>+    # Fedora product related restrictions
>+    # field IN (severity, priority) AND value_changed AND in_group(fedora_bugs) THEN ALLOW ELSE NOT-ALLOW

is it fedora_bugs or fedorabugs just a mismatch between the comment and the actual code.

>+    if ( $self->product_obj->name eq 'Fedora' ) {
>+        if (($field eq "severity" || $field eq 'priority') && $newvalue ne $oldvalue ) {

and here it needs to be $field eq "bug_severity"  for it to find the field.


other than that all works perfect.

Cheers,
Noura
Comment 26 David Lawrence 2009-06-18 10:57:23 EDT
Thanks Noura. Actually I am going to stick with fedora_bugs and not fedorabugs to be consistent with other group naming. I fixed your issues and checked it in. Should be in the next update.

Dave
Comment 27 Mark McLoughlin 2009-06-19 06:17:47 EDT
Hmm, has something changed here already? I'm in the fedorabugs group and I now can't change priority or severity in e.g. bug #504444
Comment 28 Noura El hawary 2009-06-19 07:58:18 EDT
Hi Mark,

actually there is not a fedorabugs or fedora_bugs group in bugzilla, shall we add this group? what was the deal and who should be in this group, can you see this group in your bugzilla permissions?

Noura
Comment 36 Adam Williamson 2009-06-19 12:36:17 EDT
Noura: fedorabugs is a FAS group. Everyone in that FAS group should have access to change those fields in Bugzilla.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 38 David Lawrence 2009-06-19 12:55:15 EDT
(In reply to comment #36)
> Noura: fedorabugs is a FAS group. Everyone in that FAS group should have access
> to change those fields in Bugzilla.
> 
> -- 
> Fedora Bugzappers volunteer triage team
> https://fedoraproject.org/wiki/BugZappers  

Adam, please educate me on what the FAS group is and how would we get a list of current members (mapped to Bugzilla accounts) so that we can do a mass update to got those into the right group.

Dave
Comment 39 Adam Williamson 2009-06-19 15:24:20 EDT
you must have a mapping already, because it's already used for bugzilla permissions. I don't understand how you wouldn't know about that. :) we already have to add people to the fedorabugs group in order for them to have triage privileges, so it's obviously mapped to something in bugzilla already. is it just the editbugs group?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 40 David Lawrence 2009-06-19 15:37:18 EDT
(In reply to comment #39)
> you must have a mapping already, because it's already used for bugzilla
> permissions. I don't understand how you wouldn't know about that. :) we already
> have to add people to the fedorabugs group in order for them to have triage
> privileges, so it's obviously mapped to something in bugzilla already. is it
> just the editbugs group?

Ok, I must have misunderstood. Yes we have had the 'fedora_contrib' group for quite a while now which is the only specific to Fedora group that I am aware of. And yes that group inherits 'editbugs' automatically. So maybe I should have just keyed this latest change to the 'fedora_contrib' group instead of creating a new 'fedora_bugs' group but none the less I can fix it where those in 'fedora_contrib' are automatically in 'fedora_bugs' without changing any code.

Dave
Comment 41 David Lawrence 2009-06-19 15:39:40 EDT
ok done. re-closing.