Re: [tor-dev] Trac priorities and severities

Hi David. Personally I find the split severity and priority redundant but that's fine (milestone, tor version, and other fields are only applicable to core tor - it's easy to ignore yet another field). However, in this case you made it mandatory by giving it a default. Mind making priority optional

Re: [tor-dev] Trac priorities and severities

> On 14 Oct 2015, at 23:13, George Kadianakis wrote: > > David Goulet mailto:dgou...@ev0ke.net>> writes: > >> On 07 Oct (11:56:32), David Goulet wrote: >>> Hello tor-dev! >>> >>> While 028 bug triaging, we realized that we *really* need priorities to >>> not be a banana field deprive of useful

Re: [tor-dev] Trac priorities and severities

David Goulet writes: > On 07 Oct (11:56:32), David Goulet wrote: >> Hello tor-dev! >> >> While 028 bug triaging, we realized that we *really* need priorities to >> not be a banana field deprive of useful meaning. If you are unaware or >> don't remember, the priority field in a trac ticket can be

Re: [tor-dev] Trac priorities and severities

On 07 Oct (11:56:32), David Goulet wrote: > Hello tor-dev! > > While 028 bug triaging, we realized that we *really* need priorities to > not be a banana field deprive of useful meaning. If you are unaware or > don't remember, the priority field in a trac ticket can be: > > blocker critical ma

Re: [tor-dev] Trac priorities and severities

On Thu, Oct 8, 2015 at 4:37 AM, Tim Wilson-Brown - teor wrote: > > On 8 Oct 2015, at 05:01, Nick Mathewson wrote: > > On Wed, Oct 7, 2015 at 11:56 AM, David Goulet wrote: > > Hello tor-dev! > > While 028 bug triaging, we realized that we *really* need priorities to > not be a banana field depriv

Re: [tor-dev] Trac priorities and severities

Hi, Yes, renaming to a more meaningful thing is great. Also, if only some group can grade entries, then it is wise to have an 'uncategorised' category which appears in a grading list towards, but not at the bottom. Field experience in these systems tells me that people get annoyed at being auto

Re: [tor-dev] Trac priorities and severities

> On 8 Oct 2015, at 05:01, Nick Mathewson wrote: > > On Wed, Oct 7, 2015 at 11:56 AM, David Goulet > wrote: >> Hello tor-dev! >> >> While 028 bug triaging, we realized that we *really* need priorities to >> not be a banana field deprive of useful meaning. If you are u

Re: [tor-dev] Trac priorities and severities

On Wed, Oct 7, 2015 at 11:56 AM, David Goulet wrote: > Hello tor-dev! > > While 028 bug triaging, we realized that we *really* need priorities to > not be a banana field deprive of useful meaning. If you are unaware or > don't remember, the priority field in a trac ticket can be: > > blocker c

Re: [tor-dev] Trac priorities and severities

This is a good proposal. Some bugs are higher-priority and affect lots of users, but are really quite trivial and don't affect user security (such as CSS bugs). I'd add another trac change: 4) hide "milestone" field in query results, replace with "severity" That way, we can quickly see bot

[tor-dev] Trac priorities and severities

Hello tor-dev! While 028 bug triaging, we realized that we *really* need priorities to not be a banana field deprive of useful meaning. If you are unaware or don't remember, the priority field in a trac ticket can be: blocker critical major normal minor trivial Those are "severities" *NOT* p