[Development] Setting the priority of bug reports created the Qt Support team

[Shaw Andy]

[snip]

> > What I would like to suggest that we do now is bring back this practice, so
> that the Qt Support team will set a priority on the bugs that it creates or
> handles, so that it makes things easier for the maintainers to actually see
> what issues are potentially a higher priority than the others. And in the case
> of the high priority issues, it will draw attention to them faster rather than
> them being picked up later on in the process. I have also discussed this with
> the developers inside Digia, and they see a need for getting help when
> triaging the bugs, so having the Qt Support team set a priority here would at
> least go some way to helping with that. Of course any priority set by the Qt
> Support team is intended to be a guideline, the maintainer would still be at
> liberty to change it if they disagree.
> 
> I assume you mean that any approver would still be at liberty to edit
> the priority if they disagree, basically that there's nothing special
> about the priority just because it was set by Qt Support.

Yes, that is my intention, it should only be seen as a guide based on the person who triaged the issue since the person creating it would have verified the bug before having created it in this case. But if an approver disagrees then that is up to them and therefore it can be changed as appropriate.

> Then there's just the theoretical problem of non-approvers setting bug
> priorities, which is that most people think their bugs are top
> priority. I'm pretty sure the Qt Support team is sensible enough that
> they don't do that, so I think it would be helpful for them to be
> setting (initial) priorities.
> 
> It would be nice to expand the concept to something more general, like
> a 'trusted triagers' status, but that can come as a later step.

I agree, long term having such a group would be good because there will always be untriaged bugs that come in from other sources currently.

Andy