This level of "giving back" is not trivial: I have often benefitted from seeing the source code of other projects and deciding I don't want to use the library, or seeing the code and deciding to modify it or take a different approach - or seeing the library and realizing that I wanted to try something similar, but this library shows me why I shouldn't do it. Maybe others will similarly benefit from seeing my stuff. If they see my stuff and think it's deficient, wonderful! Alter it to make it fit your needs, or use it as an inspiration for your own fresh rewrite.
But I'm not maintaining software for other people. God bless people who do; that's wonderful. But it's perfectly OK to just post stuff up in case someone else wants to use it. When people see the code on Github they think "oh I can make feature requests" or "I can send a PR." Fair enough - Github is "social coding" after all. So I just won't put code on Github.
Open Access, or not.
Open for contribution... or not.
Commit ownership transferals, or not.
In some cases there are whole steering committees.
It should be just the other way around. If a project wants contributions, for example, then they can communicate that by posting contribution guidelines in the README.
Open pull requests are better than no pull requests. If the maintainers don't want them merged to their code base, other users can still merge them to their base.
You need to contact the maintainers directly and talk with them, preferably in an informal format where it is okay for things to be forgotten or thrown out.
The fact that things are written down and recorded forever with an expectation of work is what is causing all the problems.
I'd prefer if they open an issue - or use an existing one - as a forum to discuss what they'll be doing in a PR. That way we can either reject an idea prior to someone putting in the effort, or talk about implementation so the resulting PR is more likely to be accepted.
Drive by PRs are fine if they're simple, but the ones of higher impact need more consideration.
Even more than PRs, I have mixed feelings about feature requests. Many of them are legit things that would make the software better, but with limited resources they're likely to sit for years. Is it better to let them pile up or close them? Maybe a new tag - Deferred.
The good thing with FOSS is that the effort isn't _wasted_ since that code is still around in a fork, if not in upstream.
Why? You've taken the time to fix a problem you are having in code that you are using. You've made that patch available to the upstream maintainer, but if they don't accept it that doesn't stop you (or anyone else) from doing what you want to do with the code. I don't see how you're any worse off.
Sometimes. Depends on the norms of the project. Depends on the scope of the changes.
I agree that sending a PR should not be considered a guarantee of merging. Rather an issue that is discussed with a mixture of prose and code.
Note that I'm not talking about how the world should be. I'm talking about how it is. I agree that people shouldn't just write up a PR without any prior communication with the maintainer and then expect it to get merged. But people do; that's just reality.
Or at least there should be a clear way to indicate on a repo, PRs are not looked at and won't be merged. So if you make a PR you understand all you're doing is just advertising your fork.
If it's excessively difficult to find a way to communicate with a project maintainer, well, maybe there's your sign that this is not a good project to contribute to.
It is (or should be) a standard practice to file an issue on the repo and ask there before starting work.
It should not be just the other way around
I do wish people weren't completely closed to PRs though. I think companies are often misled when they think they'll get free labor out of open source, etc. and I think the free-as-in-libre aspect is more important relative to community aspect than a lot of people, but still - I hate it when my only option if I want a bug fixed is to wait for the company to do it themselves or fork. Even if I have to sign over all my rights of the code, I'd so much rather they at least consider taking my PR and be done with it. They don't have to do it for features they don't like or fixes that have downsides. But for a straightforward fix, at least look at it. It might be all the free help you ever get from the community.
Even if people sign over the rights, there can still be admin to prove that they have those rights to sign over in the first place, or the responsibility for any fall-out if it turns out they didn't later, which some will not want to take on.
Also, some projects are personal and while the authors are perfectly happy to share they want to keep their version theirs, as in entirely created by them. People release their code open source for a variety of reasons, sometimes contributions back in that manner are not actually desired and we shouldn't take offence at that (it isn't intended to raise offence).
> ought to be made very clear in README.md or CONTRIBUTING.md or something too
This is a large part of the answer, I'd agree with you there.
The default assumption on github, and more generally, is that contributions are likely to be welcome and in fact actively desired. Politely explaining that this isn't the case in obvious places removes the confusion (and if someone hasn't read the usual places before submitting the PR that is their mistake not something to blame the project owner for). A sentence or two of text, as seen in the example that started this thread, in the README or similar documentation, should be sufficient. Perhaps also add it to the LICENSE file if you think that is more likely to be checked than someone reading the whole of the README (though if the readme is long enough for that to be a significant issue, perhaps look to streamline it and move some detail off to supplementary files).
I think you're missing an important point here: the right to fork is the primary point of Open Source. Sure, it's nice if you don't have to fork, but ultimately the reason Open Source is important is so that you can fork if you have to. The other parts, about projects being able to accept contributions from others and so on, are nice to haves, but not essential. The right to fork is what is essential, so that when a project has a bug, and the project owners aren't fixing it, which is expected to be the most common case (see below for why), you, as an individual, can at least fix the bug for yourself, instead of being stuck with a proprietary system with a bug you can't fix at all.
Why is it expected to be the most common case that the project owners won't fix the bug? Because the tradeoff between benefit and cost from the project's point of view is very different than it is from yours. For you, it's much easier, as you say, for the upstream project to accept your PR than for you to have to maintain your own fork. But from the project's point of view, it's much harder to accept your PR than to just ignore it. Sure, you might be convinced that you've fixed an important bug and your code will be a net gain to the project. But how do they know that? To them, you're just some random person on the Internet. It's not like they have people sitting around just waiting for random people on the Internet to make contributions. Any time spent on evaluating your code is time not spent on something the project has already committed to doing. And if they aren't feeling any pain from the bug themselves (which they won't be if you, a random person on the Internet, have had the time to see it and code a fix for yourself), fixing it won't be on the list of things they are already committed to doing.
The parent poster was talking about submitting a Pull Request. In other words, contributing the work for free. I suppose expecting someone to look at it might be asking them to do something for free, but if that's a problem then I agree that Github should have the option of not having the button on a project at all.
Or maybe you thought PR stood for Problem Report, in which case expecting it to be looked into by someone is an expectation of free labor.
Free Software is about the freedom of the user - freedom to distribute, freedom to study, freedom to use, freedom to modify. Somehow people have managed to pervert this so that it not only means "free as in free beer so that I can use it" but even "free beer so that OTHER PEOPLE can do work that I want done, for free." There is absolutely no entitlement to this.
I could fork a project and make the fix in my own repo. In fact you have to do that to make a pull request. I even specifically lay out scenarios where I absolutely agree it's not a good return on time invested for the maintainers to bother. But if I forked an open-source project every time I had a bug fix that required time from the maintainer that's worse for everyone. My point is that even though I fully understand and support where the litestream policy is coming from, for anything beyond a personal project I think some flexibility in accepting outside contributions is a win for everyone. I'll do all the work I can without having rights on the project. I'll sign over all my rights. Have tests? I'll run them and post the results. But a rigid "love it or fork it" attitude is a lose-lose.
Who is 'everyone'? Does that include the maintainer? If so, why is it worse for them?
> a rigid "love it or fork it" attitude is a lose-lose.
How so? Who exactly is losing, and what exactly are they losing?
edit: And to be clear, I freely acknowledge the inverse in my original comment. As TFA explains they were seeing a lot of PRs with unintended side-effects that were complex and counter-intuitive. At no point have I said people MUST accept this as part of the terms of a copyleft license as the original replier seems to think. I used phrases like "I do wish" and "I'd so much rather" and "They don't have to", so obviously it's preference I have. But that's my preference as not only a user of open-source software, but as a committer / PMC member on multiple Apache projects and other open-source projects. It's not remotely coming from a position of entitlement for free-as-in-beer software or ignorance of what it takes to develop and maintain open-source software.
They can still benefit from it by getting the fixed version from the PR author.
> the PR author who can continue using the same version as everyone else,
In other words, the PR author is expecting the maintainer to do the work of upstreaming and supporting their (the PR author's) fix for free.
> and yes, the maintainer who is foregoing even the possibility of the fix without starting from scratch.
And that is their prerogative. If they actually really want that fix they can always get it later. But as said by OP, chances are really good that the way the fix was done would conflict with the direction they want to take the project. And that would actually be a net loss for the maintainer.
> As I said in my comment, it makes total sense to me to look at a major change or a risky fix and say "no this isn't worth my time". But I'm sure we've all had those bugs where they take forever to track down until eventually you find a simple problem in code that is obviously an error. To not even take a look at it, as a rigid matter of policy? Yes, I absolutely think open-source maintainers would be missing out on saving some larger efforts.
This basically boils down to, expecting an open source maintainer to do the work--for free--of maintaining other people's patches in a patchwork codebase that they no longer have total control over.
That doesn't make a lot of sense. To create a pull request, one must have already done the work to fork the repo themselves. The pull request is an offer to contribute that work back. If the project owners cannot or do not wish to do the work to even triage pull requests, that's fine, but in that case it's pretty clear that a public GitHub repo is the wrong place to be.
In fact, if you only look at the "issues" framework, GitHub does a pretty good job of making things easy to use compared to the other bug trackers...
I'm not the one to defend GitHub, but what's the big deal about not accepting pull requests? If you clearly state that you won't accept PRs and somebody still sends them, then you can close them right away and problem solved. Am I missing anything?
Another issue is that the github pull request model is not very "gitonic". There are much saner systems like sourcehut.
Yes. The "reduce the stigma" part. Having users open a PR to just get it automatically closed by a bot (which also needs to be set up) it's far less welcoming than NOT having at all a "Pull requests" tab where you can open said PR.
That said, I agree with the idea of simply removing the possibility to make external PR's. The possibility to view (internal) PR's must be there though, so that external viewers can see PRs from the mainainer(s).
I don’t think optimizing for that edge case makes a ton of sense. Having the ability to hide PRs might be a nice feature, but some people use that for stuff other than straight pull requests.
A few of those who didn't read the README, and get their PRs auto closed, might get upset at the maintainers, and write something a bit angry, making it less pleasant to be a maintainer.
You can easily do that, but what you can't do is prevent people from being angry. You can do everything in your power to prevent people from accidentally wasting their time, and you should. This is where "hide the feature" would come in.
> Really fuck em if they’re gonna stay butt hurt about it.. this should have been cleared up in kindergarten.
Such an attitude from a maintainer can piss people of and make them write angry things to the maintainer, causing him/her to quit.
Also, I remember a case where after some time someone decided that since the maintainer was not answering, it was fine to add insults and threats.
Oh please, only somebody with a ridiculously thin skin would be offended by seeing rejected his PR to a project that clearly states that does not welcome outside contributions.
I'm quite angry because I spent time investigating this problem and now it won't be fixed and it is not logical and I've lost my time.
Obviously one needs to be judicious with this, but I've scored some big wins from this. In addition to bypassing projects who don't want to accept the (IMHO) perfectly reasonable contributions, I've also some cases where the upstream project shouldn't accept my changes and I shouldn't submit them. I've got one case where I forked a package and essentially twisted it so hard that it destroys it for its original purpose, even though it now does exactly what I need. A couple of others where the upstream is obviously dead. Another case I can think of where in principle the upstream could accept it, but it adds a subtle and easy-to-misuse feature to the package that I understand fairly well having written it, but would really encourage users to mess themselves up and is hard to document properly, so I probably won't ever submit it.
It's not something I do all the time by any means... the above paragraph describes nearly all the cases where I've done it. It's 3 or 4 in as many years. But each of them was a fairly large win.
You'll then have to maintain the fork, re-applying your changes whenever the upstream repo is updated
I don't understand the anger, are you angry because he doesn't have the same opinion as you and doesn't want to make the implementation behave according to your opinion?
I guess the lesson is that there is always someone angry over something unreasonable.
People like that are very common and often very vocal.
In order to keep the IP for a project pristine (for the sake of downstream users), I would prefer never to see somebody else's copyrighted solution to a problem. If I see their contribution but I don't want to accept it, I'm forced to come up with a new creative solution that a court would (maybe, hopefully) consider original.
This is especially important for CC0/public-domain projects, where many contributors will not fully understand the implications of contributing and may not be in a position to release code into the public domain.
You are doomed, then. They can always sent a (unrequested) email to you, Cc'd to a public mailing list. The PR interface is just another equivalent way for people to send messages to you, like email.
The Github Pull Request interface is an attractive nuisance, like an unfenced swimming pool. You can't keep people out with warning signs, they won't read them. Put up a fence, though, and even the obtuse will get discouraged.
I don't want to have to set up an auto-close bot when I should be able to just untick a checkbox in the project's settings.
I don't want to have to click through PR notifications and manually close them when I should be able to just untick a checkbox in the project's settings.
That is an interesting observation. Can you elaborate on what you mean? Thanks!
https://docs.github.com/en/github/building-a-strong-communit...
I thought everyone filed PRs this way; is there another workflow I haven't heard of?
[1]: It takes you to https://github.com/$upstream/$repo/compare/master...$you:$br...
If so, one possible solution is to maintain the primary repo elsewhere (Source Hut, Gitlab. wherever), and run a sync routine on a cron (or perhaps every push):
1. unarchive Github mirror repo
2. Push changes from primary repo to Github mirror
3. archive Github mirror repo
There's a race condition where someone might see the unarchived repo and start a pull request during the brief period where the sync is taking place, but the possibility that they'd both start and then fisish a pull request during sync periods seems remote.
Which hack you would choose depends on how important it is never to see pull requests (e.g. for IP reasons as described elsethread).
As a maintainer you are free to close my PR, or work togheter with me to bring it in line with your project standards.
Repo -> Settings -> Moderation Settings -> Limit to repository collaborators
It's more of a workaround than a solution, and depends on how much you trust GitHub Actions, but this one will autoclose all issues and/or PRs.
https://github.com/marketplace/actions/repo-lockdown
> Best solution is to keep code somewhere other than github. Is sourceforge still around?
Aside from Sourceforge and self-hosting (simply via gitweb, or with GitHub-like features in Gitea, Phabricator), there are the big ones like GitLab and Bitbucket, cloud repo services on AWS and Azure, and smaller/indie services like Sourcehut (sr.ht), Launchpad, and RhodeCode.
The way I explain it is you know how when your computer illiterate parents ask you to do some simple task that you have literally no idea how to do, but you look at some menus that have vaguely similar sounding titles based on your years of building up intuitions about how computer UIs work, click those menus, find what you need and do the task? GitLab breaks all those intuitions so easy tasks become hard.
YMMV, of course.
I've been using Sourceforge recently and am pretty happy with it overall, though it's still very alpha quality.
Will it be at the top? Down the side? Tab based? Drop downs? Who knows!?
Meanwhile, Github's UI is so stable (outside of the super infrequent redesigns) you basically develop a muscle memory for it.
Honestly I'm not sure how you could even be confused by it as an individual developer either. I used it for my individual projects before getting a real development job and didn't have any issues. It different to github but not worse or less correct. Its just github has become the standard on what the default layout and names should be.
You can find it in the project settings in the "sharing and permissions" section: https://docs.gitlab.com/ee/user/project/settings/#sharing-an... You can also disable the repository feature, and use the project for issue management only.
IIRC, you must be owner of the project.
How about just stating in README about your PR policy in big letters? And if then people get angry because they were too lazy to read, .. well you cannot and should not please everyone.
Anyway, and what bothers me with GitHub is Microsoft, even though so far I cannot really complain. At least they have not sneakily bundled adware with OSS installers, like sourceforge did. So they really lost all reputation and trust for me and are never a alternative again. I rather go with microsoft and that says something.
https://docs.github.com/en/github/creating-cloning-and-archi...
I'm not sure if a mirror repo actually blocks pull requests. Check with GitHub Support for more information:
Also mind: Even if pull requests are off somebody else might emerge and maintain a fork, which becomes more successful. Maybe even going as far that that the original owner can safely outsource the maintenance of the thing he created.
The minute they become just another dumb git host, their relevance disappears.
How do you get locked in? PRs, once merged, are just regular commits. You lose the history and discussion around the PR itself, but that's all, but it's not like any alternative allows you to migrate ( e.g. the abomination that is using email for git collaboration is stuck in unreadable, unsearchable, unindexed emails somewhere; you can copy the data pretty much the same way as from GitHub, but both are unexploitable without a lot of tinkering / adaptation)
If you don't, and you submit a PR, you should expect the PR to be closed with a "Unfortunately, this change was not discussed. As a result it may clash with other efforts underway, or our future roadmap. Also, not having discussed it prior to the PR increases the suspicion that you have not followed our coding guidelines. Consequently this PR is closed. Please propose the change on the mailing list and take part in the discussion before revising this patch and resubmitting the PR."
Because of this I think an auto-close is fine. I also do think Github should allow disabling the PR tab.
I think that spending more of a weekend in a PR without checking before with the maintainers is a bad idea, because there is a big risk that is not merged and is a waste of time.
Also, each project has it's own weird rules, like code style, space vs tabs, changing whitespace in unrelated lines, adding tests, ... and a long list. Some are written explicitly, and some are just implicit rules. So sometimes it's difficult to make a PR that follows all the rules.
Every rule has exceptions, and this is definitely one for the rule I described. Thank you for pointing reminding me and clarifying.
More people need to realize that Open Source projects are a gift from the authors to the software community. Other developers do not have the right to make changes, push for the development to go in a certain direction, etc. If an author wants that they'll turn stewardship over to a committee and maybe be part of such a committee. You have only two rights with Open Source work you want to work differently: fork it or forget about it (i.e., not use it). Anything else is a massive gift from the maintainer(s) and should be viewed as such.
And yeah, as you can tell from the last paragraph I'll proudly wear an Arsehole button to avoid wearing a Burnout button. Heck, to borrow from Bruce Lee in Snowcrash, I'd even wear a "12 Gauge" button to avoid burnout (button only though, the behavior is not for me).
https://aws.amazon.com/codecommit/pricing/
"Our transaction and storage quotas are designed to handle the most common developer workflows without incurring overages. For most workflows where CodeCommit users are manually using Git operations, these quotas are rarely breached."
"$0.001 per Git request"
I need an option that is limited to $5 a month, with DDoS being their problem.
DDoS is always their problem. AWS and co always waive charges due to attacks or significant errors on user's part ( e.g. writing an infinite loop that results in a huge bill)
It goes beyond bug trackers, too. One other detail is that different projects can share resources with one another. I use one mailing list to slurp up all patches for my smaller side projects into one place, for example.
I'm still pissed at Filezilla for jumping on that particular adware bandwagon though...
https://github.com/isaacs/github/issues/1191 3 years and counting.
Some people are resorting to adding bots which auto-close PRs with a message like "Sorry, I'm not accepting PRs at this time", but that only triggers once the person has put in the effort to patch your project, at which poi t they may get annoyed to be suddenly told that PRs aren't welcome.
Best solution is to keep code somewhere other than github. Is sourceforge still around?