Why I am tired of writing pull requests

by gistacoder • 14 years ago

110 61 14 years ago

richo• 14 years ago

Link to your GH profile?

I've written dozens of pull requests and most of them either get merged, or I get a concise explaination about why they're not being merged.

probably 3/5 I have to go through a few iterations of hack and rebase before they go upstream. I'm fine with this.

With some more background maybe we can offer feedback about why your code isn't making it upstream?

Rayne• 14 years ago

I will pass absolutely no judgement on you because I have no idea who you are, what you do, what the quality of your code/work is, but have you considered that maybe there is actually something wrong with the pull requests?

With no references to examples if what you're talking about, it comes off as a bit of a temper tantrum. But that's just what it feels like, but I have no idea because I have nothing to look at to form an opinion.

aeturnum• 14 years ago

Even if he's misguided, he's trying to contribute. His description of someone finding a problem with his code could be written by someone who is a poor coder and doesn't understand why. However, it also doesn't sound like the people who rejected his pulls were very convincing at explaining why.

I think the point of the article is that the pull requests he's made came to nothing other than rejection. Nothing about the experience led him to believe he should make pull requests in the future. Even if he's a poor coder, I think that's a poor result and is worth talking about.

ethermal• 14 years ago

Well said.

austinbv2• 14 years ago

I have had similar things happen to me.

https://github.com/joyent/node/pull/3710

I sit and argue my pull like crazy but it is just getting derailed :/ oh well.

adamrt• 14 years ago

Unless I'm confused, aren't you also the author of that gist?

https://gist.github.com/3444052 your names on that one.

austinbv2• 14 years ago

nope just edited a typo

kisielk• 14 years ago

The original gist is on the bottom of the revision stack on the right, it was by an anonymous user.

josegonzalez2• 14 years ago

That's really too bad. For the record, I've written a couple hundred pull requests - no really! - and those that haven't been accepted have been because

  - The project is no longer maintained (I fork or rewrite better in this case)
  - I was actually doing it wrong
  - My pull didn't have tests and that was the convention (gotta respect conventions)
  - The author wished to keep my feature out for some random reason, but either gave me a hook or showed me how to override behavior in a clean way.

When the developer refuses to pull for not one of these reasons, it's usually because they don't have time. Which is fine, I totally understand that. I do that myself - I currently have 17 open PRs that I've sent and 20 from others in projects I maintain - so that's expected.

I would also say that when a PR isn't merged because the developer wants to write it himself, it's probably a stylistic issue and your implementation doesn't fit in with his vision for the project. You can't just pull in every request that comes by, otherwise the code becomes a complete shit-show and then debugging, maintaining, and extending it is a nightmare. I can personally attest to this, having committed this faux pas myself.

mirsadm• 14 years ago

I always figured the unwritten rule for every developer is to always follow the existing code's style regardless of their own opinion of it.

josegonzalez2• 14 years ago

That's not always the case, and sometimes if you don't know the language very well - in my case, Ruby - then certain patterns aren't available to you and it looks hokey without you realizing it.

xrt• 14 years ago

Meta: This is a problem w/ HNs layout, but using a fixed pitch line of 144 chars makes the entire page wide enough to require horizontal scrolling. Correction: for Chrome, just the comment, for IE9 the entire page. Is there a bullet list markup?

Cyranix• 14 years ago

HN formatting is limited to the following: http://news.ycombinator.com/formatdoc

Because the monospaced format is intended for code, it assumes that lines will be short, so lines longer than ~85 chars get the overflow effect.

dumbluck• 14 years ago

Agreed. I have a few projects now I've not had time to integrate patches for and they've waited months. I know they are using the patches so they aren't waiting on me, and no one else has complained so it isn't on my priority list. either. In the meantime, I'm submitting pull requests to github projects that I am getting paid at work to work on, some accepted, some denied.

cliftonk• 14 years ago

Some projects are more receptive to pulls from authors outside the core team than others. Namely, large projects in use by thousands of people.

Most library authors truly appreciate these kinds of pull requests.

