Hacker News Reader

Comment by chimprich | Hacker News Reader

If you want to go with that analogy, it's more like opening a community cafe and hanging a sign on the wall saying "please bring a dish for our free communal meal - we'd be happy to add it (when we get around to it, if we like it, and if the cafe is still open - good luck, because you probably won't know if it has closed!)

I have a fairly popular free/open source project and I both agree and disagree with the author. Mostly users are polite and non-entitled, but it's exhausting answering all the (very polite) questions and requests for help.

I've had to turn down dishes that wouldn't have worked for the cafe, and it makes me feel bad. I've requested users contact me before writing a PR but of course people don't read the FAQ.

View on HN

> I've had to turn down dishes that wouldn't have worked for the cafe, and it makes me feel bad. I've requested users contact me before writing a PR but of course people don't read the FAQ.

As someone who has submitted PRs without much communication to repos asking to talk before PR are submitted: in my case these were generally cases where it just seemed easier for me as a user to just change the code rather than to contact the author, try to make some sort of social interaction online, explain why and what I'm trying to do, potentially enter some sort of negotiation trying to hammer out some agreement and then doing the code change PR dance anyway. Much easier to just make some straightforward code changes - done and dusted in a few hours.

And sure, I completely understand if a maintainer then says "no thank you". That's the risk I took by my just do it attitude. No hard feelings on my side.

I do that, too! Sometimes it makes most sense: for instance if I found and fixed a bug, I don't need to open an issue to ask permission for the PR; I just send the PR.

Also many times, I find it easier to express my idea with code (by making a PR with the change) than with text.

I only open an issue first if the code contribution will take a considerable amount of time and I want to make sure that the maintainer is fine with it before I start. Or if I need help from the maintainer, of course.

> it's more like opening a community cafe and hanging a sign on the wall saying "please bring a dish for our free communal meal - we'd be happy to add it (when we get around to it, if we like it, and if the cafe is still open - good luck, because you probably won't know if it has closed!)

that may be a better analogy for you, but i reckon the best-fit analogy is up to each individual, depending on where they want to set their boundaries.

some may prefer the analogy of being an author of a book: the author researches and writes a 10 chapter book, then copy-edits and publish the finished work, perhaps releasing it into the public domain. not obvious that the author would be willing to copy-edit and release a 2nd edition of the book incorporating an 11th chapter written by someone else.

with the last project that i had some fixes for, i forked the project, fixed the issues so they would work for me, and then opened issue reports on the upstream repo, sharing the problem, and how i fixed it with links to the commits, in order to open a discussion to find out if that is the right fix for the problem i found. i didn't want to submit a PR as long as i wasn't confident that this was an appropriate fix.

on the other hand, in that project, just submitting a PR might have gotten me more feedback (i didn't receive any responses to my issues)

the main point though is that i fix problems for my own needs, so why should i ask you before doing so? but then i also do not have any expectations that my fix is accepted. if it isn't, then i'll just keep running my own fork.

Reply on news.ycombinator.com