MailmanWiki

Google Summer of Code 2019 Ideas Page

Mailman is free software for managing electronic mail discussion and e-newsletter lists. Mailman is integrated with the web, making it easy for users to manage their accounts and for list owners to administer their lists. Mailman supports built-in archiving, automatic bounce processing, content filtering, digest delivery, spam filters, and more. Many open source denizens will be familiar with Mailman 2.1, which is used to manage many project mailing lists. All of our current work is on Mailman 3, which was released in 2015, but there's still lots of room for new features and ideas!

Not sure about how GSoC works? Check out the GSoC student Guide

Getting Started

The GSoC student Guide has some great general GSoC information. Read it first!

Before you ask any questions about how to do anything in git or initialize your repository please read through the git howto and see if that answers your questions.

Here's a few skills that will make it easier for you to get started as a Mailman developer:

Specific projects may have additional desired skills listed along with them.

What is Mailman Suite?

In Mailman 3, we've divided up the code into a number of sub-projects. We refer to the whole package as "Mailman Suite" and there's a few really important pieces you should know:

There's also a number of smaller projects that provide the glue to make these pieces work well together, or allow them to be used separately.

All the Mailman source is now on GitLab.

Documentation & Installation

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

Mailman is written in Python. Mailman supports Python 3.5+. Each individual projects may have their own restrictions on the Python versions you can use depending on the support of the their dependencies.

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

GSoC Application Process

To be considered as an applicant for Google Summer of Code 2019, we need you to contribute at least one non-trivial Merge Request and have that accepted.

The best way to get started is to set up a local development environment, documentation for which is available here.

You can then find issues tagged with "beginner-friendly" and "easy" on our Gitlab Page. Feel free to open more issues when you find them.

Contacting us

The most successful GSoC students are the ones who work closely with the Mailman team. As you might expect from a group that makes mailing list software, our preferred method of communication is our mailing list, but we also have an IRC channel. Please do not send private messages or emails unless asked to do so or the subject is personal rather than technical, since we get a lot of similar questions and would rather the questions and answers happen in public so everyone can benefit.

Writing Your Application

You might also want to look at Last year's page

FAQ

This page might be of some help.

This question has been asked tons of times on the mailing list (mentioned above) and IRC Channel (again, mentioned above). Both of them are logged publicly and are searchable. It would be really nice to go through them once before you ask the same question again. More specific questions are encouraged and receive more attention than "How do I start?". Mentors do try hard to reply to each and every email to the developers list, but in case you don't get any replies on trivial questions, don't be discouraged. Also, in case you are a student, helping others with small problems that you know about is also a great way to get noticed. Don't worry too much about giving wrong answers, list is constantly monitored by the core developers and your mistakes would be corrected.

Issues, bugs and tests are obviously a good way to contribute. But, writing/improving documentation is another great way to contribute for beginners. It doesn't have to be a real commit or patch, write up a detailed blog post about what problems you faced while setting up mailman for development. What parts of mailman you find are difficult to understand? What are awesome things about mailman?

Note: To qualify for Google Summer of Code, your proposed project must be a coding project. That's Google's rule. Documentation and tests help to make a substantial contribution, but only count toward GSoC to the extent that they apply to your new or changed code. Additional work on documentation or testing is considered a community contribution, which is a consideration in deciding who to accept.

In most of the cases the reason for a MR to be pending is that there is either something missing or something incorrect. In either of those cases, first check the MR itself and any issues associated with it, to see if there are comment you have missed. If it's not obvious what you need to do next, contact any mentor or the org admin (maxking) and we'll look into it, or ask the relevant person. I don't mean that you do that for each one, just the ones that haven't been noticed by anyone for a *long time*. (Use your judgment as to what is "long" when there's a deadline coming up.)

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.

Moderating Emails and Threads in Hyperkitty

Hyperkitty is GNU Mailman's official archiver. However, it also supports some advanced functionality which allows users to send messages/emails through its web interface.

Moderation of topics being discussed in a Mailing List has been one of the biggest complaints on Mailman Users. Email is a very distributed and open protocol, which makes it hard to restrict users from following up on threads that have been going on for a long time and need to be shut down.

With Hyperkitty, we can tackle this problem by adding moderation actions to specific Email Headers. This allows us to moderate all the replies to a message (In-Reply-To: and References: header fields).

Requirements

Mentors

Add support for bounce processing in Core

In Mailman 3, bounces (undeliverable posts) from various email addresses are recorded. This information can be used to temporarily suspend delivery to the subscriptions of that address, alert the administrators and list owners, and/or various other actions can be taken.

There exists an implementation in Mailman 2.1.x series and can be used as a reference to implement a similar or more advanced system in Mailman Core.

Requirements

Mentors

Support for REST Callbacks in Core

Mailman Core exposes a REST API for the clients to request information from it and display that to users in their respective UI. Postorius uses the API to allow admins/list owners to manage the lists and subscribers to manage their subscription. Hyperkitty uses the API to fetch information about the new mailing lists created so that it is ready to archive emails for those lists.

The changes in the Core's database today aren't conveyed to Clients. Instead, clients which care about changes must poll the REST API , which is quite inefficient.

Core could use a pub-sub model to send out events, which Hyperkitty and Postorius (clients) can subscribe to.

Requirements

Mentors

Support for multiple wsgi servers

Mailman Core's API today runs using wsgiref, which is a reference implementation of wsgi protocol in standard library. However, there are some other more performant implementations of wsgi servers, like gunicorn or uwsgi. The intent of this project is to support running the REST API using any random wsgi server with little configuration.

Requirements

* Intermediate Level

Mentors


MailmanWiki: DEV/Google Summer of Code 2019 (last edited 2019-03-07 00:19:29 by XiaoxingYe)