Ignoring pull requests discourages open-source contributions

by luu • 12 years ago

185 108 12 years ago

jhasse2• 12 years ago

I'm in a similar situation: https://github.com/JuliaLang/julia/pull/7714

Can someone help me what would be the polite way to do? I really don't want to annoy anyone, but also wouldn't want my work to be only on my local branch ;)

glesica• 12 years ago

Have you tried posting to the dev mailing list? You might also check out the IRC channel (#julia on Freenode).

StefanKarpinski• 12 years ago

Bumping the issue by posting something is probably the best way to go. I promise we won't get annoyed and it's easy to miss things like this. I suspect that what happened here is that all of the people who commented didn't feel like they had the "authority" to just go ahead an merge it, while everyone else (myself included) wasn't following the conversation (July was a really busy month) and didn't feel informed enough to pull the trigger. From a quick scan just now, this conversation looked to me like there were unresolved issues still, but upon more careful reading, that's not the case. It can be helpful to say something like: "I believe all the issues people have raised have been addressed. This should now be good to go." This change is quite nice and I'm testing it out right now. Sorry this languished for so long and I hope it won't discourage you from contributing – it is very much appreciated.

Update: this is now merged into Julia master. Thank you!

jhasse2• 12 years ago

Cool! Thanks :)

I guess Hacker News rocks and also Dan Luu is right about "Props to OpenBlas, Julia, Rust, jslinux-deobfuscated, and np for being incredibly friendly to new contributors."

ViralBShah• 12 years ago

I think we should separate out some developer documentation from the main documentation and put this there. This is a common question on a new contributor's mind, and having something like this written up in our developer documentation will probably go a long way towards putting them at ease.

The number of open PRs is now large enough, that it is not possible for any one person to chase them, and things occasionally do slip by.

the_af• 12 years ago

The title of this article is unfortunate in my opinion; I clicked it expecting a diatribe against open source. But in fact, it isn't.

To me, the relevant part is this:

"This behavior, eminently reasonably reasonable on the part of any individual, results in a systemic failure, a tax on new open source contributors. [...] It doesn’t take egregious individual behavior to create a hostile environment."

So the causes aren't necessarily hostile behavior, and in fact there may be both permanent and temporary solutions to this problems. Therefore, a better title would be "How to encourage open source contributions" :)

EdwardDiego• 12 years ago

The title of this article is unfortunate in my opinion; I clicked it expecting a diatribe against open source. But in fact, it isn't.

I was expecting a rant against shitty builds, my biggest contribution to contributing to an open source project.

phaer• 12 years ago

Thanks for your post and for not picking on one project in particular, but the obfuscation of the projects name in your last screen shot doesn't really work. It's trivial to read the projects name there.

dpweb3• 12 years ago

Couldn't you charge people to look at their pull requests? The contributor's fix may seem very important to them, but in actuality may or may not be of any value at all.

They are using free software but asking the maintainers of it to spend their time to review their pull request. Some entitlement there. The justification, my fix is important. Well, we don't know that, and to determine it costs time.

I would think a fee system where people pay to have their pull requests prioritized. I know it goes against this misguided idea that everything free is a virtue, but there is a good reason why some things have an associated cost involved.

zzzeek3• 12 years ago

this is very true because a pull request that solves a problem that the software's maintainer is also interested in solving is one that will be merged quickly. it's the frilly things that nobody else really needs, are difficult to review and merge, don't include tests, aren't particularly well written, and/or will only make the codebase worse just to appease someone's half-baked use case of dubious validity that typically sit in the queue for weeks or months.

nmb• 12 years ago

Interesting idea, but it would incentivize people against writing small, modular commits.

dpweb3• 12 years ago

It prioritizes them overall. People wouldn't have to pay, but paid ones take priority. Maybe even crowdfund each request, would put the priority in the hands of the community, while the owners retain final say.

otterley3• 12 years ago

Couldn't you charge people to look at their pull requests?

I'm puzzled - your response to a complaint that there's a tax on new open-source contributors is to tax them more?

zo12• 12 years ago

You misunderstood the sentence. In the sentence you quoted, "you" is referring to the project maintainer and "people" is referring to the contributors. So in essence, the suggestion is for the maintainer to charge the contributors for looking at their pull requests.

joeblau• 12 years ago

Ive noticed this on my project. People make suggestions that seem great, but they only help a small, extremely advanced portion of the community. It would be interesting to see something like this in place, although serendipitously good contributions would probably also fall with this in place.

Thrymr• 12 years ago

I seriously doubt that a financial incentive would change most maintainers' attitude towards pull requests. What is an appropriate piece rate for a PR review? There are plenty of highly paid developers who are doing a side project for free, for whom an hourly consulting rate <$100 would be well below their market rate. Well paid professionals doing a labor of love are not likely to be motivated by $5-10 here and there. Not all package maintainers are in this category, of course, but most are volunteers who don't expect financial compensation for it. Offering me $5 (or whatever nominal amount) to review a pull request is more likely to insult me than motivate me.

This is my problem with Gittip/Gratipay as well, the amounts are not enough to make a self-sustaining project, and even if it becomes a standard expectation, when someone else is willing to do it for free it would breed resentment. Open source should not be a service economy dependent on the gratuities of others.

Note that I'm not arguing that developers should work for free, just that small sums aren't likely to change their behavior. Sustainable business models for open source projects are difficult, and I suspect that tips are not often going to provide one.

dpweb3• 12 years ago

I wouldn't be too US centric in your assumptions. India will soon overtake the US in software devs and the average Indian dev makes approx. $5400/yr.

http://www.glassdoor.com/Salaries/india-software-developer-s...

Now, even on the high end if the Indian dev makes $7k a year or $3.50/hr. And I'm a relatively high paid US developer who depends on their project and I offer $50, that's 14 hrs. of work. Not insignificant.

memset4• 12 years ago

Something about this post does not sit well with me, though I have many colleagues who have expressed a similar sentiment.

Overall, the OP seems to be suggesting that, merely by posting code on github, we have now been conferred with the responsibility of "maintaining an open source project."

In fact, I find the first couple of screenshots kind of awful. "Why this is ignored?" Ugh, I think I'm going to go back to bed.

When I make a blog post, I'm not expected to respond to every comment. Or respond to every tweet. It's reasonable to not respond to every email. So what is it about posting code on the internet which mandates that people read, review, respond to, engage with, and eventually merge your code? And I do say mandate, because this blog post is basically a take-down, of which many have been written, of some poor project which has a bunch of outstanding pull requests.

I'm sorry that individuals feel that, by not spending their time to review code, they feel that it creates a "hostile" environment in open-source.

