That is how you end up never contributing anything or having your first pull request be rejected.
The random driveby contributor strategy has never worked for me. Most of my projects had me as their "long term" contributor or the opposite, I let one of my contributors become one.
Organization is critical to the success of a project and you're basically telling someone to forget about it and waste the maintainers time.
As a maintainer of a lot of large/popular projects, this couldn't be further from the truth. I stick that label onto things that are typically trivial and I don't want to allot much time to aside from approving/merging a PR and letting it get stuffed into the next release cycle.
That is how you end up never contributing anything or having your first pull request be rejected.
Best way to avoid having your pull request rejected, is to make sure the change is actually wanted, which you can figure out by communicating.
So if some random webapp has a button in the wrong place, don't open a PR moving the button to the right place, open a issue and confirm it's wrong, and confirm the maintainer(s) would be fine with the suggested change. If something is unclear, clear it up before spending time on the PR.
Once consensus is reached, it'll be trivial to get the PR merged.
By just using common sense one can still contribute to a project without making a huge commitment. One of the most important things to do is to check how they respond to pull requests. The vast majority of projects are positive and responsive towards them. There are some that seem to sit in limbo for various reasons but even those can later be merged into an unofficial fork and still be useful.
I've had dozens of "driveby" contributions get approved and merged. Just check the CONTRIBUTING.md if there's one and make sure your pull request includes everything the maintainer may want to know.
Comments
That is how you end up never contributing anything or having your first pull request be rejected.
The random driveby contributor strategy has never worked for me. Most of my projects had me as their "long term" contributor or the opposite, I let one of my contributors become one.
Organization is critical to the success of a project and you're basically telling someone to forget about it and waste the maintainers time.
As a maintainer of a lot of large/popular projects, this couldn't be further from the truth. I stick that label onto things that are typically trivial and I don't want to allot much time to aside from approving/merging a PR and letting it get stuffed into the next release cycle.
Also, there's a lot to learn from closed PRs.
Best way to avoid having your pull request rejected, is to make sure the change is actually wanted, which you can figure out by communicating.
So if some random webapp has a button in the wrong place, don't open a PR moving the button to the right place, open a issue and confirm it's wrong, and confirm the maintainer(s) would be fine with the suggested change. If something is unclear, clear it up before spending time on the PR.
Once consensus is reached, it'll be trivial to get the PR merged.
By just using common sense one can still contribute to a project without making a huge commitment. One of the most important things to do is to check how they respond to pull requests. The vast majority of projects are positive and responsive towards them. There are some that seem to sit in limbo for various reasons but even those can later be merged into an unofficial fork and still be useful.
I've had dozens of "driveby" contributions get approved and merged. Just check the CONTRIBUTING.md if there's one and make sure your pull request includes everything the maintainer may want to know.