I got reeeeally good at producing repro gifs that I could plug straight inline into email replies to "can't repro"; it's forever clear that most developers either don't know how to test the product they are building, or simply can't be bothered to try.

I've worked with enterprise software. The result its that people will eventually just wait a few hours/days and lie if they even care enough to do that. The perverse incentives destroy what utility a bug tracker could bring. Int theory transparency could help by changing the incentives if third parties analyze the metrics and call out bullshit to an audicence that matters.

From experience with Microsoft (paid) support (after doing 5 tickets because it's never the right team and apparently moving tickets internally is for losers), they will ask for proof of the reproduction. And they will take every opportunity to shift the blame ("Oh I can see in the log you're running an antivirus, open a ticket with them. Closed").

Yep. On the other side of the curtain this often isn't nefarious. It's a simple cost/benefit analysis of spending time on something that one user is complaining about versus a backlog of higher business priorities. I've seen this in my work and it makes me sad for the user, but it often does take a bit of effort to spear these bug reports through.

> Author must not have worked in enterprise software before.

Or with open source projects. Fucking stalebot.

> Of course, the only way to counter this is by saying "Yes I verified it" without actually verifying it.

I'm not going to lie. That's not who I am. If Apple really wants to close a bug report when the bug isn't fixed, that's on their conscience, if they have one.

They could just, not close the bug?

Mozilla is famous for having 20 year old bug reports that gets fixed after all that time.

How about they keep the bug report open until they attempt and confirm the bug is no longer reproducible?

I recompiled OpenSSL to make s_server -www return the correct, static XML blob for a .NET application that was buggy to make a reproducer for them that didn't rely on our product at all and which could be self-contained on a very barren windows VM they could play with to their heart's content and which didn't even care about the network because everything was connecting via loopback, so they couldn't blame that, eitehr.

Turns out there was a known bug in Microsoft schannel that had yet to be patched and they'd wasted weeks of our effort by not searching their own bug tracker properly.

My favourite variant of this merrygoround is when they ask you to demonstrate the issue live in a Teams session, you do so, and there's this moment of silence followed by an "Oh... I see".

Then you assume, naively, that this means that they've recognised that there really is a product problem and will go off and fix it. However, then in turn the support tech needs to reproduce the the issue to the development team.

They invariably fail to do so for any number of reasons, such as: This only happens in my region, not others. Or the support tech's lab environment doesn't actually allow them to spin up the high-spec thing that's broken. Or whatever.

Then the ticket gets rejected with "can't reproduce" after you've reproduced the issue, with a recorded video and everything as evidence.

If you then navigate that gauntlet, the ticket is most typically rejected with "It is broken like that by design, closed."

It'd kind of sad, how the market went. I suppose there are pluses too.

But back in the 80s and 90s, margins were significantly higher. If you look at hardware, I recall selling hardware with 30% margin, if not more... even 80% on some items.

Yet what came with that was support, support, support. And when you sell 5 computers a month, instead of 500, well.. you need that margin to even have a store. Which you need, because no wide-scale internet.

On the software side, it was sort of the same. I remember paying $80 for some pieces of software, which would be like $200 today. You'd pay $1 on an app store for such software, but I'd also call the author if there was a bug. He'd send an update in the mail.

I guess my point is, in those days, it was fun to fix issues. The focus was more specific, there was time to ply the trade, to enjoy it, to have performant, elegant fixes.

Now, it's all "my boss is hassling me and another bug will somehow mean I have to work harder", which is .. well, sad.

It's a false dichotomy - something being "a simple cost/benefit analysis" doesn't remove the ethical dimension, and can absolutely be nefarious. A movie villain saying "it was just business" doesn't make their actions less villainous.

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)

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.

Back in another part of my career I worked a lot with putting Macs on ActiveDirectory. And there was a common refrain from Apple about bugs in that implementation: "works on 17!".

