I was told by a project that they only want my help on a few things

Question

I am a young programmer who is interested in many many different types of projects and often start my own projects which are far too large to complete by myself so I went out and tried to find a project which matched my skill level, was using a technology that I enjoyed using, and was a product I found meaningful. After doodling around on various projects I ran across an open source program that I loved as a child and began to fix bugs as I found them or they were reported and got all of my PRs denied. I asked the admin why and they responded that they prefer that I only fix bugs with a certain label.

I really would like to continue helping this project. Is there any general rule of etiquette on GitHub or open source projects in general that I don't see? This is my first major project I helped with and I spent a large number of my free time working on it recently so am slightly angry to be told this.

Answer 1

Normally, help is very welcome. But every project has its own culture. Sometimes it's spelled out explicitly as a “Contributing” guide, sometimes it's implicit and you'd have to learn by lurking.

It is best not too invest too much effort at once. One reasonably-sized pull request at a time. This helps you to become familiar with the conventions of the project, and helps the project members to start trusting you. Reasonably sized means that you don't swamp the project with many irrelevant small changes, but that your PRs are still small enough to be reviewed easily.

Not every pull request is helpful. For example, far reaching changes, introducing a new dependency, or implementing functionality that is out of scope for a project are not generally received well. Those have to be discussed first. In general, PRs are most useful not when they expand the project, but when they fix a small problem you've encountered while using the software.

Some issues are not an invitation for a pull request. It is unusual that you would only be “allowed” to tackle specially tagged issues, but it is common that an issue requires discussions and design work rather than a bunch of code. It could also be the case that someone is already working on that issue. The maintainers might want to work on some issues themselves if these issues are very important: it is often easier to do something yourself, than it is to manage others to do that thing in the manner you wanted. Wanting to mentor other people is not the main reason why many people maintain open source software.

When you present code, make sure that it fits in with the rest of the project: that it adheres to the same coding conventions as the surrounding code, and that all tests continue to pass. If you are unsure about some decision in your code, explain that in the pull request so that this concern can be addressed.

All of these steps won't guarantee that your PRs get accepted, but they might help. And while open source contributions are nice, they're not the only way to grow as a programmer. For example, answering questions on Stack Overflow or posting a program you've written on Code Review are approaches I've used to “level up” as a developer.

Answer 2

I really would like to continue helping this project. Is there any general rule of etiquette on GitHub or open source projects in general that I don't see? This is my first major project I helped with and I spent a large number of my free time working on it recently so am slightly angry to be told this.

In general: they are the owners of the project, not you. That means they are responsible for determining what the project is, how it acts, what problems it tries to solve, how the community around it works, etc. They are the ones that users will scream at if it corrupts their data. They are the ones that will get blamed if it's difficult to implement a feature because of past architectural decisions. There is a lot more to software development than just programming, and they're responsible for all of that.

You don't have to deal with any of that, which is great! But that means you need to ask them when doing any work, because they have a larger picture. (This is the case in most businesses as well.) My general rule of thumb is to only ever preemptively do work if I'm ok it never getting used - otherwise, I talk to the project leaders first.

Answer 3

To add to @amon's answer - another consideration may be the timing. Some projects use strict development cycles (or sprints). For example, a certain development sprint may concentrate only on improvements to feature X and during that sprint changes to Y are rejected. Another example could be that a project is nearing a release and is now focusing on stability. During this phase, only bugfixes (or even only fixes to severe bugs) are accepted.