5

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.

  • 2
    What did they actually say? Can you provide links? There is almost certainly an underlying reason, not just that there are things with certain labels. For instance, you might be fixing bugs that they don't actually consider to be bugs, or otherwise don't fit into their product vision, so they're asking you to only work on things they've already triaged and determined they want to fix. – Xiong Chiamiov Dec 2 '17 at 18:38
  • I'd rather not share the actual project but the gist of it is that I was fixing minor design/UX issues (missing borders, layout quirks, etc) and they wanted for me to fix bugs in the JS part as opposed to the CSS part. – dalearn Dec 2 '17 at 22:39
  • They seriously would mark ~1 out of 25 reported bugs (the harder ones to fix) as "help wanted" and wouldn't take any other contributions. – dalearn Dec 2 '17 at 22:40
  • Did you consider that you might have been fixing issues that would disappear if you fixed the issues you were pointed to? Anyway, without links to the actual discussion all we can do is guesswork. – Michael Schumacher Dec 3 '17 at 21:39
  • One of the great things about FLOSS is you can use the version that you’ve fixed up. Don’t let it discourage you. There’s nothing wrong with keeping a personal fork and occasionally pulling from upstream if they’re not interested in your patches. – RubberDuck Dec 9 '17 at 23:52
6

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.

3

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.

2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.