> I think the gitlab tooling allows us to be more diplomatic in closing bugs that are out-of-scope or not aligned with the goals of the project at large.
Can you give more details about this? Closing is closing and Bugzilla allows you to name your statuses whatever you want, so I don't understand how GitLab would change anything.
My experience is that GitLab (and GitHub) is worse in tracking bugs compared to Bugzilla (I've triaged about 10k reports).
I also think having the cut-off at 1 year is a bit drastic. I would have gone for 5 years.
Right. So your goal is to separate reports about bona fide bugs in the codebase from reports that either a) are no longer bugs in the codebase or b) are issues outside the scope of the codebase. That's a laudable goal.
Filtering out years of bugs based on the lack of timely response from a submitter (or others) doesn't seem like a sound way to achieve that goal. There's no clear relationship between a lack of response and the relevant bug's existence/non-existence.
The correlation between bugs that matter a great deal to me and bugs I don’t respond to is much greater than zero.
If you delete all the bugs that caused people to abandon your platform then you are cutting off your own nose.
Can’t reproduce is a better metric but only if it’s other users rather than the maintainers. I find that a lot of people who write buggy code also are bad at reproducing issues (which I think is why they have bugs in the first place. Lack of imagination or rigor or both).
Why not have a buck tracking system where only contributors have write access and a second system where users can submit their reports?
In the face of that reality, a separated internal and external bug trabkin system might be a viable solution.
It's not clear to me the question here, can you be more specific? Many bugs filed are not necessarily bugs in the codebase.
I do wish we treated bugs and user support separately. I rather prefer the terseness of an engineering journal for what it is, but that tends to anger those expecting user support.
> How does Gitlab prevent those same maintainers from creating that same problem again?
In Bugzilla, the only real option we had was "Closed: WONTFIX/NOTABUG" which almost always resulted in hurt feelings on the part of the bug reporter.
I think the gitlab tooling allows us to be more diplomatic in closing bugs that are out-of-scope or not aligned with the goals of the project at large.