If the author had, instead of using github, simply posted a .tar.gz file on their personal home page, this wouldn't even be an issue. If you wanted to make a change, you'd download the source, modify it, and get on with your day. But somehow github (and probably the fact that everyone's dependency management system depends on "official" releases, often from github) keeps people from doing what they used to do, which was just change the code and continue on their way, and has bred some sort of animosity towards the very folks who provided this code in the first place.

My must-read on this topic is from Armin Ronacher, who says:

"I found it quite hard this year to work on my own projects because the bug trackers were full of things I personally did not really care about. The things I wrote over the last few years all work so well for me, that I don't need to fix problems or add things. When there is something that needs fixing, I will work on it, but otherwise I don't necessarily get the motivation to work on it." [1]

Armin does take steps to improve this, but to me it is important to say that he didn't have to.

I maintain several OSS projects. I have often gotten poorly-tested pull requests and merged them without reading, understanding, or testing code. It's the OSS maintainer who gets the heat, in the form of hundreds of emails, when things break, not the person who made the PR.

So I agree with the central theme that too many open pull requests is discouraging, and for projects which want to grow, there must be a process for managing it. But I think this is completely at the discretion of the maintainer, that we should take advantage of our ability to fork and modify code (since when did the definition of OSS become "they must also accept patches") and it is frankly rude for us to publicly knock a a project because they haven't chosen to accept your patch.

Here is a productive idea: make it easy for me to use `pip` to install my forked version of a library. That way I won't have to care whether it is merged into master. (In fact, pip already lets you use git as a repository source, but you can apply this to all of the other dep managers for other languages.)

[1] http://lucumr.pocoo.org/2013/11/28/emotional-programming/

phaemon2• 12 years ago

merely by posting code on github, we have now been conferred with the responsibility of "maintaining an open source project."

Well, yes, because by making the code available on Github and inviting issues and pull requests, you're saying "I'm maintaining an open source project."

So what is it about posting code on the internet which mandates that people read, review...

Nothing, as you yourself point out later in your post:

If the author had, instead of using github, simply posted a .tar.gz file on their personal home page, this wouldn't even be an issue

Exactly. This would have been a much better thing to do.

The point is that when you appear to be inviting contributions and someone spends their time and effort fixing a problem in your code, it creates a hostile environment when you then completely ignore these people.

The lack of information and feedback is what causes the problem and it's hardly onerous to at least provide a note saying something like, "This project is not actively maintained, but feel free to use it as a base for your own projects."

zephod• 12 years ago

because by making the code available on Github and inviting issues and pull requests

I may have missed something but where in the original article did he say he was _inviting issues and pull requests_?

The grandparent comment seems to be saying that hosting code on GitHub is not a tacit invitation for collaboration. It's OK to use it as a free central storage repository for projects where you're not interested in collaboration.

Also what about situations where an SVN repo is automatically mirrored to GitHub?

omni• 12 years ago

pip installing your own version of a forked library is already very easy.

1. Open up the setup.py, change the name variable to something unique, e.g. memset-flask 2. Run python setup.py register sdist upload 3. pip install memset-flask

memset4• 12 years ago

Also, in your requirements.txt, you can have a line of the form:

git+git://github.com/classicspecs/ClassicUPS.git

which will do exactly what it looks like it should! More documentation here for installing from tags, etc: https://pip.pypa.io/en/latest/reference/pip_install.html#git

3pt141593• 12 years ago

This is failing of Github by making it hard to mark projects as open to pull requests.

krick4• 12 years ago

Not really, because you well might be open to contributions and merge them sometimes and maybe even fix some bug reports yourself, but you don't have to and if I'm contributing a pull-request for your project it doesn't mean that you are obligated (in any sense of the word) to merge it or take any actions on it whatsoever. If I'm making a pull request I must be prepared for it, because nobody promised me it would be otherwise.

rwmj• 12 years ago

Actually I'd prefer if Github let you marked projects as closed to pull requests. For our projects we prefer to review patches on the mailing list, but there's no way to turn off pull requests in github, so instead we went and modified the project banner in ALL CAPS, although people still post pull requests.

iamstef2• 12 years ago

I believe you are reading into this incorrectly. The title of this post is "How to discourage open source contributions" not "The responsibility of open source project owners".

If you are not interested in contributions to you project, then you are not the intended audience.

Some thoughts supporting the post:

As a contributor I view my contributions as an investment, if my contribution is likely to help others I will be more motivated to contribute. If unfortunately it looks like my contribution will merely idle, I will consider alternatives. Quick-patch my fork and move on, switch to another project that is well maintained or if the project is critical to my work, I may offer to maintain it.

In addition, I will more likely to go above and beyond in my contribution if the project is well maintained and the likelihood of my work landing in the mainline is high. As a maintainer, a positive correlation exists between active maintenance and community contributions.

tittus• 12 years ago

If you are not interested in contributions to you project, then you are not the intended audience.

I presume it's obvious that if you're not looking at pull requests, you don't particularly care about contributions.

But this article isn't arguing that these maintainers are hypocritical for expecting contributions while being hostile to them. The article is effectively arguing that these maintainers should be doing more free work for the author, because by releasing open source they have signed up for the moral obligation of maintaining it in order to make the community less "hostile".

MatthewWilkes• 12 years ago

For what it's worth, this particular library is github/linguist – a core part of github that actively requests pull requests.

krick4• 12 years ago

Funny that this particular complaint then is quite justified, while the generalized one is not. Because, well, github is commercial enterprise which builds it's business on the phenomena of open source itself, by providing the service that uses this particular library as well and users of this service just provide them with fixes for this app (which obviously is maintained, as we are using that service right now and somewhere out there are programmers, paid to work on this particular app).

But author of the blogpost didn't want to reveal what library he's talking about, which makes the whole complaint much harsher than it should be.

krick4• 12 years ago

My thoughts exactly. In fact, that blogpost seems more (much, much more) discouraging "open source contributions" than what author of it found discouraging. Because, you know, it makes me think like "Here, I wrote some little thing that isn't anything special, but still, somebody might make use of it, or maybe some novice programmer may use code as reference and pick up some tricks, and, anyway, github is free… but wait, if people eventually start using it and there will be bugs and feature requests and pull requests I'll have to merge and politely explain why I wouldn't merge something unless some minor stylistic fix wouldn't be made, and I'll have to answer all kinds of ridiculous complaints[1] and worry about if I'm not reinventing the wheel and looking silly on the internet[2]… and if I'll wish not to be distracted and work on something else, or go watch a movie and won't spend my time on that thing, people will think I'm a jerk and will write blogposts about it and… nah, unless it's really something important and I'm ready to work on it I'll better keep it to myself".

So that how I might think and would be wrong, as author of this blogpost is wrong. Because free open source is, well, free and open for everything and everyone, and nobody has any obligations to it, and you can never take for granted work somebody does for you for free, ever.

[1] https://news.ycombinator.com/item?id=8712035

[2] https://news.ycombinator.com/item?id=5106767

pkhagah• 12 years ago

I see this situation differently. If you don't have time or energy to invest in reviewing PR, then you should say so on your project page clearly. And don't accept PR at all. It wouldn't waste other contributors time.

Otherwise say that you are looking for active contributors and give them PR access, if and when you get someone eligible.

Just accepting PR and doing a lottery on them is not useful for anyone.

Retra• 12 years ago

The point is that you don't have an obligation to anyone. If it's useful to _yourself_ to do it that way, then by all means.

pgeorgi4• 12 years ago

Another productive idea: allow github repos to come without "pull request" button - that's the one feature that can't be disabled, but for various projects that would be exactly the right thing to do: the "it might be useful to others, but for me it's done" projects just like those using github as mirror (because people desperately need the fork button).

But it doesn't make immediate business sense: projects not using pull requests don't buy into the platform. Amazing enough that the bug tracker can be turned off...

sytse• 12 years ago

GitLab B.V. CEO here, on GitLab you can turn off merge requests per project (and issues as well of course).

memset4• 12 years ago

What would it sound like if the remedies to this took the form of "perhaps I could..." rather than "X person should..."?

What's the real problem we're trying to solve? Getting PRs merged or automating our build process or setting expectations or what?

freshhawk• 12 years ago

I think this is the result of people not recognizing two very different types of open source code.

There's the friendly dump of useful stuff. It's not an open source project, but it's code people know would be useful and are nice enough to share. Obviously there is no responsibility to maintain it, everyone can just fork it and it can diverge freely and no one cares.

Then there are actual projects. A person or group saying "Here is a problem we all share. Let's stop reinventing the wheel and work together on this. I will do some management work on this in return for your contributions and my name being prominent. Forking this for no reason is considered rude. Please contribute to this project instead of starting your own clone of it with your name on it."

Those are both good things, but they are different. People should be clear about what kind of project it is.

dalke3• 12 years ago

I think you're describing project governance rather than something about open source code.

Me, I'm in a third group. I write commercial open source. Only people who pay for my software get access to it, under the MIT license. Is it sharing if it costs money? ;)

rattray2• 12 years ago

I agree. The problems the author describes happen all too often in the "actual projects" category; it certainly looks like the screenshots were from one such project.

res0nat0r• 12 years ago

Another great fix for this problem if you don't have time to work on issues, or users are becoming more of a burden than a help...go to your github repo settings page and disable them.

Anderkent• 12 years ago

You can't disable pull requests.

egonschiele• 12 years ago

In my experience, most pull requests I open have been merged quickly. When they don't, it's because the repo is part of a large company/organization and there's no owner for the github repo.

Also, what are these magical projects getting hundreds of PR's? Most of mine seem to just get bug reports instead.

I have to sympathize with both sides. It sucks to have a PR ignored, but I also don't want to open source projects if it just means something else I have to maintain. Theoretically, if I don't merge PRs, the community chooses a new fork as the "canonical" fork. I've seen this happen with small communities (its happened a few times with Haskell). I think it's tougher when it's a popular project.

HashNuke2• 12 years ago

I found a simple solution to opensource burnout: when someone contacts me about a project and wants to improve it, I give them access to the repo.

I do this when:

* I don't have the time/interest on the project

* The person seems genuinely interested in maintaining it

Most people I've come across in the opensource world are polite. So I just assume that the ones I grant access to repos are nice enough for other people to interact with.

Matumio2• 12 years ago

Same here, but I don't even care if the person is interested maintaining it. I have observed twice now that the interest of somebody submitting an almost trivial patch flamed up after I granted push access. The project suddenly got a burst of life again, and commits started to become more and more ambitious.

HashNuke2• 12 years ago

I am going to try that from now on. Giving people access to repos and then letting them pass on the baton when they are done. That is a very novel idea.

P.S: Yes I upvoted you and I wish I could do it once more :)

