Hacker News new | past | comments | ask | show | jobs | submit login

The key thing is that your frustration doesn’t entitle you to anything.

The best thing to do is to contact the maintainer first before you do the work. Saves a lot of frustration. But I feel that people don’t want to hear no and need an excuse to do the work anyway because they like doing it.

The ‘no’ that eventually is / will be communicated shattered the illusion that they are helpful/contributing.

For me the whole “no” topic is all about setting personal boundaries. Maintainers have to deal with the same drama as mostly women face when dealing with unwanted attention.

But to me it’s 100% this ingrain sense of mostly men feeling so entitled to basically anything is so toxic.

“No” is a perfect antidote to that toxicity.




> The key thing is that your frustration doesn’t entitle you to anything.

Well see, I never said that.

However, I do think maintainers, issue reporters, and contributors equally deserve clear and respectful communication and that, further, the burden rests on the maintainers to clearly communicate initial expectations.

> The best thing to do is to contact the maintainer first before you do the work

That's rarely possible without filing an issue, which will apparently be immediately closed anyway, and I think the better solution is for the README to merely state the expectations.

GitHub provides the ability to disable issues altogether. Just do that if all you want to do is release a personal project as open source only.


There is a middle ground where sometimes the maintainer does accept a PR and sometimes they don't for whatever reasons they have.

Maybe it's all clearer to you, but this isn't about you and what you want or need. This is what about maintainers need to keep their sanity and not abandon the project(s) all together.

Be happy with what you get, accept rejection / disagreement, especially if nobody asked for anything. And most of all, just accept the ambiguity. Learn to live with it.

I maintain that just contacting developers first before making a change/feature + PR is the best way possible to at least have some chance that the PR will be merged.


> However, I do think maintainers, issue reporters, and contributors equally deserve clear and respectful communication and that, further, the burden rests on the maintainers to clearly communicate initial expectations.

Why? No they don't deserve anything. Unsolicited communication is unsolicited.

>GitHub provides the ability to disable issues altogether. Just do that if all you want to do is release a personal project as open source only.

Why should anyone bother. It doesn't mean anything


I was going to argue your comment, but you don’t deserve it.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: