Skip to main content
HashnodeMailman Proposal

Command Palette

Search for a command to run...

GSOC Proposal

Updated
•9 min read
T
Tanisha Dubey

My Background:

I’m Tanisha Dubey, a Computer Science and Engineering student at LNCT College currently in the 6th semester. I’m experienced in building RESTful APIs and backend systems using Python, I have solid foundation in data structures and Object-Oriented Programming. I’m a Fast learner, with capabilities of working in a group and continuously improving technical expertise.

I have engaged in MailMan community, through which I have gained hands-on exposure of mailman’s workflow and separation of permission on the basis of roles.  I have contributed through MR and technical discussions, they made me understand the contribution standards in Mailman project.

My skills:

•          Programming: Python

•          Core CS: DSA, OOP, OS, DBMS, SE

•          Backend: Flask, FastAPI

•          Database: MongoDB, SQL 

•          Tools: Git, GitHub, Flask SocketIO

•          AI/ML: NumPy, Pandas, Matplotlib, YOLOv8

•          Soft Skills: Problem-solving, Teamwork, Leadership, Communication, Quick Learning.

My contributions

1.     MR #1456: docs: Add explanation of shunting in process model

: https://gitlab.com/mailman/mailman/-/merge_requests/1456

Description

The current documentation present in architecture.rst explains the flow of message handling in Mailman but does not describe how errors during message processing are handled. The documentation also references the unshunt command but never explained shunting.

The changes add an explanation of message shunting in process model section in architecture.rst. The new section describes when messages are moved to the shunt queue, the types of errors that can cause this, and how it differs from other message dispositions such as discard, reject, and hold.

2.     MR #185: Docs: Added reference of shunt document to FAQ section

: https://gitlab.com/mailman/mailman-suite-doc/ /merge_requests/185

Description

Follow up of: mailman!1456

This change adds a FAQ entry explaining why messages may appear in the shunt queue and how administrators can handle them using the mailman unshunt command.

The FAQ entry also directs readers to the Process model section of the Mailman Core architecture documentation for a more detailed explanation of message shunting.

Project Proposal Information

·        Proposal Title (*): Improved UI for Subscription Management

·        Project size: 175 hours

Proposal Abstract (*):

1.     The problem –

Mailman 3 provides a powerful mailing list management system, and Postorius acts as its primary web-based administration interface. However, the current subscriber management interface provides only minimal information on the “List Members” page. Administrators must open each subscriber’s individual settings page to inspect subscription preferences such as delivery mode, moderation settings, or digest configuration.

This workflow becomes inefficient for lists with a large number of subscribers, as administrators must navigate through multiple pages to inspect or modify settings. Additionally, the list visibility behaviour does not clearly distinguish between lists that are private and those that should remain visible to subscribers but hidden from non-subscribers.

As a result, managing subscriber settings and navigating lists becomes unnecessarily time-consuming and confusing for administrators and users.

2.     The solution –

This project aims to improve the subscription management interface in Postorius by enhancing the subscriber list view and refining list visibility behaviour.

·       The improved UI will allow administrators to view important subscription settings directly in a structured table view, reducing the need to open individual subscription pages.

·       The project will improve navigation between subscriber profiles and subscription settings, and introduce a clearer list visibility option so that private lists remain hidden from non-subscribers while still being visible to subscribed users.

·       To improve usability for large mailing lists, the subscriber table will support filtering options similar to GitHub issue filters. Administrators will be able to filter members by attributes such as delivery mode, moderation status, role, and bounce score.

These changes will make subscription management faster, clearer, and more scalable for mailing list administrators.

Technical Approach:

1.     Allow administrators to view important subscription settings directly in a structured table view:

Example missing fields from current UI:

·        receive own posts

·        hide address

·        acknowledge posts

·        preferred language

Implementation

1.     Identify the Django view responsible for rendering the members page in Postorius.

2.     Extend the data retrieved from Mailman Core via mailmanclient to include additional subscription attributes.

3.     Modify the Django template rendering the members table to display these attributes as additional columns.

4.     Implement a horizontal scrolling table layout to support large numbers of attributes without breaking the UI.

5.     Optionally implement expandable rows for advanced settings to avoid visual clutter.

The UI will remain compatible with the existing Bootstrap layout used by Postorius.

2.     private lists remain hidden from non-subscribers while still being visible to subscribed users:

The goal is to ensure that:

·        public lists are visible to everyone

·        private lists remain hidden from non-subscribers

·        subscribers can see lists they belong to.

Implementation

Update the logic responsible for rendering the list overview page.

            Conceptually:

if list.is_public:     show_list()

elif user.is_authenticated or user_is_subscriber:    show_list()

Authenticated user will be – Superuser, List admin, Moderator, Subscriber.

3.     Filtering options similar to GitHub issue filters

Administrators managing large mailing lists need better ways to search and filter members.

This project will introduce filtering functionality similar to GitHub’s issue filters.