Bitching about pull requests in such a generalized way is destructive behavior and having it up-voted here surely isn't good for many of the impressionable people that read news here.

simanyay• 14 years ago

The first thing you should always do is create a ticket. There you can discuss if its worth spending time on a patch and what the best implementation could be. Pull requests that come up out of nowhere usually end up in the end of maintainers' queue.

Or you can continue calling people who maintain free and open source projects in their spare time douchebags and neckbeards.

sciurus• 14 years ago

I cam here to say this. If something is going to take you more than 15 minutes to do, it's better to coordinate it with the project maintainers first. If it takes you less than 15 minutes, you didn't invest enough to be bitter if your code isn't accepted.

zr52002• 14 years ago

Or you can do that, proposing a trivial enhancement, and have

1) The maintainer tell you "that isn't the designed behavior" (no kidding it doesn't do that now, that's why I want to enhance it!)

2) It marked it as a duplicate of the last handful of people that wanted similar features

3) The ticket closed

I'm looking at you, jquery-ui

karlshea• 14 years ago

Or you can be like OpenLayers and just ignore a ticket with almost a dozen comments and two working patches and a pull request!

Sometimes people just don't want your code.

desfrenes• 14 years ago

Or you can be like Zend Framework and just ignore a ticket with a working patch and then months later have someone else to win a tee-shirt because that someone who has write access to the repository just participate to a bug hunt. Sometimes people want your code. They just don't want you.

j-kidd• 14 years ago

Personally, I think ticket description is more important than code, so I always create a ticket first. Unfortunately, github's issue tracker doesn't allow attachment, and thus it inadvertently promotes this "pull requests from out of nowhere" behavior.

Call me old fashioned, but I still like ticket + attached patches way more than anything else. Recently, I stumbled upon a Google Code project with several defect issues. One guy commented on each of the issue with a link to his github fork which he has applied the fixes. I clicked the link, and found that the fork has been deleted. What a waste.

arantius• 14 years ago

> github's issue tracker doesn't allow attachment, and thus it inadvertently promotes this "pull requests from out of nowhere" behavior.

"Refs #XXX" in the description (PR or any commit) ?

mnutt• 14 years ago

I've found that if it's a pull request of any significance, if you want it merged it's good to hop on IRC and talk to one of the maintainers and get their take on it. That can head off a lot of issues and save a lot of your time. Then if you still need the change, you know up front that you'll be maintaining your own fork.

apeace• 14 years ago

I can't say I've had a similar experience on Github, or heard anything of that sort from the many developers I know who write pull requests (or even just submit issues) on Github.

I think there should be an expectation that getting a pull accepted on a huge repo like Node or Rails should be a bit hard. When code is being used by thousands of people and companies, it's important that a lot of thought and care is put into even the smallest changes.

And finally, there is an easy way to end the negativity: respond to it by doing what they say. If they want you to do it in a different way, make a separate pull request and leave it up to the maintainers to choose the best one. Best never to argue on Github. If there's a disagreement, answer it with code.

I understand where the OP is coming from. This certainly does happen from time to time, and it's awful when it does. But I think this post is overblowing it. I certainly hope he does try sending pull requests again!

jmathes• 14 years ago

I'm with you. I added parallel test execution to PHPUnit, which its maintainers have been promising since 2005. When I started writing it, they found me and encouraged me along. So I spent two weeks on it at 16 hours a day. When I was done, they invented reasons not to merge. When I was done fixing the reasons they had invented, they said they didn't want to merge it because they were going to write it themselves.

graue• 14 years ago