The joke is that Apple owns the 17.x.x.x class-A range on the Internet (they got in early, the also have a second class-B and used to have a second class-B that they gave back), and what engineers were really saying is that they could not reproduce on the AD systems that Apple had setup (lots of times it was because AD had been setup with a .local domain, a real no-no, but it was in Microsoft's training materials as an example at the time...).

How is that worse? Leaving it open signals to anyone searching about it that's it's still an issue of concern. It will show up in filters for active bugs, etc. Closing it without fixing it just obfuscates the situation. It costs nothing (except pride?) to leave "Issues (1)" if there is indeed an Issue.

> Not all bugs are easily reproducible

Apple did not say they couldn't reproduce it. Neither did they say that they thought they fixed it. They refused to say anything except "Verify with macOS 26.4 beta 4".

> and even if they are 100% reproducible for the user, it's not always so easy for the developers

It's not easy for the user! Like I said in the blog post, I don't usually run the betas, so it would have been an ordeal to install macOS 26.4 beta 4 just to test this one bug. If anything, it's easier for Apple to test when they're developing the beta.

> the most "efficient" thing is just to ask the user to re-test.

Efficient from Apple's perspective, but grossly inefficient from the bug reporter's perspective.

> realistically I can't really do anything with it

In this case, I provided Apple with a sample Xcode project and explicit steps to reproduce. So realistically, they could have tried that.

I suspect that your underlying assumption is incorrect: I don't think Apple did anything with my bug report. This is not the first time Apple has asked me to "verify" an unfixed bug in a beta version. This seems to be a perfunctory thing they do before certain significant OS releases, clear out some older bug reports. Maybe they want to focus now on macOS 27 for WWDC and pretend that there are no outstanding issues remaining. I don't know exactly what's going through their corporate minds, but what spurred me to blog about it is that they keep doing this same shit.

> Google had their own versions of things. IIRC bugs had both a priority and s everity for some reason (they were the same 99% of the time) between 0 and 4. So a standard bug was p2/s2. p0/s0 was the most severe and meant a serious user-facing outage. People would often change a p2/s2 to p3/s3, which basically meant "I'm never going to do this and I will never look at it again".

Yeah, I've done that. I find it much more honest than automatically closing it as stale or asking the reporter to repeatedly verify it even if I'm not going to work on it. The record still exists that the bug is there. Maybe some day the world will change and I'll have time to work on it.

I'm sure the leadership who set SLAs on medium-priority bugs anticipated a lot of bugs would become low-priority. They forced triage; that's the point.

> People even wrote automated rules to see if their bugs filed got downgraded to alert them.

This part though is a sign people are using the "don't notify" box inappropriately, denying reporters/watchers the opportunity to speak up if they disagree about the downgrade.

> Google had their own versions of things. IIRC bugs had both a priority and severity for some reason (they were the same 99% of the time) between 0 and 4.

At the company I worked with (not Google, but a major one) this was the same. We used Salesforce, the "Lightning Experience" or whatever it was called [0]. Our version was likely customized for our company, but I think the idea was the same - one, I think the "priority", was for our eyes only, one was for the customer (the "severity"). If the customer was insistent on raising the severity, we'd put it as sev1, but the priority was what we actually thought it was. I was actually surprised that for the ~4 years I was there no one made the mistake of telling the customer the priority as a mistake, especially when a lot of people were sloppily copy-pasting text from Slack or other internal tools that sometimes referred to a case as either the severity or the priority.

Those were heavy customers with SLAs, though, not supermarket apps or anything like that.

What was sad was that our internal tools, no matter how badly written, with 90's UI and awful security practices, our tools were 50 times as fast as whatever Salesforce garbage we had to deal with. Of course, there was a lot of unneeded redundancy between the tools so the complexity didn't stay in the Salesforce tool. But somehow the internal tools written by someone 10 years ago, barely maintained, who had to still deal with complex databases of who-what-when-how, felt like you had the DB locally on a supercomputer while SF felt like you were actually asking a very overworked person to manually give you your query right on each click. I'm exaggerating, but just by a bit.

[0] That name was funny because it was slow as shit. Each click took 5 to 20 seconds to update the view. I wonder what the non-Lightning version was.

What an interesting display of a principal-agent problem.

> Imagine trying to run a burndown of your sprint when zero of the Radars are closed, because they have to be verified in production before being closed, meaning you cannot verify until after the release.

I think most teams use verify as a "closed" state to hide all that messiness. But sure, zero bugs is a project management fiction and produces perverse outcomes.

Interesting insight to what should be a good internal process if users followed up.

In this case the bug wasn't fixed.

> A lot of teams simply close Radars that remain unverified for some amount of time because they are being "graded" on this.

The simple solution here: you should also be graded on closing bugs that get re-opened.

I think you're incorrectly assuming two things:

1. Apple engineers actually attempted to fix the bug.

2. Feedback Assistant "Please verify with the latest beta" matches the Radar "Verify" state.

I don't believe either of those are true.

I totally understand that from the perspective of individual employees: they have little incentive to do more than the bare minimum to close tickets. But this behavior is typically a symptom of broken corporate culture and failure to align internal metrics. For every customer who takes the trouble to submit a formal bug report there are likely many others who just live with it, and badmouth you to other customers. Doing deep investigations of even minor bug reports also tends to expose other, more serious latent bugs. And root cause analysis allows you to create closed-loop solutions to prevent similar future bugs.

Large monopolistic tech companies like Apple and Microsoft can afford to ignore this stuff for years because there are few realistic alternatives. But longer term eventually a disruptive competitor comes along who takes product quality and customer service more seriously.

I’d argue that there should be no higher business priority than shipping a product you already sold. If you sold a product and your customer spends their time documenting exactly why and how you sold them something that’s broken, you should make that a high priority. As a natural progression, you’ll start shipping less buggy / better tested products and that’s how you unlock yourself from the obligation you made to your existing customers to do other work.

Not directed at you of course, just the proverbial “you” from the frustration of a purchaser of software.

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.

Fuck stalebot.

Companies have no consciences.

> they basically insist that I become an unpaid systems engineering QC person

Microsoft support is guilty of this, especially for Azure & 365 issues.

Like sorry, but you aren't paying me to debug your software. Here's a report, and here's proof of me reproducing the problem & some logs. That's all I'm going to provide. It's your software, you debug it.

> keeping the bug open when realistically I can't really do anything with it might be worse

I've heard this from others before but I really don't understand the mindset.

What's the harm in keeping the bug open?

A company like Apple should have complex enough tools to perfectly capture system state at the time of the bug so that they can reproduce it

I've been on both sides of this. Absolutely sucks as a user falling prey to stalebot or some poor sap pretending to be stalebot, but when I was working in enterprise tech support it was a huge relief to close a case and get it off my plate, for any reason. We had to take 2 new cases per day minimum, update each case (I often had 20+) every few days minimum. Only a small minority were a quick and easy solution (like security vulns with a fix ready we could send the customer were the easiest). We were stuck with our cases also, you couldn't give them to someone else unless you were out sick pretty much, and you'd get them back when you returned unless by some miracle the other guy fixed their problem. An inactivity close on a stalled case was comforting, I was finally free. I think they started cracking down after a bit and said you had to check in with them 3 times x days apart first instead of just immediately closing after no word for 2 weeks, and then they wanted you to call them first. Absolute nightmare.

I think as long as the issue isn't stuck with any one person then it's easier to leave open until it's actually fixed, like the 20+ year old Mozilla bug reports. Big corpo bureaucratic nonsense just ruins everything.

Damn. I've put quite a lot of effort into open source tools w.r.t. debugging and bugfixing, but yeah putting that for a corporate product that doesn't even respect you must be draining.

Surely a few years worth of open but unverified bugs would cause some issues with reporting and such.

makes it very hard to lie with your metrics

> It certainly doesn't seem to hurt their bottom line, which is the only thing they care about.

I want to draw out this comment because it's so antithetical to what Apple marketed that it stood for (if you remember, the wonderful 1984 commercial Apple created; which was very much against the big behemoths of the day and the way they operated).

We're at the point where we've normalized crappy behavior and crappy software so long as the bottom line keeps moving up and to the right on the graph.

Not, "Let's build great software that people love.", but "How much profit can we squeeze out? Let's try to squeeze some more."

We've optimized for profit instead of happiness and customer satisfaction. That's why it feels like quality in general is getting worse, profit became the end goal, not the by-product of a customer-centric focus. We've numbed ourselves to the pain and discomfort we endure and cause every single day in the name of profit.

This is exactly the mindset to which GP and I object.

>anybody's bug.

:)

