Hi all,
The GNU Mailman Project is applying for Google Summer of Code 2026[1]. Our Ideas Page[2] has been updated. We're still open for mentors, of course, and ideas. There's no deadline, but to be most useful it would be helpful to have these suggestions by February 19 when Google announces selected organizations.
Summer of Code projects must involve substantial amounts of new code. The effort involved should be 150 to 200 hours (although programmers' skills may be anywhere from "novice" to "10x", so the amount of code can vary more than that!) Projects which are primarily documentation, user interface skinning, or tests are usually ineligible. Please send those to me by email or on this list if you think the idea would be of interest to other Mailman users, or might trigger suggestions for improvement from them.
We are also interested in "tiny" tasks which are suitable for demonstrating interest and making the applicant familiar with our review process. If you have some minor annoyance (whether bug or missing feature) that you think might take an experienced Mailman dev an hour, this is a good chance to get some eyes on it. For these it would be most helpful if you file an issue on the relevant project (usually core[3], Postorius[4], or HyperKitty[5]), and mark it "easy" and "GSoC", and "beginner-friendly" if appropriate. (The difference between "easy" and "beginner-friendly" is "easy" means low effort, while "beginner-friendly" means it does not require prior knowledge of Mailman internals or non-stdlib Python modules such as SQLAlchemy, Zope, or Django.) Documentation and testing tasks are welcome here.
Looking forward to your ideas!
Steve
Footnotes: [1] https://summerofcode.withgoogle.com/
[2] https://wiki.list.org/DEV/Google%20Summer%20of%20Code%202026
[3] https://gitlab.com/mailman/mailman
[4] https://gitlab.com/mailman/postorius
[5] https://gitlab.com/mailman/hyperkitty
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
On Tue, Feb 03, 2026 at 11:21:46PM +0900, Stephen J. Turnbull wrote:
The GNU Mailman Project is applying for Google Summer of Code 2026[1]. Our Ideas Page[2] has been updated. We're still open for mentors, of course, and ideas. There's no deadline, but to be most useful it would be helpful to have these suggestions by February 19 when Google announces selected organizations.
Do add what was discussed here a month or so ago: the ability for a list owner to change a user's email address. Although it is possible for a user to do this the mechanism is too complicated for many users to achieve without a lot of help; allowing the list owner to do so could save much effort.
Problems:
• should a list owner be able to do so ? Ie rogue/malicious list owners. I think that this question is moot since a list owner can already add/remove list members.
• What about multiple lists ? Ie if an email address is subscribed to multiple lists. It would be a pain if the list owner would need to make the change for each list, but if some of the lists were managed by other owners, ie one list owner did not have management ability for some of the other lists. The conflict is making multiple list owners having to make the same change vs one list owner being able to (maliciously) change the list rosta for a list that s/he has no rights to.
-- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html #include <std_disclaimer.h>
alain williams writes:
Do add what was discussed here a month or so ago: the ability for a list owner to change a user's email address.
Sorry, but this is a design problem that is way out of scope for GSoC. For example
From: alain@hacks.r.us
To: somelist-owner@example.net
Subject: Please change my address
I can't access my addw address because I'm not working at phcomp
any more. -- AlainOops.
In general, addresses are *owned* by users. So you need to authenticate the *user* in order to be sure you're changing the address for the right person. List owners are often not even power users. At least site owners can be expected to have some experience with how nasty the raw Internet is and a certain amount of paranoia, but that's not generally true of list administrators.
I want the people designing privilege hierarchies to be MUCH more paranoid than typical site owners.
? should a list owner be able to do so ? Ie rogue/malicious list owners.
I'm not really worried about a rogue list owner. I'm worried about naive list owners.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
On Wed, Feb 04, 2026 at 12:41:59AM +0900, Stephen J. Turnbull wrote:
I want the people designing privilege hierarchies to be MUCH more paranoid than typical site owners.
Hmmm, I get your point. I was not paranoid enough :-(
Maybe some really clearly written end user documentation that is easily found might help. I think that I have just given myself a job.
-- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html #include <std_disclaimer.h>
alain williams writes:
Hmmm, I get your point. I was not paranoid enough :-(
Yeah, I'm going to post it as an RFE since you're the third person to support it. I've also tagged it "won't fix" :-) but if somebody has a really brilliant idea with a merge request, I'll review it. https://gitlab.com/mailman/postorius/-/issues/642
Maybe some really clearly written end user documentation that is easily found might help. I think that I have just given myself a job.
The easily-found part would be easy to implement with link in the Postorius template(s).
Or the process could be implemented with a workflow starting at the landing page:
- a prominent button "change address" takes you to the addresses page
- each address would have a "change address" button which has a form prompting for the new address
- submitting the form sends a verification code to the address,
- clicking on the verification link takes you to a page which asks if the old address should be deleted or kept
- if you click "keep", you get a list of memberships using the old address with radio buttons for "keep <old>" and "change to <new>".
Bonus points for short-circuiting trivial cases (only one address, only one subscription). Need to handle primary address.
The main problem is (as always) the Postorius authentication step. People forget their passwords or get scared by social auth. :-(
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
participants (2)
-
alain williams -
Stephen J. Turnbull