6156
Comment: python skills, GSoC ideas
|
21206
Fixed a few styling issues
|
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 the Mailman code and asking questions if you aren't sure how it works. * Familiarity with any version control (Mailman core and Postorius use bzr, Hyperkitty uses git). |
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 for Mailman core/.client and Postorius only through Launchpad (which uses 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 == GSoC is a big chance to hack on an open source project, work with experienced developers, learn things that you might not find in a text book, get your code out there -- and get paid for all that! If you already look at it like that then the following list of expectations will probably not trouble you. But we have to set up some basic rules for working together, and it is important that you follow them: * 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 GSoC is a full-time commitment. * We '''must''' know about any other involvements (of more than a day or two), so mention them in your application. * Your mentor(s) need to know where you stand. They are happy to spend a significant amount of time helping you -- use it! * Bi-weekly blog posts on the work you have been doing. Progress doesn't mean getting tasks done every day. There will be times where you get stuck. That's normal. Letting us know what's difficult is equally important as telling us about a cool new feature you just finished. * Regular communication with the community on our mailing list. Open source is equally about writing software as about discussing it with the community. Also see this page for [[ https://wiki.python.org/moin/SummerOfCode/Expectations|PSF expectations]]. '''Important:''' One of the biggest no-nos during GSoC is disappearing without your mentor(s) knowing about it. Communication is the only way for us to effectively measure what you are working on, so please know that not delivering regular updates will lead to a failure at midterm. == Getting Started with Mailman == |
Line 32: | Line 46: |
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 56: |
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 59: |
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 72: |
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. ---- === 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]]). Skills:: Javascript, HTML. Difficulty:: Easy/Beginner-friendly Mentors:: Florian, Terri, Aurelian. All students interested in this task should discuss it on the mailman-developers mailing list. ---- === 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! * Banned word list. This plugin would check messages against a banned word list (e.g. racial slurs, words related to discussions that need a cooling-off period) and either hold or discard messages based on what the admin wants done. * Checking for personal information. On public lists, sometimes people mistakenly post phone numbers or addresses to the list and want them removed from archives when they notice. This plugin would look for things that look like personal information (e.g. check for common phone number, email address, postal address formats) and take appropriate action (perhaps mailing the person to ask them to confirm that they really want this posted? perhaps emailing the admin? discarding the post?) * 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:: Florian, Aurelian. All students interested in this task should discuss it on the mailman-developers mailing list. Skills:: Knowledge about message/event queues and the pub/sub messaging pattern More reading:: * Look for IListArchiver interface in mailman's source code. ---- == More ideas == {{{#!wiki important 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 68: | Line 301: |
* 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 70: | Line 317: |
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. | 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 76: | Line 325: |
* <<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) * <<MailTo(24.sneha NO AT HARVEST gmail DOT com, Sneha Priscilla Makini)>> (stylistica 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.
Contents
-
Google Summer of Code 2015 Ideas Page
- Skills Required
- Expectations
- Getting Started with Mailman
- Want to get involved?
-
Project Ideas
- A Dashboard for Admins/Owners/Moderators
- Subscriber profile pages
- Github/development tools integration
- Shared bookmarking toolkit
- Better handling of list styles
- Continuous Integration for Mailman Suite
- Mailman Client written in Javascript
- Anonymous lists
- Dynamic Sublists
- Build 2-3 Mailman plugins
- Message queue based email archiver
- More ideas
- Mentor List
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 use bzr, Hyperkitty uses git).
- 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 for Mailman core/.client and Postorius only through Launchpad (which uses 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
GSoC is a big chance to hack on an open source project, work with experienced developers, learn things that you might not find in a text book, get your code out there -- and get paid for all that! If you already look at it like that then the following list of expectations will probably not trouble you. But we have to set up some basic rules for working together, and it is important that you follow them:
- 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 GSoC is a full-time commitment.
We must know about any other involvements (of more than a day or two), so mention them in your application.
- Your mentor(s) need to know where you stand. They are happy to spend a significant amount of time helping you -- use it!
- Bi-weekly blog posts on the work you have been doing. Progress doesn't mean getting tasks done every day. There will be times where you get stuck. That's normal. Letting us know what's difficult is equally important as telling us about a cool new feature you just finished.
- Regular communication with the community on our mailing list. Open source is equally about writing software as about discussing it with the community.
Also see this page for PSF expectations.
Important: One of the biggest no-nos during GSoC is disappearing without your mentor(s) knowing about it. Communication is the only way for us to effectively measure what you are working on, so please know that not delivering regular updates will lead to a failure at midterm.
Getting Started with Mailman
Here are some useful links to get you started with Mailman Development.
How to SPAM (Student Proposals Augmenting Mailman – 2013 version)
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.
Links to Mailman3 source code
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).
- Skills
- Javascript, HTML.
- Difficulty
- Easy/Beginner-friendly
- Mentors
- Florian, Terri, Aurelian. All students interested in this task should discuss it on the mailman-developers mailing list.
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
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!
- Banned word list. This plugin would check messages against a banned word list (e.g. racial slurs, words related to discussions that need a cooling-off period) and either hold or discard messages based on what the admin wants done.
- Checking for personal information. On public lists, sometimes people mistakenly post phone numbers or addresses to the list and want them removed from archives when they notice. This plugin would look for things that look like personal information (e.g. check for common phone number, email address, postal address formats) and take appropriate action (perhaps mailing the person to ask them to confirm that they really want this posted? perhaps emailing the admin? discarding the post?)
- Add your own here!
- 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.
- 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
- Florian, Aurelian. All students interested in this task should discuss it on the mailman-developers mailing list.
- Skills
- Knowledge about message/event queues and the pub/sub messaging pattern
- 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.
- 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 bug 1414169).
Add audit trail for user subscriptions and user management changes. Who added them? What checks were made? bug 1414174
A collection of the ideas not yet implemented from Marin's ideas lists for mailman. See A rich web interface for mailing lists, 16 Brainstorm Ideas For Mailman’s Web Interface and 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 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 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)
Sneha Priscilla Makini <24.sneha NO AT HARVEST gmail DOT com> (stylistica on #mailman)