[Mailman-Developers] Re: [Mailman-Users] How Do I Volunteer for a To Do list item?

Listwrangler listwrangler@iximd.com
Thu, 2 Sep 1999 22:07:56 -0500


Dear Barry,

>We'd love it if you'd help out with the documentation (an admitted
>weakness).  Currently this effort is being carried out on the
>mailman-developers@python.org list.  For now I suggest you check those
>archives and subscribe to that list.

Thanks, I'll do that. Some day... I just had to port the organization's web
site and I'm all balled up with that now. The new ISP was going to alias
the old addresses and web sites, so for the user nothing would changed.
Suffice it to say, they changed, and I can't access the web site anymore.
I'm trying to get my access restored, but have accepted the new ISP's offer
to port to a new address. Most of the links in the site are relative URLs,
but some weren't, and of course all the pointers and explanations for how
to use our online features have changed, so I have to rewrite that...

Sigh.

>Great!  We need volunteers to help out.  What MD features are you
>particularly missing?  What is broken in MM for you?

I sent a separate email about Membership Management console, so I'll skip
that here.

Regarding moderator features, I have sat down and drawn up a preliminary
list of what should be simple changes. I'll have to think harder about
deeper functionality.

But this is what I think would be helpful but easy to access.

The list administrator should have access to all functions of all lists.
Only the list administrator should have access to configuration and related
issues.

The moderator should have access to administrivia for their lists, but no
access to configuration. This is on the theory that a moderator will be a
user with limited technical skills. The goal should be to equip them with
easy to understand tools that are useful for list and user management while
preventing them from getting into configuration and other stuff they don't
understand. I walk my moderators through the screens, telling them what
they're allowed to touch and what they're not allowed to touch. They're
good people, they don't have the urge to play with things they've been told
not to play with. However, I have some staffers that might get list
responsibilities that I definitely DO NOT want to access configuration
stuff!

So I thought, the simplest thing is to just go through the admin pages and
decide which ones it's okay for the moderators to access.

Moderators access:

Membership Management
Bounce Options
Subscriber List
Tend to Pending Administrative Requests

The rest should be reserved for the administrator.

Hoever, the General Info page should be split into two pages, one for admin
only stuff, and one for moderator stuff. The moderator should be able to do
the following:

Introductory paragraph for the list
List specific text prepended to new subscriber welcome message
Test appended to an unsubscription notice
Administrivia filter
should administrator get notices of administrative requests immediately?
should administrator get notice of un/subs?
Send mail to poster when their posting is held for approval?

The other items should be reserved for the administrator, as they
presumably will have a better understanding of the implications of the
choices. Also, if there are multiple lists on one site, there should be
uniformity in naming and descriptive practices, so things like the list
name and terse description should be done in accordance with whatever the
organizations standards are, and the list admin should be responsible for
making that happen. However, the list administrator really doesn't care
what the intro message is -- that's content, which is the responsibility of
the moderator.

The moderator should also have a box for changing their password.

Password features:

There are some security features that you might want to consider adding to
the password

user must change password at next log on
remember password history (to prevent the same password being recycled)
minimum length (maybe this is there, I always use moderately long passwords
so i haven't checked)
a help file about good passwords -- eg, don't use words that can be found
in a dictionary, don't use words that can easily be guessed, don't use your
name, the listname, minimum length, etc

Another feature I think I would like is when non-posters are not allowed to
post, give an option for send the posts to the admin request pending page,
or to redirect them to a different email addy.

Real world example: We run a conference, the True Spirit Conference. The
TrueSpirit list is for conference committee members only, and is restricted
so non-members cannot post. We give out the list address as the 'more info'
address to avoid confusion. If you want TrueSpirit info, you send it to
truespirt@iximd.com . So, the general public inquiries, 'where is the
conference, how much does it cost?' get held, and the person tasked with
tending the email list can then just rejects them (and the rejection
message tells them where to get more info), and also subscribes their
address to the announcement list, so they get the press releases as they
become available. But sometimes people want to volunteer to help, or want
to make a presentation, or need to know about wheelchair access, etc, and
their inquiries need to get redirected to a human being to respond to.

So if the approval page and had another option:"redirect to: "

and then you could fill in the address, that would be great. Ideally there
would be some configuration options for the redirect, like 'default
address' to redirect to, so you could just check 'redirect' and it would
automatically get mailed without having to type in the address every time.
Then you would have to have a redirect message, that would have some canned
message like, "Thank you for your interest in _name of mailing list_. Your
query had been redirected to the proper person to follow up on." The
administrator/moderator would have the option of customing the text in the
configuration page to change what the redirect message was, or the option
of changing the response on an individual basis. (The way reject works now.)

Oh, which reminds me, where do I rewrite the default rejection message? And
if I can't, then I recommend that it be possible. There's about three
common reasons we reject, and if we could put them in the default, then I
could just click instead of typing the reason each time.

And, for the moderator, an option to prepend a simple header message for
each email would be useful. Yes, you have this, but it's blank. You've got
a footer already filled in that has the list name, URL, etc. But I don't
know the format, I want to add in a header that says, "This message posted
_date_ by _username_ to _listname_:" (The help file should give the syntax
for common headers so that non-technical moderators can choose to use them
or not.)

This is particularly helpful if the list headers have been munged to remove
the sender's address. Yes, there are debates about munging, so I won't
share my views on the subject; but in certain circumstances it's useful to
have the reply-to set to the list name while the individual poster's name
is at the top of the message.

These are the things that I keep mumbling to myself about as I work the
lists, I'll give some deeper thought to the subject and get back to you
with additional suggestions.

Gary








Listwrangler
listwrangler@iximd.com

********************
For help with subscribe/unsubscribe, troubleshooting, or more info about
The American Boyz email lists, please visit: ________ (new web page being
developed, please stand by), or request a copy of the Amboyz Elist Help
File to be emailed to you.

If you are familiar with Mailman, the following lists are implemented with
Mailman and use standard Mailman features: Amboyz-Main, Amboyz-Announce,
TrueSpirit, and ElderTG