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

> If they said they are welcome, it means they are.

No. Talk is cheap, actions speak louder. It's incredibly easy to brush off users with that patch talk. Actually working with the people who do provide those patches? That takes some serious effort from the maintainer: evaluating and testing their contributions, providing constructive feedback, making sure they are credited, generally helping them help you so that they can accomplish their goals without compromising your goals.

When you straight up challenge someone to show you the code and they respond by doing just that, it reflects very poorly on maintainers if they can't even muster a reply.




> Actually working with the people who do provide those patches?

Patches welcome means "Send me a patch and I can run git am", not "let me teach you".


Really? Just a git command, a button press on GitHub? So why don't they just do it? Why don't they apply the patches when people send the code in then?

Turns out it's actually pretty difficult to get people to run that command. Once I reported a bug and sent the fix. Something like a month later the guy just rewrote the patch without even engaging with me. Yeah, that made me feel like shit. Another patch I sent was a simple feature. This time I made sure to ask if there was anything wrong with the code. Some refinements were suggested and I was even told I could expect it to get merged. It's still languishing there unmerged in the mailing list over a year later despite multiple follow ups.

Sorry but maintainers don't have the moral superiority to demand free labor if that's how they treat people when actual code is written and sent in. I'd rather have a Linus Torvalds type shit all over my code and me personally than be treated like that. I never expected them to teach me but I absolutely did expect them to merge the code I wrote if they didn't have any objections to it.

I've had many great experiences in open source that offset all that, one such maintainer even commented in this thread. The brain never forgets the negative experiences though. It's a survival mechanism that stops us from stepping on the same nail twice.


> Really? Just a git command, a button press on GitHub? So why don't they just do it? Why don't they apply the patches when people send the code in then?

Because the patch was bad.

> Something like a month later the guy just rewrote the patch without even engaging with me.

Do you think he'd have done that if the patch was good? Was his version completely identical to yours?

> Yeah, that made me feel like shit

At least it didn't introduce a new bug to every user… I'm sure collective feelings of the userbase were less harmed in this case.

> Sorry but maintainers don't have the moral superiority to demand free labor

But you have the moral superiority to demand free labour from maintainers, to review, improve, test your patch?

Look at this pull request for example: https://github.com/ltworf/localslackirc/pull/387

How could a thing like that be merged?

When asked to split it, he just proceeded to open tens of pull requests that were all based on the previous one, in a chain. And every commit contains thousands of lines of unrelated changes with what the description is.

Then he got upset.


> Because the patch was bad.

> Do you think he'd have done that if the patch was good?

Who knows? You posted an example where you explained your rationale for not merging. You told the guy exactly what was wrong, he just refused to listen. I didn't get the same courtesy.

Maybe he didn't want my name to show up in the commit log. Maybe he just hated my guts. Could be anything. I don't know why the other patch wasn't merged either. Maybe they discussed it on IRC or something and decided against it. Maybe they forgot about me. Who knows.

> But you have the moral superiority to demand free labour from maintainers, to review, improve, test your patch?

You're the maintainer. If there's a problem or deficiency, people generally just create issues in the tracker and leave it at that. You asked for the code. You actually got the code. Now we ask you to do your part which is reviewing the code on its merits and letting us know what you think of it. If it's accceptable, then merge it. If not, then let us know why so we can make it acceptable to you.

That's exactly what you did in your example PR so I'm not even sure why we're disagreeing here.

> How could a thing like that be merged?

I wouldn't have merged that either. Nothing wrong with your conduct. He did not address the issues blocking the merger. When maintainers give me feedback like that, I take it seriously and address the issues raised. I try very hard not to submit shoddy work to begin with.




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

Search: