I have been cleaning up in my TODOs over the weekend. Monday is a national holiday in Denmark, so it has been a nice long weekend, with room for chores, dinner with friends, cleaning, gardening and of course open source software development.
This has resulted in a few maintenance releases and a lot of commits to my GitHub repositories.
I had some outstanding PRs I needed to review, one was a change to a Perl::Critic policy I implemented some time ago, about two years to be exact. (Please see the blog post) related to the policy: Perl::Critic::Policy::InputOutput::ProhibitHighPrecedentLogicalOperatorErrorHandling.
A kind developer, Nathan Mills, had taken the time to address a question I had raised in my own repository, but had somewhat forgotten about and had left a PR updating the documentation and the test suite and answering the question I had posed.
Is the policy relevant for two-argument variation of open?
The question was yes and Nathans PR demonstrated this with tests and documentation.
The PR from Nathan had been pending for some time. I really wanted to merge the proposed changes, the issue to me was that the policy had never been adopted into the Perl::Critic core distribution, together with another policy I had also created earlier: Perl::Critic::Policy::RegularExpressions::RequireDefault.
For Perl::Critic::Policy::RegularExpressions::RequireDefault I had actually released it to CPAN, but I was hoping on getting the policy adopted in to the core distribution. Where as Perl::Critic::Policy::InputOutput::ProhibitHighPrecedentLogicalOperatorErrorHandling was only available on GitHub.
Last week I wrote a blog post touching on the topics of contributing to significant projects instead of just releasing for yourself and hoping that somebody accidently discover your project and use it and perhaps even contribute back.
Contributing to more significant repositories hold some benefits to rolling your own, such as:
- Your contribution get more visibility
- You feel you provide value by contributing back to a tool you might use and enjoy
- You feel a part of a community
- You boost your developer confidence, because you are actually able to contribute to a project involving developers, which are much more skilled than you
- You contributions get more attention and this might be good for your CV
All of the above points are very subjective and therefor the backfire of not having your contribution accepted, can feed to your inner imposter. But as we all know with imposter syndome, it has to be ignored and we have to evolve beyond it. This sounds easy, but can actually be quite challenging and exhausting.
I gathered that at least the release of this policy would benefit somebody, since Nathan had proposed changes and another user had commented on my PR. So instead of laying dormant in a PR queue I could just release the policies as stand-alone policies.
I retracted the two PRs I had outstanding with Perl::Critic:
- "First shot at PR for new policy: ProhibitHighPrecedentLogicalOperatorErrorHandling"
- "Adoption of existing (new) policy Perl::Critic::Policy::RegularExpressions::RequireDefault"
Do note - I have no issues with the Perl::Critic distribution or it's maintainers, I just could not wait any longer and I wanted to make Nathans PR valuable and worthwhile and Perl::Critic::Policy::InputOutput::ProhibitHighPrecedentLogicalOperatorErrorHandling has just been uploaded to PAUSE/CPAN and should be available for you to use.
If you experience any issues or have any ideas for improvements, do not hesitate to contribute via GitHub.
Thanks to Nathan Mills for his contribution included in this second release, but first release to CPAN of Perl::Critic::Policy::InputOutput::ProhibitHighPrecedentLogicalOperatorErrorHandling.
Top comments (0)