Funny at first but I’m coming around to that perspective

> It certainly doesn't seem to hurt their bottom line

…yet

Every other month I get an email from a legacy pre-GH bug tracker that's either a "me too" or "bug fixed in latest release" a decade after I filed these one-offs you would be so quick to throw away. Bugs with no activity for years on end.

Closing bugs because they can no longer be reproduced: obviously fine.

Closing bugs automatically after a cron job demanded that the user verify reproducibility for the 11th time: obviously bad.

That would be an accurate summary of almost all software.

Either it's quickly produced and thrown out the door as it's a startup trying to iterate and find market fit asap or because it's a bigcorp who's metrics are all not related to software.

I wish someone had told me how common this was back when I worked myself to death fixing every UI abnormality that no one except some misincentivized testers used to report at my first job. At the time I thought it was dishonest to say something was irreproducible and it'd be beneath me to patch an issue knowing it'll sprout ten others.

I'm proud of fixing everything properly but I won't repeat it ever unless the company actually has that high a bar across the board.

> the developer will push back on the bug author and say "I can't reproduce this, can you verify it with the latest version?" without actually doing anything.

We do this. Because frankly, very often the bug has been reported by others and has been fixed, we just can't connect the dots in our ticketing system.

That's of course less than ideal, but given that a lot of tickets we get are often very poorly described it's hard. It's one aspect I have genuine hope AI can help us with.

