5 ms·

> What's the relationship between the existence of a bug in the codebase and the propensity of the bug reporter to respond to an email? It's not clear to me th

> What's the relationship between the existence of a bug in the codebase and the propensity of the bug reporter to respond to an email? 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.

jancsika 8y ago
> It's not clear to me the question here, can you be more specific? Many bugs filed are not necessarily bugs in the codebase. 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.
- hinkley 8y ago
  I know that I for one steer people away from projects where serious bugs go unfixed for a long time. I have very little incentive to follow up on them once I’ve switched tools. 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).
maldeh 8y ago
A "WONTFIX/NOTABUG" closure at least gives confidence that a bug was investigated. Do we know how many bugs were still pending investigation here, prior to being closed due to this migration?
buovjaga 8y ago
> 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. 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.
- audidude 8y ago
  My mistake, it was 5 years for projects that did trim. Most projects brought all bugs over afaik.
konschubert 8y ago
> I do wish we treated bugs and user support separately. Why not have a buck tracking system where only contributors have write access and a second system where users can submit their reports?
- buovjaga 8y ago
  I oppose this sort of thing and rather encourage forming a strong QA team to separate the fluff from the real deal.
  - konschubert 8y ago
    The problem is that apparently they don't have this team. In the face of that reality, a separated internal and external bug trabkin system might be a viable solution.
    - buovjaga 8y ago
      This would cement an alternate reality, where the growing of the QA team would become more difficult. Trust me, I am talking from experience of recruiting and onboarding hundreds of volunteers into FOSS teams (with varying levels of success and involvement). Recruiting volunteers to FOSS is insanely difficult and any addition of complexity will just result in more headaches.

jancsika 8y ago

> It's not clear to me the question here, can you be more specific? Many bugs filed are not necessarily bugs in the codebase. 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.

hinkley 8y ago
I know that I for one steer people away from projects where serious bugs go unfixed for a long time. I have very little incentive to follow up on them once I’ve switched tools. 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).

maldeh 8y ago

A "WONTFIX/NOTABUG" closure at least gives confidence that a bug was investigated. Do we know how many bugs were still pending investigation here, prior to being closed due to this migration?

buovjaga 8y ago

> 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. 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.

audidude 8y ago
My mistake, it was 5 years for projects that did trim. Most projects brought all bugs over afaik.

konschubert 8y ago

> I do wish we treated bugs and user support separately. Why not have a buck tracking system where only contributors have write access and a second system where users can submit their reports?

buovjaga 8y ago
I oppose this sort of thing and rather encourage forming a strong QA team to separate the fluff from the real deal.
- konschubert 8y ago
  The problem is that apparently they don't have this team. In the face of that reality, a separated internal and external bug trabkin system might be a viable solution.
  - buovjaga 8y ago
    This would cement an alternate reality, where the growing of the QA team would become more difficult. Trust me, I am talking from experience of recruiting and onboarding hundreds of volunteers into FOSS teams (with varying levels of success and involvement). Recruiting volunteers to FOSS is insanely difficult and any addition of complexity will just result in more headaches.