Sounds like a pretty bad case of NIH. Maybe you should fork? (Although, I haven't heard the other side of this, so that's assuming the project's code standards were followed, your code was good quality, etc.)

ericclemmons• 14 years ago

Please link your fork! Heck, maybe Travis-CI will let PHP projects take advantage of it.

FuzzyDunlop• 14 years ago

I find it a shame that people do that and fuck around with contributors to their project. The time comes when they need contributors to submit patches, and fewer people will bother.

mmcnickle• 14 years ago

PHPUnit has a very definite style to its code, perhaps the changes didn't follow the style closely enough.

Do you still have a fork? I'd love some parallel test execution.

saurik• 14 years ago

From the Google Guava team, regarding the difficulty on the other end of people accepting random pull requests:

https://plus.google.com/113026104107031516488/posts/ZRdtjTL1...

http://news.ycombinator.com/item?id=3691587

cbsmith• 14 years ago

Yes. I ironically I've seen this contributor's sentiment shared internally in Google too (about many projects).

The real scaling challenge is in managing precisely this problem. It's not easy to solve.

hnruss• 14 years ago

This is highly subjective. Every project and maintainer is different.

Personally, I try to be 100% positive whenever I interact with anyone who has put their time and energy into improving a project that I maintain because I am 100% grateful for their effort. If I think that their code could be better in some way, I make that suggestion to them in a positive way. If they don't want to take my advice, then I'll merge their request and make the improvements myself. Heck, even if their code breaks something I'll still merge it in-- then fix it myself while retaining the intention of their code.

Being negative towards contributors is counter-productive.

k33n• 14 years ago

So anyone who won't accept your pull request or doesn't think it has merit is a neckbeard living in a basement?

Yeah, this isn't totally emotion-driven or biased at all.

mikescar• 14 years ago

I'm newish to github and submitting pull requests but the OP's experience is very unfortunate and orthogonal to mine. People I don't know and who are better devs than I am have all been very nice.

I started using a small PHP framework plugin written by a guy who did everything right. I want to contribute eventually, so I asked him what his license choice will be and some questions that would hopefully keep our code in sync.

He was really polite and helpful, and wants to do an MIT-style license.

I forked his github project just to keep my pull requests and work stuff outside of that cleaner.

Not really sure what solution the OP is looking for. If your pull requests are universally rejected, perhaps you could change your approach.

Github is only the best software sharing platform anyone has devised thus far in our young discipline. You can't even message people privately, you can open a new Issue though.

zquestz• 14 years ago

I have to say I haven't had this issue. Generally I accept quality pull requests to my projects within days. Pull requests I have sent to other projects have been merged in within a couple weeks at worst...

Perhaps in the future it would be worth discussing your changes with the developer ahead of time to see if that feature is something he wants in his core product. That could save you some time and effort in the future.

spullara• 14 years ago

I usually give constructive feedback on pull requests I can't accept and then they either drop the request or fix it. Seems to be a pretty common pattern for projects in active development.

danso• 14 years ago

I haven't done enough pull requests to comment on the author's experiences...but one of my only was a trivial change...almost one of personal taste...to Twitter Bootstrap and I was disproportionately excited when it got acceptd. I'm assuming there's a disproportionate letdown for the inverse situation

snogglethorpe• 14 years ago

He describes a social problem which is very dependent on the actual maintainers, but blames it on the mechanism.

Yeah, some projects have prickly/uncooperative maintainers... so what? That's true regardless of the collaboration mechanism used, and there's no obvious reason why pull requests make this problem worse than other mechanisms.

Indeed, I would guess that pull requests make things better than many other methods, because they (1) make it much easier to review changes, (2) make it much easier for the submitter to update his changes in response to comments, (3) handily keep the discussion and patches all together in one easily accessible place, and (4) maintain a record of the request, helping to avoid the "forgot about it" problem that you get with e.g. patch requests on mailing lists ("Subject: ping" :).

Frankly, given the attitude in his rant, it seems pretty likely the problems he apparently has with maintainers aren't entirely the maintainers' fault...

harryf• 14 years ago

I didn't read that in his post. He seemed mostly to be troubled by how easily the process can be derailed by going off topic on getting lost in details.

dasil003• 14 years ago

It doesn't seem like he's ever committed to open source before because none of this is new. So maybe Github is the problem in that it lowered the bar for this guy to put in just enough effort to get his feelings hurt.

Kliment• 14 years ago

A project I maintain has an experimental branch that takes most pull requests unless they have obvious issues (which I ask the author to fix). Only things I have not accepted so far were major GUI changes that I considered confusing. (I did accept one change that basically redid the entire GUI because it was awesome). The merges back to the master branch are several months apart, but I think it's a good idea to do deep quality control on the code AFTER it's merged to keep contributors engaged.

misnome• 14 years ago

On the other hand, I've actually taken projects with unmerged pull requests, and pulled them into my own repo to use the new functionality/bug fixes. So they aren't necessarily just sitting there uselessly.

EvilTerran• 14 years ago

It might be worth commenting to that effect on the pull request. It'd at least provide a morale boost to the author of the request; and showing that someone out there is already using the changes might even make the maintainer more likely to accept them.

ionforce• 14 years ago

Sounds like a case of entitlement. Why would you waste your time working on something and not know if it is wanted or not?

It's your fault for not planning ahead.

jamesaguilar• 14 years ago

Ah the peril of general claims with no specific examples.

mammo• 14 years ago

The good thing about this post is that it reminded me to be better at expressing my gratitude when finding solutions to my problems in pull requests. This makes the person who made the pull request understand that the work was appreciated even if it wasn't pulled and I would imagine that a request with many "thank you" comments would be more likely to be pulled.

zobzu• 14 years ago

This is not really the norm, but it does happen every now and then that pull requests are refused cause "they'll do it themselves". At which point you may think "my code sucks that much?"

Then when they do, they just copy your pull and put no credits, and there, you understand. Classic :P

But then again, it's not the norm. I don't give a fuck about pull requests or anything similar anymore since a long, long time. I just put it there for anyone who wanna take stuff, but the fixes are generally for my own use. And I'm usually too lazy to fork and fix the world, anyway.

njr123• 14 years ago

What happens more often to me, is that the pull request gets ignored. The gist.io [1] repository itself is a perfect example of this. 5 open pull requests, most of them now more than a month old have been completely ignored.

https://github.com/idan/gistio/pulls

nathan_f77• 14 years ago

I don't know man, it sounds like your code might not be very good. I'll have to make that assumption if you don't provide any examples, because I've never seen something like that happen. Especially not for 20 straight pull requests.

You don't have to look very far to find douchebag programmers, but I've always had friendly encounters on GitHub.

talmand• 14 years ago

I was going to make a sarcastic comment about the silliness of the thought that since you haven't had the same experience then the author's complaint is invalid.

I don't think it's necessary though.

After all, if it hasn't happened to you then there's no way it has happened to someone else, right?

Plus, your automatic assumption that he's a bad coder is part of the problem the author is complaining about. You know nothing about his code therefore an assumption, positive or negative, is not something you can make.

igorgue• 14 years ago

Before going into all the hassle, you should talk in their conversation channels, IRC or mailing list, about your approach and why you want to make this change, get the core developers involved into your development.

I get this every time at work, and sometimes I just don't have time to review something that looks unneeded, from my point of view, and something I can't review, since it's too big of a change.

perlpimp• 14 years ago

Engage core developers not the ivory tower bastards. If the core team is not helpful and you think you have a good idea, fork!

As well if you PRs are bug fixes then there is no excuse, if they are feature additions / changes then you might want to invest into a fork, do some cool work and then get noticed. Maybe they'll merge!

I haven't had any trouble getting my PRs accepted takes about a week to three weeks.

ezyang• 14 years ago

I wrote a piece a while back, which I think retitled would make a good companion article, "Why I am tired of merging pull requests" <http://blog.ezyang.com/2010/05/i-hate-patches-confessions-of...;

oogali• 14 years ago

Maybe he wants some constructive criticism?

But does he get that a) people are short on time, b) if your code looks/feels like it's too much work to review, the reviewers may procrastinate, and c) no one is actually obligated to accept your unsolicited contribution?

I feel like, pre-Github, this anger would be happen of the course of a few e-mails on a mailing list, and then instantly put in check by a more mature person. There would be no misconceptions in your feelings toward the project, and vice versa -- you could either take it or leave it.

Now, it just builds and festers, until it comes out in a blog post, where probably zero of the original parties even see the concern.

Can we bring back mailing list flames?

Why I am tired of writing pull requests

Related Stories