Is your argument "it's bad everywhere, so it's ok"? As a software developer I do understand how enterprises operate, as a customer and a user I'd put Apple under higher scrutiny and would expect better.

I used to think that there is no harm in keeping the bug open. I think if you honestly feel that you have the time and resources to go back to the bug and fix it, then by all means keep it open.

But I find that sometimes I can tell from experience that the IR is not actionable and that it will never be fixed. Some examples:

* There's not enough info to reproduce the issue and the user either can't or won't be able to reproduce it themselves. Intermittent bugs generally fall into this category. * The bug was filed against some version of the software that's no longer in production (think of the cloud context where the backend service has been upgraded to a newer version).

Sometimes the cost to investigate a bug is so high relative to the pain caused that it just closed as a WONTFIX. These sometimes suck the most because they are often legitimate bugs with possible fixes, but they will never be prioritized high enough to get fixed.

Or sometimes the bug is only reproducible using some proprietary data that I don't have access to and so you sometimes have no choice but to ask the bug filer "can you still reproduce this?".

Computer systems are complicated. And real-world systems consisting of multiple computer systems are even more complicated.

What is the use in keeping it open when no one will ever look at it again after it goes stale? It still exists in the system if you ever wanted to find it again or if someone reports the same issue again. But after a certain time without reconfirming the bug exists, there is no point investigating because you will never know if you just haven't found it yet or if it was fixed already.

I don't work at Apple, so I can't comment on that. But that doesn't always help. There's been plenty of times where I have a full HAR file from the user and I can clearly see that something went wrong, but that doesn't always mean I can reproduce the issue. (I recognize a HAR file doesn't represent the complete state of the world, but it's often one of the best things a backend developer can get)

That’s easy enough. The hard part is doing so without capturing a bunch of email, messages, and other private data that happens to be in memory at the time.

Feeling overwhelmed by insurmountable mountain of bugs and issues is not the way either. We can argue that closing the tickets is not the best way, but if realistically nobody will ever look at them, why not make the developers feel better.

