3 ms·

> So I think it's good advice that maintainers should use stalebot, because the alternative is a dead project. This doesn't follow at all for me. What stalebot

by jjav 4y ago

> So I think it's good advice that maintainers should use stalebot, because the alternative is a dead project. This doesn't follow at all for me. What stalebot causes is a project that superficially seems to be in great shape, having only a smaller number of fairly recent bugs open. Whereas in reality it's a project with tons of known bugs that just get sweeped under the proverbial rug to make the bug list appear deceivingly clean. The passage of time doesn't make a bug go away, it's still a bug in the project. The conflict arises because a bug database serves multiple purposes. Yes, it's a To-Do list for engineering. In that context, not everything can be done now so it might be understandable to close them. But the same can be achieved by lowering the priority which puts it at the bottom of the To-Do list. But the other purpose of a bug db, a more important one, is that it is the repository of knowledge of all known problems with the project. It allows consumers of the project to understand what isn't working and to see where the quality trend is going over time. Yes, this could also be achieved with a document on Known Issues explaining the problems and ideally the reason they don't get fixed. But a project that's closing bugs automatically with a bot I bet isn't putting the effort into such documentation either. I never close any bugs due to time. If they accumulate, so be it. It's a honest representation of the state of the project to would-be users. Eventually I get to it, might be many years later, but the bug was still there. When I close the bug intentionally it's because it's no longer an issue.

UglyToad 4y ago
Maybe (most likely) this is a problem of GitHub's terminology. For genuine bugs, e.g. here's the repro, the stack trace, the code to replicate it, it happens 100% of the time if you follow these steps, I'd agree that just having it open and in the backlog would be preferable. The problem is those make up maybe at a generous estimate, 10-15% of issues in a projects backlog. In the interests of full disclosure here's mine (I don't use stalebot) https://github.com/UglyToad/PdfPig/issues?page=1&q=is%3Aissue+is%3Aopen https://github.com/UglyToad/PdfPig/issues?page=1&q=is%3Aissu.... As you can see from the backlog I close almost nothing. This was a deliberate choice to avoid closing things until the fix was confirmed by the reporter. But equally that's the first time I've opened the repository in a couple of months and the amount of angst and dread I feel just from the size of that list means I'll probably find yet another excuse not to do anything on it this coming month. Discussions on this topic feel a lot like "technical solutions to social problems"; by which I mean "well in the ideal world a perfectly logical person would do x, y, z so the system should reflect that". And while a stalebot is the archetypal technical solution to a social problem it at least works with how maintainers work. Sometimes in life you want to ignore a problem and have it go away. When you can't do that, e.g. government bureaucracy, work stuff, social obligations, that's where stress comes from. And asking volunteer maintainers to add a whole new source of stress in their life falls apart when people get busy, or their life circumstances change, or they get ill or tired or whatever. Yes, in a perfect world the issue backlog would be sacrosanct and perfectly groomed/prioritized. But we're just fleshy sacks of chemicals and we're not perfect. Unrealistic expectations from users are the cause of maintainer burnout. Because GitHub closed issues are still viewable and searchable (I'd guess most people search it through a search engine not the terrible inbuilt search) I'd disagree that they're deceiving users somehow.

by jjav 4y ago

UglyToad 4y ago

Maybe (most likely) this is a problem of GitHub's terminology. For genuine bugs, e.g. here's the repro, the stack trace, the code to replicate it, it happens 100% of the time if you follow these steps, I'd agree that just having it open and in the backlog would be preferable. The problem is those make up maybe at a generous estimate, 10-15% of issues in a projects backlog. In the interests of full disclosure here's mine (I don't use stalebot) https://github.com/UglyToad/PdfPig/issues?page=1&q=is%3Aissue+is%3Aopen https://github.com/UglyToad/PdfPig/issues?page=1&q=is%3Aissu.... As you can see from the backlog I close almost nothing. This was a deliberate choice to avoid closing things until the fix was confirmed by the reporter. But equally that's the first time I've opened the repository in a couple of months and the amount of angst and dread I feel just from the size of that list means I'll probably find yet another excuse not to do anything on it this coming month. Discussions on this topic feel a lot like "technical solutions to social problems"; by which I mean "well in the ideal world a perfectly logical person would do x, y, z so the system should reflect that". And while a stalebot is the archetypal technical solution to a social problem it at least works with how maintainers work. Sometimes in life you want to ignore a problem and have it go away. When you can't do that, e.g. government bureaucracy, work stuff, social obligations, that's where stress comes from. And asking volunteer maintainers to add a whole new source of stress in their life falls apart when people get busy, or their life circumstances change, or they get ill or tired or whatever. Yes, in a perfect world the issue backlog would be sacrosanct and perfectly groomed/prioritized. But we're just fleshy sacks of chemicals and we're not perfect. Unrealistic expectations from users are the cause of maintainer burnout. Because GitHub closed issues are still viewable and searchable (I'd guess most people search it through a search engine not the terrible inbuilt search) I'd disagree that they're deceiving users somehow.