Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't be that open-source user, don't be me

jacobtomlinson.dev

Post reply on HN
Print view View original

161–170 of 173 posts

Re: Don't be that open-source user, don't be me

#161

Post by tgsovlerkhgsel »

One pattern I've noticed that leads to low quality bug reports is that high quality bug reports take time, and bug reports, even if they're high quality, are often ignored if they're not an absolutely critical issue.

After spending an hour of time writing the perfect bug report a couple of times, and each time receiving no reward (= fix), often not even seeing a sign that anyone looked at the report, this gets incredibly frustrating, and creates a temptation to not put in the effort anymore.

Which results in low quality bug reports, which exacerbates the issue (makes work harder for the maintainers, makes bugs less likely to get looked at/fixed, makes it more likely that the user encounters more such frustration).

I see the pattern, but I don't have a solution. One thing I've started to do is filing an initial low-quality bug report and offering to follow up (and actually doing it) once anyone shows any amount of interest, but that still leaves a crappy and non-actionable bug report.

Re: Don't be that open-source user, don't be me

#162

Post by Jiro »

tgsovlerkhgsel wrote: post #161

One pattern I've noticed that leads to low quality bug reports is that high quality bug reports take time, and bug reports, even if they're high quality, are often ignored if they're not an absolutely critical issue. After spending an hour of time writing the perfect bug report a couple of times, and each time receiving no reward (= fix), often not even seeing a sign that anyone looked at the report, this gets incred…

>After spending an hour of time writing the perfect bug report a couple of times, and each time receiving no reward (= fix),

Something that may be happening in that case is that the demand for making the bug report high quality is not sincere, but is just meant to kill it by filibuster. The developers won't fix the bug regardless, but by making it easy to say "you didn't follow all these steps in submitting the bug", they can put the blame on the user rather than just admitting they won't fix it.

Re: Don't be that open-source user, don't be me

#163

Post by nmstoker »

softfalcon wrote: post #127
nmstoker wrote: post #122

"If you take anything away from this post I hope it is that these costs need to be paid by someone, the maintainer." - there will be a minimal cost attending to any interaction but provided the efforts made by a reporter are sufficiently well focused then that reporter is saving time for the maintainers. The issue i observe is countless people do such a stunningly bad job at reporting problems. I've some sympathy for…

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 worthwhi…

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!)

Re: Don't be that open-source user, don't be me

#164

Post by nmstoker »

solatic wrote: post #137
softfalcon wrote: post #127

Earlier quoted context omitted.

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 worthwhi…

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

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

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.

Re: Don't be that open-source user, don't be me

#165

Post by rowanG077 »

welder wrote: post #5

As an open source maintainer[1], the etiquette tips are great. However, I think +1 and status check comments are ok in certain situations where the issue might have been forgotten or it's a high priority issue. I also like when someone reminds me they're blocked by an issue. It helps me prioritize fixing bugs so I work on things actually affecting people instead of things nobody is using. Just be polite and your comm…

This. It can be an important signal an issue that a maintainer might think is low priority in reality isn't. Don't forget that a maintainer doesn't really know how their software is used.

Re: Don't be that open-source user, don't be me

#166

Post by rowanG077 »

Aeolun wrote: post #51
welder wrote: post #5

As an open source maintainer[1], the etiquette tips are great. However, I think +1 and status check comments are ok in certain situations where the issue might have been forgotten or it's a high priority issue. I also like when someone reminds me they're blocked by an issue. It helps me prioritize fixing bugs so I work on things actually affecting people instead of things nobody is using. Just be polite and your comm…

> I also like when someone reminds me they're blocked by an issue. As a user, this feels weird to me. If I’m actually blocked by a bug you’ll receive a PR, not a +1. If I have the leisure to +1 I’m clearly not blocked enough for you to consider it pressing.

While in theory this would be great some issues are really not feasible for a first time contributor to work on.

Re: Don't be that open-source user, don't be me

#167

Post by pcthrowaway »

jacobtomlinson wrote: post #156
pcthrowaway wrote: post #39

Earlier quoted context omitted.

Perhaps I misunderstood the author, I assumed '+1' in this context meant the thumbs-up reaction. I'm certainly feeling much more charitable towards the OP if they literally meant people commenting "+1" (which is unfortunately a thing), but I think in a lot of contexts "+1", "thumbs-up", "like" are interchangable.

OP here. Thumbs up is great, commenting with the string “+1” is not great, commenting with “Why this this not done yet, this is very important to me. I might switch to another project if you don’t implement this.” is terrible.

Totally fair, and for what it's worth I agree. When I read the original post, I thought by '+1' you just meant the thumbs up reaction

Re: Don't be that open-source user, don't be me

#168

Post by eCa »

microtonal wrote: post #32
eCa wrote: post #9

> As time went on the wording of the +1s got stronger I think a +1 (as a thumbs up reaction, or similar) can’t be a bad thing. Comments that turn more passive/agressive (or just agressive) most certainly can. I don’t think the later should be mixed up with the former.

I think a +1 (as a thumbs up reaction, or similar) If you refer to +1 comments (which the second sentence seems to imply), these are a bad thing, since it sends a notification to everyone who is subscribed to an issue. If you are maintaining a popular open source project, useful comments (reproducers, potential solutions) get buried between all useless +1 comments.

Yes, should have been clearer. I meant reactions. Even as a reader of issues, all the +1 comments are annoying, can only imagine how it is for the maintainer.

Re: Don't be that open-source user, don't be me

#169

Post by samatman »

dessant wrote: post #146
samatman wrote: post #141

Earlier quoted context omitted.

No, I think it's fair to work backward: GitHub doesn't offer a way to disable PRs, the service is explicitly 'social coding', therefore those using it should not be disgruntled about PRs showing up. The healthy maintainer-side attitude is that these impose no obligation whatsoever to review, apply, or even look at, the fork in question.

GitHub is indeed a platform that can be used for social coding, and it is also a service that encourages the use of contribution guidelines. If the maintainer asks you to open an issue to discuss your contribution before submitting a pull request, you are expected to follow their wishes. https://docs.github.com/en/communities/setting-up-your-proje...

Which of course I do.

The emotional side of the burden of closing PRs which don't follow guidelines is the part which can be set aside. It's just a bit of housecleaning, it's seldom done from malice, English is not everyone's first language, etc.

Getting upset that a mechanism which exists and won't change gets used is not healthy.

Re: Don't be that open-source user, don't be me

#170

Post by WesolyKubeczek »

cube00 wrote: post #71

> I also occasionally returned to issues that hadn’t been resolved to [..] ask if there was an ETA on a fix. I felt I was being helpful. I irrationally get annoyed when someone asks for an ETA like this, I'm sure it's a genuine question but it just feels like a nag to "hurry the fork up already!"

Sometimes people would like just a ballpark. Is this going to be looked at this year? At all? Is it on roadmap? Should I wait a week or just carry on with my own patch, work around it, or go with an alternative solution? A ballpark response may at least add enough clarity for people to know how to proceed in the meantime. "I'll look into it real soon now" out of some unwarranted sense of duty and then a year of radio silence is not helpful.

"ETA" sure is a wrong term. (You're not my manager! Argh!!!) However, work enough in a corporate setting, and those words firmly suck into you and it takes a time to unlearn them. ETA, touch base, circle back to (or worse, faux military vocabulary in a company that has jack to do with military, my pet peeve). Unless they go out of their way to be pushy, you may as well not assume ill intent where there's only a professional deformation.

Post reply on HN