Sure. So try to reproduce on a current build, and close with a "No longer reproduceable on ___". That'd be good practice. Closing silently because no one can be bothered to evaluate at all is horrendous, and creates the user expectation that "no one looks at these, so I'm not going to keep reporting it" which "justifies" developers closing old bugs.

the right thing to do is to actually ping the original reporter if possible, or a developer that you might assign the bug to and try to drive it to a conclusion.

if the answer is 'everything in that part of the code has been rewritten' or 'yeah, that was a dup, we fixed that' or 'there isn't enough information here to try to reproduce it even if we wanted to' or 'this a feature request that we would never even consider' or some other similar thing, then sure delete it.

otherwise you're just throwing away useful information.

edit: I think this difference of option is due to a cultural difference between (a) the software should be as correct as reasonably possible and (b) if no one is complaining then there isn't a problem

Careful saying that too loudly, the “ship new features at all costs” gang will come for your head. They don’t approve of things like “quality software” and “making stuff that works past the demo and cursory inspection” or “actual user utility”.

All my homies hate stalebot

Companies are made of humans who do.

I had an even more time consuming experience like this. I worked with Apple Support over the phone for a few months. They had me install a profile on the iPhone to collect more diagnostic logs, had me perform various steps to reproduce the issue, followed up for more information, etc. After a few months, the person assigned to the case went on vacation or something and another person was assigned. Coincidentally, it was getting closer to a new iOS release date. My whole case went completely dead and there was no way to revive it.

No. https://news.ycombinator.com/item?id=47523983

I think asking someone if they can still reproduce an issue is valid. Especially if it was trivially reproducible for them, and now it isn't, that seems like a fine resolution, and the bug should be closed.

But in the other cases, closing the bug seems to me to be a way to perturb metrics. It might be true that you'll never fix a given bug, but shouldn't there be a record of the "known defects", or "errata" as some call them?

For your specific scenarios:

- lack of information on how to reproduce or resolve a bug doesn't mean it doesn't exist, just that it's not well understood.

- For the "new version" claim, I've seen literal complete rewrites contain the same defects as the previous version. IMHO the author of the new version needs to confirm that the bug is fixed (and how/why it was fixed)

- I agree there are high cost bugs that nobody has resources to fix, but again, that doesn't mean they don't exist (important for errata)

- Similarly with proprietary data, if you aren't allowed to access it, but it still triggers the bug, then the defect exists

In general my philosophy is to treat the existence of open bugs as the authoritative record of known issues. Yes, some of them will never be solved. But having them in the record is important in and of itself.

See my reply to eminence32 - bug tracking serves as a list of known defects, not as a list of work the engineers are going to do this [day/month/year].

Reminds me of this Raymond Chen Microsoft blog post:

https://devblogs.microsoft.com/oldnewthing/20241108-00/?p=11...

Because it isn’t about the developers feelings, it’s about the users. Why not set aside a day or half day a week to fix those bugs instead?

Either you truly need to fix the bugs, in which case the feeling is good and maybe more effort should go that way (more resources assigned to it or whatever), or you're at a scale where tackling everything is impossible and you shouldn't feel overwhelmed by seeing the noise then.

But I think modern industry pretends all it's fine to convince themselves that it's ok to chase the next feature instead.

>creates the user expectation that "no one looks at these

Apple has done the best job of creating this expectation.

Apple Feedback = compliments (and ideas)

Public Web = complaints & bug reports

Apple Support = important bug reports (can create feedback first then call immmediately)

—

Prev comment w/link (2mo ago): https://news.ycombinator.com/item?id=46591541

> try to reproduce on a current build

Good luck doing that when the bug report (like virtually all bug reports in nature) doesn't provide sufficient reproduction steps.

Closing bugs because of a rewrite is probably the most harmful practice in the whole industry. The accumulated unresolved issues of your existing code base are a rich resource of test cases. Writing the new code base without checking to see if it fixes the old bugs is a mistake.

There's also going to be mountains of bugs resulting from cosmic rays hitting the computer, defective ram chips, weird modifications of the system the reporter hasn't mentioned.

