This is important. We need some vocabulary definitions for all different levels/aspects of "open".

Open Access, or not.

Open for contribution... or not.

Commit ownership transferals, or not.

In some cases there are whole steering committees.

The vocabulary is already there. What is out of place is the perception of where the defaults lie. Right now we seem to assume that, unless someone takes the time to write out rules explicitly saying what they're not willing to do, then they must be willing to do it.

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.

Asking the maintainer if you are allowed to provide a fix is an option?

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.

The real problem is that pull requests are the wrong form of communication. By the time someone sends a pull request they already put a significant amount of effort into their message and thus will rightfully get angry when their efforts are being rejected.

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.

>> By the time someone sends a pull request they already put a significant amount of effort into their message and thus will rightfully get angry when their efforts are being rejected.

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.

Putting in effort unfortunately doesn't mean creating positive value (https://en.wikipedia.org/wiki/The_Mythical_Man-Month).

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.

> rightfully get angry

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.

I contract for a lot of large enterprise, and I’ve written a lot of patches for open source projects in that capacity (to fix issues my large enterprise customers were having). My default position for this has always been that I’m going to get the benefit of fixing the problem regardless of whether my changes are merged. If the project maintainer chooses to merge my changes, then that’s even better, because that’s a tacit commitment from the project maintainer to maintain my changes into the future.

> a tacit commitment from the project maintainer to maintain my changes into the future

Sometimes. Depends on the norms of the project. Depends on the scope of the changes.

Of course. A lot of the time there’s not even a commitment that the project isn’t going to be entirely abandoned at some point in the future. But if you make your improvements available for other people to benefit from, you’re greatly increasing the chances that other people are also going to help maintain them (or maybe just devote some effort to avoid breaking them).

i dont think anyone submitting an unsolicited PR should be expecting it to be merged in. it's a way to convey a complete idea, not a guarantee of merging.

I do that. I sometimes prefer PRs to discuss my improvements. By the time I answer questions such as "how intrusive would this change be", "what exactly needs to be changed", "how would I test my change", I'm already halfway through the PR.

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.

No, they shouldn't be expecting anything, but a lot of people will. And that's just how it is. If we don't want people to waste their time and potentially get upset, we should write out up-front what our contribution policy is.

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.

absolutely. im on the side of documenting and reiterating to get this across.

Pull requests are the best form of communication. Have you ever had a user propose a feature, agree to contribute it, and go dark? A pull request says "I did this work, I think you might want to use it". Even for repos that aren't accepting contributions, it's better to have pull requests so that users can fork and apply PRs themselves than not have anything. Even if the original organization isn't interested in open collaboration and just wants to code dump, the community can still fix their own bugs and if it becomes frequent enough a maintained fork might appear.

That's fair, but I think there should be another feature for this that lists out the forks and the change they bring.

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.

Yes this. These days, I'm not gonna bother without communication directly from a maintainer that a PR to do whatever I'm interested in doing would be welcome and can be reviewed and merged in a decent timeframe.

This is the approach I want to take as well - but I give up so many times because I can’t track down a method of communicating with that person. I looked a while ago and I couldn’t find a way to send a message to a user on GitHub. Any recommendations on effective ways of reaching out to project owners?

It's usually fine to open an issue on the repo. It should have a detailed description of what's wrong, reproduction steps if appropriate etc, basically enough to show that you know what you're doing, have put some effort into it, and care about the project. Perhaps you'll get a response from a project maintainer, and can ask if they're open to a PR to fix it. IME, there's pretty good chances of positive engagement and eventual PR merge if you're fixing an actual bug in a good way, and not trying to add some massive new feature or completely change the way the thing works or something.

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.

rightfully -> understandibly

> Asking the maintainer if you are allowed to provide a fix is an option?

It is (or should be) a standard practice to file an issue on the repo and ask there before starting work.

Even if the repo is open to PRs, you want to make sure you're not duplicating work someone else is doing and that you have all the requirements.

> It should be just the other way around

It should not be just the other way around

The vocabulary already exists. For example, the lua project clearly states lua is free software but it is not open development, all development happens behind closed doors.

What if somebody sends you an email patch?