For anyone still following the other threads, I plan to make changes to Test::Reporter that will stop authors from being copied on reports. These changes will likely happen on Sunday and then I will be encouraging CPAN Testers to upgrade.
As testers upgrade, the immediate effect is that authors will stop getting notifications. However, that's a "cold turkey" approach and I've heard about as many authors complain that they don't want to stop getting emails as I've heard authors complain that they don't want to keep getting emails. I can't please all of you all the time, so these are my thoughts on how to mildly piss-off both groups while migrating to a better long-term solution. * Barbie and I are discussing a centralized email notification service. It will likely provide either an aggregate of recent reports for an author or will provide first notification for an dist/perl/arch tuple. (Come join cpan-testers-discuss if you want to weigh in with opinions as to which way it should be.) * We'll turn the email notification service on, hopefully within a week or two, tuits permitting. It will be opt-out, probably manually administered at least at first, but will restore email notification for those that never wanted to see it go away. Those who don't want email at all will probably hate us again, but at least the overall volume of mail will be way down (max 1 per day). Those that we know don't want email (like Andy Lester) we'll add to the opt-out list at the start. * We'll launch some sort of author notification preferences system. (This is also in the design stage). We'll ask authors to start confirming their desire to be notified by email --> i.e. we'll ask people to opt in * After a period of time to allow people to opt-in, the default policy for authors without a stated preference will be changed to "no mail". >From that point on, CPAN Testers will be a purely opt-in service. Hopefully, the design of the notification system will be such that people who want to innovate new ways of filtering notifications to particular distributions or platforms of interest can contribute to the code base to do so. In my view this approach has a degree of fairness to all parties: * Authors who don't want email will see substantially reduced volumes of email quickly and will have a single place to request an opt-out * Authors who do want email will continue to get notifications after a brief interruption and will eventually be forced to opt-in to continue to do so * Authors who only want notifications for some things will have no choice initially, but will be able contribute to add such features There is sufficient outrage now over email volumes that waiting for the preference system seems pointless and hopefully, in exchange for quick action now, those that are most annoyed will be willing to be patient during the transition from opt-out to opt-in. -- David
