Anything in particular you'd like me to take a crack at?

[tsibley]

I'm assigned PPI for the month of January's CPAN PR challenge. Do any maintainers have suggestions for something in particular? If not, I'm happy to trawl through the open issues/PRs and figure out something to hack.

[wchristian]

Haha, jeeze, you got a doozie of a dist. I've been hard-pressed for time, and need to actually sort through the current state to integrate what @moregan has been doing into a new release. Due to that i can't make a solid recommendation. But we have a plentiful issue list and if you look through it, you're sure to find something that appeals to you. :)

You can also hop on IRC and find @moregan and me in #toolchain for most of the day.

[tsibley]

Sounds good. Are RT tickets fair game too, or just those on github? I already hang out on #toolchain (and greater irc.perl.org) as trs. :)

[wchristian]

Ah, i thought i'd seen the name before. :)

One more thing that would help a lot is take RT tickets that haven't been made issues here yet, verify them, and make them github issues.

[moregan]

You could take care of #152 and #153 without much trouble, since they don't deal with parsing. The fix for #153 would need tests, too, of course. Pull request #154 adds a lot of docs to the module in question, but no code, so there shouldn't be much conflict.

A small task could be to audit the PPI classes against xt/api.t, checking for classes and methods that that aren't in the DATA section of that test file.

A pass was done over the RT queue a few months ago, and most of those tickets got GitHub issues created. A number of those GitHub issues have since been closed. There may be a handful of RT tickets that can now be closed. I don't know if creating new GitHub issues counts towards the challenge. Let me know if you want to go down this road; I can send my notes.

It shouldn't be too hard to find PPI::Token::* object methods without unit test coverage. (Several of the outstanding pull requests have added test coverage, so check against those before writing tests based on your discoveries.)

120 might be very easy if you're a toolchain hound.

If you want something bigger, would you enjoy setting up an author test that runs Perl::Critic against the appropriate files in the source tree, ensuring that there are no complaints? You wouldn't have to do the work of determining which Perl::Critic checks are appropriate for PPI; the perlcriticrc that controls which checks are done can be provided. Basic desires: 1) make target for P::C run against PPI source, 2) test in xt/ that fails if there are P::C complaints, 3) both (1) and (2) work on both Linux and Windows, 4) dependencies (on Perl::Critic, Perl::Critic::Pulp, etc.) don't cause issues for non-developers.

There's the intention of adding a PPI::Statement::Sub->attributes method, which would return a list of all the sub's PPI::Token::Attribute objects. This involves working with the PPI API a bit, but doesn't require changing tokenizing or lexing.

[moregan]

I see you've done Travis setup before. I think we'd like to have that for PPI.

[tsibley]

I submitted a PR for #120, see #162.

Travis CI setup + test fixes is #163.

[tsibley]

Thanks for the tips on what to tackle!