3 ms·

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 th

by 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 mook 6y ago

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.