Differences between revisions 11 and 34 (spanning 23 versions)
Revision 11 as of 2015-01-23 18:34:06
Size: 6156
Comment: python skills, GSoC ideas
Revision 34 as of 2015-02-20 04:50:50
Size: 14332
Editor: terri
Comment: Removing the intermediate python requirement, since we're adding easier tasks, fixing sorting
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 (for instance, you can write list comprehensions, classes, subclasses, and generators, and you at least sometimes use virtual environments, even if you are not yet comfortable making your own decorators and you rarely write lambdas)
  * 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 code elsewhere in Mailman.
  * 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.
However 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 you should be prepared to use launchpad.

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.

{{{#!wiki tentative

This is a tentative list and not certain!

* Make mailman core able to localise digests and other mass mails for individual subscribers if administrators turn on full personalization
* Add new skins/themes to HyperKitty and/or Postorius
* Add GitHub API integration (to automatically mail a Mailman list when a repo gets a new GitHub pull request)
* Write a Mailman API client library in another language (e.g., Go, PHP, JavaScript, Ruby)
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.


----

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

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.

Difficulty: Easy/Beginner-friendly

----

=== 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

 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.

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

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

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

----

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

 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!)

 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.

 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

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

 Skills::
 Knowledge about message/event queues

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

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

----


=== 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
 
----

== More ideas ==
{{{#!wiki important

This is a tentative brainstorming list! Before dedicating yourself to any of these, please talk to the mailman-developers list.
Line 67: Line 192:

 * Make mailman core able to localise digests and other mass mails for individual subscribers if administrators turn on full personalization.
 * User profile pages in HyperKitty and Postorius (see [[https://fedorahosted.org/hyperkitty/ticket/74|HyperKitty bug 74]] and [[https://bugs.launchpad.net/postorius/+bug/1104497|Postorius bug 1104497]]).
 * 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]]
Line 76: Line 206:
 * <<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 code elsewhere in Mailman.
  • 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 you should be prepared to use launchpad.

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.


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.

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.

Difficulty: Easy/Beginner-friendly


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

Skills
Some level of experience in working with Javascript is required (since it would involve a fairly good amount of JS coding).
Difficulty Level
This is an intermediate level task, best suited for those having prior experience with building NodeJS applications.
More Reading
  • Source and documentation of the current mailman-client

  • Look for REST Server documentation in mailman core.


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.

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!)
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.
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
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).

Skills
Knowledge about message/event queues
Difficulty Level
Intermediate or advanced depending on the actual proposal of the student.
More reading
  • Look for IListArchiver interface in mailman's source code.


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


More ideas

This is a tentative brainstorming list! Before dedicating yourself to any of these, please talk to the mailman-developers list.

  • Make mailman core able to localise digests and other mass mails for individual subscribers if administrators turn on full personalization.
  • User profile pages in HyperKitty and Postorius (see HyperKitty bug 74 and Postorius bug 1104497).

  • 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 bug 1414169).

  • Add audit trail for user subscriptions and user management changes. Who added them? What checks were made? bug 1414174

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.

  • 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)