My recommendation tho of course is to find an existing project you’re passionate about, find their tracker, and dig in! Few softwares are ever truly done. Make one you love even better.
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
You can search github for labels like “needs-help” or “good-first-issue” etc. Many many projects would love help, but aren’t asking for it. Example query: https://github.com/issues?q=is%3Aopen+is%3Aissue+label%3Anee...
My recommendation tho of course is to find an existing project you’re passionate about, find their tracker, and dig in! Few softwares are ever truly done. Make one you love even better.
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.
OP could also try "good first issue" and specify Python as the programming language in their search:
Link gives a 404
github search is not available if you're not logged in to the site... works after login.
seems rather hostile. any idea what's the rationale behind it?
1) Vendor lock-in 2) GH search is resource hungry, there are older HN posts discussing this
Microsoft wants users to move away from GitHub to other alternatives.
The issue is that GitHub is a Microsoft company, a lot of people would like to help, but without having to have a relationship with corporations