Differences between revisions 5 and 39 (spanning 34 versions)
Revision 5 as of 2015-01-13 18:25:38
Size: 5314
Editor: maxking
Comment:
Revision 39 as of 2015-02-20 05:49:14
Size: 19684
Editor: terri
Comment: Adding "propose your own" again at the bottom because I suspect students will miss it.
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
GNU Mailman is hoping to participate in Google Summer of Code (GSoC) 2015 and this page consists of some of the project ideas and guidelines on how to participate. GNU Mailman plans to participate in Google Summer of Code (GSoC) 2015. This page presents of some of the project ideas and guidelines on how to participate.
Line 11: Line 11:
  * Intermediate python programming
  * Familiarity with any version control (Mailman core and Postorius uses bzr, Hyperkitty ues git) (note: this may change for MM core by GSoC if Launchpad gains git support.)
  * Python programming. You can be fairly new to Python, but you're going to have to be comfortable reading the Mailman code and asking questions if you aren't sure how it works.
  * Familiarity with any version control (Mailman core and Postorius uses bzr, !Hyperkitty ues git) (note: this may change for MM core by GSoC if Launchpad gains git support.)
Line 15: Line 15:
'''Note:''' You can use a vcs of your own choice for playing around, but we accept merge requests only through Launchpad (which uses bzr) for Mailman core and Postorius.
Howe
ver we are planning to switch to git very soon.

We encourage you to discuss your doubts with us so that we can help you get up to speed. But the more you are able to demonstrate ability in advance,
'''Note:''' You can use a version control system of your own choice for playing around, but we accept merge requests only through Launchpad (which uses bzr) for Mailman core and Postorius.  We are hoping to switch to git, but only when Launchpad switches and we don't have a schedule for that, so expect to use bzr. 

We encourage you to discuss your questions with us so that we can help you get up to speed. But the more you are able to demonstrate ability in advance,
Line 21: Line 20:
== Getting Started ==
== Expectations ==

These are a few things expected out of you, as a prospective GSoC student for GNU Mailman. Some of them are very strict and may lead to your application getting rejected or failure in evaluations, if not followed.

  * 40hrs/week on an average, the exact time may be more or less depending on the requirement of the project. You can compensate for slack in next or even previous weeks, but no less than 30hrs/week avg. would be tolerated.
  * You '''must''' mention about any other involvements (of more than a day or two) during the period of GSoC in your application.
  * Weekly progress-reports to your mentors, failing to do so can directly lead to your failure in evaluations.
  * Bi-weekly blog posts on the work you have been doing.

