GNU Mailman is hoping to participate in Google Summer of Code in 2014.  This page captures some ideas for student projects and provides information on how to get involved.

Required Skills

Incoming students will need the following skills:

• Intermediate python programming
• Familiarity with source control (Note: Mailman core and Postorius use bzr, Hyperkitty uses git)
• Ability to set up your own development environment for Mailman 

Additional desired skills may be listed with specific projects.

Note: while it is possible to use a git mirror or other tools to use git for Mailman core and Postorius development, we DO NOT RECOMMEND USING GIT for GSoC.  Merge requests need to happen on launchpad (that is the one way new code gets accepted into those projects), and previous GSoC students have found that the time required to make it all work is more than they anticipated.  (We may one day switch to git, but it won't be happening this summer.)

We're happy to help you get up to speed, but the more you are able to demonstrate ability in advance, the more likely we are to choose your application! 

Getting Started

Interested in getting started with Mailman development?   Here are some links for potential students and mentors:

• How to SPAM (Student Proposals Augmenting Mailman – 2013 version)

• Development Home

• Getting started with the Mailman web UI

• Tips for Prospective Google Summer of Code Students

Mailman is written in Python.  For developers, the path of least resistance is probably to use python 2.7+ (sadly not all our requirements handle python 3 yet) and work under Ubuntu Linux, although it is definitely possible to do development on other platforms.  You are not required to use a virtual machine for Mailman development, although many people prefer to do so.

Development work on Mailman 2.1 has been frozen for some time, so all new project ideas should be related to Mailman 3.

Other Resources for New Developers

These are "how to get involved" resources from other projects.  There are many tidbits of advice you may find useful if you're the kind of person who finds browsing for small tidbits useful.  "Somebody" should integrate the useful content and link the sources, but for now they're just linked here.

• https://openhatch.org/wiki/Contributing_to_Python

Want to get involved?

If you're interested in participating in GSoC 2014 as a student, mentor, or interested community member, you should join the Mailman Developers mailing list: http://mail.python.org/mailman/listinfo/mailman-developers and post any questions, comments, etc. to mailman-developers@python.org.

In addition you may be able to find us on IRC at #mailman on irc.freenode.org.  If no one is available to answer your question, please be patient and post it to the mailing list as well.  (We *are* the developers for Mailman -- unsurprisingly, most of us prefer to communicate via email.)

Mailman has in the past participated under the Python Software Foundation's umbrella, and will again this year.  The PSF has some additional information (including other IRC channels and mailing lists) here: https://wiki.python.org/moin/SummerOfCode/2014

Project Ideas

We're still discussing possible ideas for 2014, and they'll appear here as we sort them out.  If you have another idea you'd like to propose (either as a prospective student, mentor, or interested community member), please send it to mailman-developers@python.org for discussion!  You can also look at older idea lists linked from the [[|Development Home]] page (Sprints section, near the bottom), but do be careful – many of those ideas are now irrelevant, were rejected, or (yay!) have been implemented.

Continuous integration tool for the Mailman suite

Mailman 3 is based on different packages which are developed independently, each with their own repository and tests suite. It's not always guaranteed that these components still play nicely with each other after a new commit. It would be very useful to have some mechanism that runs a series of tests to make sure everything's not fundamentally breaking. This could start as a command line based tool, with optional integration into existing CI solutions like Jenkins.

Task Level: Intermediate

Desired skills (in addition to those named above): none

Potential mentors: (for more information, post to mailman-developers@python.org)

Postorius Responsive UI

In 2014 a web ui should be equally usable on a desktop computer as on a phone. The CSS mechanisms needed to use the same HTML for different devices are pretty well supported across browsers. Postorius should be usable on a phone or tablet without constant zooming.

Task Level: Intermediate

Desired skills (in addition to those named above): Solid experience with HTML5/CSS3/JS.

Potential mentors: Barry

Port core / Postorius / Hyperkitty / mailman.client to Python 3

The Mailman core is working torward supporting only Python 3 in the near future, so Postorius/Hyperkitty/mailman.client should be ported as well (probably supporting both 2.6+ *and* 3.3+ in order to not frustrate people who use additional Django apps that haven't been ported yet). This could either be one porting effort or separate ones for each project, but the applications are different enough that trying to do all is pretty ambitious.

Task Level: Intermediate

Desired skills (in addition to those named above): none

Potential mentors: Stephen, Barry

Design interface "themes" for specific types of list

The Mailman admin interface exposes a huge number of settings, but many lists will never use them.  We would like to have a variety of simplified interfaces specialized to various uses of Mailman. 

Some examples:

• An announcement list might require member management, management of authorized posters to the list, and moderation of list postings.
• A "simple" discussion list might require member management, moderation of list postings, changes to list description, and changes to things that might trigger moderation

Although it is possible to build entirely separate new interfaces to mailman, we realize that many people will want to just use postorius and configure it to suit their needs, so ideally we would have a way of creating these themes from the main interface.  We might also want to use this theme system for more traditional theme elements such as colours and icons.  It's not yet clear the best way to do this: we might be able to achieve it using nothing more than CSS templates (this would be very lightweight and convenient in many circumstances; a fast way for anyone to see an interface customized for their most often used options) but there may also be cases where the site admin will want to disable options in the web interface for some users and not have it possible for them to circumvent it. 

We want someone to take a look at Postorius, the current Mailman web interface, and develop several proof of concept interface themes or views as well as a more general templating system to create more such themes in the future.

Task Level: Intermediate

Desired skills (in addition to those named above): none

Potential mentors: (for more information, post to mailman-developers@python.org)

Improve Postorius' test suite

Currently Postorius' test suite consists mostly of unit-tests, using nose as the test runner. The test coverage could definitely be improved. It might also be nice to add some doctests as a developer resource. This project could also feature some interface/navigation testing, using Selenium, casperJS or similar.

Task Level: Intermediate

Desired skills (in addition to those named above): none

Potential mentors: (for more information, post to mailman-developers@python.org)

"To Do" Section in Postorius

Postorius has an inactive "To Do" section that is waiting to be filled with life. The idea is to provide the logged-in user with a list of things to do next. For instance, list owners/moderators could be notified of new messages in the moderation queue or unapproved membership requests. Users who have added additional email addresses to their profile could be reminded if confirmation is still needed etc. It would be extra nice to have some kind of indicator (nav bar?) for new To Do items that is visible on all pages.  You may also wish to look at Dardie's "Message Interface" to Mailman (developed under the auspices of the Systers org for GSoC 2013.  Ask Stephen <stephen NO AT HARVEST xemacs DOT org> for more information.)

Task Level: Intermediate

Desired skills (in addition to those named above): Some HTML/CSS skills, maybe also some JS, depending on the implementation.

Potential mentors: (for more information, post to mailman-developers@python.org)

Mailman command line client

A command line tool to manage lists, create backups etc.

Task Level: Intermediate

Desired skills (in addition to those named above): none

Potential mentors: Stephen

Mailman SNMP support

The idea is to add SNMP capabilities to MM. The SNMP interface should follow the FCAPS model <http://en.wikipedia.org/wiki/FCAPS>. What exactly that means for an MLM and MM in specific is something that has to be layed out and implemented (in parts) as part of the project. It would be interesting to know, for example, how many mailing lists there are, how many people subscribed to each mailinglist, how many non-subscribed senders send to the mailinglist etc. pp.

Task Level: Intermediate

Desired skills (in addition to those named above): Knowledge of / experience with the SNMP protocol.

Potential mentors: (for more information, post to mailman-developers@python.org)

Android/iOS/Ubuntu Phone/Cordova app for Mailman administration

Task level: unspecified

Desired skills (in addition to those named above): none

Potential mentors: (for more information, post to mailman-developers@python.org)

Full anonymization

When a user posts to a fully anonymized list, the From field gets rewritten to <bighash>@<list.dom.ain>.  Then replying to this address would forward the message to the original user.

Task Level: Intermediate

Desired skills (in addition to those named above): none

Potential mentors: Stephen

No-logging mode

Sometimes, people may want to use Mailman for mailing lists, but don't want anyone to know they're using it.  For example, they may be using it for an activist list where there is real concern about prosecution, or they may simply want to maintain privacy for their users at a greater depth.

To aid with this, we want to develop plugins and modes to support no-logging, such that a mailing list records cannot be subpoenaed.  Configuration controls for Postorius should be added, too.

The goal of this GSoC project could be a suite of privacy features and functions that allow setting them all at once (or in groups) for improved usability.  (The "suite" idea is too ambiguous and probably too ambitious for GSoC.  However, feel free to propose more/alternative privacy features!)

Task Level: Intermediate

Desired skills (in addition to those named above): none

Potential mentors: (for more information, post to mailman-developers@python.org)

Administrative email message log

(Suggested by rsk)

Add a configurable set of options, and the relevant Postorius controls, that will instruct Mailman to keep a log of

(a) all incoming adminstrative messages and

(b) all outgoing administrative messages.

(a) can be kinda sorta done by configuring the MTA to send second copies elsewhere, but (b) can't...and this really should be done inside Mailman.

The log should consist of full copies of the messages in mbox format. This is useful for debugging, for dealing with attacks, AND for proving, when necessary, that we really did receive an opt-in or unsubscribe. (By administrative messages I mean anything to -request, -owner, etc., as well as outbound subscription confirmation requests.)

Task level:  Intermediate

Desired skills (in addition to those named above): none

Potential mentors: Stephen

Mentor List

The following folks are mentors and administrators for Mailman's 2014 Google Summer of Code effort.  Most mentors, even if they list addresses here, probably prefer that you post to Mailman Developers <mailman-developers@python.org> instead of sending private mail.  That gives you the broadest exposure to all mentors (improves chance of selection, we are not going to get a slot per mentor!), and probably somebody can respond to you relatively quickly if the "obvious suspect" doesn't.

• Florian Fuchs <flo DOT fuchs NO AT HARVEST gmail DOT com> (Mailman suborg admin, nick: florianf on freenode)

• Barry Warsaw <barry NO AT HARVEST list DOT org> (Mr. Mailman and Pythonicity consultant - nick: barry on freenode, ping me on #mailman channel)

• Stephen <stephen NO AT HARVEST xemacs DOT org> = Stephen J. Turnbull (call me "Steve", my handle is "Stephen" for historical reasons, nick: yaseppochi on freenode)

• Terri Oda (PSF org admin, all hail Terri!)