Reimagining perl5-porters email list for 2021 and beyond

Let's examine if in 2021 an email redistribution list, i.e. perl5-porters@ (p5p) is still the best model for collaborating on the perl language. This is a discussion so comment below!

Advantages of an email list:

  • Familiar interface, people can use their client of choice
  • Low resources to run and maintain
  • Easy to derive automation from as email is all well known protocols
  • Everything is email

Disadvantages of an email list:

  • Email addresses disclosed to all participants (can be changed)
  • UI experience for participants inconsistent, may require client side configuration to "get right"
  • Email "reply" text can lower the signal to noise ratio
  • No topic categorization of posts, its all dumped in to your inbox
  • Tricky to respond to missed emails
  • Moderation is crude, every email is reviewed and approved, or everything is approved
  • Once an email is relayed it can't be moderated further
  • Encourages side channel correspondence
  • Everything is email

Given the long list of disadvantages we can guess why email lists (and newsgroups) have largely fallen by the wayside.

Self-hosted web forums largely replaced them, which themselves are now largely replaced by "social media" - be that Facebook pages/groups, reddit topics, stackoverflow etc. Although we can learn much from how web forums are still used by android developers etc

My own personal experience is that my current employer has all but eliminated email, seriously. I receive 2-3 emails each day which are always automated notifications and often from external sources (health insurance notifications, stockholder notices etc)
For so many of us, our professional lives are built on top of email - so imagining work without email is like imagining a new colour.

Because imagining new things is hard, let's start a discussion around requirements first and see where that leads us.

In terms of prior art- there is no shortage of "collaboration software" in 2021. From issue trackers that have bolted on kanban boards, to chat software on steroids - there are different approaches we can learn from. Perhaps we should use one of those instead? There are good arguments to be made around this.

For convenience, I will split my proposed requirements in to functional and non-functional, as well as aspirations which can help guide design choices.

Functional requirements:

  • People and automation can post content
  • People and automation can post content that has various relationships with other content
    • Reply being the most obvious relationship
  • Content can have relationships with external things (CVE notices, GH bugs, RT issues, etc)
  • Content can be tagged with arbitrary tags, allowing it to be classified
  • Content has various metadata
  • A system for voting
  • UI makes responding quick and easy
  • Personal contact details controlled by each participant
  • Moderation features
    • Moderators able remove posts from view, still visible to moderators
    • Features to correspond with moderation actions privately
    • Content is never deleted, only hidden
  • API for integration with other systems, github, irc bots, etc
  • Generalized notification system with user controls
    • Send's emails
    • Calls other API's as mentioned
  • Uses CPAN users
    • 2fa
  • Rate limiting & throttling
  • Anti-spam
  • Web based and cli tools, perhaps email driven interaction
  • Well Indexed and searchable
Non-Functional requirement:
  • FOSS code
  • Self hosted?
  • Written in Perl
  • Encrypted backups
  • Modular, so to make contributing and administering simple


  • Help prioritize urgent matters like CVE's
  • Reduce busy work for people
    • Automate and integrate with RT, GH etc.
    • Reduce unnecessary reading
    • High signal to noise ratio
  • Respect peoples privacy
  • Promote respectful collaboration
  • Promote data driven decision making
  • Modern looking interface

In my minds-eye I have something of a hybrid of Hacker News/Reddit and Asana/Monday dot com. It's hard to resist the temptation to make our own. I suspect that in just on hack-o-thon a minimum product that is already more effective than an email list could be built using on Mojolicious and GraphQL.

How would we get this thing?

I mentioned a hack-o-thon, this type of thing worked nicely enough for MetaCPAN.

TPF might reasonably call for some well known Perl consultancies for priced proposals then do fundraising activities to cover the costs. Such proposals could be milestone based or components assigned to different firms working in parallel.

Now what?

What are your thoughts? What could we add or clarify? Hopefully you have a radically different concept you can describe?


According to Neil Bowers, the purpose of p5p is "the development and maintenance of Perl" ( which is also covered in the "perlpolicy" document (


There are a few other solution issues aside from the functional aspects. If you look at p5p, a small number of people dominate conversations. It's not that they are more active, but they reply more and push their agenda more.

You shouldn't write any of this stuff yourself, and TPF shouldn't ask for bids. There's not enough money in their bank accounts to convince anyone to write custom software and maintain it, and hosting is an ongoing problem for projects. I much more about that in a response to TPF's recent survey effort. Read their various meeting notes and see how much they actually accomplish before committing them to something.

And, I think GitHub issues covers most of your requirements.

To be honest, a lot of the conversation has already moved to github. I'm not sure the rest really needs a better place.

You might be pleased to hear I created an account here. Which is where most of my stuff belongs.

If I could have boiled everything I suggested into one coherent statement it would be:

Let's create a software stack that makes it as likely as possible for someone to find a place to contribute. Engineer contribution targets for the types of people you have and make it easiest for the layers to interface (or avoid one another entirely).

Leave a comment

About Dean

user-pic I blog about Perl. I am now in California