Managing the internals mailinglist traffic

• Version: 0.9
• Date: 2008-10-31
• Author: Lukas Smith smith@pooteeweet.org
• Status: Under Discussion
• First Published at: http://wiki.php.net/rfc/managinglisttraffic

This RFC proposes a way to reduce mailinglist traffic on the internals list without making it impossible for the community to raise their concerns on this vital piece of infrastructure on PHP.net decision making.

So some core developers as well as lurking end users have noted that the traffic on this list prevents them from being able to follow this list. This is obviously a huge problem since this mailinglist is supposed to be our primary discussion and decision making tool.

I had a chat about this with Zoe, Stefan (of symfony fame) and Pierre at IPC. In this discussion I got the following idea (note that I am listing the names here in order to credit them in this idea, not because they necessarily endorse it):

What if we have two lists for internal discussions. One which is just as open as the current one and one that is moderated. People with commit karma for php-src (and maybe also phpdoc) get unmoderated access. However this obviously creates the issue that the community and newcomers will have a much harder time to get in contact with the core development team. As the list is moderated, it would require people to manually allow the given posts. This creates a bottleneck which would also create considerable work for those moderators.

Here I come to the key part of my idea. We would allow every PHP usergroup to also appoint one person that gets unmoderated access to the list. This enables members of the usergroup to feed their ideas via that person directly to the list, taking load of the list moderators and ensuring that things a given UG deem important are not lost in this process. Furthermore this intermediate step would serve to throttle the traffic and make the numbers of posters (their writing style and expertise) more easily transparent to other posters (but more importantly to the readers). I am sure this will help reduce misunderstandings and more importantly result in a more friendly tone (its just natural for people to feel overwhelmed by too large a crowd).

As a side bonus, we strengthen UGs around the world. This will hopefully lead to better communication channels between internals and active community members. It will certainly ease the organization of future testfests (or docfrenzy's) as we will then have contact people to talk to as well as more of an incentive for people to join their local UG. I would not want to try to come to a closed definition of what constitutes a UG. Lets just create an interface were people can register their UG and manage the email address for the contact person (and maybe a few other things like their website etc). People can create physical UGs as well as virtual UGs for all I care. If we notice that this liberal approach gets abused (people faking UGs to get direct access and more voting rights) we can decide on taking some protective measures. But for now lets just assume that everybody in the community understands the beauty of such a liberal approach.