[Mailman-Developers] Feedback for mailman developers

[Adrian Bye]

Hi guys,

I've copied 3 people who emailed me since May 2007 about this issue.  I
don't know any of them, they just found my post from 3 years ago on the web
and wrote to me.  Clearly its important to them since they emailed me about
it.

Guys:  I encourage you to subscribe to the mailman-developers list so you
can communicate your needs directly with the mailman development team.

The one-click unsubscribe is a critical feature for mailman and will open up
a much larger interest base.  I am not proposing 1-click unsubscribe for
discussion mailing lists such as this one - that would obviously cause
problems with people unsubscribing each other by mistake.  However a lot of
organizations use mailing list software to broadcast newsletters to their
membership.  If users cannot unsubscribe via some kind of (simple) 1-click
interface then it limits the people who can use the system and may not be
CANSPAM compliant.  The FSF is one organization that has been running a
newsletter for a while and they have had to manually handle unsubscribe
requests.  Peter Brown is copied as well as RMS and may be able to respond
if necessary.

When many users cannot unsubscribe from an announcement list (as the FSF
used mailman for) they often don't bother, instead they just hit the "this
is spam" button.  Neither the sender or receiver notices anything when this
happens.  For the receiver, future emails from the list go into the trash,
so hitting the "this is spam" button accomplished their purpose.  The sender
doesn't realise there was a problem because they never heard from the
recipient.  But the mail services know (eg hotmail/gmail/yahoo/aol) and they
begin to mark the IP address/domain of the sender as a spam sender.  This
causes future WANTED mail from that sender to go into the trash.

When we were experimenting with mailman 3 years ago, we found that in fact
mailman already has a bad reputation for email.  We found our mail was
directly going into the trash when it included mailman headers.  When we
modified mailman to send but hide the mailman headers, we got directly into
the inbox.  This testing is 3 years old, and I don't remember the specific
services we were testing to, but it included one of hotmail or yahoo.

While mailman continues not to support easy unsubscribe in the footers, it
will continue to hamper the growth of free software, as free software
organizations will not have a reliable product to mail to broadcast to
interested users.  This demand is evidenced by the emails I get every 2
months from people asking me for this patch due to my emails in the archives
from 3 years ago.

I'm not here to get into a debate - I only joined the list again to ask to
have that post removed because I'm tired of responding to these requests
which I cannot help with.

I hope this explains my point of view.  Best of luck,

Adrian


On 2/7/08, Barry Warsaw <barry at list.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Feb 5, 2008, at 4:07 PM, Adrian Bye wrote:
>
> > Hi guys (and RMS, copied),
> >
> > About 3 years ago I made this post:
> >
> > http://mail.python.org/pipermail/mailman
> > -developers/2005-February/017850.html
> >
> > As a result, I get an email every 1-2 months from people asking for an
> > updated patch.
>
> It looks to me like there are really two separate unrelated features
> here.  Distributing them in the same patch would make it difficult to
> review, discuss, test and integrate, regardless of whether they are
> good ideas or not.
>
> I would like to encourage you to develop your patches in a different
> way.  I'm not making any promises about whether they would be
> integrated if you do this, but it would make it easier for us to look
> at, and I believe easier for your to maintain separately if you decide
> to continue to do so.
>
> I would highly recommend creating two separate Bazaar branches of the
> Mailman 2.1 code.  Each would implement just one of your features.
> You could create a third branch with the whole thing if you wanted,
> but I don't think it would be necessary.  You should then register on
> Launchpad and push these branches, publishing them in a live source
> code repository for all to see.
>
> I'm really trying to encourage this style of development.  To me,
> patches living in a tracker is dead code.  With a published, public
> branch, the entire process is more transparent, we can easily do a
> merge and test if we wanted to look at it.  We can even find these
> branches easily via Launchpad.  And you will have an easier time
> maintaining them, because as new revisions get pushed to Mailman 2.1
> trunk, you can just merge, commit, and push to update your own branch.
>
> If you -- or anybody else -- has questions about this workflow, please
> ping me on #mailman on irc.freenode.net.  I will happily walk you
> through it.
>
> Cheers,
> - -Barry
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (Darwin)
>
> iD8DBQFHqvot2YZpQepbvXERAqmsAJ9H2Y9EBEIw03mDt/NPUHsL7EcYlACggzB3
> pcP+bzgjF1D1dIv89m8VLCY=
> =BC8W
> -----END PGP SIGNATURE-----
>



-- 
Adrian Bye
Tasmania Consulting Group
http://TasmaniaConsulting.com
adrian.bye at tasmaniaconsulting.com
Phone: 305-433-8188 Fax: 305-428-2665

Mailing address:
8260 NW 14th St, EPS-Y12457
Doral, FL, 33126-1502