Please tell us where you work so we can avoid all of your company’s software. Unless it’s Microsoft, because we’ve already seen the results of that attitude there.
I don't see how it's an unreasonable request. If you demand that I work with some ancient version, I then have to install and uninstall said program every time I work on your ticket specifically. You will be prioritized last, because my effectiveness is measured by how many tickets I close.
just bc everyone is calling you insane: you are being extremely reasonable.
Author must not have worked in enterprise software before. That's a classic trick where 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. And if it doesn't get confirmed then they can close it as User Error or Not Reproducible. Of course, the only way to counter this is by saying "Yes I verified it" without actu…
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").
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.
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").
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.
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.
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.
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. Do…
Yeah competition works. I don't like nexus that much but they accept every ticket I've opened and fix it the next release. Two things I think affect that. One, my ticket has the name of a fortune 100 next to it. Two, artifactory will eat them alive if they don't keep customers happy.
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").
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.
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.
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, be…
High end enterprise products still come with support. That's literally what customers are paying for: a single throat to choke.
Exactly! The "pay a lot of money but get really good support" tier still exists just about everywhere. You just didn't do the first part.
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.
There's obviously some nuance here, but the fact is that much modern software is riddled with bugs, and this is sub-optimal for everyone (both software users and software builders). Most of the bugs which frustrate and irritate software users are not due to uncontrollable events such as cosmic rays flipping a bit. Most of them are plain old code defects. But, you do have a valid point. Allow me to rephrase it this wa…
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…
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 c…
> 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.