zackmorris• 12 years ago

When I first heard about open source in the mid 90s, I thought "that can't possibly work with no leader" because I thought that writing to the repository was open to anyone. I wondered if maybe then someone would stress test a revision and if it was good enough, sign off on it as the most recommended version to download. So basically there would be no "current" version, that one would be this evolving hodgepodge out ahead of the one most people used. I guess I envisioned it working kind of like evolution, so the best versions would split and merge again like reproduction and the most fit version would rise to the top.

So on some level I think open source has actually failed, because it didn’t work out that way. Instead there seems to usually be a handful of maintainers who allow certain patches to go in, but if there’s too much of a disagreement, we end up with a fork, never to be merged again. The burden on that handful of people is so high that on some level I'm amazed anyone ever takes on the infinite support liability of starting an open source project in the first place.

Just out of total curiosity, does anyone know of any other ways of organizing open source, I mean from decades ago when it was first getting started? Were there ever any successful projects that were more organic, where a greater portion of the contributors or even all of them could make changes? Did they devolve into anarchy or did they work?

Update: I didn't expect this to be down voted, perhaps it was my poor choice of wording. What I meant to say was "So on some level I think open source has failed to live up to its original vision of open contribution leading to viable software".

jdumblauskas• 12 years ago

good post -- I think you really got to the core issue -- "that can't possible work with no leader" -- or at least a "benevolent dictator". I guess I'd like to see evidence of an old open source project that has withstood the test of time. None come to mind.

