1. 45

  2. 18

    Wow. That was much longer and much better than I thought. It went on forever and it was all good.

    Apart from a few projects I care about, I’m a pretty lazy open source contributor. Do I have do some clone fork pull push hokie pokie dance? Not happening. Can’t I just mail you a patch? No? Then you won’t get it. My interest in submitting the patch is proportional to the effort used to create it. (Is it coincidence that the projects I care most about generally require zero patches?)

    If somebody is trying to contribute code to me, I try not to sweat the details. If their mailer mangled the patch, I’ll make the edits by hand unless it’s a large enough change that’d I’d screw it up. I wonder if this is a function of cvs not having a one click merge button. There’s no magic gateway that all changes flow through, so I don’t care that submissions must be perfectly aligned with said gateway. (Amazon doesn’t deliver packages by shooting them from Seattle through my window with a perfectly aligned maglev cannon, even though that would be very convenient. Sometimes I think that’s what the perfect pull request is trying to be.)

    (Also, lol at cocktails for programmers.)

    1. 13

      This was a great read. It’s something that I’ve never explicitly thought about before, but after reading it, it really hits home. I have a smattering of open source projects, and whenever someone submits a PR (yeah, I guess I’m one of the “cool kids” that likes the Github hokie pokie dance), I always see the contribution as a privilege. Namely, someone has taken the time to fix a flaw they perceived in my software. As someone who submits PRs to other projects myself, I know this usually requires a lot of time and effort, and so I always try to give deference to the contributor.

      Sometimes I do critique some of the PRs—usually with smallish changes—but I almost always offer to do the changes myself. I don’t feel I really have any right to demand that the contributor do extra work (particularly as the maintainer of not-so-popular projects). For example, one of my unmaintained projects received two PRs in rapid succession. The patches looked reasonable, so I merged them and then gave the submitter commit access to the repo. They went on to refactor some of the code and hopefully made a once unmaintained project a bit better for those that are still using it. This couldn’t have happened if all I did was whine about small things that I didn’t like.

      I guess for me, I came at this from an empathetic angle. I try to treat contributors how I would hope to be treated. But that’s a bit simplistic. This article really explained it much better than I could.

      1. 12

        Totally agree. For Leiningen I’ve stolen the “one accepted patch gets you commit rights” model from Rubinius (which I believe stole it from Hugs), and it’s been a huge success. We’ve had over a hundred committers, and I’ve only had to revert two commits. One of them was from an overzealous contributor who merged a patch that was only submitted as a joke.

        1. 2

          I hadn’t heard of the “one accepted patch gets you commit rights” model before - I like it and might give it a go on some of my small projects. Do you publicise that this is your policy, or quietly give them commit rights after a patch you think demonstrates they’re trustworthy?

          1. 4

            I publicize the policy, but I don’t add them to the list unless they specifically ask me. I’d estimate that less than 20% actually bother to ask. Occasionally I’ll offer and they’ll even decline if they don’t feel comfortable with it, which I think speaks volumes to the fact that if you put your trust in people, they will respect that trust and do their best not to violate it. Consider that the cost of granting commit rights to someone who will abuse them is actually very small; revoking and reverting is easy.

            It also doesn’t hurt that I offer a free sticker (if you send a SASE) once you’ve had a commit accepted. The content of the commit is immaterial; it can be a typo fix in the docs or whatever.

        2. 6

          To clarify my hokie pokie comments.

          I clone a project off github. I make a few small changes. OK, submit time. Because I have a checkout, I can make diffs trivially by running git diff. But I can’t commit and push. Oh. I’m supposed to switch back to the website and click fork. Then switch back to my terminal and connive to get git to push to my fork. Then switch back to the web site and click pull request. That’s frustrating to me, especially when the diff is already there. I can see it in my terminal. I know the partial solution is apparently to preemptively fork every project I might ever want to clone, but then my github page is cluttered with 9000 husks of never used forks.

          If you haven’t bought in to the whole system, it can be pretty off putting. I don’t mind some interaction with github if people like it (hey, your project, you host it where you want. I even host some stuff there), but occasionally it feels like there’s a “minimum 15 years experience with github” rule.

          1. 4

            I’m not going to pretend that submitting a PR on Github is easier than mailing a patch, but I do think it’s much easier than what you’re letting on here.

            But yes, I’ve definitely bought into the Github craze. I used its issue tracker last year as a TA. The instructor, another TA and I amassed almost 400 issues (closing 300 of them) in a single semester + a little bit of summer. We tracked everything from modifications to the course testing/grading infrastructure to actual grading tasks. We closed off issues with commits as we went and used tags/milestones/assignment to track who was supposed to do what by which date. (Notably, we didn’t use PRs. We didn’t have time to go through code review.)

            We had to spend a little bit of time (maybe a week) getting comfortable with the issue tracker, but once we did, it paid off in dividends. Since PRs are also just like normal issues, they can also be leveraged in the issue tracker. As you said, it’s a really great experience if you buy into it. I guess I just wanted to say that there are really some good reasons for buying into it. (Not that I think you implied otherwise!)

            1. 1

              I use GitHub all the time and am a happy customer. But the things you’re describing here are really bread and butter of any issue tracker. In fact, GitHub’s issue tracker is actually more limited than most; they removed the ability to sort/prioritize issues a few years ago, and now (within the context of a milestone or tag) issues always display in order of their integer ID.

        3. 5

          I almost appreciate it more when a patch is difficult to get merged. Yes, it takes more time and effort on my part (as well as others) but when you have multiple maintainers commenting on things from possible bugs, all the way down to coding and comment style, you know that it has been thoroughly vetted by at least part of the community. If a bug presents itself in that code sometime later, it also helps me feel a little better about having written that bug in the first place :)

          1. 5

            As a mostly solo/freelance developer, I can relate to this: rigorous discussion is one way to sharpen your skills. The depressing thing is when the discussion isn’t constructive, but it really just stonewalling, with no intention of ever merging or helping you get to a merge-able state.

          2. 3

            Man, I would be over the moon if somebody submitted a patch to my one useful open source project (https://github.com/whbboyd/backup if anybody’s interested). It would make my week. Even if they just emailed me a description of what they wanted changed, I’d be ecstatic that the thing I made was useful enough for somebody else that they wanted to make it more useful rather than finding an alternative.

            Maybe part of the problem is that open source contributions are now a way to build a software portfolio, rather than a way to solve problems you have? And it looks better for your portfolio if you run more successful projects, and so people have a tendency to exert their authority, which, for the most part, is done by rejecting patches.

            The one thing I disagree with is the author’s initial example of a deficiency in Keynote. The correct response to a missing feature like that is to patch it (go figure); if that’s impossible, because, for instance, the deficient program is proprietary and closed-source, it’s a much better choice all around to replace it than to build a dubious infrastructure of tools around it that the “upstream” is liable to bring crumbing down with a metaphorical shrug at their slightest whim. Everything else seems spot-on, though.