4 ms·

I understand, agree, and feel for you. It sucks when people are vague when asking for something. From what I can tell though, a lot of folks are vague in gener

I understand, agree, and feel for you. It sucks when people are vague when asking for something. From what I can tell though, a lot of folks are vague in general. They’ll avoid putting in the effort to clarify as long as possible, hoping others will do that clarification work for them. The question I then ask is “why?” I think the answer lies in three categories of people: - lacking knowledge: to know what’s worthwhile to explain what’s happening (common with non-technical folks) - lacking time: to take the necessary effort to describe and explain something is expensive if you have a very full schedule - too lazy: can’t be bothered to care enough to take the time to explain themselves properly. I’d like to think it’s more of points 1 and 2 that are causing this problem, but I have a feeling the majority of it is point 3 based on my interactions with humanity. What are your thoughts on this? Ideas for how we could improve bug submission given this very clear and arguably difficult problem?

rapind 4y ago
It’s definitely laziness, but they’ll argue it’s lack of time (and lack of knowledge is really just too lazy to self inform). It’s not just a problem with open source, but commercial product support as well. I’ve had customers who invest no effort in a support request then get annoyed when we try to politely extract what the actual issue is from them. For open source I’d lean towards a policy of 0 investment from you, then 0 investment from me. You can always archive low effort issue reports to peruse at a later date when you have free time to see if you can discover something meaningful in them.
- tennis_80 4y ago
  I agree with this. In my experience often people want to push the problem to someone else - if you can say in your team status update "I've opened a ticket with X, waiting on them to solve the issue", you can get away with being blocked. If the aforementioned ticket is closed for lack of detail, it becomes more obvious to others on said team that the person needs to do more exploratory work.
anonred 4y ago
Bug report templates work wonders. Ours is just some checkboxes and a few lines for OS version, package manager, etc. but it’s been effective at filtering out low effort reports.
solatic 4y ago
The naive approach is to have bug submission be part of the product you ship to customers. If you run into an issue - "a report has already been sent. If you want to follow the status of your report, click here <link with bug ID number>". If the user runs into an issue that doesn't trigger the automated bug report submission, then have a UI with the relevant questions, which can automatically attach stuff like application version number, OS version, etc. The problem? a) Pretty expensive to implement. You basically need to be FAANG with a huge install base and measurable reduction in customer service costs to justify the expense. b) This pattern doesn't integrate well into developer workflows, i.e. if you try to automatically open a GitHub issue with it, then who opened the issue, a bot? How do you ensure users stay notified, even if they don't have a GitHub account? If the issue is a duplicate of an existing issue, how do you auto-subscribe the user to the existing issue? What if the repository is private? You can't really come up with technical solutions to human problems. The human problem is that users need to be listened to, and you need to talk with them. Maybe it's a bug, maybe it's a feature. Maybe the user has an issue with their Internet access. Maybe the user didn't RTFM. You run into this problem with poor GitHub issues because GitHub issues is not a platform for Product, and you should not force it or expect it to become one just because it seems easier to do so when everything else relating to the open-source library is already there on GitHub. GitHub Discussions is a step in the right direction, but GitHub's UI is currently lacking in terms of helping projects start to move Product and Customer Support into Discussions and creating a consistent user experience across projects for doing so.
- nmstoker 4y ago
  Interesting you should mention about submitting details like app version number, OS version etc. Although it's not within an app, and only partially automated, i tried building a tool to help people gather Python environment details etc to help them create richer Github issues with less effort: https://github.com/nmstoker/gatherup https://github.com/nmstoker/gatherup The demo video needs work to explain it better and as a project it didn't really go anywhere but it was interesting to work on a few years back.
nmstoker 4y ago
You're absolutely right to ask why, and the reasons you give do drive the difficulties here. Although I'm fairly technical, I think I have a fair understanding of those in the non-technical camp due to my background and general experience, but I sense I sometimes expect too much of the average person (not meaning this to sound superior!) Improving bug submission is worth consideration because there's value to be unlocked: the people in need of a solution have insights the developers etc benefit from and they themselves would benefit (one hopes!) from the solution but there's a good chance it could apply for others too. From the little I've read about behavioural science, i suspect that a selection of nudges may help but it could take time and perseverance to get it right. There are little tricks that Github and SO already use to shift things the right way. It's important to base these on how they'd work for target users, as designing them for how people who design such systems or already have well developed problem solving serves no one and will fail! It's also important not to be overly Draconian or pushy (keeping the nudges reasonable) seems important too, and the smartest ones probably lead people on to better submissions as much as block bad ones, the earlier the better (no one wants to fill in some onerous form only to be told off by a computer!)

