in reply to Tips on contributing to the community?

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!


🦛

  • Comment on Re: Tips on contributing to the community?

Replies are listed 'Best First'.
Re^2: Tips on contributing to the community?
by MoodyDreams999 (Scribe) on Aug 29, 2024 at 18:39 UTC

    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.

        That's great to know that I can bring a semi-unique perspective on something like that and yeah, I have experienced some of it while trying to get a task done, but didn't really think about it in that way before of how I can improve it. Some of documentation is actually some low hanging fruit that would be pretty valuable. I appreciate the new perspective!

      "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.