Read on Twitter
The #Hacktoberfest time of the year has come.
We welcome *thoughtful* contributions to FOSS and would be glad to get good-quality pull requests.
BUT!
Unfortunately, there's an increasing trend of getting a lot of spam during this period of time.
cc @Hacktoberfest https://twitter.com/sethmlarson/status/1311436585909575684
We welcome *thoughtful* contributions to FOSS and would be glad to get good-quality pull requests.
BUT!
Unfortunately, there's an increasing trend of getting a lot of spam during this period of time.
cc @Hacktoberfest https://twitter.com/sethmlarson/status/1311436585909575684
Please, be mindful wrt what you submit and strive for perfection!If you are a first-time contributor, start by figuring out the contribution guidelines for a given project. It may also be useful to ask whether your contribution is something that the project would even want.
Once you've sent your PR, don't abandon it forever! There's a high chance that it needs updating. It may have some flaws that are only visible to the maintainers or long-term contributors.Occasionally, there may be something small that blocks your PR from being merged.
If your PR is good overall, the maintainers may be able to fix some minor problems by themselves and merge it. But it's not always the case. For instance, when you untick the checkbox normally allowing the maintainers to tweak the PR branch in your fork.
Another example is projects requiring that you sign a DCO, a CLA or/and sign-off your commits. These are legal blockers.
Always work with the reviewers to discuss what is the best way to get your contribution to the finish line.
Always work with the reviewers to discuss what is the best way to get your contribution to the finish line.
And follow up on *any* requests they may have. It does not always mean actually changing your PR. Sometimes it just requires a comment explaining your decision and continuing the discussion.
Sending pull requests is not the only way to contribute to FOSS!
Sending pull requests is not the only way to contribute to FOSS!
You may interact with the community, build tooling, and talk about the ecosystem. You may also *become a maintainer* yourself. This may sound unreachable but it's easier than you think. The hard part comes later when you do the maintaining. 
Whatever you mean to contribute is not always what the project needs. And the maintainer may rightfully reject such a PR. **It is not a bad thing.**
Things you send over may be unaligned with the project goals or be breaking somebody else's workflow https://xkcd.com/1172/
Things you send over may be unaligned with the project goals or be breaking somebody else's workflow https://xkcd.com/1172/
It's literally a maintainer's job to prevent such things from happening. It's also their burden because whatever they accept from you, they'll end up maintaining themselves. (Although, it's ethical to keep maintaining at least your own contribution).
Another thing to understand is that **it's okay to create a fork** (not what GitHub calls a fork but a fully separate derivative project). It may also be a good idea to have a separate extension/plugin/library project with your feature if the ecosystem allows this.
In conclusion, please remember that maintainers are human beings too. They don't owe you anything (unless you pay for the professional services or https://tidelift.com/subscription/pkg/pypi-cherrypy?utm_source=pypi-cherrypy&utm_medium=referral&utm_campaign=twitter).
A lot of spam is only going to cause their burnout faster. https://xkcd.com/2347/
A lot of spam is only going to cause their burnout faster. https://xkcd.com/2347/
Follow codes of conduct of the projects and communities that you are a part of.
Be nice to other members of the community. 
Behave. Be humane, open, considerate, and thoughtful.
-- @webknjaz