rapind 4y ago

It’s definitely laziness, but they’ll argue it’s lack of time (and lack of knowledge is really just too lazy to self inform). It’s not just a problem with open source, but commercial product support as well. I’ve had customers who invest no effort in a support request then get annoyed when we try to politely extract what the actual issue is from them. For open source I’d lean towards a policy of 0 investment from you, then 0 investment from me. You can always archive low effort issue reports to peruse at a later date when you have free time to see if you can discover something meaningful in them.

tennis_80 4y ago
I agree with this. In my experience often people want to push the problem to someone else - if you can say in your team status update "I've opened a ticket with X, waiting on them to solve the issue", you can get away with being blocked. If the aforementioned ticket is closed for lack of detail, it becomes more obvious to others on said team that the person needs to do more exploratory work.

anonred 4y ago

Bug report templates work wonders. Ours is just some checkboxes and a few lines for OS version, package manager, etc. but it’s been effective at filtering out low effort reports.

solatic 4y ago

The naive approach is to have bug submission be part of the product you ship to customers. If you run into an issue - "a report has already been sent. If you want to follow the status of your report, click here <link with bug ID number>". If the user runs into an issue that doesn't trigger the automated bug report submission, then have a UI with the relevant questions, which can automatically attach stuff like application version number, OS version, etc. The problem? a) Pretty expensive to implement. You basically need to be FAANG with a huge install base and measurable reduction in customer service costs to justify the expense. b) This pattern doesn't integrate well into developer workflows, i.e. if you try to automatically open a GitHub issue with it, then who opened the issue, a bot? How do you ensure users stay notified, even if they don't have a GitHub account? If the issue is a duplicate of an existing issue, how do you auto-subscribe the user to the existing issue? What if the repository is private? You can't really come up with technical solutions to human problems. The human problem is that users need to be listened to, and you need to talk with them. Maybe it's a bug, maybe it's a feature. Maybe the user has an issue with their Internet access. Maybe the user didn't RTFM. You run into this problem with poor GitHub issues because GitHub issues is not a platform for Product, and you should not force it or expect it to become one just because it seems easier to do so when everything else relating to the open-source library is already there on GitHub. GitHub Discussions is a step in the right direction, but GitHub's UI is currently lacking in terms of helping projects start to move Product and Customer Support into Discussions and creating a consistent user experience across projects for doing so.

nmstoker 4y ago
Interesting you should mention about submitting details like app version number, OS version etc. Although it's not within an app, and only partially automated, i tried building a tool to help people gather Python environment details etc to help them create richer Github issues with less effort: https://github.com/nmstoker/gatherup https://github.com/nmstoker/gatherup The demo video needs work to explain it better and as a project it didn't really go anywhere but it was interesting to work on a few years back.

nmstoker 4y ago

You're absolutely right to ask why, and the reasons you give do drive the difficulties here. Although I'm fairly technical, I think I have a fair understanding of those in the non-technical camp due to my background and general experience, but I sense I sometimes expect too much of the average person (not meaning this to sound superior!) Improving bug submission is worth consideration because there's value to be unlocked: the people in need of a solution have insights the developers etc benefit from and they themselves would benefit (one hopes!) from the solution but there's a good chance it could apply for others too. From the little I've read about behavioural science, i suspect that a selection of nudges may help but it could take time and perseverance to get it right. There are little tricks that Github and SO already use to shift things the right way. It's important to base these on how they'd work for target users, as designing them for how people who design such systems or already have well developed problem solving serves no one and will fail! It's also important not to be overly Draconian or pushy (keeping the nudges reasonable) seems important too, and the smartest ones probably lead people on to better submissions as much as block bad ones, the earlier the better (no one wants to fill in some onerous form only to be told off by a computer!)