Ignoring pull requests discourages open-source contributions(danluu.com)
danluu.com
Ignoring pull requests discourages open-source contributions
http://danluu.com/discourage-oss
122 comments
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.
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.
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.
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.
I think a lot of people like using the web UI because you don't have to add another remote just to pull from it maybe once.
I'd definitely want to contact the creators of the PRs anyway so that they are aware of my fork.
I'd definitely want to contact the creators of the PRs anyway so that they are aware of my fork.
re finding forks, what about Github's network/members "chart"? github.com/author/repo/network/members
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
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.
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.
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.
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 :)
P.S: Yes I upvoted you and I wish I could do it once more :)
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?
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?
> 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.
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.
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.
To that end, the author also suggested that it may serve the project (and subsequent forks) well if the project owner disabled PRs.
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.
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.
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.
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
https://www.reddit.com/r/programming/comments/1pczpr/how_to_...
http://danluu.com/everything-is-broken/#github
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?
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?
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/
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/
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.
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.
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.
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.
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.
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.
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.
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.
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.
Cloud services will destroy Indian IT services viz TCS/Infosys/Wipro/TCS/HCL
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.
Interesting idea, but it would incentivize people against writing small, modular commits.
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.
> 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?
I'm puzzled - your response to a complaint that there's a tax on new open-source contributors is to tax them more?
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.
I didn't misunderstand. I think the confusion may stem from the question of whom the taxation is bad for - the maintainer or the contributors.
I don't believe prospective co-committers should ever be taxed for their contributions. If their contributions aren't helpful/don't live up to their standards, you can reject the request with a polite explanation.
Open-source project maintainers should understand that by posting their code on GitHub, they're inviting contributions -- that's why GitHub is called "social coding." Its purpose is to make code better through a marketplace of contributions. If you put your code there, you voluntarily accept the burden of dealing with PRs. If that's the tax people are concerned with, there's an easy way to escape it: don't use GitHub, or disable the "issues" feature in the repository. I'm not sure if you can disable PRs; but you can certainly say that you won't accept patches via GitHub in your CONTRIBUTING and/or README document.
I don't believe prospective co-committers should ever be taxed for their contributions. If their contributions aren't helpful/don't live up to their standards, you can reject the request with a polite explanation.
Open-source project maintainers should understand that by posting their code on GitHub, they're inviting contributions -- that's why GitHub is called "social coding." Its purpose is to make code better through a marketplace of contributions. If you put your code there, you voluntarily accept the burden of dealing with PRs. If that's the tax people are concerned with, there's an easy way to escape it: don't use GitHub, or disable the "issues" feature in the repository. I'm not sure if you can disable PRs; but you can certainly say that you won't accept patches via GitHub in your CONTRIBUTING and/or README document.
> If their contributions aren't helpful/don't live up to their standards, you can reject the request with a polite explanation.
that's really not how it works in reality. The vast majority of pull requests do contain something that is ultimately a positive addition, so a simple "rejection" is not appropriate. Instead, in order to get a pull request to be presented in the way that the maintainer needs it to be, the request have to be slowly nursed over days/weeks/months, in a series of often dozens of back and forth emails, code samples, coachings, tutorings, attempting to get the PR submitter to please write correct tests, please get it to look a certain way, etc. The contributors will frequently themselves not reply for weeks or months when these suggestions are made - pull requests that ultimately have something useful will languish just as much if the maintainer attempts to compel the contributor to finish the work of preparing the PR for a merge, as if the maintainer just took a long time to finish the PR themself. It is much less effort and usually much more expedient for the maintainer to simply take the PR in its incomplete state and just fix it directly. Very often the problem is involved enough that the maintainer needs to be involved in restructuring in any case, even with a very well written PR.
The reality of the pull request is that it is in the vast majority of cases a more verbose form of bug report or feature request. They are quite often just as much work, if not more, than a plain bug report, for the maintainer of a well-written project.
that's really not how it works in reality. The vast majority of pull requests do contain something that is ultimately a positive addition, so a simple "rejection" is not appropriate. Instead, in order to get a pull request to be presented in the way that the maintainer needs it to be, the request have to be slowly nursed over days/weeks/months, in a series of often dozens of back and forth emails, code samples, coachings, tutorings, attempting to get the PR submitter to please write correct tests, please get it to look a certain way, etc. The contributors will frequently themselves not reply for weeks or months when these suggestions are made - pull requests that ultimately have something useful will languish just as much if the maintainer attempts to compel the contributor to finish the work of preparing the PR for a merge, as if the maintainer just took a long time to finish the PR themself. It is much less effort and usually much more expedient for the maintainer to simply take the PR in its incomplete state and just fix it directly. Very often the problem is involved enough that the maintainer needs to be involved in restructuring in any case, even with a very well written PR.
The reality of the pull request is that it is in the vast majority of cases a more verbose form of bug report or feature request. They are quite often just as much work, if not more, than a plain bug report, for the maintainer of a well-written project.
> The reality of the pull request is that it is in the vast majority of cases a more verbose form of bug report or feature request. They are quite often just as much work, if not more, than a plain bug report, for the maintainer of a well-written project.
OK, so what, though? If it makes the software better for the users, I don't understand the problem. If the problem is "but it's work for me," see above: you knew the job was dangerous when you took it. Volunteerism should be a labor of love. If it isn't, find a replacement for yourself.
OK, so what, though? If it makes the software better for the users, I don't understand the problem. If the problem is "but it's work for me," see above: you knew the job was dangerous when you took it. Volunteerism should be a labor of love. If it isn't, find a replacement for yourself.
> OK, so what, though? If it makes the software better for the users, I don't understand the problem.
there isn't a problem! your pull request might take me 6 months to respond to. That's the point. Contributors shouldn't have a problem with that, either.
there isn't a problem! your pull request might take me 6 months to respond to. That's the point. Contributors shouldn't have a problem with that, either.
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...
"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...
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".
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".
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.
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.
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.
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" ;-)
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" ;-)
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)
Fixing this is moving forward:
http://bugs.python.org/issue15873
(Perhaps it's fair to say, slowly moving forward)
Ah, yes, I put that issue into the tracker two 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.
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.
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.
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.
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.
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.
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".
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".
> 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.
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.
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/
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/
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.
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.
> 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".
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".
I agree. The author has released something into the world in the hopes that it will further progress for someone else or themselves. That's awesome. And the OSS community on GitHub has some great tools to fork the project if the author disengages.
But I do think that those tools aren't obvious or are outside the confidence level of many new contributors, and can be a real detriment to convincing developers that open source is worth their time.
It would be great to point less-experienced developers to a list of open source projects that are very responsive and supportive in their pull request management for their first contibutions. Does a list like that exist?
But I do think that those tools aren't obvious or are outside the confidence level of many new contributors, and can be a real detriment to convincing developers that open source is worth their time.
It would be great to point less-experienced developers to a list of open source projects that are very responsive and supportive in their pull request management for their first contibutions. Does a list like that exist?
It would be awesome if Github exposed a metric for contribution responsiveness.
- The average time it takes for a member to reply to a pull request.
- The average time it takes to merge a pull request.
- The percentage of pull requests that get merged.
These metrics will vary pretty widely even between repos that are trying to be responsive. Maybe just comparing these metrics to the their historical values within the same repo would shed some light on whether or not the members are becoming unresponsive. Maybe there are better metrics.
- The average time it takes for a member to reply to a pull request.
- The average time it takes to merge a pull request.
- The percentage of pull requests that get merged.
These metrics will vary pretty widely even between repos that are trying to be responsive. Maybe just comparing these metrics to the their historical values within the same repo would shed some light on whether or not the members are becoming unresponsive. Maybe there are better metrics.
Check out Issue Stats[0]: http://issuestats.com/
The project won the "Annual Data Challenge" on GitHub this year.[1]
[0]: https://github.com/hstove/issue_stats [1]: https://github.com/blog/1892-third-annual-data-challenge-win...
The project won the "Annual Data Challenge" on GitHub this year.[1]
[0]: https://github.com/hstove/issue_stats [1]: https://github.com/blog/1892-third-annual-data-challenge-win...
pulse typically gives a good indication. https://github.com/stefanpenner/ember-cli/pulse
"But I do think that those tools aren't obvious or are outside the confidence level of many new contributors"
You HAVE to fork the project to even submit a pull request. That's the exact opposite of "not obvious". If you're viewing the source on Github, clicking the "Edit" icon will even do that for you...
You HAVE to fork the project to even submit a pull request. That's the exact opposite of "not obvious". If you're viewing the source on Github, clicking the "Edit" icon will even do that for you...
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.
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.
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? ;)
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? ;)
If you give people your software under the MIT License, they can give it to anyone they want to.
"Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so"
http://opensource.org/licenses/MIT
"Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so"
http://opensource.org/licenses/MIT
I'm confused. Could you explain your point?
Yes, that's the MIT license I use. My customers can share the code if they want. But I sold them a copy of the software, I didn't share it with them.
Yes, that's the MIT license I use. My customers can share the code if they want. But I sold them a copy of the software, I didn't share it with them.
You said "only people who pay for my software get access to it". I was pointing out that anyone your customers choose to share your software with get access to it.
Sorry, I let out the words "from me" because I thought it was implied. I don't share this open source software. I sell it.
freshhawk listed two categories: 1) a "dump of useful stuff" with "no responsibility to maintain it" by people who are "nice enough to share." I don't fit in that because a) I include a year of support in the sale, and b) I don't share it, I sell it.
2) "Then there are actual projects. A person or group saying 'Here is a problem we all share. ... I will do some management work on this in return for your contributions and my name being prominent'". I don't expect trade in kind, I expect money. Just like proprietary software vendors (especially those who distribute sources).
Thus I consider myself as a member of group #3.
freshhawk listed two categories: 1) a "dump of useful stuff" with "no responsibility to maintain it" by people who are "nice enough to share." I don't fit in that because a) I include a year of support in the sale, and b) I don't share it, I sell it.
2) "Then there are actual projects. A person or group saying 'Here is a problem we all share. ... I will do some management work on this in return for your contributions and my name being prominent'". I don't expect trade in kind, I expect money. Just like proprietary software vendors (especially those who distribute sources).
Thus I consider myself as a member of group #3.
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.
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
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
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...
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...
GitLab B.V. CEO here, on GitLab you can turn off merge requests per project (and issues as well of course).
But GitLab isn't Github.
People want GitHub. coreboot uses gerrit, which isn't good enough for people[tm], and thus we mirror to github.
I use gitlab for my personal hosting needs, and I'm happy enough with it that I use it, even though there would be more lightweight options (gogs, gitblit).
I use gitlab for my personal hosting needs, and I'm happy enough with it that I use it, even though there would be more lightweight options (gogs, gitblit).
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?
What's the real problem we're trying to solve? Getting PRs merged or automating our build process or setting expectations or what?
The "perhaps I could" option in this case is to drop the github mirrors I maintain.
Luckily, those projects aren't among those plagued with pull requests they never intended to follow up on (but couldn't avoid because that frickin' button can't be disabled), but that's certainly the solution I'd take.
Not sure if anybody is happier with that.
Luckily, those projects aren't among those plagued with pull requests they never intended to follow up on (but couldn't avoid because that frickin' button can't be disabled), but that's certainly the solution I'd take.
Not sure if anybody is happier with that.
> 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."
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."
> 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?
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?
>"I may have missed something but where in the original article did he say he was _inviting issues and pull requests_?"
I think what the OP is saying is that by putting a project publicly on Github, and allowing people to submit issues/pull requests you're "inviting" it. I don't use Github, but I can guess that there is an option to "disable" those features, or at the very least keep the project private.
I think what the OP is saying is that by putting a project publicly on Github, and allowing people to submit issues/pull requests you're "inviting" it. I don't use Github, but I can guess that there is an option to "disable" those features, or at the very least keep the project private.
You can easily disable issues and either disable the wiki or make it editable only by project members, but there does not seem to be a way to disable or restrict pull requests.
> I may have missed something but where in the original article did he say he was _inviting issues and pull requests_?
It's right there on the Github project page. I don't know if Github has an option of disabling those things; it would perhaps be best if it did, but at the moment it - at the very least - implicitly invites participation.
As for other situations: is my suggestion of adding a note to the README.md problematic?
It's right there on the Github project page. I don't know if Github has an option of disabling those things; it would perhaps be best if it did, but at the moment it - at the very least - implicitly invites participation.
As for other situations: is my suggestion of adding a note to the README.md problematic?
You cannot disable pull requests on Github. You can disable the issue tracker. You could however put something in the summary shown at the top of the page that you will likely not accept pull requests.
For what it's worth, this particular library is github/linguist – a core part of github that actively requests pull requests.
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.
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.
I can understand why he didn't. He'd reveal himself as a free rider by doing so.
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.
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.
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.
[deleted]
This is failing of Github by making it hard to mark projects as open to pull requests.
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.
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.
I shouldn't waste my time making a PR if someone is going to ignore it. Really, there should also be a way of someone marking a project as "needing a maintainer" so that someone that is very interested in a project succeeding can take it over and its work can continue (including the previously unmerged PRs).
The best thing about being free of obligations is that it works both ways: you don't have to "waste your time" on making pull-requests if you don't feel like doing it. As well as author of the project doesn't have to accept it or do whatever you'd like him to do. Thinking otherwise is completely unreasonable and will only hurt yourself. Because, one more time: you cannot demand anything from somebody whom you are not paying for his work. More than that: author of the project might be maintaining it very actively, but still won't accept your pull requests. Why? Because he doesn't think that functionality you added is necessary or appropriate in his project. Or maybe your code is just messy. Or he isn't sure that suggested change doesn't open new bugs or security/performance issues. Or whatever reason it is, it's his right to decide if he wants to accept/answer/read it or not. He might even accept every single pull request out there except yours. It's his right. And your right is to decide if you are fine with it or not and if you are ready to "waste your time" on contributing or not. And for every button you'd like to be on the project menu, there is one universal button: "Fork project".
Krick you are being needlessly combative.
Some maintainers have abandoned projects and aren't going to merge a single character typo-fix. Why? Because of whatever reason they want. I never said that they have to accept it. I never said I was "demanding" shit from them. Furthermore if an author is actively maintaining it, then they should respond in a civil way to every pull request, even if it is a "decline to merge" response.
Again, what I said wasn't that I shouldn't waste my time putting together a pull request if it isn't going to be accepted. Just that I shouldn't waste my time making a pull request if it is going to be ignored. It isn't too much to expect someone to at least say "Hey, sorry I'm not writing PHP anymore so I can't really look over you PR. If someone is will to take over the project I'd be more than willing to transfer it to them." I'm not talking about rights, I'm talking about what a level of decency I expect from someone I'd accidentally bump into on the street car, and you're basically countering with: "But he has a right to be an asshole!"
I'm talking about Github and it's broken user interface. It is the main place for open source code repositories and the model is broken. Many people complain about abandoned projects, or about struggling to maintain a library they no longer use.
Github should make it easier to collaborate socially around code, and one of the ways they should do this is by stopping wasted effort in pull requests.
Some maintainers have abandoned projects and aren't going to merge a single character typo-fix. Why? Because of whatever reason they want. I never said that they have to accept it. I never said I was "demanding" shit from them. Furthermore if an author is actively maintaining it, then they should respond in a civil way to every pull request, even if it is a "decline to merge" response.
Again, what I said wasn't that I shouldn't waste my time putting together a pull request if it isn't going to be accepted. Just that I shouldn't waste my time making a pull request if it is going to be ignored. It isn't too much to expect someone to at least say "Hey, sorry I'm not writing PHP anymore so I can't really look over you PR. If someone is will to take over the project I'd be more than willing to transfer it to them." I'm not talking about rights, I'm talking about what a level of decency I expect from someone I'd accidentally bump into on the street car, and you're basically countering with: "But he has a right to be an asshole!"
I'm talking about Github and it's broken user interface. It is the main place for open source code repositories and the model is broken. Many people complain about abandoned projects, or about struggling to maintain a library they no longer use.
Github should make it easier to collaborate socially around code, and one of the ways they should do this is by stopping wasted effort in pull requests.
You can just put that in the README, or make a fork if you're not the maintainer.
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
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
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
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
[deleted]
Sir_Cmpwn(3)
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.
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.
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 ;)
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 ;)
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!
Update: this is now merged into Julia master. Thank you!
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."
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."
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 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.
Have you tried posting to the dev mailing list? You might also check out the IRC channel (#julia on Freenode).
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.
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.
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.
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.
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...
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...
> 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))
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))
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" :)
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" :)
> 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.
I was expecting a rant against shitty builds, my biggest contribution to contributing to an open source project.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.