Also see this page for [[ https://wiki.python.org/moin/SummerOfCode/Expectations|PSF expectations]].
 
== Getting Started with Mailman ==
Line 32: Line 43:
Development work on Mailman 2.1 has been frozen for some time, so all new project ideas should be related to Mailman 3.

=== Links to Mailman3 source codes ===
Development work on Mailman 2.1 has been frozen for some time, so all new project ideas must be related to Mailman 3.

=== Links to Mailman3 source code ===
Line 42: Line 53:
All of the above listed projects are a part of Mailman Project. Your proposal may involve any one of them or a combination of more than one. All of the above listed projects are a part of Mailman Project. Your proposal may involve any one of them or a combination of them.
Line 45: Line 56:

If you're interested in participating in GSoC 2015 as a student, we suggest that you fix at least one bug for any of the projects mentioned above before submitting your application. There are several beginner friendly bugs for each of the projects listed on their respective launchpad bug trackers (Hyperkitty has separate one [[ https://fedorahosted.org/hyperkitty/ | here]]).
=== Where to get help? ===
Line 55: Line 69:
We're still discussing possible ideas for 2015, 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 [[mailto:mailman-developers@python.org|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.
If you have other idea you'd like to propose , please send it to [[mailto:mailman-developers@python.org|mailman-developers@python.org]] for discussion!  You can also look at the to-do list for Mailman 3.0 [[ ../Mailman 3.0 | here]], and see if anything is interesting enough that you would like to work on it through the summer.

----

=== A Dashboard for Admins/Owners/Moderators ===

A single page that lists all to dos in one place (subscription requests, held messages). Probably useful for owners/moderators of multiple lists. Right now, each list gets its own page so owners of multiple lists must click through each one to make changes.

This task is primarily going to be part of Postorius.

 Skills:
 Javascript, HTML.

 Difficulty::
 Easy/Beginner-friendly

 Mentors::
 Florian, Terri. All students interested in this task should discuss it on the mailman-developers mailing list.

----

=== Subscriber profile pages ===

Let users opt-in to show their membership to other
list members. Possibly along with some additional user information.
This could be useful for more private lists if you want to get an idea
who your audience is.

This task will probably span both Postorius and perhaps also Hyperkitty. (see [[https://fedorahosted.org/hyperkitty/ticket/74|HyperKitty bug 74]] and [[https://bugs.launchpad.net/postorius/+bug/1104497|Postorius bug 1104497]]).


 Difficulty::
 Easy/Beginner-friendly

 Mentors::
 Florian, Terri, Aurelian. All students interested in this task should discuss it on the mailman-developers mailing list.

 Skills:
 Javascript, HTML.


----

=== Github/development tools integration ===


Per https://twitter.com/gvwilson/status/535279362871144448 -- a tool
that will take a thread from a Mailman mailing list and turn it into a
thread on a GitHub issue. Or any kind of GitHub API integration tool
(e.g., to automatically mail a Mailman list when a repo gets a new
GitHub pull request)

This doesn't necessarily have to be github -- launchpad, gerrit, jira, bitbucket, etc. would all be valid targets. But as Github is popular and familiar to many developers, it may be a good place to start.


 Difficulty::
 Easy/Beginner-friendly

 Mentors::
 Any mentor can help with this task. All students interested in this task should discuss it on the mailman-developers mailing list.

----

=== Shared bookmarking toolkit ===

A shared bookmarking tool that listens to a Mailman list, pulls out
URLs that people mention, and adds them to an OPML file or Pinboard.

This idea by itself is may not be enough for a Summer of Code project, so interested students should brainstorm about some related tools that might be useful and discuss them with the developers.

 Difficulty::
 Easy/Beginner-friendly

 Mentors::
 Any mentor can help with this task. All students interested in this task should discuss it on the mailman-developers mailing list.



----

=== Better handling of list styles ===

Mailman can be used for a variety of different purposes: Discussion lists, announcement lists, newsletters and more. Each of those need different settings that currently need to be applied for each list separately. Note that we are NOT talking about visual styles here. This project is about functional differences in the way the lists work.

The idea of this project is to make it easier for site admins to apply certain list styles to a list (or even multiple lists at one) by providing a number of fixed templates or styles that take care of the list configuration. Ideally, this might also have a web interface (as part of Postorius?) where administrators can manage styles without having shell access to the machine.

This project will likely touch Mailman Core and Postorius.


 Difficulty::
 Easy/Beginner-friendly

 Mentors::
 Abhilash, Florian, Terri. All students interested in this task should discuss it on the mailman-developers mailing list.

----

=== Continuous Integration for Mailman Suite ===

Setting up continuous integration for all mailman projects with support for different database backends (sqlite and pgsql are a must, others should be easy to add). It should also enable developers to test their separate branch. Look up travis-ci if you have no idea what continuous integration means.

 Difficulty Level::
 Easy/Beginner-friendly

 Mentors::
 Any mentor can help with this task. All students interested in this task should discuss it on the mailman-developers mailing list.

 More reading::
  * Look into archives of mailman-developers list for previous discussions on the topic during last GSoC.
  * Buildbot - An open source testing framework (you can obviously look for better alternatives if you want).


----

=== Mailman Client written in Javascript ===

mailman.client is the client library that talks to core's REST API through HTTP. Right now we have one official client in python but it would be nice to have it in
Javascript as well so mailman could be integrated with NodeJS/IO.js.


 Difficulty Level::
 This is an intermediate level task, best suited for those having prior experience with building NodeJS applications.

 Mentors::
 Florian, others. All students interested in this task should discuss it on the mailman-developers mailing list.

 Skills::
 Some level of experience in working with Javascript is required (since it would involve a fairly good amount of JS coding).

 More Reading::
   * Source and documentation of the current [[ https://launchpad.net/mailman.client | mailman-client ]]
   * Look for REST Server documentation in mailman core.

----


=== Anonymous lists ===

When a user posts to such lists his email-address is disguised as <foo>@<bar>, and when someone replies to the same address it should be delivered back to the intended recipient.

 Difficulty Level::
 Intermediate

 Mentors::
 Abhilash. All students interested in this task should discuss it on the mailman-developers mailing list.


----

=== Dynamic Sublists ===

Dynamic Sublists is an addition to Mailman by Systers that allows the dynamic creation of topics/sublists that users can then subscribe/unsubscribe from and filter more easily.

More details can be found [[http://wiki.mailman.psf.io/DEV/Dynamic%20Sublists|on the Dynamic Sublists wiki page]]

We'd like to use dlists in Mailman 3 as a replacement for the old topics system of Mailman 2. This project is to port the existing mailman 2 code for dlists to mailman 3, which is a fairly complex task in and of itself. There was a Systers project to do this a few years ago, so you may find references to that. The project was never completed.

The existing lists code is [[https://code.launchpad.net/systers|available in Systers' launchpad repositories]]. If you find the branch with only the dlists changes (there used to be one), please link it here.


 Difficulty Level::
 This is at least an intermediate task, as the ideal student will have to follow this through Mailman Core, Postorius (to add a web interface for subscribing/unsubscribing) and Hyperkitty (to make the archives aware of the dlists). You will also need to be able to read code built for Mailman 2 and translate to Mailman 3.

 Mentors::
 Terri. All students interested in this task should discuss it on the mailman-developers mailing list.

 Skills::
 Understanding of mailing list communication. For example, you should have a rough idea of some answers to the following questions: "How do people talk on mailing lists? What sort of threads would they want to unsubscribe from? What sort of interface would work best for this?" (although be open to working with real users!)


 More Reading::
   * [[http://wiki.mailman.psf.io/DEV/Dynamic%20Sublists|Dynamic Sublists wiki page]]
   * Mailman bug "Rip out or redesign the topic system" (see [[https://bugs.launchpad.net/mailman/+bug/975705|bug 975705]])
   * "[[https://www.usenix.org/legacy/events/lisa2001/tech/full_papers/spertus/spertus.pdf|Dynamic Sublists: Scaling Unmoderated Mailing Lists]]" LISA paper from 2001 by Ellen Spertus, Robin Jeffries, and Kiem Sie. This paper describes the dynamic sublists system in detail.
   * The [[http://systers.org/mailman/listinfo/systers-dev|systers-dev]] list is a public list that uses the code, if you want to examine it on a live server. (The folk who know the dlists code and have worked with previous attempts at porting it are also all subscribed to this list.)


----

=== Build 2-3 Mailman plugins ===

Mailman 3 has a new plugin system that allows people to build rules that run before mail is delivered, but it's not entirely obvious to people how this will work since there aren't any complex plugins built yet. This project would involve choosing a couple of interesting plugins and building them both as useful pieces in their own right but also as examples for developers to build upon later.

 Some plugin ideas::
   * Spam Assassin integration. This would involve making it possible for list admins to set a threshold for their list and have Mailman discard any messages with a Spam Assassin score higher than the threshold.
       * This would involve some work in Postorius to add an interface as well as work with Mailman Core for the plugin.
       * Setting up Spam Assassin can be non-trivial, so make sure you know how to do this before proposing this plugin idea!
   * Add your own here!

 Difficulty Level::
 Intermediate or advanced, since you will be the first person to use the plugin system and will have to be comfortable with suggesting architectural changes if needed

 Mentors::
 Barry, Stephen, others. All students interested in this task should discuss it on the mailman-developers mailing list.

 More reading::
   * zope.interfaces and its implementation on mailman.

----

=== Message queue based email archiver ===

Hyperkitty is mailman's official archiver, however it would be a good idea to add an alternative to it based on message queues, either publish-subscribe or a fifo message queue. Possibly
an implementation which could be extended to use several different backends (like zeromq, redis etc) of choice would be best. (Support or thoughts on pub/sub support for other system
events in mailman would be a plus, though not necessary).


 Difficulty Level::
 Intermediate or advanced depending on the actual proposal of the student.

 Mentors::
 Aurelian? All students interested in this task should discuss it on the mailman-developers mailing list.


 Skills::
 Knowledge about message/event queues

 More reading::
   * Look for IListArchiver interface in mailman's source code.


 

----
== More ideas ==
Line 59: Line 296:
The list of projects is to appear here, hopefully soon! This is a tentative brainstorming list! Before dedicating yourself to any of these, please talk to the mailman-developers list. These are ideas that are potentially GSoC-worthy, but need more research before they could be proposed.
Line 62: Line 300:
 * Make mailman core able to localise digests and other mass mails for individual subscribers if administrators turn on full personalization.
 * Gather and surface administrative statistics in Mailman & Postorius, such as number of posts sent, # bounced, # of domains accessed, which lists are quiet and which are busy (see [[https://bugs.launchpad.net/mailman/+bug/1414169|bug 1414169]]).
 * Add audit trail for user subscriptions and user management changes. Who added them? What checks were made? [[https://bugs.launchpad.net/bugs/1414174|bug 1414174]]
 * A collection of the ideas not yet implemented from Marin's ideas lists for mailman. See [[https://mairin.wordpress.com/2010/03/16/a-rich-web-interface-for-mailing-lists/|A rich web interface for mailing lists]], [[http://blog.linuxgrrl.com/2012/03/13/mailman-brainstorm/|16 Brainstorm Ideas For Mailman’s Web Interface]] and [[http://blog.linuxgrrl.com/2012/03/14/mailman-brainstorm-2/|16 More Brainstorm Ideas For Mailman’s Web Interface]]. Note that the mailman developers and users don't love all of these ideas equally, so you definitely need to do some research on these.
   * You might also want to see [[http://groupserver.org/groups/development/messages/topic/26kwK1NFBEa46gcjtJURF1|Michael JasonSmith's commentary on how this worked for GroupServer]]

----

=== Propose your own idea! ===

You can also propose your own idea, if you think you have a great one. Make sure to talk about it on [[mailto:mailman-developers@python.org|Mailman Developers <mailman-developers@python.org>]] first, though, to make sure that it's suitable for Summer of Code, meets the needs of enough Mailman users, and has at least one mentor interested enough to commit to it for the summer.

----
Line 64: Line 316:
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 [[mailto:mailman-developers@python.org|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. The following folks are mentors and administrators for Mailman's 2015 Google Summer of Code effort.  Most mentors, even if they list addresses here, probably prefer that you post to [[mailto:mailman-developers@python.org|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.    Remember that participating in mailing lists is a very important part of being a Mailman developer, so consistent public participation on the mailman-developers mailing list will make you more likely to get hired!
Line 68: Line 322:
 * <<MailTo(flo DOT fuchs NO AT HARVEST gmail DOT com,Florian Fuchs)>> (Mailman suborg admin, nick: florianf on freenode)
 * <<MailTo(aurelien NO AT HARVEST bompard DOT org, Aurelien Bompard)>> (abompard on #mailman)
 * <<MailTo(terri NO AT HARVEST toybox DOT ca, Terri Oda)>> (terri on #mailman)
 * <<MailTo(stephen NO AT HARVEST xemacs DOT org, Stephen J. Turnbull aka Steve)>> (yaseppochi on #mailman)

Google Summer of Code 2015 Ideas Page

GNU Mailman plans to participate in Google Summer of Code (GSoC) 2015. This page presents of some of the project ideas and guidelines on how to participate.

Skills Required

These skills are appreciated but their absence in no way disqualifies anyone from participating. Specific projects may have their desired skills listed along with them.

  • Python programming. You can be fairly new to Python, but you're going to have to be comfortable reading the Mailman code and asking questions if you aren't sure how it works.
  • Familiarity with any version control (Mailman core and Postorius uses bzr, !Hyperkitty ues git) (note: this may change for MM core by GSoC if Launchpad gains git support.)
  • Ability to setup your own development environment for Mailman

Note: You can use a version control system of your own choice for playing around, but we accept merge requests only through Launchpad (which uses bzr) for Mailman core and Postorius. We are hoping to switch to git, but only when Launchpad switches and we don't have a schedule for that, so expect to use bzr.

We encourage you to discuss your questions with us so that we can 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!

Expectations

These are a few things expected out of you, as a prospective GSoC student for GNU Mailman. Some of them are very strict and may lead to your application getting rejected or failure in evaluations, if not followed.

  • 40hrs/week on an average, the exact time may be more or less depending on the requirement of the project. You can compensate for slack in next or even previous weeks, but no less than 30hrs/week avg. would be tolerated.
  • You must mention about any other involvements (of more than a day or two) during the period of GSoC in your application.

  • Weekly progress-reports to your mentors, failing to do so can directly lead to your failure in evaluations.
  • Bi-weekly blog posts on the work you have been doing.

Also see this page for PSF expectations.

Getting Started with Mailman

Here are some useful links to get you started with Mailman Development.

Mailman is written in Python. Mailman 3 core is compliant only with python3.4 and the rest of the projects work on python2 (2.7+).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 must be related to Mailman 3.

All of the above listed projects are a part of Mailman Project. Your proposal may involve any one of them or a combination of them.

Want to get involved?

If you're interested in participating in GSoC 2015 as a student, we suggest that you fix at least one bug for any of the projects mentioned above before submitting your application. There are several beginner friendly bugs for each of the projects listed on their respective launchpad bug trackers (Hyperkitty has separate one here).

Where to get help?

If you're interested in participating in GSoC 2015 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. But we want you to go through the resources mentioned above before asking questions, most of the times the answer is in there somewhere. Developers would be more enthusiastic to help you if you yourself have done some ground work.

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/2015

Project Ideas

If you have other idea you'd like to propose , please send it to mailman-developers@python.org for discussion!  You can also look at the to-do list for Mailman 3.0 here, and see if anything is interesting enough that you would like to work on it through the summer.


A Dashboard for Admins/Owners/Moderators

A single page that lists all to dos in one place (subscription requests, held messages). Probably useful for owners/moderators of multiple lists. Right now, each list gets its own page so owners of multiple lists must click through each one to make changes.

This task is primarily going to be part of Postorius.

  • Skills: Javascript, HTML.
  • Difficulty
    Easy/Beginner-friendly
    Mentors
    Florian, Terri. All students interested in this task should discuss it on the mailman-developers mailing list.


Subscriber profile pages

Let users opt-in to show their membership to other list members. Possibly along with some additional user information. This could be useful for more private lists if you want to get an idea who your audience is.

This task will probably span both Postorius and perhaps also Hyperkitty. (see HyperKitty bug 74 and Postorius bug 1104497).

Difficulty
Easy/Beginner-friendly
Mentors
Florian, Terri, Aurelian. All students interested in this task should discuss it on the mailman-developers mailing list. Skills: Javascript, HTML.


Github/development tools integration

Per https://twitter.com/gvwilson/status/535279362871144448 -- a tool that will take a thread from a Mailman mailing list and turn it into a thread on a GitHub issue. Or any kind of GitHub API integration tool (e.g., to automatically mail a Mailman list when a repo gets a new GitHub pull request)

This doesn't necessarily have to be github -- launchpad, gerrit, jira, bitbucket, etc. would all be valid targets. But as Github is popular and familiar to many developers, it may be a good place to start.

Difficulty
Easy/Beginner-friendly
Mentors
Any mentor can help with this task. All students interested in this task should discuss it on the mailman-developers mailing list.


Shared bookmarking toolkit

A shared bookmarking tool that listens to a Mailman list, pulls out URLs that people mention, and adds them to an OPML file or Pinboard.

This idea by itself is may not be enough for a Summer of Code project, so interested students should brainstorm about some related tools that might be useful and discuss them with the developers.

Difficulty
Easy/Beginner-friendly
Mentors
Any mentor can help with this task. All students interested in this task should discuss it on the mailman-developers mailing list.


Better handling of list styles

Mailman can be used for a variety of different purposes: Discussion lists, announcement lists, newsletters and more. Each of those need different settings that currently need to be applied for each list separately. Note that we are NOT talking about visual styles here. This project is about functional differences in the way the lists work.

The idea of this project is to make it easier for site admins to apply certain list styles to a list (or even multiple lists at one) by providing a number of fixed templates or styles that take care of the list configuration. Ideally, this might also have a web interface (as part of Postorius?) where administrators can manage styles without having shell access to the machine.

This project will likely touch Mailman Core and Postorius.

Difficulty
Easy/Beginner-friendly
Mentors
Abhilash, Florian, Terri. All students interested in this task should discuss it on the mailman-developers mailing list.


Continuous Integration for Mailman Suite

Setting up continuous integration for all mailman projects with support for different database backends (sqlite and pgsql are a must, others should be easy to add). It should also enable developers to test their separate branch. Look up travis-ci if you have no idea what continuous integration means.

Difficulty Level
Easy/Beginner-friendly
Mentors
Any mentor can help with this task. All students interested in this task should discuss it on the mailman-developers mailing list.
More reading
  • Look into archives of mailman-developers list for previous discussions on the topic during last GSoC.
  • Buildbot - An open source testing framework (you can obviously look for better alternatives if you want).


Mailman Client written in Javascript

mailman.client is the client library that talks to core's REST API through HTTP. Right now we have one official client in python but it would be nice to have it in Javascript as well so mailman could be integrated with NodeJS/IO.js.

Difficulty Level
This is an intermediate level task, best suited for those having prior experience with building NodeJS applications.
Mentors
Florian, others. All students interested in this task should discuss it on the mailman-developers mailing list.
Skills
Some level of experience in working with Javascript is required (since it would involve a fairly good amount of JS coding).
More Reading
  • Source and documentation of the current mailman-client

  • Look for REST Server documentation in mailman core.


Anonymous lists

When a user posts to such lists his email-address is disguised as <foo>@<bar>, and when someone replies to the same address it should be delivered back to the intended recipient.

Difficulty Level
Intermediate
Mentors
Abhilash. All students interested in this task should discuss it on the mailman-developers mailing list.


Dynamic Sublists

Dynamic Sublists is an addition to Mailman by Systers that allows the dynamic creation of topics/sublists that users can then subscribe/unsubscribe from and filter more easily.

More details can be found on the Dynamic Sublists wiki page

We'd like to use dlists in Mailman 3 as a replacement for the old topics system of Mailman 2. This project is to port the existing mailman 2 code for dlists to mailman 3, which is a fairly complex task in and of itself. There was a Systers project to do this a few years ago, so you may find references to that. The project was never completed.

The existing lists code is available in Systers' launchpad repositories. If you find the branch with only the dlists changes (there used to be one), please link it here.

Difficulty Level
This is at least an intermediate task, as the ideal student will have to follow this through Mailman Core, Postorius (to add a web interface for subscribing/unsubscribing) and Hyperkitty (to make the archives aware of the dlists). You will also need to be able to read code built for Mailman 2 and translate to Mailman 3.
Mentors
Terri. All students interested in this task should discuss it on the mailman-developers mailing list.
Skills
Understanding of mailing list communication. For example, you should have a rough idea of some answers to the following questions: "How do people talk on mailing lists? What sort of threads would they want to unsubscribe from? What sort of interface would work best for this?" (although be open to working with real users!)
More Reading
  • Dynamic Sublists wiki page

  • Mailman bug "Rip out or redesign the topic system" (see bug 975705)

  • "Dynamic Sublists: Scaling Unmoderated Mailing Lists" LISA paper from 2001 by Ellen Spertus, Robin Jeffries, and Kiem Sie. This paper describes the dynamic sublists system in detail.

  • The systers-dev list is a public list that uses the code, if you want to examine it on a live server. (The folk who know the dlists code and have worked with previous attempts at porting it are also all subscribed to this list.)


Build 2-3 Mailman plugins

Mailman 3 has a new plugin system that allows people to build rules that run before mail is delivered, but it's not entirely obvious to people how this will work since there aren't any complex plugins built yet. This project would involve choosing a couple of interesting plugins and building them both as useful pieces in their own right but also as examples for developers to build upon later.

Some plugin ideas
  • Spam Assassin integration. This would involve making it possible for list admins to set a threshold for their list and have Mailman discard any messages with a Spam Assassin score higher than the threshold.
    • This would involve some work in Postorius to add an interface as well as work with Mailman Core for the plugin.
    • Setting up Spam Assassin can be non-trivial, so make sure you know how to do this before proposing this plugin idea!
  • Add your own here!
Difficulty Level
Intermediate or advanced, since you will be the first person to use the plugin system and will have to be comfortable with suggesting architectural changes if needed
Mentors
Barry, Stephen, others. All students interested in this task should discuss it on the mailman-developers mailing list.
More reading
  • zope.interfaces and its implementation on mailman.


Message queue based email archiver

Hyperkitty is mailman's official archiver, however it would be a good idea to add an alternative to it based on message queues, either publish-subscribe or a fifo message queue. Possibly an implementation which could be extended to use several different backends (like zeromq, redis etc) of choice would be best. (Support or thoughts on pub/sub support for other system events in mailman would be a plus, though not necessary).

Difficulty Level
Intermediate or advanced depending on the actual proposal of the student.
Mentors
Aurelian? All students interested in this task should discuss it on the mailman-developers mailing list.
Skills
Knowledge about message/event queues
More reading
  • Look for IListArchiver interface in mailman's source code.


More ideas

This is a tentative brainstorming list! Before dedicating yourself to any of these, please talk to the mailman-developers list. These are ideas that are potentially GSoC-worthy, but need more research before they could be proposed.


Propose your own idea!

You can also propose your own idea, if you think you have a great one. Make sure to talk about it on Mailman Developers <mailman-developers@python.org> first, though, to make sure that it's suitable for Summer of Code, meets the needs of enough Mailman users, and has at least one mentor interested enough to commit to it for the summer.


Mentor List

The following folks are mentors and administrators for Mailman's 2015 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.

Remember that participating in mailing lists is a very important part of being a Mailman developer, so consistent public participation on the mailman-developers mailing list will make you more likely to get hired!

  • Abhilash Raj <raj DOT abhilash1 NO AT HARVEST gmail DOT com> (maxking on #mailman)

  • Barry Warsaw <barry NO AT HARVEST list DOT org> (barry on #mailman) - MM core co-mentor

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

  • Aurelien Bompard <aurelien NO AT HARVEST bompard DOT org> (abompard on #mailman)

  • Terri Oda <terri NO AT HARVEST toybox DOT ca> (terri on #mailman)

  • Stephen J. Turnbull aka Steve <stephen NO AT HARVEST xemacs DOT org> (yaseppochi on #mailman)

MailmanWiki: DEV/Google_Summer_of_Code_2015 (last edited 2016-03-24 01:40:26 by stephen@xemacs.org)