Perl Toolchain Summit: People & Projects

The Perl Toolchain Summit (PTS) is taking place later this month in Marlow, in the UK, as previously announced. This event brings together maintainers of most of the key systems and tools in the CPAN ecosystem, giving them a dedicated 4 days to work together. In this post we describe how the attendees are selected, and how we decide what everyone will work on. We're also giving you a chance to let us know if there are things you'd like to see worked on.

This blog post is brought to you by cPanel, who we're happy to announce are a Platinum sponsor for the PTS. cPanel are a well-known user and supporter of Perl, and we're very grateful for their support. More about cPanel at the end of this article.

PTS People

The prime goal for PTS is to bring together the lead developers of the main components of "the CPAN ecosystem" and give them four dedicated days to work together. The goal is to assemble "the right people" -- for both Perl 5 and Perl 6 -- then lock them in a room and let the magic happen. The PTS is an invite-only event, to ensure there are no distractions.

The CPAN ecosystem is an ad-hoc agglomeration of services, tools, modules, and specifications, each of them worked on by teams of one or more people. It's structured somewhat like the Perl onion: at the core we have PAUSE, ExtUtils::MakeMaker and the like. Around that we have the widely used services like CPAN Testers and MetaCPAN. Further out we have CPANTS and developer tools.

This same structure is followed in deciding who is invited:

  • The core group is the approximately 10 people who maintain the core systems like PAUSE, ExtUtils::MakeMaker, Dist::Zilla, MetaCPAN, etc.
  • They nominate people who they think should attend, based on who has been doing good things on the CPAN ecosystem over the previous year. The top 10 from that list are invited, resulting in about 20 people.
  • Those 20 people go through another round of voting, and we end up with about 30 people.
  • We've had a number of experimental attendees, and the organisers occasionally invite someone who seems deserving but hasn't floated up through the voting.
  • On some years we've had remote participants, but to be honest that doesn't work so well, as the people on-site tend to get into their groove, and the focus can be quite dynamic.

Most people working on the CPAN ecosystem are volunteers, and we all know that commitment and time available waxes and wanes; people come and go. So over time the people who get invited to the PTS slowly evolves.

PTS Projects

An invite to the PTS effectively says "you're doing good things for our community, so we'd like to offer you a dedicated four days to work on them, with similar people around you". In addition to coding, it's a great chance to grab the right group of people to thrash out some knotty issue, or agree on some change to a thing going forward.

In the run-up to the PTS, the attendees start thinking about what they're going to work on, and record them on the event wiki's project page. This not only helps them organise their thoughts ahead of time, but lets people identify overlap, common interests, and interesting projects that they'd like to help with.

It also prompts people to nudge each other: "hey, any chance you could work on XYZ bug/feature, as that would enable me to …".

One of the big benefits of the PTS is the chance to grab people and discuss something at depth, possibly iterating over a number of days. This may be on how to solve some cross-system issue, work out how to take something forward, or how to make something new happen. The "River of CPAN" model came out of such discussions at this event in Berlin (when it was known as the QA Hackathon).

The first time I attended this event, I went with a long todo list. I worked on maybe half of them, worked on a bunch of things that came up during the 4 days, and went home with an even longer todo list, fired up for the coming months. I generally work at the periphery of the CPAN ecosystem, but seeing the value of this event is what prompted me to help out with organisation since my first year (and I know that the other organisers have similar feelings).

What would you like to see worked on at the PTS?

This is your chance to let the attendees know if there's something you'd like to see worked on at the PTS:

  • Is there a MetaCPAN issue that's bugging you?
  • Ideas to make life better for module developers?
  • Or better for module users?
  • A topic you'd like to see discussed?

If so, please let us know via the comments, or you can email the organising team: organisers at perltoolchainsummit

About cPanel

cPanel® is a web-based control panel for managing a web hosting account. It provides a simple yet powerful interface for managing email accounts, security, domains, databases, and more. cPanel was originally written (in Perl!) by Nick Koston in 1997. cPanel (the company) now employees over 200 people, and Nick is their CEO. They've been using Perl 5 for more than 20 years, and have long been supporters of Perl and its community. You may recognise some of their developers who are CPAN authors: Todd Rinaldo (TODDR), Mark Gardner (MJGARDNER), Nicolas Rochelemagne (ATOOMIC), and others. Their CEO, Nick, still develops in Perl today.

We are very grateful to cPanel for continuing to support the Toolchain Summit.

4 Comments

I would like to suggest similar summits for other significant parts of the Perl ecosystem. Perhaps for 'DBI/DBD', or 'HTTP' (LWP, HTTP::*, Hijk, etc), maybe even 'Logging' might get people excited?

One thing I would like to see more of is PDL. This powerful module, I feel, needs a summit of its own.

One thing I would like to see is something like a "Do-it-in-Perl" site where users who encounter a script in another language (say, in a magazine or online), sees if that script can be ported into Perl and publish that code on this site. This would 1) be a useful tutorial for newbies as well as an intellectual exercise for experienced perl developer and 2) just as importantly demonstrate areas where the Perl ecosystem is deficient, or needs modernising. It seems that Perl is squeezing itself into smaller and smaller niche areas which may be a fatal error, and one needs to retain an ability to serve the interests of the modern IOT and AI aware emergent developer.

Indeed, smaller scale is what I had envisioned when I made a suggestion. Although more open rather than invite only.

Leave a comment

About Neil Bowers

user-pic Perl hacker since 1992.