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.
- 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
- Rate limiting & throttling
- Web based and cli tools, perhaps email driven interaction
- Well Indexed and searchable
- 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.
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" (https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259782.html) which is also covered in the "perlpolicy" document (https://perldoc.perl.org/perlpolicy)