I had a GitHub project that got a few hundred stars. The amount of mean, crazy, and entitled people is crazy. I have no idea how the bigger projects can deal with it.
So I closed the issues on those two projects that got most low-quality issues. People started to open PR to tell me I was wrong and I should open the issues. This cemented my decision, oh the entitlement of some people.
Some users are overly entitled, but some maintainers are self-absorbed douchebags. I've seen both sides.
Even if they close all issues with no comment, they have given you a such _massive_ head start vs having to write the entire project yourself from scratch. How can you be anything but grateful?
Also if it's a real issue that you won't fix you should at least leave the issue open so other people know.
IMO you can definitely be extremely grateful for someone's contribution and also think they are sort of rude, not incompatible views/feeling.
Where does that bad feeling come from? Does it come from the fact that you feel like you're owed a response? Do you get the same feeling when you email strangers and they don't respond?
> Also if it's a real issue that you won't fix you should at least leave the issue open so other people know.
> IMO you can definitely be extremely grateful for someone's contribution and also think they are sort of rude, not incompatible views/feeling.
You're not entitled to gratitude. Assuming that people should & will run their own projects according to your values around courtesy is a little self-centred.
If you need the bug fixing and the maintainer isn't doing it fast enough, just fork it. This is the point of open source.
It's just the time spent for me, I mean if for some reason I put like an hour of my time composing an email to a stranger and they didn't respond I would unhappy. It would be my fault but I would still be unhappy.
I agree that no one is entitled to have everyone act nice to them. I just think it's nice to tell someone why you're closing their issue.
> If you need the bug fixing and the maintainer isn't doing it fast enough, just fork it. This is the point of open source.
100%
There's something about putting time and effort into writhing a good bug report that forces you to truly try and understand what's happening.
I think you mistakenly switched the roles there. You are not isolating a bug for the author. The author is using their software and is happy with its current state. It is you that is being hit by a supposed bug, and you are isolating it for yourself. Then you are expecting the author to do the additional work for you and handle your supposed fixes. Don’t get me wrong, you’re probably both helping each other in the best spirit of open source, but it’s not you who’s the ideal of generosity there.
1. For you, since you are nice and helpful debugging it and fixing it for you and others so I want to make it easy for you to use the working code.
2. For other users that might hit the bug, for every PR bugfix there are likely N people hitting the bug.
3. For me in case I hit it in the future.
4. For correctness sake.
But not all bugs are straightforward, many have side-effects or disadvantages that I might not be comfortable merging straight away. So I have to evaluate how long it'll take me to review the PR and whether it's even worth-it (the vast majority of times PRs are worth-it, but issues are a hit and miss).
The problem was when people came like "I am using this library, can you debug my code?" and pasted a 500-liner, or like "this doesn't work on my XYZ system, fix it", or when they were just rude or demanding.
I've met some wonderful people BTW, and would also not trade that for anything.
Did those pull requests have code changes?
https://github.com/franciscop/picnic/pull/203/files
+If you spot a bug or any other issue you may go to hell because this software is officially Bug Free(TM). +
But also had some C libraries for Arm STM32 and only ever got solid pull requests and people eager to help. You see the same thing in IRC / Discord channels of those technologies.
which will be interesting to see if you ask them for payment for fixes, would they pay?
I think a lot of this has to do with the effort you put into community management. We put tons of energy into making it easy to make good contributions: PR/issue templates, we're on slack, we respond to emails, we make it as easy as possible to get your code in as long as it passes tests. It's a lot of effort and I can't imagine doing it for something that was just a personal project, but I think that's how the bigger projects deal with it.
This is besides my fulltime job, friends and hobbies. So I don't really have much time for growing a community, I've done some effort in the past when I had more time and it worked fairly well, but I found it to be very project-oriented in general so if you do many smaller projects (as opposed to few large ones) the community approach doesn't scale well.
I don't encounter many mean/crazy people! I can count them with one hand. I find few entitled people, but most people I've found are nice.
If it's a user-facing project, then people will approach the project's "github issues" as a company's support line, and feel a bit more entitled.
If it's a library or plugin for developers, people generally have more empathy and appreciation towards the maintainers.
I think maybe it has to do with:
1. Hype.
2. What percentage of developers were forced to use your tool/library against their will by their employers or forced upon them as a dependency of some other tool.
If a project is overhyped, then developers will be disappointed by reality and they will complain. The best you can do is try to set realistic expectations.
If a developer was forced to use your library by their employer (or it was forced upon them as a dependency of another tool/library that they're using and your dependency was throwing some weird error) then they will also complain. The best you can do about that is try to make your library work 'out of the box' as well as possible and make it work well in as many environments and operating systems as possible. Regulating hype by setting realistic expectations can also help prevent employers from forcing their developers to use a library. You should use more technical terminology instead of business buzz words when describing your project. You want to attract developers, not project managers.
Oh boy you'd have thought people had paid thousands of dollars for the code the way people talk to the maintainers.
The one thing that gives me pause is the prospect of having to manage a bunch of unfriendly feature requests and bug reports. Here's hoping we find ourselves in a virtuous niche.
It's about time that programmers recognize that a "Delete GitHub" movement is as valid and as needed as "Delete Facebook" or "Delete Twitter".
GitHub is not really about software development. GitHub is yet another social networking site, only it's for busywork masquerading as Real Important Programmer Stuff.