> And how do you address my point that the volume of so-called "unimportant" bugs
I would address your point by first re-focusing our attention on the basic and commonly understood meaning of the word "unimportant" - the definition is fairly easy to understand, so just grasping that again as part of the conversation seems to be necessary.
So, you asked about the "so-called" unimportant bugs? Yeah, they're called that because they're the unimportant ones. It sucks if an unimportant bug bothers you or interrupts your workflow - been there.
If unimportant bugs still seem important to you, an easy way to understand this concept is that in comparison, other bugs exist that are deemed even more important than these. And the company developing the software in question gets to make this call.
> a myriad of small, nearly-meaningless bugs ... pile up until your product is noticeably full of them.
I don't think that is at all how this works. There are numerous bugs and errors in software that have no real effect on users. Could they be fixed? Sure. But having 10 of these (your words) "nearly-meaningless" things still results in ... near-meaningless. If they had meaning and were important, people would be complaining so much about it that you couldn't sweep the issue away by auto-closing a dead 2-year-old ticket.
> Google is constantly, constantly, constantly, constantly adding new features.
Correct. It is what people/users seem to like and want. Unsurprisingly, new features come with new bugs... these new bugs may be way nastier than the so-called "unimportant" bugs that have been well-known for a while. Which fix should the team focus on?
> Worse, they've obviously chosen to auto-close bugs that they've ignored
They've "ignored" aka de-prioritized some requests, because otherwise all requests would have to be considered equally important. When that happens, important things don't get handled.
If the bugs being auto-closed were important, users would be clamoring about it, discussing the issue, and opening tickets with support. When one developer with a hawk-eye for errors drops a new bug/suggestion, it isn't going to get the same attention as a huge file-deletion bug in the new feature that just rolled out and is being actively used.
> I don't know whether they do that anymore, but the point is that Google has plenty of time to do stuff.
Again, even big companies do not have infinite resources. Just jumping to the conclusion that they're big means they should be able to do everything tells me there is a lack of experience speaking an opinion here.
I’ve seen that argument a few times, yet no one has ever been able to point to any tangible proof. Anecdotally, I see people significantly more frustrated by things working poorly than a lack of imagined features no one asked for.
> Unsurprisingly, new features come with new bugs... these new bugs may be way nastier than the so-called "unimportant" bugs that have been well-known for a while. Which fix should the team focus on?
They should first focus on the bugs to old features that the new features caused. Adding new functionality should never cause a regression to what already exists, but when it happens, those should be prioritised.
> I’ve seen that argument a few times, yet no one has ever been able to point to any tangible proof.
The tangible proof you're looking for is the current market/state of software as it is developed and released in general across the commercial industry.
> Adding new functionality should never cause a regression to what already exists, but when it happens, those should be prioritized.
The general audience and attention cycles pay attention and/or act in response to things like new features, not old bug fixes. Even if fixing old bugs is a #1 priority for you, it does not change that the average consumer accepts the current arrangement with very little complaint.
> The tangible proof you're looking for is the current market/state of software as it is developed and released in general across the commercial industry.
When every company does the same thing, that tells you nothing about what the public wants. There is simply no choice. By your logic, every authoritarian thing governments do is what people want, but all of those are highly contentious. Pointing at the current state of things is seldom an accurate barometer of desire. If that were the case, nothing would ever change.
> with very little complaint.
Clearly you haven’t been closely following the release of macOS Tahoe. Don’t conflate the general public with “influencers” whose only job is to hype anything new.
> When every company does the same thing, that tells you nothing about what the public wants.
Widespread adoption across an industry is a classic market response to satisfying demand.
> By your logic, every authoritarian thing governments do is what people want, but all of those are highly contentious
Discussing software feedback forums and jumping to how I would respond to a conversation about a authoritarian "thing" governments do is irrelevant and didn't go anywhere
> Clearly you haven’t been closely following the release of macOS Tahoe.
You have jumped to an entirely incorrect conclusion here. I have made dozens of comments and been involved in the beta testing of Tahoe.
It is generally best in a conversation to try and engage with the information others post.
> the basic and commonly understood meaning of the word "unimportant" - the definition is fairly easy to understand
This is nonsense. I don't agree at all. The meaning of "important" and "unimportant", with respect to any particular issue, is vague, controversial, arguable. It's ridiculous to suggest that we can easily put bugs into those two categories.
> There are numerous bugs and errors in software that have no real effect on users.
This is also nonsense. If there's "no real effect", then there's no bug.
> But having 10 of these (your words) "nearly-meaningless" things
What are you claiming to be my words?
> It is what people/users seem to like and want.
More accurately, what stockholders/advertisers seem to like and want.
> They've "ignored" aka de-prioritized some requests, because otherwise all requests would have to be considered equally important.
That's nonsense, and not how it works. In fact the Google bug tracker has a specific "Priority" label for each report. You don't need to close a bug report to assign it a priority.
> When that happens, important things don't get handled.
That's not true either. Not all open bug reports get "handled".
> When one developer with a hawk-eye for errors drops a new bug/suggestion
1. I didn't drop a suggestion.
2. I didn't have a "hawk-eye for errors". I'm not specifically looking for bugs in Chrome. I have absolutely no desire to do free labor for an ultra-wealthy mega-corporation. I was simply using the developer tools, and they didn't work right.
> Just jumping to the conclusion that they're big means they should be able to do everything
Another straw man.
> there is a lack of experience speaking an opinion here
What "lack of experience" are you referring to? I've been a professional software developer for 19 years, how about you?
Sorry for not responding to the rest of your message, it's just a low priority kind of thing where I'll probably just respond in 2 years and ask for a system report and then auto-close the ticket.
I would address your point by first re-focusing our attention on the basic and commonly understood meaning of the word "unimportant" - the definition is fairly easy to understand, so just grasping that again as part of the conversation seems to be necessary.
So, you asked about the "so-called" unimportant bugs? Yeah, they're called that because they're the unimportant ones. It sucks if an unimportant bug bothers you or interrupts your workflow - been there.
If unimportant bugs still seem important to you, an easy way to understand this concept is that in comparison, other bugs exist that are deemed even more important than these. And the company developing the software in question gets to make this call.
> a myriad of small, nearly-meaningless bugs ... pile up until your product is noticeably full of them.
I don't think that is at all how this works. There are numerous bugs and errors in software that have no real effect on users. Could they be fixed? Sure. But having 10 of these (your words) "nearly-meaningless" things still results in ... near-meaningless. If they had meaning and were important, people would be complaining so much about it that you couldn't sweep the issue away by auto-closing a dead 2-year-old ticket.
> Google is constantly, constantly, constantly, constantly adding new features.
Correct. It is what people/users seem to like and want. Unsurprisingly, new features come with new bugs... these new bugs may be way nastier than the so-called "unimportant" bugs that have been well-known for a while. Which fix should the team focus on?
> Worse, they've obviously chosen to auto-close bugs that they've ignored
They've "ignored" aka de-prioritized some requests, because otherwise all requests would have to be considered equally important. When that happens, important things don't get handled.
If the bugs being auto-closed were important, users would be clamoring about it, discussing the issue, and opening tickets with support. When one developer with a hawk-eye for errors drops a new bug/suggestion, it isn't going to get the same attention as a huge file-deletion bug in the new feature that just rolled out and is being actively used.
> I don't know whether they do that anymore, but the point is that Google has plenty of time to do stuff.
Again, even big companies do not have infinite resources. Just jumping to the conclusion that they're big means they should be able to do everything tells me there is a lack of experience speaking an opinion here.