You could sink an infinite amount of time investigating and find nothing. At some point you have to cut off the time investment when only one person has reported it and no devs have been able to reproduce it.

> 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.

Why do you close the issue then?

This is where a company that categorizes customer feedback like unwrap.ai or enterpret could help with volume and priority

Ignorant question, if privacy didn’t matter and they had an atomically identical machine, would there still be plenty of edge cases where it was the printer or the Wi-Fi causing the issue?

In any case I would have said it sounds difficult on every front

Move them to a deficated status. “Never triaged”, “lost”, “won’t do”, what have you.

That way, you’re at least not deluding yourself about your own capacity to triage and fix problems, and can hopefully search for and reopen issues that are resurfaced.

That kind of attitude disgusts me. Like it's someone else's job to have a sense of accountability. They would not remain employed in my company.

When I developed software I would jump right on top of any bug reports immediately, and work until they were fixed. I was grateful to my customers for bringing them to my attention.

I can sort of back that for desktop apps but telemetry is so trivial for webapps needing a reproducer is almost an embarrassing admission the operator has no clue what they're doing.

Error tracking and tracing make it fairly straight forward to retroactively troubleshoot unreproducible issues.

  > this often isn't nefarious. It's a simple cost/benefit analysis of spending time on something that one user is complaining about versus a backlog of higher business priorities.

You can triage without closing tickets. So it is nefarious. It is metric hacking

If you're having trouble reproducing, tag "needs verification" or something else. But closing a ticket isn't triaging, it is sweeping problems under the rug

> I don't think you can trust engineering teams (or, worse, individuals) to "own" bugs. They're not going to want to do them.

I will disagree there. The engineers often want to fix the bugs. Management is telling them they need it's all hands on deck for (Insert company goal here. Probably AI right now).

Followed by management also telling them they have too many bugs, of course. In a condescending tone.

> IIRC bugs had both a priority and s everity for some reason (they were the same 99% of the time) between 0 and 4. So a standard bug was p2/s2. p0/s0 was the most severe and meant a serious user-facing outage

I've seen this at a couple places... I think it's supposed to help model things like if something is totally down, that's an S0... But if it's the site for the Olympics and it's a year with no Olympics, it's not a P0.

Personally, that kind of detail doesn't seem to matter to me, and it's hard to get people to agree to standards about it, so the data quality isn't likely to be good, so it can't be used for reporting. A single priority value is probably more useful. Priority helps responsible parties decide what issue to fix first, and helps reporters guess when their issue might be addressed.

> People would often change a p2/s2 to p3/s3, which basically meant "I'm never going to do this and I will never look at it again".

I learned this behavior because closing with wontfix would upset people who filed issues for things that I understand, but am not going to change. I'm done with it, but you're going to reopen it if I close it, so whatever, I'll leave it open and ignore it. Stalebot is terrible, but it will accept responsibility for closing these kinds of things.

(I work at ElevenLabs)

Sad to hear this. How are you submitting the bug report? If you submit an issue via any of our open source repos on GitHub you'll get a timely human response.

I mean it can be useful to do that every year on old (say 2y+ tickets) but the way it is usually done is completely aisine

Sensible way would be probably something like this

* run cleaning yearly, on bugs say not touched (which is different than age!) for last 2 years * mark bug waiting for answer, add automated comment with "is it still happening/can you reproduce it on newest version?" * if that gets unanswered for say 3 months THEN close it.

that way at least it's "real" issue and even if solution is not being worked on maybe someone will see workaround that sometimes someone posts in the comment. Not create new one that gets closed for being duplicate...

Meanwhile I've seen shit as aisine as making bug stale 30 days after reporting.

What if no devs even tried to reproduce it, and they have no reason to believe they've fixed the bug with any other changes?

That seems to be the case described in the article. In such a situation, I think it's dishonest to ask the reporter to expend even more effort when you've spent zero. Just close it if you don't want to do it, you don't have to be a jerk to your customers, too, by sending them off on a wild goose chase.

