GSoC 2015: brainstorming ideas suitable for beginners?
![](https://secure.gravatar.com/avatar/3d3805dffab0985a925b949d41e8ba5d.jpg?s=120&d=mm&r=g)
Hi all,
In my role as org admin for Python, I'm trying to make sure we have more beginner-friendly ideas on the GSoC pages, and Mailman's among the groups that doesn't have any. How embarrassing for me as a Mailman developer. ;) It's also a problem for Mailman if we're applying as a separate organization, as Google seldom allows orgs unless they have a reasonable number of ideas suitable for open source newbies.
(The idea behind this is that many students are very new to Open Source and we want them to at least get something out of the application process, learn how to set up their environments and learn about what it takes to get hired as a GSoC student. Even if they don't make it in their first year, they'll be much more ready for later years!)
I'd love some help brainstorming some actual beginner-friendly ideas, though, because I'm currently all idea'd out. Anyone want to suggest some simpler things they'd like to see in Mailman that we could maybe put on the list?
Suggesting and idea does not mean you have to volunteer to mentor them, although I'm always looking for new mentors too!
Terri
![](https://secure.gravatar.com/avatar/f5ffd00413b67d3ef755afb15651401b.jpg?s=120&d=mm&r=g)
On 02/17/2015 04:03 AM, Terri Oda wrote:
Hi all,
In my role as org admin for Python, I'm trying to make sure we have more beginner-friendly ideas on the GSoC pages, and Mailman's among the groups that doesn't have any. How embarrassing for me as a Mailman developer. ;) It's also a problem for Mailman if we're applying as a separate organization, as Google seldom allows orgs unless they have a reasonable number of ideas suitable for open source newbies.
(The idea behind this is that many students are very new to Open Source and we want them to at least get something out of the application process, learn how to set up their environments and learn about what it takes to get hired as a GSoC student. Even if they don't make it in their first year, they'll be much more ready for later years!)
I'd love some help brainstorming some actual beginner-friendly ideas, though, because I'm currently all idea'd out. Anyone want to suggest some simpler things they'd like to see in Mailman that we could maybe put on the list?
Suggesting and idea does not mean you have to volunteer to mentor them, although I'm always looking for new mentors too!
Terri
I don't know whether these are beginner-friendly enough, but here are some thoughts:
- 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)
- 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
- Add new skins/themes to HyperKitty and/or Postorius (per https://fedorahosted.org/hyperkitty/ticket/83 and https://bugs.launchpad.net/postorius/+bug/1196608 )
- Expose new REST API features in Postorius https://bugs.launchpad.net/postorius/+bug/1062925
- HyperKitty: RSS feed generation https://fedorahosted.org/hyperkitty/ticket/84
- HyperKitty: Present all messages in a thread at once, and offer plaintext download of the whole thread https://fedorahosted.org/hyperkitty/ticket/88
-- Sumana Harihareswara http://brainwane.net
![](https://secure.gravatar.com/avatar/28a58b235ae770d6a1f25d1c6e45bdd0.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 17.02.2015 um 10:03 schrieb Terri Oda:
I'd love some help brainstorming some actual beginner-friendly ideas, though, because I'm currently all idea'd out. Anyone want to suggest some simpler things they'd like to see in Mailman that we could maybe put on the list?
Just from the top of my head, either as a combination of the two or as single projects (if fleshed out a bit further):
- 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.
- Subscriber pages: Let users opt-in to show their membership to other list members. Possibly along with some additional user information[1]. This could be useful for more private lists if you want to get an idea who your audience is.
Florian
[1] The "additional user info" bit possibly re-raises the big question of a central user data store for all Mailman components, which will clearly not be solved as part of a GSoC project, especially a beginner-friendly one. But we do already have a little bit of info, the user's email address and the gravatar (if there is one). So all we'd have to store is an opt-in flag somewhere in the Django-DB.
Suggesting and idea does not mean you have to volunteer to mentor them, although I'm always looking for new mentors too!
Terri
_______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/f%40florianfuchs....
Security Policy: http://wiki.list.org/x/QIA9
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iQEcBAEBAgAGBQJU432YAAoJEEceGbPdavl7CqEH/AvOLwc+qyWkmNw6Tahm6Jjb IHVnz4yv4sTFmdB9iqYXkOQqt7XgpEoIYUZwV+j7+vltDSYSh2qecKyVyQjBkEUC wc7hU8/czOw2E/I3MG1siRzCGeekGJSTFXf2NoKksUNca9DUQe0leNKs1VWXwaX5 uAsyitJxaiPJIsrKHeVhGO6g4rSmqBMi+Q+HTaBIZQqZZd1Qh7ZgUV4qXFuTjUXw D4Ae20sdFAdLD412e3LrgI58JiXRNIHBfWzN1Zg0RoY95rw/AuDafrlPT37I2E7O mahaaJAJrmPO3EimeDPmj1TTV7NWOpaU9Vlzd6H5BX4KweUxAaafYHFrkYXN/pU= =L+aD -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/b009b2809a98fc29d87d2ef8a9609005.jpg?s=120&d=mm&r=g)
[1] The "additional user info" bit possibly re-raises the big question of a central user data store for all Mailman components, which will clearly not be solved as part of a GSoC project, especially a beginner-friendly one. But we do already have a little bit of info, the user's email address and the gravatar (if there is one). So all we'd have to store is an opt-in flag somewhere in the Django-DB.
I have implemented a central data store into the REST proxy server. It’s a simple table structure as follows:
———————————————————————————————————————————————————————————————————————— resource_type | resource_id | private/public | key | value ———————————————————————————————————————————————————————————————————————— user list domain server
User access permissions for the data rows is the same as access to the resource_type & resource_id
It’s workable as a part of the auth proxy but feels like it would fit better in the Mailman core database since the data is so tightly bound to Mailman resources. It’ll need an effective replication mechanism to ensure consistency with Mailman which is a challenge I’m not relishing solving.
as
On 18 Feb 2015, at 4:42 am, Florian Fuchs <f@florianfuchs.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 17.02.2015 um 10:03 schrieb Terri Oda:
I'd love some help brainstorming some actual beginner-friendly ideas, though, because I'm currently all idea'd out. Anyone want to suggest some simpler things they'd like to see in Mailman that we could maybe put on the list?
Just from the top of my head, either as a combination of the two or as single projects (if fleshed out a bit further):
- 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.
- Subscriber pages: Let users opt-in to show their membership to other list members. Possibly along with some additional user information[1]. This could be useful for more private lists if you want to get an idea who your audience is.
Florian
[1] The "additional user info" bit possibly re-raises the big question of a central user data store for all Mailman components, which will clearly not be solved as part of a GSoC project, especially a beginner-friendly one. But we do already have a little bit of info, the user's email address and the gravatar (if there is one). So all we'd have to store is an opt-in flag somewhere in the Django-DB.
Suggesting and idea does not mean you have to volunteer to mentor them, although I'm always looking for new mentors too!
Terri
_______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/f%40florianfuchs....
Security Policy: http://wiki.list.org/x/QIA9
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iQEcBAEBAgAGBQJU432YAAoJEEceGbPdavl7CqEH/AvOLwc+qyWkmNw6Tahm6Jjb IHVnz4yv4sTFmdB9iqYXkOQqt7XgpEoIYUZwV+j7+vltDSYSh2qecKyVyQjBkEUC wc7hU8/czOw2E/I3MG1siRzCGeekGJSTFXf2NoKksUNca9DUQe0leNKs1VWXwaX5 uAsyitJxaiPJIsrKHeVhGO6g4rSmqBMi+Q+HTaBIZQqZZd1Qh7ZgUV4qXFuTjUXw D4Ae20sdFAdLD412e3LrgI58JiXRNIHBfWzN1Zg0RoY95rw/AuDafrlPT37I2E7O mahaaJAJrmPO3EimeDPmj1TTV7NWOpaU9Vlzd6H5BX4KweUxAaafYHFrkYXN/pU= =L+aD -----END PGP SIGNATURE-----
Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/andrew.stuart%40s...
Security Policy: http://wiki.list.org/x/QIA9
![](https://secure.gravatar.com/avatar/173371753ea2206b9934a9be1bdce423.jpg?s=120&d=mm&r=g)
On Feb 20, 2015, at 07:25 PM, Andrew Stuart wrote:
It’s workable as a part of the auth proxy but feels like it would fit better in the Mailman core database since the data is so tightly bound to Mailman resources. It’ll need an effective replication mechanism to ensure consistency with Mailman which is a challenge I’m not relishing solving.
Do you think this has to be integrated into the core for 3.0? I'd still prefer to keep it separate for better experimentation and testing. If the design and API proves stable, then perhaps it'll make sense to integrate it with the core for 3.1.
Cheers, -Barry
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Barry Warsaw writes:
On Feb 20, 2015, at 07:25 PM, Andrew Stuart wrote:
It’s workable as a part of the auth proxy but feels like it would fit better in the Mailman core database since the data is so tightly bound to Mailman resources. It’ll need an effective replication mechanism to ensure consistency with Mailman which is a challenge I’m not relishing solving.
Do you think this has to be integrated into the core for 3.0? I'd still prefer to keep it separate for better experimentation and testing. If the design and API proves stable, then perhaps it'll make sense to integrate it with the core for 3.1.
I don't which way this argues, but Mailman 3 already needs "effective replication mechanisms" because Postorius and HyperKitty both add to the basic database schema.
![](https://secure.gravatar.com/avatar/b009b2809a98fc29d87d2ef8a9609005.jpg?s=120&d=mm&r=g)
Do you think this has to be integrated into the core for 3.0? I'd still prefer to keep it separate for better experimentation and testing.
if: there was an “application data” table:
———————————————————————————————————————————————————————————————————————— resource_type | resource_id | private/public | key | value ———————————————————————————————————————————————————————————————————————— user list domain server
and: the ability to set domainowner and serverowner permissions in 3.0,
then: there would be a huge payoff in terms of avoiding the downstream challenge of migration upgrade scripts, data migrations, testing, backups, the risk of something going wrong for the end-user sysadmin.
else: the alternative for me is to go ahead with deploying application data and domainowner and serverowner into the auth server, and later needing to work out how to migrate these back into Mailman core in some later version - I’m thinking that if those tables were there in Mailman 3.0 rather than say version 3.1 then a vast amount of downstream work, risk and thinking could be saved (for me). Not insurmountable but would really take alot of engineering to do safely. Getting random sysadmins to do stuff like data migrations that is a little anxiety provoking.
David Murray, who does the Python email package, implements APIs as “provisional” so they are not part of the official release but are present in the code, until some version further down the track where he formalises the provisional API following road testing and feedback. Sort of a logical separation for experimentation and testing. Could that be a way to implement an application data table and serverowner and domainowner permissions in 3.0? That way, consumers of the REST API can use the provisional API functionality at our own risk that it might change before being formalised. I’d take that any day over the need to write stuff that a random sysadmin could run to migrate their data into a new table structure later.
Implementing an application data table and domainowner/serverowner as “provisional” would be a stitch in time for me anyway.
As I mentioned I’ve done it myself anyway in the auth server but theres a bunch of unaddressed challenges relating to replication and synchronisation - whenever the application data is accessed, there needs to be checks to verify that both the user and the resource actually exist in Mailman, and there’s no easy way to know when users and resources have been deleted from Mailman, potentially leaving stale application data.
As always though, I’m not super attached to the outcomes - you’re the boss Barry so I’m OK with whatever path.
as
On 22 Feb 2015, at 5:05 am, Barry Warsaw <barry@list.org> wrote:
On Feb 20, 2015, at 07:25 PM, Andrew Stuart wrote:
It’s workable as a part of the auth proxy but feels like it would fit better in the Mailman core database since the data is so tightly bound to Mailman resources. It’ll need an effective replication mechanism to ensure consistency with Mailman which is a challenge I’m not relishing solving.
Do you think this has to be integrated into the core for 3.0? I'd still prefer to keep it separate for better experimentation and testing. If the design and API proves stable, then perhaps it'll make sense to integrate it with the core for 3.1.
Cheers, -Barry
Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/andrew.stuart%40s...
Security Policy: http://wiki.list.org/x/QIA9
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Andrew Stuart writes:
Do you think this has to be integrated into the core for 3.0? I'd still prefer to keep it separate for better experimentation and testing.
the alternative for me is to go ahead with deploying application data and domainowner and serverowner into the auth server,
I disagree with the implicit assumption right there. From Mailman's point of view, this is *Andrew's* auth server, not *the* auth server. If we're serious about serving the enterprise, we need to figure these things out、because Mailman is going to need to plug into an existing auth and user database system.
I don't know if we care any more, but enterprise integration used to be a goal. It's still a requirement of some of our most loyal users (universities, who FAQ us about using their databases to populate lists for classes etc every year).
![](https://secure.gravatar.com/avatar/b009b2809a98fc29d87d2ef8a9609005.jpg?s=120&d=mm&r=g)
Yes that’s a reasonable line of thought Stephen. You are correct I haven’t made any attempt to integrate with enterprise auth systems. Also, I’ll avoid describing my auth server as ‘the auth server’.
Is there anything that would define what sort of functionality is required for enterprise integration?
The two things that I’ve suggested might be worth including in the core are hopefully of broad value and not specific only to what I’m doing. (rounding out the permissions, with serverowner and domainowner, including an application data table that stores keys and values).
thanks
as
On 22 Feb 2015, at 9:36 pm, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Andrew Stuart writes:
Do you think this has to be integrated into the core for 3.0? I'd still prefer to keep it separate for better experimentation and testing.
the alternative for me is to go ahead with deploying application data and domainowner and serverowner into the auth server,
I disagree with the implicit assumption right there. From Mailman's point of view, this is *Andrew's* auth server, not *the* auth server. If we're serious about serving the enterprise, we need to figure these things out、because Mailman is going to need to plug into an existing auth and user database system.
I don't know if we care any more, but enterprise integration used to be a goal. It's still a requirement of some of our most loyal users (universities, who FAQ us about using their databases to populate lists for classes etc every year).
![](https://secure.gravatar.com/avatar/6271f25d487757bb93d9f02708448338.jpg?s=120&d=mm&r=g)
On 22 Feb 2015, at 22:10, Andrew Stuart <andrew.stuart@supercoders.com.au> wrote:
Yes that’s a reasonable line of thought Stephen. You are correct I haven’t made any attempt to integrate with enterprise auth systems. Also, I’ll avoid describing my auth server as ‘the auth server’.
Is there anything that would define what sort of functionality is required for enterprise integration?
For the University of Sussex, UK, we’d love to have LDAP integration to authenticate users against either an OpenLDAP or an Active Directory server. I don’t think there’s much difference, except in the construction of DNs from usernames. We’d need the ability to (a) find a user with an LDAP search, then (b) perform authentication against the LDAP database.
For bonus points, when registering the user, you could also pick up the user’s email address and name from the LDAP database.
However, while some lists are exclusively for local users, others might include third parties. For example, a list might support a multi-institution research project. So, we need a protected username name-space, too. And, we can’t assume that local usernames map to email addresses, either. So, the email address foo AT sussex.ac.uk might not belong to username foo.
Oh, and we probably need to support multiple local domains. Particularly subdomains of sussex.ac.uk.
-- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148
![](https://secure.gravatar.com/avatar/b009b2809a98fc29d87d2ef8a9609005.jpg?s=120&d=mm&r=g)
Hi Ian,
Thanks for the info. I’ll have a look.
as
On 24 Feb 2015, at 12:14 am, Ian Eiloart <iane@sussex.ac.uk> wrote:
On 22 Feb 2015, at 22:10, Andrew Stuart <andrew.stuart@supercoders.com.au> wrote:
Yes that’s a reasonable line of thought Stephen. You are correct I haven’t made any attempt to integrate with enterprise auth systems. Also, I’ll avoid describing my auth server as ‘the auth server’.
Is there anything that would define what sort of functionality is required for enterprise integration?
For the University of Sussex, UK, we’d love to have LDAP integration to authenticate users against either an OpenLDAP or an Active Directory server. I don’t think there’s much difference, except in the construction of DNs from usernames. We’d need the ability to (a) find a user with an LDAP search, then (b) perform authentication against the LDAP database.
For bonus points, when registering the user, you could also pick up the user’s email address and name from the LDAP database.
However, while some lists are exclusively for local users, others might include third parties. For example, a list might support a multi-institution research project. So, we need a protected username name-space, too. And, we can’t assume that local usernames map to email addresses, either. So, the email address foo AT sussex.ac.uk might not belong to username foo.
Oh, and we probably need to support multiple local domains. Particularly subdomains of sussex.ac.uk.
-- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148
![](https://secure.gravatar.com/avatar/173371753ea2206b9934a9be1bdce423.jpg?s=120&d=mm&r=g)
On Feb 23, 2015, at 09:10 AM, Andrew Stuart wrote:
The two things that I’ve suggested might be worth including in the core are hopefully of broad value and not specific only to what I’m doing. (rounding out the permissions, with serverowner and domainowner, including an application data table that stores keys and values).
mm3 does have a key/value store (well, a table that associates unicode keys with values), but it's hidden behind the pending database API. I'm not sure it would be good to generalize or hijack this for your purposes.
Cheers, -Barry
![](https://secure.gravatar.com/avatar/173371753ea2206b9934a9be1bdce423.jpg?s=120&d=mm&r=g)
On Feb 22, 2015, at 11:20 AM, Andrew Stuart wrote:
there was an “application data” table:
———————————————————————————————————————————————————————————————————————— resource_type | resource_id | private/public | key | value ———————————————————————————————————————————————————————————————————————— user list domain server
and: the ability to set domainowner and serverowner permissions in 3.0,
No question, I think domain owner and server owner (or site owner) are concepts that we should capture in the core. I'd accept contributions for this, so let me describe my thinking (open to suggestions!).
The first question is whether to associate addresses, users, or both with the permissions. If you look at the member table (Member model class) you'll see we have a foreign key for both, but the logic ensure that we can't get conflicting values. This allows us to implement the "address as a member" or the "user as a member using their preferred address". I'm not sure whether we need this level of complexity for the site and domain owners.
The other observation is that we'd like to make it easy for both owners two have multiple contact addresses, so that we have fallbacks in case one of them starts to fail.
So I'm thinking we use a User for this association. The user would have to have at least one validated address linked to it.
For domains, we already have a domain table (Domain model class). Since we'd like to be able to associate multiple domain owners, it seems like we need a many-to-many table associating domains to users. (More than one user can own a domain, and any user can own more than one domain.) That table probably doesn't need anything else.
Since we have no site table/model, I think it would be enough to add a flag to the user table/model to indicate whether they are a site owner or not.
Now sprinkle with tests, database migrations, documentation, and REST, and I think you have at least this part solved.
Cheers, -Barry
![](https://secure.gravatar.com/avatar/b009b2809a98fc29d87d2ef8a9609005.jpg?s=120&d=mm&r=g)
I am currently associating users, not addresses with these permissions, so your suggestion is compatible with my stuff.
site owner does sound more appropriate than server owner.
Everything else suggested sounds fine to me.
as
On 24 Feb 2015, at 11:42 am, Barry Warsaw <barry@list.org> wrote:
On Feb 22, 2015, at 11:20 AM, Andrew Stuart wrote:
there was an “application data” table:
———————————————————————————————————————————————————————————————————————— resource_type | resource_id | private/public | key | value ———————————————————————————————————————————————————————————————————————— user list domain server
and: the ability to set domainowner and serverowner permissions in 3.0,
No question, I think domain owner and server owner (or site owner) are concepts that we should capture in the core. I'd accept contributions for this, so let me describe my thinking (open to suggestions!).
The first question is whether to associate addresses, users, or both with the permissions. If you look at the member table (Member model class) you'll see we have a foreign key for both, but the logic ensure that we can't get conflicting values. This allows us to implement the "address as a member" or the "user as a member using their preferred address". I'm not sure whether we need this level of complexity for the site and domain owners.
The other observation is that we'd like to make it easy for both owners two have multiple contact addresses, so that we have fallbacks in case one of them starts to fail.
So I'm thinking we use a User for this association. The user would have to have at least one validated address linked to it.
For domains, we already have a domain table (Domain model class). Since we'd like to be able to associate multiple domain owners, it seems like we need a many-to-many table associating domains to users. (More than one user can own a domain, and any user can own more than one domain.) That table probably doesn't need anything else.
Since we have no site table/model, I think it would be enough to add a flag to the user table/model to indicate whether they are a site owner or not.
Now sprinkle with tests, database migrations, documentation, and REST, and I think you have at least this part solved.
Cheers, -Barry
Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/andrew.stuart%40s...
Security Policy: http://wiki.list.org/x/QIA9
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Andrew Stuart writes:
I am currently associating users, not addresses with these permissions, so your suggestion is compatible with my stuff.
+1 on associating users with permissions (plus the validation Barry recommends).
site owner does sound more appropriate than server owner.
Users think of "site" as being nearly synonymous with "domain", though. I don't think we should use "site" in a different way, that would confuse them.
There should be a way to contact the actual operator of the host, which I think of as "hostmaster" or "server owner".
Steve
![](https://secure.gravatar.com/avatar/c0d04778ffa954634a86791d27a274ad.jpg?s=120&d=mm&r=g)
On 2/23/2015 8:08 PM, Stephen J. Turnbull wrote:
Andrew Stuart writes:
I am currently associating users, not addresses with these permissions, so your suggestion is compatible with my stuff.
+1 on associating users with permissions (plus the validation Barry recommends).
site owner does sound more appropriate than server owner.
Users think of "site" as being nearly synonymous with "domain", though. I don't think we should use "site" in a different way, that would confuse them.
There should be a way to contact the actual operator of the host, which I think of as "hostmaster" or "server owner".
Steve
My .0002 cents. :)
In a previous message, the thought of making Mailman usable in an enterprise environment was brought up. A good idea. Also, I believe I remember a goal for Mailman v3 was to have one instance of Mailman be able to host lists for multiple domains. Given that information and information from Andrew and Stephen, there are several different layers of "ownership". Thinking about it a little, I see:
"Owner" Description
List Owner can administer a list Server Owner can administer all lists on one server (server may host multiple domains) Site Owner can administer for all lists at a site (site has multiple servers) (site is a physical location) Domain Owner can administer for all lists for a domain (domains may be hosted on multiple servers possibly across multiple sites)
Note: if site is considered a physical location, then an additional owner permission may be "Host Owner" for all their sites at different locations.
Nailing down a good permissions structure is very important if Mailman is to be used in the enterprise, both in a large organization or by a hosting company (e.g. Rackspace, etc.).
Better people than I can come up with a better solution than my quick thought. I do think it is important that once you get past the "List Owner" level of permissions, there is potential interaction between "Server Owner", "Site Owner", and "Domain Owner". This also points to a need for a robust authentication system that can handle multiple ways to authenticate the various owners.
Well, probably in over my head again.
Thanks, Chris
![](https://secure.gravatar.com/avatar/173371753ea2206b9934a9be1bdce423.jpg?s=120&d=mm&r=g)
On Feb 24, 2015, at 07:53 AM, Chris Nulk wrote:
Also, I believe I remember a goal for Mailman v3 was to have one instance of Mailman be able to host lists for multiple domains.
Yes, but not on physically distinct hosts. Or in other words, yes MM3 supports virtual domains
Given that information and information from Andrew and Stephen, there are several different layers of "ownership". Thinking about it a little, I see:
"Owner" Description
List Owner can administer a list Server Owner can administer all lists on one server (server may host multiple domains) Site Owner can administer for all lists at a site (site has multiple servers) (site is a physical location) Domain Owner can administer for all lists for a domain (domains may be hosted on multiple servers possibly across multiple sites)
Note: if site is considered a physical location, then an additional owner permission may be "Host Owner" for all their sites at different locations
I think the distinction between server owner and site owner as described above doesn't exist, or I don't quite understand the definitions. Multiple servers isn't a concept embodied in Mailman anywhere. For example, if you were to run a hosting provider and had clients at A.example.com and B.example.com, and they ran distinct Mailman servers, the two wouldn't have any organizational or administrative overlap, except at a higher level, e.g. postmaster@HOSTING.example.com. That's not something I see Mailman having to represent in any useful way.
Cheers, -Barry
![](https://secure.gravatar.com/avatar/173371753ea2206b9934a9be1bdce423.jpg?s=120&d=mm&r=g)
On Feb 24, 2015, at 01:08 PM, Stephen J. Turnbull wrote:
Users think of "site" as being nearly synonymous with "domain", though. I don't think we should use "site" in a different way, that would confuse them.
That's a good point.
There should be a way to contact the actual operator of the host, which I think of as "hostmaster" or "server owner".
system_administrator?
Cheers, -Barry
![](https://secure.gravatar.com/avatar/b009b2809a98fc29d87d2ef8a9609005.jpg?s=120&d=mm&r=g)
I’m looking forward to being able to set and get domainowner and serverowner (or siteowner or whatever its called). It will allow me to delete lots of code and there’s no greater joy than deleting code.
Are you anticipating this will be in V3.0?
thanks
as
On 24 Feb 2015, at 11:42 am, Barry Warsaw <barry@list.org> wrote:
On Feb 22, 2015, at 11:20 AM, Andrew Stuart wrote:
there was an “application data” table:
———————————————————————————————————————————————————————————————————————— resource_type | resource_id | private/public | key | value ———————————————————————————————————————————————————————————————————————— user list domain server
and: the ability to set domainowner and serverowner permissions in 3.0,
No question, I think domain owner and server owner (or site owner) are concepts that we should capture in the core. I'd accept contributions for this, so let me describe my thinking (open to suggestions!).
The first question is whether to associate addresses, users, or both with the permissions. If you look at the member table (Member model class) you'll see we have a foreign key for both, but the logic ensure that we can't get conflicting values. This allows us to implement the "address as a member" or the "user as a member using their preferred address". I'm not sure whether we need this level of complexity for the site and domain owners.
The other observation is that we'd like to make it easy for both owners two have multiple contact addresses, so that we have fallbacks in case one of them starts to fail.
So I'm thinking we use a User for this association. The user would have to have at least one validated address linked to it.
For domains, we already have a domain table (Domain model class). Since we'd like to be able to associate multiple domain owners, it seems like we need a many-to-many table associating domains to users. (More than one user can own a domain, and any user can own more than one domain.) That table probably doesn't need anything else.
Since we have no site table/model, I think it would be enough to add a flag to the user table/model to indicate whether they are a site owner or not.
Now sprinkle with tests, database migrations, documentation, and REST, and I think you have at least this part solved.
Cheers, -Barry
Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/andrew.stuart%40s...
Security Policy: http://wiki.list.org/x/QIA9
![](https://secure.gravatar.com/avatar/173371753ea2206b9934a9be1bdce423.jpg?s=120&d=mm&r=g)
On Feb 25, 2015, at 04:12 PM, Andrew Stuart wrote:
I’m looking forward to being able to set and get domainowner and serverowner (or siteowner or whatever its called). It will allow me to delete lots of code and there’s no greater joy than deleting code.
Are you anticipating this will be in V3.0?
Please file a bug and we'll see. ;)
Cheers, -Barry
![](https://secure.gravatar.com/avatar/6c2f33d168a70197681245ca1a98a766.jpg?s=120&d=mm&r=g)
How about having personalized announcement mailing lists ?
A personalized mailing list will allow mailman users to send personalized emails to all the list members from a common email template. Suppose I am the manager of a company and I need to ask all the workers for a meeting. I want each of my workers to prepare a topic to speak on during the meeting. For this I need to send each of them a message separately mentioning the topic he/she has to speak on.
Suppose the email *template* is like this:
*To : <worker-email>* *Subject: <sub>*
*Hello <worker-name>,*
*Hope you are having fun at <worker-place>. I am arranging a meeting at 5 p.m. on Saturday. I want you to speak on <topic> during the meeting. So, come prepared for that.* *<other-suff>*
*Best wishes,*
*Ankush Sharma* *Manager* *foo-bar*
And I have a spreadsheet data on the mailing list server like this: https://docs.google.com/spreadsheets/d/1cAbdSmc1NA-C9IZFjc_zB67qEvgmX8Jr3xYy...
Mailman can have a functionality of flooding the *template* by using the spreadsheet data. The variables in the *template* (< -- > stuff) would be replaced by the corresponding row data in the spreadsheet corresponding to the emails of the list members. This can provide great flexibility to mailman users who use mailman as announcement list.
Later on, mailman can have the functionality of saving email templates and choosing one of them in a certain scenario. Mailing lists can be made more personalized and powerful in this way.
Expecting further feedback or suggestions on this idea.
Ankush Sharma IIT-BHU,Varanasi github.com/black-perl
On Thu, Feb 26, 2015 at 4:40 AM, Barry Warsaw <barry@list.org> wrote:
On Feb 25, 2015, at 04:12 PM, Andrew Stuart wrote:
I’m looking forward to being able to set and get domainowner and serverowner (or siteowner or whatever its called). It will allow me to delete lots of code and there’s no greater joy than deleting code.
Are you anticipating this will be in V3.0?
Please file a bug and we'll see. ;)
Cheers, -Barry
Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/ankush.sharma.ece...
Security Policy: http://wiki.list.org/x/QIA9
![](https://secure.gravatar.com/avatar/b009b2809a98fc29d87d2ef8a9609005.jpg?s=120&d=mm&r=g)
There’s a bug at:
https://bugs.launchpad.net/mailman/+bug/1423756
Requesting domainowner and serverowner
thanks
On 26 Feb 2015, at 10:10 am, Barry Warsaw <barry@list.org> wrote:
On Feb 25, 2015, at 04:12 PM, Andrew Stuart wrote:
I’m looking forward to being able to set and get domainowner and serverowner (or siteowner or whatever its called). It will allow me to delete lots of code and there’s no greater joy than deleting code.
Are you anticipating this will be in V3.0?
Please file a bug and we'll see. ;)
Cheers, -Barry
Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/andrew.stuart%40s...
Security Policy: http://wiki.list.org/x/QIA9
![](https://secure.gravatar.com/avatar/1786350e8a814c84a91563c7c11e4000.jpg?s=120&d=mm&r=g)
How about domain-wide settings for default list styles or maybe set a default list style for an entire mailman installation through Postorius? That could make the work of list-admins easy if they manage too many lists and don't want to do repetitive change in each and every list. Additionally ability to change the settings for only a subset of all lists could also be possible.
On Tuesday 17 February 2015 02:33 PM, Terri Oda wrote:
Hi all,
In my role as org admin for Python, I'm trying to make sure we have more beginner-friendly ideas on the GSoC pages, and Mailman's among the groups that doesn't have any. How embarrassing for me as a Mailman developer. ;) It's also a problem for Mailman if we're applying as a separate organization, as Google seldom allows orgs unless they have a reasonable number of ideas suitable for open source newbies.
(The idea behind this is that many students are very new to Open Source and we want them to at least get something out of the application process, learn how to set up their environments and learn about what it takes to get hired as a GSoC student. Even if they don't make it in their first year, they'll be much more ready for later years!)
I'd love some help brainstorming some actual beginner-friendly ideas, though, because I'm currently all idea'd out. Anyone want to suggest some simpler things they'd like to see in Mailman that we could maybe put on the list?
Suggesting and idea does not mean you have to volunteer to mentor them, although I'm always looking for new mentors too!
Terri
Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/raj.abhilash1%40g...
Security Policy: http://wiki.list.org/x/QIA9
-- thanks, Abhilash Raj
![](https://secure.gravatar.com/avatar/173371753ea2206b9934a9be1bdce423.jpg?s=120&d=mm&r=g)
On Feb 18, 2015, at 12:24 AM, Abhilash Raj wrote:
How about domain-wide settings for default list styles or maybe set a default list style for an entire mailman installation through Postorius? That could make the work of list-admins easy if they manage too many lists and don't want to do repetitive change in each and every list. Additionally ability to change the settings for only a subset of all lists could also be possible.
That would be pretty cool. Right now the style system is pretty stupid, mostly a refactoring of the legacy "set all the mailing list object attributes" approach. I think we could do better, not only in the way we define and apply styles, but maybe also in removing the restriction that styles only take effect at list creation time.
That could be a sufficiently large enough task for GSoC.
Cheers, -Barry
![](https://secure.gravatar.com/avatar/3d3805dffab0985a925b949d41e8ba5d.jpg?s=120&d=mm&r=g)
Thanks all! I've put up stuff for the ideas I could describe well enough off the top of my head.
Also, mentors, I've listed a few likely key people beside each project idea, but some of them are just a generic "anyone can help with this" -- if any of these particularly interests you, please put your name down. Google prefers we have actual names listed when we can (I'm not entirely sure why, as this hasn't proven to be helpful, but we can always change the names after the page is reviewed.)
Applications are due 1900 UTC Friday, so around 13h from now!
Terri
![](https://secure.gravatar.com/avatar/28a58b235ae770d6a1f25d1c6e45bdd0.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 20.02.2015 um 06:46 schrieb Terri Oda:
Thanks all! I've put up stuff for the ideas I could describe well enough off the top of my head.
Thank you Terri!
Also, mentors, I've listed a few likely key people beside each project idea, but some of them are just a generic "anyone can help with this" -- if any of these particularly interests you, please put your name down. Google prefers we have actual names listed when we can (I'm not entirely sure why, as this hasn't proven to be helpful, but we can always change the names after the page is reviewed.)
Applications are due 1900 UTC Friday, so around 13h from now!
I completed the application yesterday and was planning to do a little more wiki-gardening today.
So let's keep our fingers crossed. Who knows, maybe we get bonus points for persistence. ;-)
Florian
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iQEcBAEBAgAGBQJU5w1BAAoJEEceGbPdavl78HAIAJ9Rj4K+L56TCn6iQd/rjSXC KFpDXcwAQLITr4QRDYs8EAIHDYwp4X/i6ZyZBqyvtSodoeRKPzl6fDjTR+OnXCes BIKw72/zvwMqZLP3U2BY8DosUbWpYTy6G70o3+XoKnvXivIX5hTp50A8L+BbQzfU Rg+0uQ10DN6bJi8/yr5wXgK9qQv2aDoTGjriKhOvln6uT6agtnvFXA6JqiUoF1Es 1eqfdbO9bCl0SJ6HFwTkADwaG0psgaPQPWkKMaQQUB3INku09Duy1OEXuiWk+ceT DPd3iEuCJZ5uSNgZ8Gt1InZtW1T0ZJtw1UxZ/kQm7wJoSKUyGhsDOfZr4BOyKic= =cXki -----END PGP SIGNATURE-----
participants (10)
-
Abhilash Raj
-
Andrew Stuart
-
Ankush Sharma B.Tech. Electronics Engg, IIT(BHU), Varanasi (U.P.), INDIA
-
Barry Warsaw
-
Chris Nulk
-
Florian Fuchs
-
Ian Eiloart
-
Stephen J. Turnbull
-
Sumana Harihareswara
-
Terri Oda