After you’ve read the code of conduct and contribution guides, you’re ready to dive in and make some contributions. Now’s a good time to make sure that you have clear expectations for how the process will work.
These general guidelines for contributors may not be spelled out in a contributing guide, but are more the result of collective wisdom gathered from working in open source for a long time.
1. They won’t fix every issue
Many, if not most, projects have limited resources, and their priorities may not align with your priorities. It’s important to keep all that in mind when you file an issue. On the one hand, opening a good issue takes time and energy. A well- written issue that describes a problem clearly with clear steps to reproduce the issue is very valuable to a project, so it’s understandable that people who write issues feel invested in them.
On the other hand, the fact that an issue may not be fixed is why we note that writing an issue is a contribution. It’s not an exchange of one thing for another, but it’s a gift. And as such, you can’t expect much in return. Good project main- tamers will thank you for filing an issue and note whether they know of any workarounds at minimum, but they do not owe you a fix. Do not take it personally if an issue you file is labeled as won’t fix.
2. They won’t merge every pull request
Submitting a pull request is the culmination of a lot of work. In order to submit a proper pull request, a developer had to spend the time to get the code working on his own machine, understand the code well enough to make a change, write the change, and then submit it.
Being disappointed when the repository maintainers then reject the pull request is understandable. Remember, though, they’re under no obligation to accept your pull request. Yes, you put a lot of time into the pull request, but they’ll have to own the code change for the lifetime of the project.
Having a pull request rejected should be a very rare occurrence. You and the project maintainers can do a lot beforehand to avoid a rejected pull request. The first step starts with communication. Before you start work to resolve an issue, comment on the issue with your intentions. Indicate your general plan of attack. Make sure that someone related to the project responds and agrees with your general approach. This communication reduces the likelihood that you go off and work on something in a matter completely contrary to the project.
Don’t stop your communication there, though. Keep it going. As soon as you have a commit or two, push it to a pull request and make sure the pull request is clearly marked as a work in progress. Marking the pull request as a work in progress lets you continue to get feedback as you go and ensure that you’re on the right path. It minimizes the time spent going down the wrong path.
Finally, make sure that you’re following all their contribution guidelines, style guidelines, and so on. This is their project, and they will own the code if they choose to merge your PR in. This is not the time and place to try to advocate for your way of working or your personal code style.
3. They don’t owe you anything
One of the biggest challenges of being a maintainer of a popular open source project is the sense of entitlement expressed by many people who use the software.
In most cases, the maintainers are all volunteers working on the project on the side. This isn’t always the case. Sometimes, they’re paid employees working on an open source project. But chances are, you are not the one paying them. They don’t owe you a feature. They don’t owe you a bug fix. They don’t owe you anything. And you should treat them accordingly.
Of course, the maintainers of a well-run project will try to go out of their way to accommodate people who participate in a project. It’s only natural that they want most people involved to be happy. Open source projects benefit from mind share and more contributors, so it’s often in their best interests to not take a hard line and try to get you that feature if it fits their roadmap and priorities and isn’t too much trouble. So it’s not wrong to ask for things. It’s not wrong to make a strong case for things you want. But at the end of the day, you don’t pay them, and they don’t owe you a thing.
Source: Guthals Sarah, Haack Phil (2019), GitHub for Dummies, Wiley.