Otherwise, why not ask the reporter to reproduce the issue every single day until you choose to fix it in some unknown point in the future, and if they miss a day, it gets closed? That seems just as arbitrary.

I'll steal this to my projects bug template! /s

"Please consider cosmic rays hitting the computer, defective ram chips, weird modifications of the system before submitting the bug. Unlesss you explicitly aknowledge that, your bug will be closed automatically in 30 days. Thank you very much"

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.

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

Because open source is corporate now

I should be more precise. Capturing the system state isn’t too hard. Turning that into a reproducer may be quite hard, because of things like you say. There are certainly a lot of bugs that such a capture would make easier to figure out, but it wouldn’t be a panacea.

Stalebot closing is a problem. There's no problem with stalebot adding a stale label (but really, a filter with last update x time ago does the same).

Adding filters so that developers only look at actionable tickets would be much more sane.

It's rather unreasonable to be annoyed. The maintainers may have entirely different priorities, which is fine. They're also likely being spammed with low-effort bug reports (not yours necessarily but from others).

The great thing about open source projects you can just fix the bug yourself and submit a PR, or fork the whole project if the maintainers won't merge your changes. If you don't have the time or skills yourself then you can even pay a contractor to do it for you.

And if the maintainer does close the issue, you can have the agent make a disparaging blog post automatically.

Deficated?

I like this. It should be a status.

"I deficated this issue. Closed."

Exactly. Thank you for saying this.

No.

My guess it's just the emergent behavior that results when a company doesn't provide developers time to fix bugs.

If their week is already booked full just trying to keep up with the roadmap deadlines, a bug ticket feels like being tossed a 25lb weight when you're drowning.

You could say: "but have pride in your work!"

But if your company only values shipping, not fixing, that attitude doesn't make it through the first performance review.

It is different when you have a billion customers, all with different setups. At that scale, you notice real defects through product telemetry, support ticket volume, or trusted channels. You receive a high volume of bug reports that are due to user confusion, misconfiguration, or misbehavior of other software on the device - where solving an issue for one customer doesn't result in improvements for the other billion. Triage, filtering, and winnowing are necessary here.

> That kind of attitude disgusts me. Like it's someone else's job to have a sense of accountability.

GTK1, GTK2, GTK3, GTK4, GTK5. Fixing bugs is hard, rewrite is easier.

And total 24/7 surveillance also makes police work easier, but it's still wrong.

You're right in that it's unreasonable to expect someone else work for you for free

But I would also say a quality bug report is a contribution in and of itself

Closing it without reason is also, literally, unreasonable

> Adding filters so that developers only look at actionable tickets would be much more sane.

That's a reasonable approach, but I don't understand how it's any more or less sane than autoclosing them with a stale label.

Whether these sorts of bugs are "open but stale" or "closed because stale" seems like it depends on whether the project defines "closed" as "no work planned" or "fixed", which both seem valid.

Either way these bugs will be hidden from developer dashboards but still available in the database so there's no practical difference, you just need to make sure everyone is on the same page about the meaning of "closed".

It's Apple. They won't even notice. If all of 4chan and HN decided to abandon Apple they wouldn't even register the change.

It is not about "priorities". Putting work into writing bug is utterly useless, because if the maintainer does not fix it in 2 months, the bug will be closed as stale. I am actually fine with open source project maintainer to prioritize stuff and hey, maybe that bug will be fixed in 6 months when they have time. But I am not fine being told "we did not had time for 2 moths, therefore we are closing your bug" as is standard on github now.

Do not throw the ball back with "this happens because bugs are not well written". Stalebot closes bug regardless of whether they are well written and ensures no one will put effort into writing another well written bug again.

> It's rather unreasonable to be annoyed.

I disagree. If you discover that a bug that makes an open source library unusable to you, after spending time on learning and using that library, and the authors close the bug as a wontfix, I think being annoyed is quite reasonable, even expected.

You pay contractors to fix open source bugs? Tell me how that works

Sheesh, you see suggestions here all the time. Just trying to be helpful

