[feature-request] hierarchical list organisation

[Hannes]

Adminstrating mailman-lists would be so much much easier, if mailman offered the possibility of organizing lists hiearchically.

Let me explain with an example:

You are part of an international organisation, that has national and local groups of activists. Now you don't want to have one mailing list for everything, but you want people to know whats happening on what level, so you create a list for every local group, one for all countries involved and a global one.
If someone joins the organisation he or she will have to register with three lists, which is rather confusing for non-technical people (and for technical people, too, because they are already member of 100+ lists ;) ).

I see that regular_include_lists was introduced to help with such situations and it really does, for the first half: I can put all local groups in the includes_lists of the country and put all countries in the include_lists of the international list, so that you get *all* the mail by subscribing to the local list.
However you still arent /member/ of the higher-level lists and can't post to them.

The easiest-to-implement technical solution would be for mailman to offer a checkbox
[ ] Automatically add members of sibling lists to accept_these_nonmembers

It would have to work recursively. This would really make my life easier; right now I manually export members from the sub-lists and add them to accept_these_nonmember manually...

This solution however is not very 'clean', it is static (people unsubscribed should dissappear from accept_these_members), it circumvents moderation-specific settings and is not very transparent. Also the whole sibling-list-thing right now is not very intuitiv, and AFAICT not very safe (the sibling-list is never asked, I can create a SPAM-list and add all other lists on the server to regular_include_lists without them being able to defend themselves)..

A more permanent and clean solution would include making proper options for "sub-lists". This could be implemented a long the following points:
* Make the option of adding other lists of the same server as members to one list
* Should both lists not share an admin, an admin of the sub-list should have to confirm this
* Mailman should then dynamically(!) add the sub-list's members to the higher-level list
* ideally this would be reflected in the interface, e.g. the members be listed in treeview:
Main List:
- member1
- member2
+ Sub-List1:
--sub-list1-member1
--sub-list1-member2
+ Sub-List2:
--sub-list2-member1
--sub-list2-member2
--+ Sub-List2'-Sub-List1:
----....

I don't know how much work implementing this would be, but from involvement of in different technical and non-technical projects I think it would help both users and admins A LOT!

Thanks for reading through all of this!
Thanks for your work on mailman!

In Solidarity
Hannes

[Adam McGreggor (adam-amyl)]

On Thu, Nov 27, 2008 at 01:56:13PM -0000, Hannes wrote:
> Public bug reported:
>
> Adminstrating mailman-lists would be so much much easier, if mailman
> offered the possibility of organizing lists hiearchically.

Hum, I'm not too sure about that (by means of introduction, I currently
list-admin around about 300 lists, for a few NGOs in the UK):

> Let me explain with an example:
>
> You are part of an international organisation, that has national and
> local groups of activists. Now you don't want to have one mailing list
> for everything, but you want people to know whats happening on what
> level, so you create a list for every local group, one for all
> countries involved and a global one.

That's what we do for one of the groups I'm invovled in; local lists
(and our international chapters come as a 'local group') are discussion
(and soon to be announce too); national lists announce only.

> If someone joins the
> organisation he or she will have to register with three lists, which
> is rather confusing for non-technical people (and for technical
> people, too, because they are already member of 100+ lists ;) ).

I'd steer punters to a script which provides (paraphrasing here)
    "Yes, I want local discussion only [ x ] "
    "Local Announcements only, thanks [ x ] "
    "I'd like national & special alerts only (every two weeks +)[ x ] "
    "local discussion plus national and International alerts [ x ] "

or something more suitable; if you're so inclined, you might want to use
some geoip trickery or something to pre-populate national/regional.

roughly detailing traffic-volumes.

[...]

> The easiest-to-implement technical solution would be for mailman to
> offer a checkbox [ ] Automatically add members of sibling lists to
> accept_these_nonmembers

Ouch! I strongly believe if people want to post to a list they should be
a member so they can receive replies to (if it was worthy of a list
post, the list can have replies as a general rule here.)

