@daleathan @codefarmer (and others that manage the bug tracker that I can’t figure out your discourse names from your bug tracker usernames) :
How can we best prioritize the bugs in the tracker? I’d like to start picking them off, but where do begin? I’d like to target the worst, most influential ones first.
Ideally? What’s been suggested by several people: let’s have AI have a go at the list. We need to get bug reports (maybe just the metadata) out in some format and have AI organize it so that its easier to tackle the whole lot in some way. E.g. most number of watchers, comments, related bugs, etc.
If we can get rid of “not a bug”, “no longer applicable”, “already fixed”, “won’t fix” type issues, the list would reduce to the ones we really need to look at. Bugs older than say 5 years (or unsupported releases) and severity below Major: close? (criteria can be fine-tuned)
One option is ping the reporter on every defect and have them reply with a note whether it’s still valid and important to them. If no reply, good candidate to close.
What I do to find a bug that might have a high impact: go to the MantisBT Summary page for Gramps and look at the “By Severity” table I look at issues with highest severity first. Many times the severity isn’t appropriate, but the Blocker list is down to 5 now. I focus on this list in decreasing severity order.
There are things we can do differently when triaging, but that can be discussed later. However, I’ve suggested an idea of periodic Bug Bashes in the past that which could be a way to keep on top of the bug count once we get the list down to a manageable number.
I can do what I did for the features: export a list of features (not closed, etc) as CSV and then have AI create categories of types of features (UI, GEDCOM, etc). For bugs (in the last N years), I’ll have it categorize based on the criteria you mentioned (severity, etc).
Then we can work on the most sevier group.
@dsblank Sounds good. Can some consideration also be given to those issues tagged as having a PATCH ?
Yes, you all tell me the criteria and I’ll do it.
@Nick-Hall what’s the plan with reviewing bugs, enhancements, and feature PRs? I’m planning on trying to do one bug/enhancement/feature PR a day. But there is already a backlog going back more than a year.
If you could at least approve a PR in principle, we could make sure that any changes pass the tests and conform to Gramps standards.
I’ll start reviewing pull requests. I should be able to get through a few every day.
That would be great! I know this is going to be a lot of work!
@gramps-project, wow! I looked at a few issues tagged “PATCH” and each one is a bit of a mess. Lots of different code versions in many different formats. And of course the codebase has changed over the years, I’m not sure we can do much with these.
There are still a few unapplied patches linked in:
(BTW, following the approach in that wishlist… we could use edit in Discourse <del> </del> to mark off items that are done and annotate with added to 6.1 with an <ins>added to 6.1</ins> )