You’ve just described AGILE development, a way for product owners to backlog code rot while empowering developers to feel like they have a say in things.

I got a lot of those too, it meant I inevitably did a little bit of free tech support for my customers. In the end I felt it was worth it as they raved about the quality of support and it was a real differentiator - not to mention built a lot of brand loyalty (and internal staff loyalty too once I grew enough to build out a team - they derived real satisfaction from actually solving problems instead of playing ping-pong).

I agree regarding the need to triage at scale, unfortunately most large companies I've encountered fail to do this well and seem ill-equipped to accept high quality bug reports of edge case defects generated by expert users (save for the odd exception that arrives by social media from someone who happens to have enough followers to get their attention outside the regular support pipeline).

In my experience this doesn't usually boil down to a systems issue (the ticketing systems etc. exist that should theoretically allow for eventual escalation to the right engineer/developer) but a corporate culture thing (the company just doesn't prioritize customer feedback especially at the level where staff who actually deal with customers interface with the teams that write/maintain the software). Often it's genuinely valued at the C-level (the Bezos story of calling Amazon"s tech support line during an exec meeting is a fun example) but diluted somewhere between them and the rank-and-file.

(Ps. I'm not arguing with you and appreciate you took the time to craft a thoughtful reply)

It should be the other way around - at billion customer scale you should be responsible for how your product interacts with other software whose developers have less resources than you.

What I've found to be most effective for program management is to set aside a maintenance team separate from the feature teams. The roadmap is then planned without counting anything for the maintenance team and they deal with bug tickets as they come in. Rotate the assignment periodically so that every developer has to occasionally spend a few months on the maintenance team.

None of those were full rewrites. Not sure what point you are trying to make.

...you're claiming error tracking and monitoring are wrong?

We're talking about companies you voluntarily have a relationship with, not the government

It's open source software. If you discover the bug, have written a failing test that demonstrates it, and a proposed solution to it, then maybe you can be annoyed when the authors close it as wontfix.

Otherwise OSS is pretty much as-is, where-is, with the exception of very widely used and corporately supported projects.

If that type of thing annoys you then you should restrict your use of open source projects to those backed by corporations with a paid support business model.

Is that a serious question? It works like any contract programming gig. You give the contractor money and in exchange they give you code (including copyright assignment). You can go through a freelancer site like Upwork if you don't know an appropriate contractor yourself.

Not really no, you got the support you were willing to pay for.

The telemetry is almost always not voluntary and neither is the relation ship with the companies in the first place unless you mean that technically you could become a hermit living in the woods.

Doesn’t this lead to problems like the feature team pushing buggy code and having no accountability or responsibility to deal with it?

My preference is to treat the defects like feature work, size and plan. Yes you might not get all the feature work done but the team is accountable for everything they make

For feature requests, sure, but not for bug reports

If the maintainer merely doesn't fix the bug, then yes. If they close the bug report so it gets lost and other contributors are discouraged from working on it, then no.

There's a lot more to effective program quality management than I can explain in a comment here. Forcing all developers to rotate through the maintenance team is one incentive not to ship crap because they might end up having to deal with it anyway. But more importantly you have to shift left the quality assurance and control activities to minimize the risk of defect leakage in the first place. And set up a closed-loop system where any leaked defect triggers a rigorous root-cause analysis that results in further process improvement.

Closed reports are not lost, they are still searchable/linkable, they are just not in the list of work to do.

This is entirely up to the maintainer, who puts in the work and gives up their time/money to do so. If you want to be in charge on a given repo, put in the work and become a real contributor, if not accept the rules the maintainers choose.

You know what I mean. If the issue is closed, it looks like it's been solved. A new issue may be created that duplicates it, etc.

Obviously it's up to the maintainer. I'm saying what the maintainer should do, not what they can do.

Dupe reports are a signal all by themselves, that's really not harmful, nor does something being closed implied solved.

You shouldn't presume to know what is best for an open source maintainer of any given project - projects vary, reports vary in quality, and the job of maintenance is not an easy one.