> It would have to work recursively. This would really make my life
> easier; right now I manually export members from the sub-lists and add
> them to accept_these_nonmember manually...

cron, list_members + add_members or sync_members, perhaps? And do the
generation of allowing posts (if you want to) using withlist?

If you're using a database to store info, you could pull the options
for sub-sets/regional constituencies from that (it's how a couple
of my lists are generated: sql select -> sync_members).

[Hannes (bugzilla-soulrebel)]

> > If someone joins the
> > organisation he or she will have to register with three lists, which
> > is rather confusing for non-technical people (and for technical
> > people, too, because they are already member of 100+ lists ;) ).
>
> I'd steer punters to a script which provides (paraphrasing here)
> "Yes, I want local discussion only [ x ] "
> "Local Announcements only, thanks [ x ] "
> "I'd like national & special alerts only (every two weeks +)[ x ] "
> "local discussion plus national and International alerts [ x ] "

I thought about something like this aswell, but registering online is not the
preferred way of doing it here. Normally some new member just goes to the
list-admin of his local group (in real life) and asks him to be added.
Then that list-admin has to add the person manually to several lists and
remove it from all of them manually if the person wants off again.
Real-life experience has shown that lists get out of sync quickly. Also it
would require every local admin to also be regional/national admin, so that he
can add new members; this is not desireable. Note, that the lists I am
talking about are non-public.

>
> > The easiest-to-implement technical solution would be for mailman to
> > offer a checkbox [ ] Automatically add members of sibling lists to
> > accept_these_nonmembers
>
> Ouch! I strongly believe if people want to post to a list they should be
> a member so they can receive replies to (if it was worthy of a list
> post, the list can have replies as a general rule here.)

That is what I am proposing: I want the members of sub-lists to automatically
become members of the "upper"-lists. The work-around right now is to put the
"sub-lists" into include_these_nonmembers (sibling-list option), so they will
definitely get replies from the upper-list, they just can't post to it. The
proposed option would grant them "posting-rights" resulting in something
similar to a full list-membership.

> > It would have to work recursively. This would really make my life
> > easier; right now I manually export members from the sub-lists and add
> > them to accept_these_nonmember manually...
>
> cron, list_members + add_members or sync_members, perhaps? And do the
> generation of allowing posts (if you want to) using withlist?

I am not sure how all these work. Do you think they could do what I need? I
really think the sub-list thing is worth considering, because it is more
transparent.
Also I would prefer not to resort to the commandline, because some admins of
local lists wouldnt be able to use that.

Thanks for your quick reply, and sorry for my late answer.

Regards
Hannes

[Kẏra (thekyriarchy)]

1. This isn't a bad idea, but it won't get anywhere until it is pushed upstream. =]

2. I got here looking for something like this. I have a similar idea, but a bit simpler and non hierarchical.

It would just be a way to have sublists that only go to subset of the whole list (and possibly people not on the "main" list?). Any mechanism for that would be cool. It's pretty open-ended, but here's more of what i had in mind and how it's different:

I imagine that the sublists could be similar to gmail allowing the use of +something on the end of your email address for different things***. I see them as leaves on a tree, rather than branches, so non-hierarchical. The use case i had in mind was: i have a group of people (friends, coworkers, whoever), and some of them are planning something (a trip, an event, whatever), and they would like to plan this on the list, without it necessarily going out to everyone. They may have a short lifespan, but are useful.

Since these discussions would be part of the main list, and presumably archived on it somehow, it probably makes sense to allow anyone on the main list to opt-in to the discussion, but perhaps let the creator of the sub-list to choose who to invite/include initially.

So, perhaps this should be filed separately?

*** Gmail allows you to add +anything to the end of your gmail address, and receive messages that way. for example, if you have <email address hidden>, and someone emails <email address hidden>, it will go through as normal. This is useful for blocking spam (adding a suffix to the local part of your email address, thus allowing you to block all incoming mail addressed to that suffix).