Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A plea for better open source etiquette

quickpeople.wordpress.com

Post reply on HN
Print view View original

51–55 of 55 posts

Re: A plea for better open source etiquette

#51

Post by [deleted] »

JangoSteve wrote: post #25
ScottBurson wrote: post #16

Earlier quoted context omitted.

I once got really pissed off when I submitted a patch to a project and got no response at all. I waited several days, but when I saw that the maintainers were responding to new threads on the mailing list -- not just to existing threads -- I got upset and wrote something intemperate. I'm not proud of that, and have no intention of doing it again, but I did and do think it's rude not to reply at all. "Thanks for the p…

> ...but I did and do think it's rude not to reply at all. "Thanks for the patch; don't know when I'll have time to look at it" is enough. You're probably right. All I can say is, when you get 100-200 emails a day, every day (it doesn't stop), it's hard. That's not an excuse nor a justification. it's just a statement, an explanation at best. Also understand that your expectation of a maintainer's response, however sm…

[deleted]

Re: A plea for better open source etiquette

#52

Post by ricardobeat »

Evbn wrote: post #37
JangoSteve wrote: post #14

I'm an open-source maintainer who doesn't always answer issues and pull-requests right away. It sucks, I'm trying to get better. I can understand the frustration, but these sort of posts (or pleas or whatever you want to call them) always lack any sort of acknowledgement of the possibility that some maintainer's life may be different than yours. > You could always have the courtesy to acknowledge the bug or PR I’ve s…

I thought the whole point of Git/hub is that branching and merging is so easy/powerful that you never get blocked waiting on uptream to integrate your fix. You just fork (on click), fix, PR, and merge later. Kids these days...

And then maintain your own fork for the rest of your application's lifecycle. Not the brightest idea.

Re: A plea for better open source etiquette

#53

Post by ricardobeat »

josephg wrote: post #15

As a maintainer of a project with almost 2000 stars on github, I sway back and forth between being allowing ("Just submit code to get what you want done. We can fix it once its in the repository") and a stickler for details ("I don't want your change until you give me tests.") I really wish I could just give everyone who submits patches commit access and let them at the repository. It would save me time. It would sav…

Definitely be a stickler for details, I'm infinitely happier seeing a PR unmerged and closed with a solid short explanation, even if it's "does not fit my style", than waiting indefinitely for a reply.

RE those pull requests: some people like hating on coffeescript. Chipmunk-js/15 is just a terrible patch...

Re: A plea for better open source etiquette

#54

Post by voltagex_ »

josephg wrote: post #15

As a maintainer of a project with almost 2000 stars on github, I sway back and forth between being allowing ("Just submit code to get what you want done. We can fix it once its in the repository") and a stickler for details ("I don't want your change until you give me tests.") I really wish I could just give everyone who submits patches commit access and let them at the repository. It would save me time. It would sav…

...What should I do if I want to fix an apostrophe in your readme? GitHub is making it difficult for me to do a #L link to your file but:

- It is slower than the C version (duh, its in javascript). Specifically, physics simulations using chipmunk-js runs about 3 times slower than the C equivalent.

should be

- It is slower than the C version (duh, it's in javascript). Specifically, physics simulations using chipmunk-js runs about 3 times slower than the C equivalent.

Post reply on HN