Example filters:

·        delivery mode

·        moderation status

·        bounce score

·        language

·        membership role

Implementation

1.     Extend the Django view handling the members page to accept filter parameters from the request.

2.     Apply filtering to the member list using Mailman Core API results.

3.     Update the frontend interface to provide dropdown filters above the table.

4.     Ensure filters work together with existing search and pagination functionality.

Filtering will be implemented at the view level, avoiding unnecessary database complexity.

Challenges I will face:

1. Efficient rendering for large mailing lists

Some mailing lists may contain thousands of members. Displaying additional attributes could increase page load time.

To address this:

·       reuse the existing pagination mechanism

·       avoid unnecessary API calls

·       only retrieve attributes required for the current page

2.  Maintaining compatibility with existing Postorius components

Changes must remain compatible with:

·       current Django templates

·       Mailman Core API

·       pagination and search features

Testing will ensure the new interface does not introduce regressions.

Current UI ---

 The current Postorius “List Members” page provides only a limited set of subscription attributes in the members table.

Vision ---

The improved interface will display important subscription attributes directly in the members table. This allows administrators to quickly inspect subscriber preferences without opening individual member pages.

Key improvements include:

• Additional subscription attributes displayed directly in the table
• Horizontal scrolling layout to support more columns without breaking the interface
• GitHub-style filtering options to quickly find members by delivery mode, moderation status, role, or bounce score
• Improved usability for administrators managing large mailing lists

3.     Benefits to the community –

This project will significantly improve usability for administrators managing large mailing lists. By presenting important subscription information directly within the members table, administrators will be able to quickly inspect and manage subscriber preferences without navigating through multiple pages.

The improvements will reduce administrative overhead and make Postorius more intuitive for both new and experienced users.

Additionally, improving list visibility behaviour will ensure that subscribers can easily discover the lists they belong to while maintaining privacy from non-subscribers. These enhancements will make Mailman 3 more accessible and efficient for communities that rely on mailing lists for communication.

Proposal Detailed Description/Timeline (175 hrs):

Phase 1 – Community Bonding & Requirements gathering (20 hours)

Week 1–2

  • Study the architecture of GNU Mailman 3, including the interaction between Mailman Core, mailmanclient, Django-mailman3 and Postorius codebase.

  • Explore the current subscriber management workflow in Postorius

  • Identify the Django views, templates, and Mailman Core REST API endpoints responsible for rendering the members list page.

  • Discuss implementation approach and finalize project scope with mentors

Phase 2 – Analysis and UI Design (25 hours)

Week 3–4

  • Analyze the existing implementation of the members list view in Postorius.

  • Identify additional subscription attributes available from Mailman Core (e.g. receive_own_postings, hide_address, acknowledge_posts, preferred_language).

  • Design the improved subscriber table capable of displaying additional attributes without breaking the layout.

  • Evaluate UI approaches such as horizontal scrolling tables and expandable rows for advanced settings.

  • Prepare a prototype layout for mentor review.

Phase 3 – Subscriber Table Enhancements (45 hours)

Week 5–7

  • Extend the backend logic to retrieve additional subscription attributes through mailmanclient from the Mailman Core REST API.

  • Modify Django in Postorius to expose the additional subscription data.

  • Update Postorius templates to display an enhanced subscriber table.

·        Add additional table columns for:

o   receive own posts

o   hide address

o   acknowledge posts

o   preferred language

  • Ensure compatibility with existing UI layout and styling

Phase 4 – Filtering and Usability Improvements (30 hours)

Week 8–9

• Implement filtering capabilities for the members list similar to GitHub-style filters.

• Add filtering options for attributes such as:

o   delivery mode

o   moderation status

o   bounce score

o   language

o   membership role

• Extend the Django view to accept filtering parameters through query strings.
• Apply filters to the member dataset retrieved from Mailman Core.
• Update the UI to include dropdown-based filters above the table.
• Ensure filtering integrates correctly with pagination and search.

Phase 5 – List Visibility Improvements (25 hours)

Week 10–11

  • Analyze the current logic controlling list visibility in Postorius.

·        Modify the list view logic so that:

o   public lists remain visible to all users

o   private lists remain hidden from non-subscribers

o   subscribed users can see lists they belong to

  • Implement the updated visibility checks in the Postorius list views and permission logic.

  • Verify consistency across list views and navigation

Phase 6 – Testing and Validation (15 hours)

Week 12

  • Add unit tests for backend changes

  • Write tests to verify correct rendering of additional subscription attributes.

  • Test integration with existing Mailman features

  • Fix bugs discovered during testing

Phase 7 – Documentation and Final Improvements (10 hours)

Week 13

  • Update documentation describing the improved subscription management UI

  • Document the new filtering capabilities and visibility behavior.

  • Address mentor review comments

  • Final code cleanup and optimization

  • Prepare final submission

29 views

Comments

Join the discussion

No comments yet. Be the first to comment.