InformalRelief• 12 years ago

OP argues that the presence of the 'Pull Requests' tab is encouraging people to create pull requests, and therefore the project owner is somehow responsible for reacting to pull requests.

There's also a 'Fork' button, which is kind of prominent, so by OP's logic, people should feel encouraged to fork the project.

"But when I looked at the mailing list for the project, I saw a wasteland of good patches that were completely ignored, where the submitter would ping the list a couple times and then give up. Did it seem worth spending a week to disentangle our IP from the project in order to submit a set of patches that would, in all likelihood, get ignored? Of course not.

If you have commit access to a project that has this problem, please own the process for incoming pull requests." (from the article)

Ok, so if the mailing list is dead and your pull requests aren't the only ones being ignored, why not just fork the project and 'own the process' yourself? You could even try to contact people who tried to contribute and got ignored, and let them now that you will 'own the process for incoming pull requests'?

And if you don't have time or energy for that, why demand it from other people?

MoOmer• 12 years ago

To that end, the author also suggested that it may serve the project (and subsequent forks) well if the project owner disabled PRs.

Matumio2• 12 years ago

Which would remove the most obvious place to look for commits for this new fork, or for this patch that you were just about to write.

masklinn2• 12 years ago

You can not disable PRs on github. The wiki yes, issues yes, but it's not possible to disable PRs, that simply isn't an option.

At best you can add a note/contribution guideline saying you don't accept PRs, and close them as soon as they're created, but it's not possible to prevent them.

blahedo• 12 years ago

Ok, so if the mailing list is dead and your pull requests aren't the only ones being ignored, why not just fork the project and 'own the process' yourself?

That's not necessarily straightforward even for experienced OSS contributors, but in the given context (newbies who have been encouraged to get into OSS by contributing a patch), it's really a non-starter.

rattray2• 12 years ago

Because Forks aren't easily discoverable (discussed elsewhere on this thread as well), the fork would be unlikely to gain critical mass, especially without an official sanction and prominent shoutout by the original repo. If the maintenance has truly lapsed, the owner may be too lazy to even tell people about the fork. This is backed up by the fact that they obviously haven't anointed a successor, as it were.

hesdeadjim• 12 years ago

I've had a similar experience and I found it to be equally frustrating.

I contributed some minor enhancements to a simple helper script, one that just made a small part of development a little smoother. I created a pull request, added a good description of what I had done, and sent it off. The author got back to me pretty quickly with a few changes he wanted done, I happily obliged, and then sat and waited for a week.

Then over the following few weeks he proceeded to nitpick and ask for changes that really just amounted to over-engineering for some future possibility he imagined for his 200 line script. I will also point out that beyond the initial commits he had made six months ago, he hadn't touched the project since.

Regardless, I obliged, made every change he asked for. That was almost a month ago and he has now gone completely silent, the pull request sitting idle.

What I learned from the experience is that beyond the points the author made, the balance of power in these projects is often an insurmountable barrier. For instance, if I say something that pisses this guy off, he simply ignores my pull request and it sits in limbo forever. Or I fork his project and other users are forced figure out which version is the best (great example of this is the shitty state of AWS libraries in the Go language).

All in all, this experience isn't enough to turn me off to contributing to open source projects. It does however make me think twice about when it's worth trying and when I might just let my private forked copy stay that way.

sciurus4• 12 years ago

Although the author tried to obfuscate the project he used as his example, people on Reddit quickly figured out that it was linguist. This is a library Github maintains that they use for detecting what language a file is written in. There is a special irony in Github employees encouraging then ignoring PRs that would improve their own product.

https://www.reddit.com/r/programming/comments/1pczpr/how_to_...

http://danluu.com/everything-is-broken/#github

memset4• 12 years ago

We have no idea why the people at github did not merge this PR. Maybe several people on the team left the company. Maybe they were pulled into a project which will have higher revenue. Maybe so few people have this problem that this improvement isn't a priority. Maybe it breaks some other internal functionality that someone uses.

We have no idea whether this "would improve their own product" because we don't know what their product is, their product roadmap, their staffing, their budget, or any of the innumerable factors which affect whether a company chooses to spend time and energy and effort and money when implementing a feature.

