Live data from Hacker News

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

jacobtomlinson.dev

121–130 of 173 posts

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

#121
post #117
post #89

Earlier quoted context omitted.

> When they make a project public they’re explicitly condoning the fact they may get a PR I don't think that's true. It appears you just assume that because pull requests cannot be disabled on GitHub. Sending unsolicited pull requests to people that clearly told you to open an issue first is disrespectful. You don't have to engage with a project or a community, but if you decide to participate by submitting a pull re…

> Sending unsolicited pull requests to people that clearly told you to open an issue first is disrespectful. You do you. I do not think it is, and so far nobody has made an issue out of it. > It appears you just assume that because pull requests cannot be disabled on GitHub. It’s more that people that make a public repo on Github and expect no pull requests on even mildly popular software are living in fairyland. Don…

It's one thing to stumble upon a repository that does not have contribution guidelines and submit a pull request, that is obviously fine. But you're advocating against respecting the wishes of strangers, and disregard their request to coordinate with them before submitting your work.

You have the option to walk away and not contribute if you don't like the rules for interaction that have been set by the people that manage the project. Or just follow the rules. Those are your only two sane options, unless you become a maintainer yourself at that project, and modify the contribution guidelines.

To be very clear, you have to understand what NO means in this context, and realize that "I don't like bureaucracy" is not a valid reason to push forward on your own terms.

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

#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 those whose first language is not the same as the maintainers, but putting thosr aside, the list of inept/time wasti reports is very very long.

- subject only issue with only vague adherence to a complete sentence!

- no unambiguous description of the problem

- no indication why it's thought to be deviating from (reasonably) expected functionality

- no indication of steps before issue

- nor if it's a one off, repeated, always happened/just started/happens to others

-no mention of context (eg system, installation method, any reasons it might be expected not to work)

and more!

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

#123
I'm an open source developer (and user of course), and I don't like people acting entitled. However I don't mind people commenting on bugs that they're also have the bug, because it gives some indication about which bugs are affecting lots of people and which are rare. I also have a rule of thumb that for every user who comments on a bug, probably another 9 are affected.

Also please file bug reports that I have some hope of reproducing locally, or if not, include all the information you have, such as the full commands and errors, the versions of everything that might be relevant etc.

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

#124
post #116
post #85

Earlier quoted context omitted.

> From what I see, somebody submitted a bug fix that hadn’t been approved/merged by you for 6 months. From my perspective the PR was reviewed and was stuck on a test case being created. The author of the PR even stated "I'll try to make a simple test case." so as far as I'm concerned the ball was in their court. But you know, reviewing PRs takes time too. Acting entitled about a review taking a long time shouldn't be…

> But you know, reviewing PRs takes time too. I agree. I’m just saying you were rude too.

He was rude, but he didn't initiate it. Frankly, he openly communicated his priorities (other things are on the list) and then got snark. So he responded in kind. Very little to blame the maintainer here.

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

#126
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'm not so sure +1's or emojis are useful, except for maybe a few cases like you have a very large audience and they all send a thumbs-down emoji to protest a bad product or design decision -- recent c#/dotnet for example. Or the reminder ping from an affected user who is still interested in and using your project. The problem I believe is that a +1 or another reaction to an issue is simply a sample from all develope…

For me (participating in a small open source project) upvotes are useful - it is a confirmation that anyone else cares about that idea and that someone read what is being proposed and at least is not protesting.

Multiple times I have no preference between two issues and worked on one with more reactions.

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

#127

"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 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?

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

#128

Regarding adding +1 to issues - rather than doing this, up-vote the issue on GitHub (thumb up). This can be useful to maintainers because they can sort by thumb up and see the most popular ones. Adding a +1 comment really does nothing - it's just one more useless notifications for everyone, and it won't allow filtering or sorting issues. People might even unwatch the issue because of this and thus missing useful comm…

Then again, adding a comment may prevent a bot from auto-closing the issue.

Project with autoclose bots is not worth wasting any time by contributing to it, even by making an issue.

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

#129
If you don’t pay for something and that something is written by a volunteer and shared for free then sit down and shut up and wait for that volunteer to maybe get to your feature request. One can always propose a PR implementing that feature. Or wait.

Even more egregious is if you’re a company making money on this free software and yelling about a missing feature and not willing to sponsor its development then you’re even further behind in the line.

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

#130
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'm not so sure +1's or emojis are useful, except for maybe a few cases like you have a very large audience and they all send a thumbs-down emoji to protest a bad product or design decision -- recent c#/dotnet for example. Or the reminder ping from an affected user who is still interested in and using your project. The problem I believe is that a +1 or another reaction to an issue is simply a sample from all develope…

It's often not immediately obvious if a request is something a lot of people want but only one person took the time to write up, or if it's a very niche thing that only that person cares about. People who +1 an issue are not a great data set, but it's a lot better than nothing and it's basically zero effort to check. If I'm looking for something to work on and there's two issues that look like they'll take similar amounts of time, both seem like good ideas to implement, and I'm not sure which is more valuable, the number of +1s is a pretty decent tiebreaker.
Post reply on HN