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

41–50 of 55 posts

Re: A plea for better open source etiquette

#41

Post by bboyjkang »

More projects should look at and adopt the Web Hypertext Application Technology Working Group (WHATWG) HTML Living Standard page (http://www.whatwg.org/specs/web-apps/current-work/multipage/...).

You can see status annotations in the left margins that allow you to go to extended/extra information on each section. If you have comments/questions on a section, you can use the widget at the bottom right (it says "Click the location of the error to select it, then type your message here:") to submit a review comment.

Re: A plea for better open source etiquette

#42

Post by Evbn »

relix wrote: 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'…

It is github, you had a fork, so anyone who wanted your feature in those 2 years could use your fork. And of course you got your feature and could easily merge upstream work as needed.

So what's the problem, aside from somebody you don't know not appreciating you? That person still gave you a great help (the rest of the project), and github prevented the difference of opinion from slowing you down more than a smidge.

Re: A plea for better open source etiquette

#43

Post by Evbn »

zdw wrote: post #8
TimCinel wrote: 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.

I kind of wish that on Github, there was a default "untested" branch bit that defaulted to on. On the back end, this would aggregate all the commits applied from a head, and allow the maintainer and contributors to know beforehand if their stuff applied cleanly. Eventually, if the project is abandoned, this untested "uberpatch" would end up being the defacto main branch. There are probably very many horrible problems…

Sounds like a security disaster, for one. I could submit a rootkit to every project on github.

Re: A plea for better open source etiquette

#44

Post by Evbn »

pixelcort wrote: post #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

This standard practice at every sane organization and bug tracking tool. Which is not many of them, sadly.

Re: A plea for better open source etiquette

#45

Post by Evbn »

_pmf_ wrote: post #23

It's not the job of open source maintainer to acknowledge every nitpicky little turd (like the mentioned documentation typos) that some guy found.

Actually, that's what the job of a "maintainer" is. Now, no one has to be a maintainer if they don't want to.

Re: A plea for better open source etiquette

#46

Post by ScottBurson »

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…

> ... when you get 100-200 emails a day, every day (it doesn't stop), it's hard

Fair enough. In that kind of situation, the only hope may be to use an autoresponder with a canned message. (This would at least assure senders their messages were received.) And try to recruit some co-maintainers :-)

Re: A plea for better open source etiquette

#47

Post by qwerta »

There is only one answer to this:

I would be very happy to review and merge your pull request. I charge by day and my daily fee is 600 euro. Bank details are bellow, once payment is cleared we may proceed :-)

Now seriously: Every minute I spend on my OS project I have to cut from my sleep or from time with my family. I would love to review patches, have a chat and perhaps get a free beer, but it is simply not possible.

For project maintainers there is simple way to avoid this overload. You need to 'manage your community growth'. If it grows too fast you will be flooded with bug reports, pull requests and emails.

For my project I have not provided build system and binary builds for a long time. Users were forced to use IDE and study the code. Also I did not provided any documentation, just a code examples. Key is to attract people with coding skills, who can actually grog code.

Also be careful how you advertise your project. You should actually target co-developers (with commit access) instead of users. For example if your project is written in Coffeecript, you should avoid using word 'javascript' on front page and in readme.

Sure it hurts number of users in short term. On long run it increased number of power users who do bug triage and answer support questions. The key is to grow number of co-developers together with number of users.

Re: A plea for better open source etiquette

#48

Post by relix »

Evbn wrote: post #42
relix wrote: 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'…

It is github, you had a fork, so anyone who wanted your feature in those 2 years could use your fork. And of course you got your feature and could easily merge upstream work as needed. So what's the problem, aside from somebody you don't know not appreciating you? That person still gave you a great help (the rest of the project), and github prevented the difference of opinion from slowing you down more than a smidge.

That's very true. I appreciate your comment because it shows the situation in another light completely. You're quite right, and logically this is also what I should think, however it just, I don't know, feels bad. Irrationally, it feels shitty. We're still humans and I guess that influences us a lot.

Re: A plea for better open source etiquette

#49

Post by voltagex_ »

ScottBurson wrote: post #46
JangoSteve wrote: post #25

Earlier quoted context omitted.

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

> ... when you get 100-200 emails a day, every day (it doesn't stop), it's hard Fair enough. In that kind of situation, the only hope may be to use an autoresponder with a canned message. (This would at least assure senders their messages were received.) And try to recruit some co-maintainers :-)

Yep, ran into the programmer's-autoresponder for the first time from the dev of the AlarmDroid app for Android. It's pretty effective.

Re: A plea for better open source etiquette

#50

Post by ricardobeat »

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…

> Or maybe they've been really busy for 6 months. They're still maintaining it

If the project has pending issues and patches for six months, it is not being maintained.

If it is something that has a large user base, I think the owner has some degree of responsibility over the community. Either add other people to project or mark it as unmaintained, allowing a fork to take over. All too often you'll find a zombie project where the author abandons it for months, yet doesn't want to let it go; if he is a well known dev people will still flock to his project because he says it's "still maintained, I'm just busy", making it harder for a substitute fork to take over. Everyone loses.

Post reply on HN