So why do we presume?

sciurus4• 12 years ago

We should not have to presume. Since Github is soliciting contributions to linguist [0], they've created an obligation to engage with outside contributors and explain their decisions. When the author wrote his blog post, there were over a hundred PRs and apparently no acknowledgement of many of them from Github. In his "How to destroy your community" talk [1], Josh Gruber refers to silence as "the most effective community destroyer of them all".

I'm not actually trying to call out Github, by the way. It's great that they've written up guidelines for contributing [0], and a glance at the PRs shows much more engagement now.

[0] https://github.com/github/linguist/blob/master/CONTRIBUTING.... [1] https://lwn.net/Articles/370157/

netheril96• 12 years ago

So why does GitHub not reply with comments about why this PR is not a good fit for this project? Or if it is too tedious to reply to every PR, put up a general guideline on "what we don't want in pull requests".

I mean, one can defend his/her decision or adopt changes if the PR is not exactly what GitHub wants. But being ignored? There is no solution.

curiously• 12 years ago

I also open sourced a project I was working on.

Basically the benefit to me has been net negative.

It has taught me to never give things away for free, especially code.

License it, sell it, do anything but open source it on github unless it is javascript or any program that is easy to just look at the source.

ninkendo• 12 years ago

The obvious solution for owners of such projects is to grant more people commit access so more people can handle outstanding PR's. A single person being responsible for all pull requests doesn't scale.

But the issue is that owners don't like giving up that much control, because it can lead to the project being taken in a direction they didn't originally intend.

This is an issue for any open-source project, which is why the biggest projects tend to have a structure where there is a dictator, a hierarchy of core contributors, and everyone else should stick to mailing lists or pull requests to contribute code.

But for small projects it's difficult because it's tough to make that kind of hierarchy work on GitHub.

I'm starting to think there needs to be a boilerplate "Contribution Guidelines for Small Open Source Projects" meta-guideline that small Open Source projects (on the size of things like gems or small utilities) can adopt, similar to how projects can adopt SemVer or a particular OSS license.

Some simple tenants of such a guideline system (or basically, an example thereof:)

1) Contributions to this Open Source project shall adhere to this projects MANIFESTO.md, which shall define the goals of the project, its scope, what it aspires to be, etc.

2) The owner of this open source project shall grant commit access (promoting them to "Core Contributors") to developers who show a consistent drive to make enhancements and fixes that fall within this well-defined manifesto.

3) Only the owner shall make changes to the manifesto. Changes to a project's manifesto should require a fork of the project. Manifestos can be designed by consensus but it should ultimately be up to the owner to commit the change.

4) Core contributors should be able to merge other developer's pull requests, and even grant commit access accordingly. If any commits get merged which fall outside of the manifesto's guidelines, the commits can be rolled back by the owner, or the core contributor can make the case for changing the manifesto, or they should fork the project to keep the commit.

I don't really have the clout to be able to develop such a meta-guideline (I'm not active in any OSS projects), but I think it would be really cool if someone would.

andyidsinga• 12 years ago

But when I looked at the mailing list for the project, I saw a wasteland of good patches that were completely ignored, where the submitter would ping the list a couple times and then give up. Did it seem worth spending a week to disentangle our IP from the project in order to submit a set of patches that would, in all likelihood, get ignored? No.

Sounds like the OP should have checked activity levels first ...then decided not to spend the extra time.

When I look at using open source for something I often use the following to determine if I should use it:

a) does it have the functionality I need today

b) is it active and being maintained ( through frequency of updates, active mailing list, sometime a financial sponsor (bigco who uses it))

yesimahuman• 12 years ago

The reason many PRs get submitted is that many of them just aren't good. Over time, having to deal with formatting issues, way too many commits in a PR that change random files, solutions to things that are really important but not done in a foward thinking way. Great PRs when done right are a wonderful thing, but the reality is that the majority of them are not great and this takes a tax on the developer.

What us OSS devs can do to help fix this is be very clear about PR protocol: ONE commit, change ONE thing. Code changes should have a unit test. And then make sure we are either merging or closing PRs for active projects.

hrjet2• 12 years ago

A part of the problem is that GitHub makes it difficult to find forks. If a project is not being maintained in the original repository, and somebody else is maintaining it, it should be made easier to discover those other forks.

Right now, when you click the "forks" link in Github it shows a pretty graph of commits across branches and repositories, which although useful in some cases, is very hard to navigate and doesn't help discover active forks.

Moreover, for the maintainer of the alternative fork, it would be nice to be able to clone the pull-requests too from the main repo. They will be able to merge any new PRs into their own fork quickly and also to automatically inform the PR's watchers.

