However there are "bugs" that actually do turn out to be just cosmic rays flipping bits or plain user error. If you as the reporter don't provide enough information for the developer to be sure they are not going on a wild goose chase then it's fair for the developer to not invest too much time.
Sure. But I'm biased because I was a "customer" of a former (large) company's products while also working at that company. So the bugs I would file were the type that a customer would file, but since I was inside, I saw how they were handled. The tactics that my fellow R&D developers would do to claim something wasn't a bug or reproducible were nearly endless.
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?
> 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.
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.
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.
Most of the time, there isn't any reason to believe it could be fixed, i.e. there were not any non-trivial changes around that area. What you're describing happens less frequently, and in such cases, the devs should discuss that with the reporter.
In this specific example, it looks like Apple gave no indications that such changes had happened, and no indications they had even spent a nonzero amount of effort following the reproduction instructions with either the old code or the new code.
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.
Constituional cours are a last defense against bad laws though and should not be the first one - they are not designed to be fast enough to prevent a lot of damage being done before they strike something down.
The first defense is that the Council of the EU (formed by government ministers of the member states) and the European Parliament (elected directly by EU citizens) have to agree on the legislation. And while the council is staffed by career politicians, the parliament is a more diverse group that's generally a bit closer to the average person
From the point of view of the individual, the parliament is our first defense. And this is an example of it working
If something in 'Chat Control' is so fundamental that it should lead to the law not even being brought up for discussion (privacy), then that 'right' should be more clearly defined in the constitution, or constitution like structure.
It's when laws can exist, but simply have bad implementations, where you obviously can't jump to an amendment process.
reply