Lots of tickets still marked new and un checked for up to 4 years.
I'll volunteer to start going through and either
updating/closing/merging/tagging them if there is interest in burning down
the list
That'd be much appreciated! Note that even many of the old tickets are
quite valid (esp feature requests) so I think they should be left open,
try to spot the ones that are duplicates of something that got fixed, or
have become invalid over time.
Regarding statuses, I usually use the "Feedback" status to indicate
something that's probably or appears fixed to me (it's closed, but
invites feedback), "Duplicate" with a related (duplicate) ticket if it's
fixed, or "Resolved" just to close it as resolved in any way (since
"Closed" is used when code is committed).
If you've got any questions, please feel free to mention tickets to me
or others.
Thanks,
···
On 13/07/15 01:42, Byron Miller wrote: > Lots of tickets still marked new and un checked for up to 4 years. > > I'll volunteer to start going through and either > updating/closing/merging/tagging them if there is interest in burning > down the list–
Dominic Cleal
Red Hat Engineering
Sounds good, I'll definitely try and link related issues, match duplicates
and look for fixed issues. Thanks for the heads up on the recommendation
for Resolved vs Closed, I was curious what the philosophy was there.
Would there be any issue with tagging tickets that seem more of issue
report as "support" vs new if/until they either get updated to turn into a
bug/patch/fix or something more actionable? or just leave those as new for
time being?
-byron
···
On Monday, July 13, 2015 at 2:20:52 AM UTC-5, Dominic Cleal wrote: > > On 13/07/15 01:42, Byron Miller wrote: > > Lots of tickets still marked new and un checked for up to 4 years. > > > > I'll volunteer to start going through and either > > updating/closing/merging/tagging them if there is interest in burning > > down the list > > That'd be much appreciated! Note that even many of the old tickets are > quite valid (esp feature requests) so I think they should be left open, > try to spot the ones that are duplicates of something that got fixed, or > have become invalid over time. > > Regarding statuses, I usually use the "Feedback" status to indicate > something that's probably or appears fixed to me (it's closed, but > invites feedback), "Duplicate" with a related (duplicate) ticket if it's > fixed, or "Resolved" just to close it as resolved in any way (since > "Closed" is used when code is committed). > > If you've got any questions, please feel free to mention tickets to me > or others. > > Thanks, > > -- > Dominic Cleal > Red Hat Engineering >> Sounds good, I'll definitely try and link related issues, match
> duplicates and look for fixed issues. Thanks for the heads up on the
> recommendation for Resolved vs Closed, I was curious what the philosophy
> was there.
Yeah, I think it's backwards compared to most software projects IME, but
it is what it is now!
> Would there be any issue with tagging tickets that seem more of issue
> report as "support" vs new if/until they either get updated to turn into
> a bug/patch/fix or something more actionable? or just leave those as new
> for time being?
If it's only an issue on the user's setup or some misunderstanding then
feel free to move it to the support tracker (the only difference being
the label and which fields are available), but if there's something we
can change to improve it then it's best left as a bug/feature/refactor
in the New state. Just ensure that it's well-described and either
change the subject to reflect what needs to be done or consider adding a
comment to summarise. It's most useful I think for developers if
they're left as issue type tickets if there's work to be done.
Cheers,
···
On 13/07/15 13:49, Byron Miller wrote:–
Dominic Cleal
Red Hat Engineering