Hacker News Reader

Comment by josephg | Hacker News Reader

When I get pull requests or issues opened on my projects I often click on the person making the request. You can usually tell a lot about someone from their GitHub history - is it a new account? Do they have student projects there? What flavour of projects are pinned? Research? Database stuff? Niche hobby projects?

If someone has an old GitHub account but very little activity, I assume they work at a leech company which uses opensource but doesn’t contribute back. I’m less likely to care about the needs of users like that. That said, professional software engineers will usually be more responsive in issue threads when they run into bugs. I’m much more likely to fix a bug if you can give me a good repro!

View on HN

> ...I’m less likely to care about the needs of users like that...

I kindly suggest you not lump in users/employees with the behaviors of their employers. Any company that i might work for might indeed be "leeches" as you noted, but that does not mean the user/associate/employee is one also. It might also be the case that said employee actually only works for such an employer as a necessity...you know for earning a living, but not really share the morals/ethics of the employer. Some employers require proprietary controls on their source code, hence preventing employees from using publicly availablr repos on github. Now, if i were to get "graded" on my low activity on github for personal projects, then i get your point...but to automatically lump in both employee and employer into one actor's ethics, seems not right.

If you use opensource code but don’t contribute back, you not an equal member of the opensource community.

You’re getting financial benefit from my donated effort. I don’t mind - I wouldn’t opensource my work if this bothered me enough. But GitHub issues opened by leeches have a certain entitled tang to them - “Hey could you donate more of your time so I can make more profit? I won’t pay you. Maybe you should be thanking me for finding problems in your work and pointing them out to you. Get to it!”

The reason you don’t contribute doesn’t matter. You’re profiting from my volunteer work and asking me to volunteer more so you can profit more.

Justify leeching to yourself how you like. But you won’t get respect from me until you contribute back.

And, yes, if you work at an immoral company, that is also absolutely on your hands.

Do you only object to the entitled tone of certain feature requests people have written, or do you see all issues created on your project without a corresponding code change as entitled? If it’s the latter, you can disable Issues on your project, leaving only Pull Requests as an option.

If you disable Issues, I suggest also briefly explaining why you did that in the README to ensure you don’t get do-nothing Pull Requests asking how you’d like bug reports submitted.

The opposite - I prefer it when an issue is opened before the PR is written. That way I have a chance to respond / give feedback on the approach.

I can respond with things like: "Oh, that problem? Yeah there's already code to work around it - here's what you need to do." Or: "You want that feature? I can see why thats valuable to you. I'm sorry but I'm never going to accept a PR from a stranger adding that. I don't need that feature for my workflow, and its complex, so the payoff isn't there for me to maintain the code. Fork my code, or implement that feature in an external library."

I'd much rather turn down a feature request in an issue tracker than turn down work in a PR, after someone has done all the work already for something I'm not going to merge. That feels bad for everyone.

If you write a good issue and take part in the discussion, that signals that you aren't taking my work for granted. Work with me to make a good repro case, and I'll work with you to fix the bug you're running in to.

Reply on news.ycombinator.com