Live data from Hacker News

A plea for better open source etiquette

quickpeople.wordpress.com

31–40 of 55 posts

Re: A plea for better open source etiquette

#31
post #7

Gulp. I'm guilty of this. An iOS component I shared became quite popular. Now I don't even do iOS development anymore, Xcode is out of date, I haven't even used ARC. Whenever people poke me, saying that the issues and PRs are piling up, I tell them my situation and ask what they suggest I do. Surprisingly, my responses get no response. Perhaps I should just add some of the past contributors to the commit access list.

Have you considered making it clear that it's not maintained anymore? Add [not maintained] to the repo description or something.

Re: A plea for better open source etiquette

#32

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

#34
post #26

Earlier quoted context omitted.

> I think one month is a bit long to have to wait for a response. You're certainly entitled to that opinion, but the amount of time that is "acceptable" is completely subjective and relative. Holding someone else to your own arbitrary standards of acceptability is exactly what I'm referring to when I say these sort of complaints usually ignore the possibility that someone else's life is different than one's own. I ca…

> Holding someone else to your own arbitrary standards of acceptability is exactly what I'm referring to when I say these sort of complaints usually ignore the possibility that someone else's life is different than one's own. I agree with the spirit with what you're saying, this is indeed all opinion. I see it like this; if you're walking along and say "hi" to your neighbour, he doesn't have to say "hi" back, but it'…

Context and scale are extremely relevant here. I can say "hi" to every stranger I pass while hiking on a remote forest trail. However, I cannot say "hi" to everyone I pass walking down the street in Manhattan. Snubbing the passerby in the forest would feel rude. Ignoring the passerby in the city is normal.

Re: A plea for better open source etiquette

#36

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 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…

>responding to new threads on the mailing list -- not just to existing threads

Not all threads are the same, some are very easy to respond, and some require a lot of thinking.

The hardest pull requests are those which are useful in some way, but not really ready to be merged, and maintainer needs to do quite a lot of work to either explain what is wrong with pr or to rework it.

saying "Thanks for the patch; don't know when I'll have time to look at it" as a default response and leaving it for a month isn't very useful, and if it is a "default response", one can assume he got it just by sending pr and not getting other response.

Re: A plea for better open source etiquette

#37

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...

Re: A plea for better open source etiquette

#38
post #29

I once submitted a pull request to add a feature to a popular OSS library. It got several "thumbs up", was actually useful, didn't change the API and had test coverage. I put a lot of time into making it nice and clean, in my opinion a perfect pull request. Two years later they closed it with a comment saying one of the more senior contributors added code that did what my code did (except 2 years later) so mine wasn'…

Given that situation, I try and find the time to teach the original poster how to rewrite it the way I think it would be better implemented - with the understanding that if they don't want to, it's my responsibility to do so.

Then again, if I can't sell them successfully on why my way would be better ... maybe I should just have accepted their code.

This takes more time over the short term but in the long term lets me give out more commit bits, which I regard as a net win.

Re: A plea for better open source etiquette

#39
One of the easiest etiquette techniques projects can adopt is to only have the person who opened a ticket close it, in both cases where a fix was applied or it was decided not to fix.

This lets the originator of the ticket verify that the issue has been resolved or that there is no issue in the first place.

Edit: clarification

Re: A plea for better open source etiquette

#40

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 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…

I see people in this discussion getting wrapped up about manners and expectations. What I'd like to contribute is this:

I think in a position that attracts a pile of daily email, you need to be able to triage what you read, saving some ( hopefully few mails ) for later detailed reply, ignoring junk and hammering out a pile of short acknowledgements as you go. It doesn't take much more time to hit reply with "Thanks, go it, will process as time allows" or similar. If you don't do this, you're treating it as junk mail in my opinion and robbing the sender of any acknowledgement. If you've _got_ to ignore valid mails in this fashion, it points to some other workload related issue.

Post reply on HN