Everyone I've ever tried to send a PR to had been very responsive. The rauth guys (litl) are great. I added some AppEngine docs for Line Profiler and I think they got pulled the next day.
A plea for better open source etiquette
11–20 of 55 posts
Re: A plea for better open source etiquette
#12We don't want bug fixes with your whining
I just want bug fixes. He wants his work acknowledged. Seems pretty reasonable!
Re: A plea for better open source etiquette
#13The LibreOffice guys are particularly good about code reviews and accepting patches. In fact, they use gerrit (http://gerrit.libreoffice.org), and I'd have to say that one piece of infrastructure has increased contributor patches exponentially.
Re: A plea for better open source etiquette
#14I'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 submitted.
The thing is, you're actually implying more than you're saying. What you really mean is, "You could always have the courtesy to acknowledge the bug or PR I’ve submitted as soon as I submit it." You mention all the things you've done by the time you've submitted the ticket on Github, and I can appreciate all of that (I even wrote an entire article espousing your side [1]). The thing is, you did all that on your own time, on your own schedule. You're asking the maintainer of the open source project to help you finish solving your problem right when you submitted the ticket, i.e. on your schedule, with no acknowledgement for theirs.
To you, it might not seem like much to ask, for the maintainer to drop what they're doing to respond to your request. But some open source maintainers are very busy. They may get between 100 and 200 emails a day during the week. The Github notification from your submission is one of them. They may own a company, with employees to whom they are responsible. And they may manage many different projects, including several open-source projects. Even if it only takes 20 seconds to physically comment on your issue or pull request, it still requires a mental context switch, which they may not have time for that day, or even that week.
Furthermore, to be frank, it's often the sense of entitlement and lack of understanding that makes it unenjoyable to respond to requests. Granted, not all contributors feel entitled, but even having to deal with one entitled person is enough to destroy your motivation for the rest of the day. Imagine that you've spent years on some project, and fixed a hundred issues submitted by users, and helped many contributors get their pull requests merged. And now imagine the 101st ticket is someone who comes along and says, "All the time and hard work you've put into this project and provided for anyone to use free of charge is not enough; you're a disappointment because you don't respond fast enough." It's exhausting.
"If you don't have time to maintain the project, then mark the project as not actively maintained so we can move on," you say. But it doesn't quite work like that. It's not that the project isn't maintained. The maintainer may just be really busy this month. Or maybe they've been really busy for 6 months. They're still maintaining it, they just might not have time to look at things for a little while. Labeling the project as "unmaintained" would be short-changing all the people who are still actively using and developing and maintaining it.
"But my change is really small, just merge it in," you say. The problem is, you don't really have the context to make that claim with 100% certainty. You're not the one who has to deal with all the issue that may come rolling in due to some unintended and unforeseen consequence of your change. Also, if there are a hundreds or thousands or tens of thousands of people using the project without a problem, and you're the first person to report an issue, chances are your issue is not that urgent. That means, even for a simple patch, the maintainer has to weigh benefits of the patch with the potential that it breaks stuff for other users. The only "small patch" is one that changes a comment in the code. If you're changing an actual line of code, the maintainer rarely sees it as "small".
I don't type all this to make excuses. Like I said at the beginning, I understand the frustration. I'm not just a maintainer, I'm also a user of other open source projects, so I know. Uncertainty sucks. This is an area I'm trying to get better about myself as a maintainer. I even considered not submitting this comment, for fear of anyone misunderstanding or taking this the wrong way, and the inevitable "open source is a responsibility" responses. But I decided to submit it anyway, in case it helps anyone who truly wonders what the hell is going on, on the other side of that pull request.
[1] http://www.alfajango.com/blog/communicating-with-engineers-a...
Re: A plea for better open source etiquette
#15As 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 save you time. It would make my project better. And I don't write opensource software because I enjoy being a policeman. I hate it. I hate saying no to real work that solves real problems. Unfortunately, the majority of pull requests are simply bad.
- Many do not understand the project's conventions (eg, if my project is written in coffeescript, so your code needs to be in coffeescript too). Example: https://github.com/josephg/ShareJS/pull/36/files . After I insisted on the code being ported to coffeescript, several users whinged on the project's mailing list about my language choice.
- Most pull requests don't have tests. Submitters usually don't even run the unit tests before submitting, and their pull requests often break the tests we do have. I understand that you don't write tests in your application, but the rules are different in an infrastructure project that many people rely on.
- People often have extra modifications in their PR that have nothing to do with the patch. For example, this pull request has good parts near the top and also makes my code uglier riiiight down the bottom in the name of 'optimization'. Quotes because optimization was never run, and the changes didn't actually improve performance. https://github.com/josephg/Chipmunk-js/pull/15/files
- Some bug reports exist only to waste my time and complain about my programming language choices. This is what I was doing instead of triaging your bug. I'm sorry, ok? https://github.com/josephg/Chipmunk-js/issues/11
I usually err on the side of allowing changes and fixing stuff later, but my projects have suffered for this several times. I've had maintainers accept pull requests that break the unit tests (and leave them broken for weeks). I've had otherwise normal code suddenly sprout extra levels of indentation. I've had mountains of bugs appear, filed against a feature I didn't write, don't understand and I never use, who's author has disappeared. I've been burned enough that I can totally understand maintainers who ignore patches and bug reports.
I still love everyone who cares about my projects enough to submit a bug report or takes the time to make a pull request. I need contributors to make good software, but it breaks my heart when nice people submit slightly bad code, and I need to either whinge at you or stop working on my own pet feature to clean up your mess. I'm sorry to everyone who's patches gets ignored, but sometimes I get tired too.
In short, its fun to complain about The Man because your precious donation of code is being ignored. But its just as thankless running a project, only we shoulder way more responsibility and burn way more time doing it. If you want me to look at more of your bug reports, help triage my other pending bugs and pull requests. If you want me to stay excited about the project, email me to say how much you like it, and tell me about the cool things you're doing with my code. If you want commit access, ask for it. Finally, if you think you can do a better job running a project, use the fork button and do something about it.
Re: A plea for better open source etiquette
#16I'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 patch; don't know when I'll have time to look at it" is enough. I did, after all, go to the trouble to track down the bug and devise and test a fix.
I have gotten upset about a submitted patch going unmerged, also, but only after a couple of years had passed. I agree, pressing maintainers to merge one's patches promptly reflects a certain self-centeredness.
Re: A plea for better open source etiquette
#17I feel like a lot of these requests, especially in the "For a PR" section are things that only more seasoned developers have an appreciation for. Since OSS runs the gamut from bad-ass-mofos to beginners, I feel like you're going to get under a 50th percentile in most of these areas. I agree that things need work, but sometimes it's hard to get to everything, especially if you're doing it for free in spare time.
Some of it comes from the fact that a lot of "bad-ass-mofos" are beginners. I know it's really not fair to group together people (not everyone's the same after all), but a lot of the etiquette issues seem to stem from a common lack of manners by and large. Also of note: Times have changed. Once upon a time, most hackers tucked their shirts into their pants. Now some have stretched earlobes.
Stretched earlobes and common courtesy are not mutually exclusive in the slightest.
Re: A plea for better open source etiquette
#18I'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…
If the OP would consider becoming a maintainer of a project they contribute to, and then follow their own advice, they do have some warrant to their complaints, otherwise not so much, for the reasons you state.
I got a substantial pull request to an open source project of mine [1] that I don't have much time for, and followed the "Pull Request Hack" [2] and made the committer a maintainer. My GitHub notifications for that project now follows this pattern: "Random user: Hi, please merge my changes", "Maintainer: Thanks for your contribution, I made some changes and merge it in!". That's pretty fulfilling.
1: https://github.com/jacobrask/node-upnp-device 2: http://felixge.de/2013/03/11/the-pull-request-hack.html (although this was before I read the article)
Re: A plea for better open source etiquette
#19Earlier quoted context omitted.
Some of it comes from the fact that a lot of "bad-ass-mofos" are beginners. I know it's really not fair to group together people (not everyone's the same after all), but a lot of the etiquette issues seem to stem from a common lack of manners by and large. Also of note: Times have changed. Once upon a time, most hackers tucked their shirts into their pants. Now some have stretched earlobes.
Stretched earlobes and common courtesy are not mutually exclusive in the slightest.
It's a metaphor for the changing times, not common courtesy.
Re: A plea for better open source etiquette
#20As 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…
I definitely didn't want to imply that "you should merge any ol' crap".
I was commenting more on how maintainers communicate (or don't communicate) their feedback. I see no problem with saying "please add tests", or "don't break the existing tests". Some of that can be managed automatically with the likes of Travis, other stuff like "I only accept code that's coffeescript" can be mentioned in the CONTRIBUTING file, and your reply to the PR can just point to the rules. I don't have a problem with any of those cases; it's stony silence that gets me.