If you want to contribute to a module, take a look at its open issues. eg. Tux recently asked for help with DBI and if you look there you will see the "Issues" link in the left nav which takes you to a list of all the open issues. I'm not suggesting that you start with such a major module as DBI, it's just an example.

Note that issues are not always about code. They may be about documentation which is equally important. That might be a less-stressful way to dip your toe in the water.

Not sure which module to help with? There is the CPAN PRC Hit List, even if it is now badly out of date. Or just ask here. Somebody will know of a module needing a little attention.

At some point you will be asked to contribute a Merge Request or a Pull Request. If you are not already familiar with git, it would be wise to have a practice with it before attempting to use it in earnest.

Thanks for your enthusiasm in contributing and good luck!

Thank you I appreciate it! I think documentation would be wise to start with that's a great suggestion. I will try to look for one I'm a bit familiar with or that I find interesting, but needs work lol easier said than done. I honestly haven't done a lot with git, but I'm pretty familiar with it as I have taken a course and dabbled a bit with it, but some actual work would kind of cement what I have already done. What does the status "stalled" mean exactly in issues, I see issues from a decade ago stalled, but without a fixed applied?

Actually the documentation is something you are uniquely qualified to improve, because experienced people lose track of what isn't obvious to newcomers. I mean, we don't want to put a perl tutorial in the documentation of every module either, but sometimes just a few extra words or a link to related content here and there can make a big difference. Lots of modules could use a few more code examples scattered throughout their docs.

"Stalled" means that progress on the issue has stalled; it may be used in different ways in different projects.

It may be that a problem was reported, but has not been possible to reproduce reliably. Or it may be that it is agreed that current behaviour is undesirable, but nobody can see a way to fix it that doesn't break something else (typically backward compatibility). It may mean that there is no consensus on whether the behaviour is a bug or not. Or it may simply be that the fix is dependent on some other work that has not been completed.

The issue has not reached a state that it can be closed, but further progress is not anticipated unless some external factor changes or someone comes up with a new idea.

Do you have any advice as far as testing or contributing to modules or getting deeper perl experience as most of what I do is related to databases, parsing and manipulating data.

What I used to do in my very early days, was go to the CPAN's most recent release list, look for distributions I might have interest in, look for bug tickets, test the interface and see if there was anything small I could do (documentation, testing etc). Another thing is once I began becoming more familiar, I would peruse distributions I was using, and do the same thing. Then I'd review distributions of the authors whom I highly respected and do the same. Slowly, I got to the point where I was fixing major bugs or adding new features. In the end, I built the confidence to start releasing my own distributions, with a whole bunch of knowledge of how I wanted to do things, simply by being exposed to how so many others did them.

I still do monitor the CPAN for new releases, but I don't have the same amount of time to work on others' software anymore (I have a whole lot of my own I do my best at maintaining), but I most definitely will open bug tickets and in some cases, write full blown fixes for problems that I find (especially if the brokenness is in the way of me completing one of my own tasks).

I started looking at others' software once I got to a point in my early Perl days where I just couldn't think of anything to create. It got me involved with other authors, helped me grow using interfaces, and helped me learn a whole bunch about coding in general.

In essence, find a piece of software you think you may like, use the SYNOPSIS code to begin testing, and read the documentation and test out the various functionality. Even submitting a patch for a missing comma is doing something. Slowly, you'll grow in confidence, and others in the community will begin recognizing you for your contributions.

Even something as opening a bug ticket that's well laid out and detailed is a huge thing for a busy author!

-stevieb

Aside from my other post, I'd like to say a few more things...

For you to be asking how to give to the community at such a fresh time is inspiring. It reminds me of my attitude and dedication during my early years. Here's a few things that helped me along the way:

• Be honest. If you make a mistake, own it. *Always* take full accountability for everything you do when things go wrong.
• Be honest. *Never* take credit for someone's work. *Always* give credit where credit is due.
• Tests, write tests before or as you write code. Your test scripts act as an API user of your software, and will help guide you toward your interface design. If you change your interface, you must update your tests, and this exposes you to what it would be like for a real user of your software (and tests are critical for regression testing).
• Documentation, write your documentation as you write your code (inline with your tests, or after your tests all pass). It is far easier to write docs as you go than it is to do so after writing an entire library. Also, if you write your docs/POD live-time, it is far more likely that it'll be accurate.
• Find your groove. Settle into a coding layout and style that works for you, but be considerate of best common practices. (I'm looking at you, 4-space indents). Learn about bracing and bracketing styles, and figure out what you like. But...
• Be consistent. Don't mix coding styles and layouts in a single file. Don't do half of a file with 4-space indents and the other half with tabs. That's just wrong.
• Answer questions. If you see a question you think you can answer... answer it! Don't worry if some narcissist gives you attitude; put forth your best response. Others who are paying attention will have your back.
• Number One: Ask questions. Never, ever, ever be afraid to ask a question, no matter how silly you may think it is. Honest. This is by far the number one rule.

Cheers,

-stevieb

ps It took me 15 years to figure out my coding style and layout to the point that it is consistent in (nearly) everything that I write from scratch nowadays. For this reason, don't be concerned about perfecting it right away. Just slowly figure out what makes code readible to you. (Note that I have slightly different styles for different languages, due to my mentioned best common practice comment, but I digress).

I love this take and your approach to optimizing yourself while minimizing overhead. This is definitely something I will need to consider.

If you can figure out how to get hold of me, I will personally mentor you on your path.

As I was typing, I was working on one of my personal projects in my IDE because of changes a corporation made to its API, reviewing issues that I'm now relieving related to my 3D printer, monitoring client stuff, and watching Harry Potter (Sorcerer's Stone).

I am going to go even one step further.

Last year, I went laterally across Canada, through Newfoundland and PEI, all the way back to BC. This year, I went from south all the way north to Tuktoyaktuk NWT (Arctic Ocean), south through Dawson City (where goldrush originated), west across the Top of the World highway to Fairbanks, Alaska, south through Anchorage, AK, to Valdez, east back through Yukon, and south again to home.

You contact me, and I'll have you (my expense) at my house and we'll work on where you are together. This is an offer that I never dreamed possible for myself, but here it is, I'm giving it to you.

If you question who I am or if my word is truth, ask anyone on Perlmonks. Not social media.

That trip sounds amazing and I can image the beauty and harshness of that terrain. I am so grateful to you for offering me such a valuable experience and honestly I never even dreamed of an offer like this for myself either and you offering to mentor me means alot to me. Perl was the language I started with and a mentor and someone to actually show me and teach me some things is something I haven't really had in regards to programming. This community has helped me alot despite my first posts being pretty inexperienced and lacking knowledge of good etiquette.

Your advice and offer is invaluable. This is something I will need to prepare for as I would want to make the most out of the opportunity and I have two kids as well so it's something I need to find the right time for as well. I'm going to follow everybody's advice to heart and work on improving more and I will reach out to you!