3 ms·

We have had essentially this argument with our internal issue tracker a number of times. Project managers always seem to get some bug in their butt to close old

by donatj 6y ago

We have had essentially this argument with our internal issue tracker a number of times. Project managers always seem to get some bug in their butt to close old issues. If they are not fixed, closing the ticket solves nothing. There is no virtue in having more untracked bugs.

marcinzm 6y ago
I'm guessing someone is measuring the Project Manager's performance based on number of open issues. Or they think someone is doing so. Even if it's just a side comment from a VP noting how many open issues there are.
NullPrefix 6y ago
>What gets measured, gets managed. Measuring open/closed issue tally is way easier than interpreting why and for what reason that particular issue is still relevant to the big picture.
Hackbraten 6y ago
In some projects, the maintainers use issues to represent their task queue. That’s not necessarily intuitive for users but a perfectly legitimate thing to do. I think that if a project uses that model then there’s nothing wrong with closing issues if you don’t intend to ever work on them.
- mook 6y ago
  I think in that case the maintainer needs a different view of the bug tracker; for example, in GitHub that would be their projects view, or if you don't like that, label the issues as stale (without closing) and using a search that excludes those results. I believe the important thing is to make the default search return the issues that the maintainers are not working on, so that known issues are still tracked (but possibly out of the maintainer's hair). The important thing is that new users would be able to find them, so that non-maintainers can still collaborate.
  - Hackbraten 6y ago
    > I think in that case the maintainer needs a different view of the bug tracker; for example, in GitHub that would be their projects view, or if you don't like that, label the issues as stale (without closing) and using a search that excludes those results. But it’s a lot quicker and easier to use the default view (and default search). > I believe the important thing is to make the default search return the issues that the maintainers are not working on, so that known issues are still tracked (but possibly out of the maintainer's hair). What would be an example where this kind of tracking is useful? > The important thing is that new users would be able to find them Users can find them either by full-text search or by browsing all issues.
    - mook 6y ago
      > But it’s a lot quicker and easier to use the default view (and default search). Yes it is; that's why all the new people would be using it. A maintainer would be visiting a pre-baked search list often, which can be done with things like bookmarks. > > I believe the important thing is to make the default search return the issues that the maintainers are not working on, so that known issues are still tracked (but possibly out of the maintainer's hair). > What would be an example where this kind of tracking is useful? People would be able to find the existing issues and not file duplicates, reducing bug management burden on the maintainers? As a secondary effect, people might be able to collaborate independent of the maintainer. > > The important thing is that new users would be able to find them > Users can find them either by full-text search or by browsing all issues. Yes, they could. But users generally would make new issues, possible mentioning the existing closed ones, because they are still affected by it, causing more noise. Ideally they'd just subscribe to it instead and make no noise for the maintainer.

by donatj 6y ago

marcinzm 6y ago

I'm guessing someone is measuring the Project Manager's performance based on number of open issues. Or they think someone is doing so. Even if it's just a side comment from a VP noting how many open issues there are.

NullPrefix 6y ago

>What gets measured, gets managed. Measuring open/closed issue tally is way easier than interpreting why and for what reason that particular issue is still relevant to the big picture.

Hackbraten 6y ago

In some projects, the maintainers use issues to represent their task queue. That’s not necessarily intuitive for users but a perfectly legitimate thing to do. I think that if a project uses that model then there’s nothing wrong with closing issues if you don’t intend to ever work on them.

mook 6y ago
I think in that case the maintainer needs a different view of the bug tracker; for example, in GitHub that would be their projects view, or if you don't like that, label the issues as stale (without closing) and using a search that excludes those results. I believe the important thing is to make the default search return the issues that the maintainers are not working on, so that known issues are still tracked (but possibly out of the maintainer's hair). The important thing is that new users would be able to find them, so that non-maintainers can still collaborate.
- Hackbraten 6y ago
  > I think in that case the maintainer needs a different view of the bug tracker; for example, in GitHub that would be their projects view, or if you don't like that, label the issues as stale (without closing) and using a search that excludes those results. But it’s a lot quicker and easier to use the default view (and default search). > I believe the important thing is to make the default search return the issues that the maintainers are not working on, so that known issues are still tracked (but possibly out of the maintainer's hair). What would be an example where this kind of tracking is useful? > The important thing is that new users would be able to find them Users can find them either by full-text search or by browsing all issues.
  - mook 6y ago
    > But it’s a lot quicker and easier to use the default view (and default search). Yes it is; that's why all the new people would be using it. A maintainer would be visiting a pre-baked search list often, which can be done with things like bookmarks. > > I believe the important thing is to make the default search return the issues that the maintainers are not working on, so that known issues are still tracked (but possibly out of the maintainer's hair). > What would be an example where this kind of tracking is useful? People would be able to find the existing issues and not file duplicates, reducing bug management burden on the maintainers? As a secondary effect, people might be able to collaborate independent of the maintainer. > > The important thing is that new users would be able to find them > Users can find them either by full-text search or by browsing all issues. Yes, they could. But users generally would make new issues, possible mentioning the existing closed ones, because they are still affected by it, causing more noise. Ideally they'd just subscribe to it instead and make no noise for the maintainer.