4 ms·

I’ve run into this on a few projects where PMs want to close all issues. Oddly there’s no external metric on this, it’s just some internal driver. It would res

I’ve run into this on a few projects where PMs want to close all issues. Oddly there’s no external metric on this, it’s just some internal driver. It would result in closing old or low priority items rather than leaving them. It would also result in things not fixed being closed. It was a surreal conversation where I asked how they knew my issue was resolved without asking me, the person who submitted it. The PM said “what do you mean, we closed it. It’s closed.” And it took time to explain the difference between thinking it’s done and properly confirming it’s done. I find the most frustrating as a user is “closed, won’t fix” as for OSS projects someone could eventually submit a fix. Closing “stale” issues is vanity tidying that’s not necessary in a digital, “free” world. I think the fix for this is to look at the “unaddressed” metric to include any closed issues that weren’t resolved. A high number of stale issues closed is a negative metric for a project. But a high number of lingering issues isn’t so bad.

yoz-y 6y ago
A won't fix might make sense if the issue is a feature request that goes against the program philosophy. In that case forking the repo makes more sense. I wholeheartedly agree that closing issues just because they are old is a terrible practice. It's also why I have stopped sending radars. No point of doing work for somebody else if it just generates even more work for me.
- pas 6y ago
  I have no problem with closing them for bugs, because in a few major versions usually the software changes sufficiently to have a good chance of that original bug report simply being obsolete (not reproducible, log/debug output not useful anymore, architecture changes, GUI changes, client software/driver changes, kernel changes, etc.) But in case of a feature request, where the project maintainer agreed it's a long term goal, a bot closing it is just noise, which IMHO discourages useful/insightful comments.
  - yoz-y 6y ago
    I don't think it's justified for bugs either. At least it should be opt-in per bug. It can hide especially sinister bugs that happen only in an uncommon case. This assumes a list of bugs that are actually reproductible bugs not an unfiltered feedback from the clients.
nicbou 6y ago
Public ISSUES are important, because they measure the need for a feature. An important issue will generate more noise, and that indicates a lot of people struggle with it. "Me too" is a valuable metric, as is additional reproduction information from other users. User requirements are not final, so the answers to it should not be. On the other hand, stale TICKETS make it difficult to get an overview of the project and its priorities. Actually important issues can get lost in a sea of wishes. You can't have the team vote on the priority of 400+ tickets with no description, no justification, and no owner. Those tickets just sink to the bottom of the backlog, never to be seen again. On occasion, they're actually important, but hard to notice amid the 400 other tickets. I always liked Kanban, because the to-do column is sorted. You can only sort a list by going through every item. When I was the agile whip, I always pushed for separate "triage" and "to do" tickets. The former is a bucket of wishes and stream-of-consciousness tickets. The latter is for tasks we understand and commit to. Our backlog refinement sessions cleaned the triage column, then sorted the to do column.
- prepend 6y ago
  Issues can be tagged. So if there’s a sea of wishes just tag them to reduce confusion and let people know they are low priority. Also, I don’t have much of an issue with closing low quality issues, but if a user writes up a good issue and it is stale due to low priority, or not enough resources, or whatnot that’s a different story. I also find it really easy to sort high priority issues amongst 400 because there are comments, likes, and activity on issues. So there’s multiple ways for me to understand what it means.
  - nicbou 6y ago
    That's why we ended up with the triage row. This way we had a list of issues we could actually sort and work on. Triage issues were de facto assigned to me, the guy in charge of refining tickets into actionable tasks. Now that I think of it, the triage column was the PM/PO's todo column.

yoz-y 6y ago

A won't fix might make sense if the issue is a feature request that goes against the program philosophy. In that case forking the repo makes more sense. I wholeheartedly agree that closing issues just because they are old is a terrible practice. It's also why I have stopped sending radars. No point of doing work for somebody else if it just generates even more work for me.

pas 6y ago
I have no problem with closing them for bugs, because in a few major versions usually the software changes sufficiently to have a good chance of that original bug report simply being obsolete (not reproducible, log/debug output not useful anymore, architecture changes, GUI changes, client software/driver changes, kernel changes, etc.) But in case of a feature request, where the project maintainer agreed it's a long term goal, a bot closing it is just noise, which IMHO discourages useful/insightful comments.
- yoz-y 6y ago
  I don't think it's justified for bugs either. At least it should be opt-in per bug. It can hide especially sinister bugs that happen only in an uncommon case. This assumes a list of bugs that are actually reproductible bugs not an unfiltered feedback from the clients.

nicbou 6y ago

Public ISSUES are important, because they measure the need for a feature. An important issue will generate more noise, and that indicates a lot of people struggle with it. "Me too" is a valuable metric, as is additional reproduction information from other users. User requirements are not final, so the answers to it should not be. On the other hand, stale TICKETS make it difficult to get an overview of the project and its priorities. Actually important issues can get lost in a sea of wishes. You can't have the team vote on the priority of 400+ tickets with no description, no justification, and no owner. Those tickets just sink to the bottom of the backlog, never to be seen again. On occasion, they're actually important, but hard to notice amid the 400 other tickets. I always liked Kanban, because the to-do column is sorted. You can only sort a list by going through every item. When I was the agile whip, I always pushed for separate "triage" and "to do" tickets. The former is a bucket of wishes and stream-of-consciousness tickets. The latter is for tasks we understand and commit to. Our backlog refinement sessions cleaned the triage column, then sorted the to do column.

prepend 6y ago
Issues can be tagged. So if there’s a sea of wishes just tag them to reduce confusion and let people know they are low priority. Also, I don’t have much of an issue with closing low quality issues, but if a user writes up a good issue and it is stale due to low priority, or not enough resources, or whatnot that’s a different story. I also find it really easy to sort high priority issues amongst 400 because there are comments, likes, and activity on issues. So there’s multiple ways for me to understand what it means.
- nicbou 6y ago
  That's why we ended up with the triage row. This way we had a list of issues we could actually sort and work on. Triage issues were de facto assigned to me, the guy in charge of refining tickets into actionable tasks. Now that I think of it, the triage column was the PM/PO's todo column.