ansible2• 12 years ago

Yeah, that would be cool. The only thing you can do right now it's to just watch the original repo, and send messages to the PR submitters to open a new PRs against your own fork.

maccam94• 12 years ago

You can just fetch the PR's on the command line and merge them to your fork. But being able to do it in the web ui would be nice too.

alxndr• 12 years ago

re finding forks, what about Github's network/members "chart"? github.com/author/repo/network/members

hrjet2• 12 years ago

Oh, thanks! I didn't know about it. But it is still very difficult to know which fork is more active. For example, see this: https://github.com/mozilla/rhino/network/members

bjz_• 12 years ago

As somebody who maintains a decent amount of Rust libraries, I do try to keep on top of my PRs, but sometimes Github's notification system makes it easy to forget that some PRs have been sitting around for a long time. For example if you click on a notification in your inbox, it automatically gets marked as read - you can't keep it around as a reminder.

What would be really nice is if you could have some sort of dashboard to let you know the status of your outstanding issues and PRs on all of your repositories - how long they have been open for, whether they are stale or not... etc. It's just too hard to go through each repo individually to check on its health.

masklinn2• 12 years ago

What would be really nice is if you could have some sort of dashboard to let you know the status of your outstanding issues and PRs on all of your repositories - how long they have been open for, whether they are stale or not... etc. It's just too hard to go through each repo individually to check on its health.

There's https://github.com/issues/assigned and https://github.com/pulls/assigned, kind of. It does require that you assign all outstanding issues, but I don't know of other cross-repository or cross-organisation tools built into github. The other alternative is to use the github API and fetch the precise information you want.

pwg• 12 years ago

Another issue is that github's "merge a pull request" system is completely broken.

Most projects on github, by virtue of being based on git, will have several branches within the repository. The regular contributors to the project will know branch 1 from branch 2 and will submit their PR's against the projects "dev" branch (whatever it happens to be).

But irregular contributors, or out of the blue contributors, will invariably choose a branch that is not the projects "dev" branch upon which to base their patch, and then submit their pull request.

And for the project receiving the pull request, the github "handle it" interface is all-or-nothing. You either put the patch in, against the branch the requester used, no matter how wrong that branch might have been, or you simply can't merge it via. github's web interface. And if you don't merge it by github's web interface, you can't mark it accepted. Your choices are "accept and merge patch" and "refuse".

So there's a very good chance that some number of those outstanding pull requests shown have actually been merged, but were merged by the maintainer pulling a patch out of github manually, and applying the change manually via git to the correct branch and not the branch the submitter picked. And since the patch was in fact merged, poking the github "refuse" button in the web interface would seem wrong, so the outstanding pull request just hangs around, forever, because github can't be told "I did merge this, just outside of your view".

StylifyYourBlog• 12 years ago

I agree with the point that many a times when a person sends in a pull request , that might be their first time doing so and their experience with you might be how they would perceive the whole open source community in the time to come

Animats2• 12 years ago

Back in 2012, I ran into a similar problem. The Python standard library has "isoformat()", which converts Python datetime objects to "2012-09-09T18:00:00-07:00" format. This is the format used in emails and RSS feeds. But there was no standard function for the inverse, parsing such strings, that got all the cases, including time zone offsets, right. Others had discovered this problem and tried to fix it. The Python repository, PyPi, had four different versions of such parsers, each broken in a different way. Because there's no way to fix anything in PyPi (it's just a list of links; it doesn't host the source), each person who had found a problem had forked the code and hosted their version somewhere else. People have been posting bug reports about this since 2008.

Further discussion unearthed seven more different Python implementations.

https://groups.google.com/forum/#!topic/comp.lang.python/Q2w...

