Hacker News Reader

Comment by masklinn | Hacker News Reader

> Author must not have worked in enterprise software before.

Or with open source projects. Fucking stalebot.

Or even non-software tickets at large corporations. I reported a water dispenser filling too slowly at my office because it took me a few tries just to fill my 1L water bottle. They said it was fixed and closed it.

It was not fixed. So I took a video of myself refilling my water bottle, attached it to the ticket, and re-opened it. They actually fixed it after that. The video was 2m12s long (and I spent god knows how long making the video file small enough to attach to the ticket lol)

this is actually a good example of how a more detailed issue will have a higher chance to be addressed. I don't know what information that's your previous report is lacking, but the video certainly give more information that the maintainer can pinpoint the cause and act on it. The ability to pinpoint the cause from the report is a godsent for maintainers, it drastically reduce the time to investigate the cause, thus able to act immediately.

Some of the information in this can may be:

* how "slow" exactly the process is related with normal behavior. If it's just said "slow" on previous report, it's easy to be dismissed

* the dispenser's behavior, such as if the water flow is consistently low volume or clogged intermittently, or if the dispenser is struggling to fetch from water source, etc

I'd say it was both. I gave a pretty detailed explanation before, far more detailed than my post here, including a timeline of when it filled in one shot, then two shots, and then three or four (can't remember). I doubt they actually checked before the video. But I was very motivated to fix the issue so I gave them proof lol

More importantly it shows how the reporter actually used the system to trigger the undesired behavior. Just because something is obvious to you doesn't mean it will be obvious to whoever is looking at the bug report.

Take a look at Anthropic's repo. They auto-close issues after just a few weeks.

I don't think I've seen an issue of theirs that wasn't auto-closed.

Wait, isn’t software engineering a solved problem?

Yes

Yes, that’s why they have such great up time. They don’t go down multiple times per day.

I just randomly plugged in numbers to look up random Claude issues on github, and out of the 20 I checked, only one was closed as fixed. :-(

Fuck stalebot.

All my homies hate stalebot

What about OSS weekend ?

As an open source maintainer, I feel that statement is really unfair. Yes, we do sometimes close bug reports without evidence they are fixed. But:

- We owe you nothing! And the fact that people still expect maintainers to work for them is really sad, IMHO.

- Unlike corporate workers, nobody is measuring our productivity therefore we have no incentive to close issues if we believe they are unfixed. That means that when we close the issue, we believe it has a high chance of being fixed, and also we weigh the cost of having many maybe-fixed open issues against maybe closing a standing issue, and (try to) choose what's best for the project.

Why do you close the issue then?

Because open source is corporate now

Because I have a reason to believe it's fixed, I have many more like it and it's difficult to reproduce. Simple :)

You have no evidence that it's fixed, but you have reason to believe it's fixed?

>Because I have a reason to believe it's fixed

What reason?

> That means that when we close the issue, we believe it has a high chance of being fixed

I agree with this iff it's being done manually after reading the issue. stalebot is indiscriminate and as far as "owing" the user, that's fair, but I'd assume that the person reporting the bug is also doing you a favor by helping you make things more stable and contributing to your repo/tool's community.

I partially agree, but even with stalebots nobody is measuring the maintainers' productivity. So when they made the choice to use stalebots, they did that because they believe that's best for the project. It's different from corporate.

Nobody is measuring their productivity, but people definitely look at how many open issues they have and potentially how long those issues have existed. They’re likely incentivized to close issues for appearances.

With a popular open source project, you'll quickly get to a number of bug reports that you have no chance of ever solving. You will have to focus on the worst ones and ones affecting most users.

At the same time, you want to communicate to users that this is the case so they don't have wrong expectation. But also, psychologically it is demotivating to have a 1000+ open bugs queue with no capacity to re-triage and only two maintainers able to out a few fours in every month or every week.

In open source, "won't fix" means either "not in scope — feel free to fork" or "no capacity ever expected — feel free to provide a fix".

The optimization problem is how do you get the most out of very limited time from very few people, and having 1000+ open bugs that nobody can keep in their head or look for duplicates in is mentally draining and stops the devs from fixing even the top 3 bugs users do face.

The problem is that your users also have limited time and if it's clear you're not even looking at issues where someone has put in lots of effort to help you then you're only going to get lazy issues and it will actually take more effort from you to do all that work yourself if you want to reach the same software quality.

I think you are missing the point: a user putting in a lot of effort into a bug report is usually trying to help themselves get the bug fixed.

As a maintainer, you will obviously look at that bug with more appreciation: but if you estimate it will take you 3 months of active development to fix it that you will have to spread over a full year of your weekends (which you can't afford), what would you do?

And what would a reasonable user rather see? Yes, this is an issue, but very hard to fix, and I don't have the time, or just letting the bug linger?

It's not about expectation of work (well, there's some entitled people sure.)

It's about throwing away the effort the reporter put into filing the issue. Stale bots disincentivise good quality issues, makes them less discoverable, and creates the burden of having to collate discussion across N previously raised issues about the same thing.

Bug reports and FRs are also a form of work. They might have a selfish motive, but they're still raised with the intention of enriching the software in some way.

IMO closing issues via stale bot is fine, the problem is locking issues so that no further conversation is allowed on the issue. Multiple times, I've encountered multi-year old issues (which is usually not fixed due to the fix not being simple or compatible with the current architecture). There's usually a good amount of conversation between users offering workarounds (and those workarounds updated for newer versions) - till stale bot locks the issue.

This 1000%. Whoever came up with the idea of closing and locking issues because no one has posted on them for awhile is at best not all that bright and at worst downright sinister.

Closing an issue due to staleness is one thing, locking it is another.

> We owe you nothing! And the fact that people still expect maintainers to work for them is really sad, IMHO.

Users also don't owe you anything either. Auto-closing reports without even looking at them is like asking for donations only to throw 90% of what you get straight into the trash. Not cool. If you don't want bug reports, state that up front or at least leave bugs open for other users to see and talk about. Otherwise, users are free to warn others to stay away from you and your projects.

And that's before getting into more complex issues like what responsibility you have if you take on maintenance of existing software and end up breaking something what was working perfectly for some users.

> Unlike corporate workers, nobody is measuring our productivity therefore we have no incentive to close issues if we believe they are unfixed.

There are plenty incentives, e.g. pride.

> That means that when we close the issue, we believe it has a high chance of being fixed, and also we weigh the cost of having many maybe-fixed open issues against maybe closing a standing issue, and (try to) choose what's best for the project.

That's fine, but bots that auto-close issues unless the reporter dances for them is the opposite of that.

Reply on news.ycombinator.com