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 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.
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.
> ...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 small or trivial, is at direct odds with the time they spend working at their day job, or spending time with their family, or relaxing. That's not to say open source maintainers don't enjoy building and maintaining open source projects. Most do (including me). It's just the recognition that maintaining open source projects comes at the expense of other things which they also enjoy.
In the same way that I believe you're justified in thinking a maintainer's non-response is rude, I believe a maintainer would be justified in thinking your expectation of them is also rude.
> ... 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 :-)
>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.
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.
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.
> 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.
> 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.
I'm glad that you did, thank you for taking the time to respond.
> 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."
While I've definitely been guilty of impatience in the past, now I try to measure the response against some kind of "OSS time", which is a lot more forgiving. I appreciate that people are likely to be busy, or away with their kids in Hawaii for the past two weeks.
Having said that...
> The maintainer may just be really busy this month. Or maybe they've been really busy for 6 months.
I think one month is a bit long to have to wait for a response. 6 months: most certainly too long. In those cases, the "pull request hack" [1] may be the way forward.
> 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 can see how a month would seem like a long time, it used to seem like a long time for me too. But for someone running a company, someone with a crazy family life, someone maintaining several projects, someone getting married or divorced or having kids, someone buying a house or selling a house or moving, someone in school, someone having financial troubles, etc., etc.; a month can be a blink of an eye. You, of course, are welcome to your opinion. I try to avoid holding people for whom I know nothing about to my own arbitrary standards, and try to withhold indignation if they don't live up to them. I admit it takes effort; I often find myself doing exactly that. I just have to remind myself that I can't really know them to the extent that I know myself, and thus it's not always fair to expect that their situation lends itself to meeting my standards.
EDIT: All that being said, I think the pull request hack could be a potential solution. It does however bring its own potential problems. You're basically putting your reputation in someone else's hands, whom you don't know. Of course that may be preferable to what you're doing to your reputation by taking a long time to respond to requests. I'm certainly considering it for a couple projects.
> 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's nice, 'sall :)
I agree. I certainly don't feel like we're arguing, just adding more pieces to both sides of the puzzle.
I guess what I'm saying is, if the neighbor doesn't say "hi" back, it might be for reasons you haven't considered, and it might not be as simple as asking them to just say "hi" back.
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.
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...
> 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...