Revision 5 as of 2014-02-10 02:23:42

Clear message

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.

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:

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.

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: and post any questions, comments, etc. to

In addition you may be able to find us on IRC at #mailman on  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.  They have some additional information (including other IRC channels and mailing lists) here:

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 for discussion!

This list is still preliminary and might change a lot within the next few days!

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

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.

Port Postorius / Hyperkitty / mailman.client to Python 3

The Mailman core will be supporting 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.

Task Level: Intermediate

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

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

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

"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.

Task Level: Intermediate

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

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

Mailman SNMP support

The idea is to add SNMP capabilities to MM. The SNMP interface should follow the FCAPS model <>. 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.

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

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

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

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. 

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.

Task Level: Intermediate

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

Administrative email message log

(Suggested by rsk)

Add a configurable set of options 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 someone really did opt-in or really did 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