Two years later, there's been little convergence. There's a currently maintained version on Bitbucket at (https://bitbucket.org/micktwomey/pyiso8601). It has four forks.

So there are now 15 different versions of this little function. A function for which there is a well defined spec, an RFC and an ISO standard, for what it is supposed to do.

That's the open source process.

pgeorgi4• 12 years ago

Python has PEP to extend the base system including the standard library. Maybe it should go through that instead of being third party code in some "repository"?

The closed source market of (say) third party win32 controls (GUI widgets) is also messy - just look at how many calendar widgets are out there, but nobody complains there. That's "market forces at work" ;-)

maxerickson• 12 years ago

Stuff like adding a single function to a library doesn't warrant the PEP process.

Fixing this is moving forward:

http://bugs.python.org/issue15873

(Perhaps it's fair to say, slowly moving forward)

scoot• 12 years ago

I contribute to an open source project that actively solicits contributions. The README asks for PRs in preference to issues (but issues are okay), and there is even a CONTIBUTING.md that describes the process.

After being active on the project for a while I was granted commit rights. I have done everything I can in that role to support the project - responding to issues, merging other's PRs after code review & testing, updating documentation, and, in response to issues creating PRs that are: coded in the same (slightly idiosyncratic) style as the original code, don't cause regressions, have their own tests, and are well documented.

In the interest of good practice I haven't merge my own PRs, but left them to the project owner to review. There they languish despite in some cases resolving issues that the project owner himself opened issues for.

So, while I don't agree with the tone, I do sympathise with the author's position. It can be demoralizing when an open-source project owner actively solicits contributions (not just a fork or create PR button, but requests and instructions), then ignores contributions that may have taken many hours (or in some cases days) to get to the point where the PR is submitted.

skybrian• 12 years ago

If you have no plans to maintain hobby code, you should discourage usage. Say it right up front:

"TagTree is unsupported and not meant for use in a production Dart application, unless you're willing to fork the code and fix any bugs you find yourself." [1]

Or if a project is widely used but difficult to contribute to, you should say so up front, like this:

"Contributing code is one of the more difficult ways to contribute to Guava, and is almost never what the project really needs most [...] We know it's tempting to submit code before the feature is accepted, but this is not always a good use of your time." [2]

People tend to over-promise because that's what they see other open source projects doing. But you don't have to be an evangelist just because everyone else is. If you're not committed to doing something, don't sell it. Real leadership is about being respectful of other people's time.

[1] https://github.com/google/dart-tagtree [2] https://code.google.com/p/guava-libraries/wiki/HowToContribu...

hw• 12 years ago

I've contributed bug fixes to open source projects on github and have had my share of ignored pull requests, sometimes they are for valid reasons like the project owner being on vacation or a business trip, but often enough the owner just didn't have enough time to manage the project.

I feel that in the latter case, it should be the responsibility of the owner to delegate more project administrators, or hand a project off to someone else to maintain. It's often hard to do so, and hard to find someone you trust that would take the project and maintain it well.

al2o3cr2• 12 years ago

Funny, you could write an article entitled "Why open-source maintainers quit" and have the sole text be a hyperlink to this article. The whole piece is a long whinge about "why won't maintainers do free work for MEEEEE!". Maybe they aren't using the project anymore, maybe they're busy with life, maybe they just got tired of triaging for a while - whatever.

The final story in the piece really sums it up: "But when I looked at the mailing list for the project, I saw a wasteland of good patches that were completely ignored, where the submitter would ping the list a couple times and then give up. Did it seem worth spending a week to disentangle our IP from the project in order to submit a set of patches that would, in all likelihood, get ignored? No."

This sounds like a great situation for somebody else to step in and pick up maintenance of a clearly-neglected project. Hell, if your company is using the software for critical-enough things to devote "a couple months" to fixing bugs it seems like it would be in your company's interest to start maintaining the project publicly, if everybody's patches are being ignored. It would certainly be more productive than complaining that somebody else won't QA and then support your fixes FOR FREE, FOREVER...

vorg• 12 years ago

If an open source project doesn't merge in pull requests, then that's the business of whoever created and/or runs that project. When a project's managers let a pull request or Jira issue sit there but create their own request or issue to do exactly the same thing often with code copied from the original, however, then that's behavior that should be exposed.

Karunamon• 12 years ago

The solution to this "problem" is remarkably simple from a repo owner's standpoint: Verbiage in your README along the lines of "This is an unstable project and pull requests will not be honored - you are welcome to fork the project, however!"

This makes it appear on the very front page of your project and is hard to miss. (How to deal with people that contribute without reading first is an exercise for the reader)

The attitude I'm seeing in here is really quite disgusting. You've put your code up on what is basically the Facebook of coders - you really should not feel put-upon when the unspoken social contract of a collaborative code editing platform is acted on by someone else.

Every culture has one, and GitHub's is shared collaboration on code bases. If you want to violate that norm, fine, it's your project, but then kindly call it out ahead of time and stop whining that the community that's made GitHub awesome is the way that it is.

hysan• 12 years ago

A fairly important point that was left out is the license. If the original developer puts some form of license on the code, then people may be afraid to fork and maintain the project on their own because no one wants to try and understand the murky waters of licenses/copyright/etc. This mentality puts the onus of maintaining the repository on the original dev despite their intentions on making the code open source. In my opinion, if you are going to open source your code but with no intention of maintaining it, then make a fully open license in plain English that says anyone can take ownership of the code.

Ignoring pull requests discourages open-source contributions

Related Stories