On allowing any list member to be an email moderator
Note: the basic info of the below feature request has been posted here: http://sourceforge.net/tracker/index.php?func=detail&aid=1394592&group_id=103&atid=350103
I received an weird but interesting weird email the other day that got me thinking about moderation of GNU mailing lists. Here's a paraphrase the email:
To: Moderator Slacker Subject: Bug-slacker-project post from xxx@gnu.org requires approval
As list administrator, your authorization is requested ... [you know rest] [mail message] Dear Slacker:
We've rather belatedly realized that a you've been ignoring the moderation messages of your mailing list which now has hundreds or thousands of held messages and/or a whole lot of spam in the archives.
If you would like to volunteer to take out the trash for this or *any* of the 25 or so lists mentioned below, please email me.
Although somehow I don't think there are going to be too many takers of this fabulous offer, the email does have I think one useful idea in it. Basically for any slacker-moderated list, it's probably okay to let just about anyone do the moderation. After all, just about any human can easily detect spam from legitimate posts.
As someone who's been doing GPL projects for a long time, things have been getting tougher. In the good old days, one gave an email address for support and the email address was used for support on the project. Nowadays the email address is used to send viruses, spam and phishing requests, and to use as the return address for viruses, and spam to others. Okay. So now this moderation thing on mailing lists was then added. That then gave the person offering support the additional burden to act as a trash man for the list (in addition to his/her own personal increased spam/viruses).
The thing that always struck me as wrong about moderated lists is that for the convenience of the poster --- and often this is someone who is a novice asking for help (and sometimes in a not even in a very respectful way) -- burden is usually put on the people who might be able to help. I think of this as the N to one burden problem: a little burden (by not having to register to post) is reduced on N people (often novices), at the expense of adding N times extra burden on the "moderator(s)" (someone who is often an expert and is 1 in number). It strikes me as a poor use of the expert's time. Actually, I'm probably not the only one who feels that way, hence the result cited above.
So it might be nice to have a box or flag for such a mailing list that allows anyone who is registered in the mailing list have the pleasure of doing email moderation.
I suppose this could be subject for abuse too (discard valid posts and accept spam), but I have a feeling that to first order approximaton this would be a big help. And doesn't mailman already have ways of watching users or moderators, and revoking moderation by the administrator or whatnot?
Thanks for considering this.
At 6:40 PM -0500 2005-12-31, R. Bernstein wrote:
So it might be nice to have a box or flag for such a mailing list that allows anyone who is registered in the mailing list have the pleasure of doing email moderation.
You can list as many moderators for a list as you like.
But there's a problem with multiple moderators, one that we have on the mailman-users and mailman-developers lists ourselves -- in addition to many other lists hosted on python.org. In short, the problem is getting all the moderators to follow the same moderation policy.
Even if you have agreed on a moderation policy, there is still a certain amount of judgement required, and Barry might feel one way regarding a given post, JC might feel a different way, and I might be somewhere on the fence -- or any other combination of the various people involved.
And that's when we all agree on the policy that should be implemented, or remember what it was that we all agreed on several months ago.
I suppose this could be subject for abuse too (discard valid posts and accept spam), but I have a feeling that to first order approximaton this would be a big help. And doesn't mailman already have ways of watching users or moderators, and revoking moderation by the administrator or whatnot?
No, there is no monitoring of the moderators -- within their limited set of actions they are allowed to perform, their actions are absolute, and for the most part are not reversible -- once a message is discarded, it is gone and there's nothing you can do to get it back. The same is true of the list administrators. You could always re-subscribe someone if they've been unsubscribed by someone else, but that's about it.
The kind of monitoring you're talking about would add significant additional load on the system, and would force the administrators to do a lot more work to keep checking up on the moderators, etc.... This would further concentrate the workload on an even smaller group of people, which I think is precisely the sort of thing you were trying to eliminate.
-- Brad Knowles, brad@stop.mail-abuse.org
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755LOPSA member since December 2005. See http://www.lopsa.org/.
Brad Knowles writes:
You can list as many moderators for a list as you like.
Fine. One just needs a way for people who are members of a list to be able to volunteer to be a moderator.
But there's a problem with multiple moderators, one that we have on the mailman-users and mailman-developers lists ourselves -- in addition to many other lists hosted on python.org. In short, the problem is getting all the moderators to follow the same moderation policy.
You are way too sophisticated. Again, we are talking about general help, info, and user lists. The policy for all of these lists is simple: if you think it's spam, discard. If not, accept.
So now let's go through the false-positive cases:
- A post is not spam but is discarded.
Not a big deal. For whatever reason the poster didn't manage to convince the moderator it was not spam. The poster can join the list, or try again and maybe another moderator will approve. This is an improvement on the current situation cited where no posts go through.
- A post is spam and let through.
Still not a big deal. Recent versions allow for deleting archive messages. Still there is the annoyance to others on the list for getting unwanted spam. An obvious solution for someone annoyed would be to volunteer to do some (or more) of the moderation of it. Or drop out of the list. Still better than what happens now, which is basically no posts get through and most certainly those that are spam-infested either don't have any members or maybe they have their own spam filters.
No, there is no monitoring of the moderators ... The kind of monitoring you're talking about would add significant additional load ...
Okay. If nothing simple can be done, so be it. Personally, I think just adding a button that allows a registered user to be a moderator would grealy improve the situation described previously. The problem of getting humans to do moderation is not theoretical, but real. And basically I think that a self-moderated system by users would largely work. To some extent, I think this is proven by wikis.
Brad Knowles wrote:
But there's a problem with multiple moderators, one that we have on the mailman-users and mailman-developers lists ourselves -- in addition to many other lists hosted on python.org. In short, the problem is getting all the moderators to follow the same moderation policy.
Even if you have agreed on a moderation policy, there is still a certain amount of judgement required, and Barry might feel one way regarding a given post, JC might feel a different way, and I might be somewhere on the fence -- or any other combination of the various people involved.
That's a very interesting and accurate observation. In fact, the moderated post that started this thread is one that I don't think I would have approved for posting to this list! I felt mildly (but not strongly) that this was a discussion that should probably take place on -users first, because it's a discussion about the possibility of changing the way the mailman list is used (by it's users) rather than a discussion about "developing" a new feature, per se. But, it's not totally off-topic for -dev so Brad is also "correct" for approving it.
The main problem I think Rocky is experiencing is the problem of absent moderators, period. Rather than some automated method of turning the moderator tasks over to others, I suggest that a better way is to more closely oversee pending moderator tasks so that the list owner and the list server administrator receive notices when a moderator's queue has not been recently attended to, and address the lack of moderation while the queue is still small and relatively fresh.
To this end, I suggest a list server setting and a per-list setting for sending email notices (to the list server admin and to the list owner, respectively) daily, listing the number and type of stale moderation requests for each list. My suggestion is that the default state of this setting be set to "on" and it can be toggled off as desired, and that the default is to start sending these emails once daily when there are pending moderator items in the queue that are older than 3 days (72 hours). List server admins and list owners could then adjust these settings based on their list traffic etc.
It might also be useful to provide a cc field for the list-owner setting so that when the owner is going to be absent from list management duties this message (and all other messages that go to the list owner) could be sent to a co-owner, and to allow the owner address to be set to nomail when there's a co-owner address entered.
jc
At 6:56 PM -0800 2005-12-31, JC Dill wrote:
That's a very interesting and accurate observation. In fact, the moderated post that started this thread is one that I don't think I would have approved for posting to this list! I felt mildly (but not strongly) that this was a discussion that should probably take place on -users first, because it's a discussion about the possibility of changing the way the mailman list is used (by it's users) rather than a discussion about "developing" a new feature, per se. But, it's not totally off-topic for -dev so Brad is also "correct" for approving it.
Okay, now that is truly weird. I thought it was kind of off-topic myself, but I thought that it would be one that either you or Barry would have approved of, so I approved it on that basis.
I guess that just goes to show that you shouldn't over-think the process too much. ;)
The main problem I think Rocky is experiencing is the problem of absent moderators, period. Rather than some automated method of turning the moderator tasks over to others, I suggest that a better way is to more closely oversee pending moderator tasks so that the list owner and the list server administrator receive notices when a moderator's queue has not been recently attended to, and address the lack of moderation while the queue is still small and relatively fresh.
We're certainly seeing some issues of absentee moderators on some of the lists at python.org, where my new version of the "mmdsr" script (see http://mail.python.org/pipermail/mailman-users/2005-December/048362.html) is showing that some lists have as many as 100 messages waiting in the queue to be moderated, and some of those messages date back to May of 2005. I think that this is a problem that needs to be addressed within the Mailman package, and not just something that can be observed externally through tools like "mmdsr".
However, I am not yet sure what would be the best way to resolve this issue. I would like to see more discussion on that topic, although I'm not sure that mailman-developers is the best place to do that.
-- Brad Knowles, brad@stop.mail-abuse.org
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755LOPSA member since December 2005. See http://www.lopsa.org/.
Brad Knowles writes:
Okay, now that is truly weird. I thought it was kind of off-topic myself, but I thought that it would be one that either you or Barry would have approved of, so I approved it on that basis.
What I find truly weird is all the discussion of the moderation process on mailman-developers not to mention perhaps the moderation itself.
Please allow me explain why I initially posted to mailman-developer.
(I have no idea if this will make it to the mailman-developers list given what I'm reading so far. As I write this, my first reply to Brad Knowles is, as far as I know, being held for moderation. But I've received two other emails from that list on the thread, one of which seems to reinterpret the problem I stated.)
I wanted to request a new feature. I looked at http://www.gnu.org/software/mailman/bugs.html to find out the proper way to do so. I submitted a feature request on sourceforge.net. But I also read at the URL mentioned:
It is also recommended that you email a note about your submission to the mailman-developers mailing list, but don't rely on just the email to get the attention of the Mailman developers.
So I do that. I have to subscribe to the mailing list first. Not to be able to post -- but to have it looked at by a moderator for posting. A little bit involved, but okay. I'm actually am lucky that the initial post was accepted.
As part of the feature request, I describe the motivation for why I think the feature helpful. And now it seems as though whether or not the *moderators* think the way to get this accomplished is by adding a feature (as I guess I am not convincingly making my case) or as some other way to set up a mailing list now determines whether or not I can discuss or even *defend* my request for a feature on mailman-developers.
Finally, there is a bit of irony with respect to the spam-infested moderator-lacking list which got me to request this and the views and treatment of the mailman-developers list.
As the co-maintainer (but not the primary or main author) of that mailing list with the too much spam per valid posting, when the issue arose I suggested exactly the tight-fisted approach that seems to be in effect on mailman-developers list. That is, make people register if they want to post. (Actually, I wasn't going to then suggest moderating them *after* registering so I guess I am a bit more liberal.)
However the main author felt very strongly that people should not have to subscribe to a group in order to ask for help or post bugs on the mailing list he set up. And interestingly, the person who sent the garbage-man solicitation to GNU developers feels exactly the same way.
But here's the part that is very relevant here: others may not share the mailman-developer moderator's view of how mailing lists should be managed or maintained. I've mentioned two people above who probably don't in a strong way. It's possible or probable that in those other 25 or so lists there are more.
And an important goal of my software projects is to allow others to do things in ways that maybe I don't necessarily personally use. So again, in sum although the *moderators* may decide that the way to handle the problem described is using mailman a different way -- again -- I don't (yet). It's a feature request.
I guess that just goes to show that you shouldn't over-think the process too much. ;)
Amen.
R. Bernstein wrote:
Please allow me explain why I initially posted to mailman-developer.
Your reasons make perfect sense. I don't want you to think I was saying your reasons were "wrong" when I mentioned in my prior post that I might not have approved your initial post. Just that there is room for interpretation about if a post is "on-topic" or not, or if it's being posted to the right list or if there's a better list for the particular discussion. My point was that even moderators who are trying to follow the same "policy" and who have very similar opinions about when a post is on- or off-topic can still disagree sometimes.
(I have no idea if this will make it to the mailman-developers list given what I'm reading so far. As I write this, my first reply to Brad Knowles is, as far as I know, being held for moderation. But I've received two other emails from that list on the thread, one of which seems to reinterpret the problem I stated.)
I wanted to request a new feature. I looked at http://www.gnu.org/software/mailman/bugs.html to find out the proper way to do so. I submitted a feature request on sourceforge.net. But I also read at the URL mentioned:
It is also recommended that you email a note about your submission to the mailman-developers mailing list, but don't rely on just the email to get the attention of the Mailman developers.
There still exist some disconnects between some of the webpages (that were often written years ago) and the mailing list policies that have been changed or updated in more recent times.
A bit of history might help you to understand how we got to where we are today.
When I first joined mailman-users, it was an open list that non-members could post to. Unfortunately, it started getting a lot of spam. First Barry tried filtering out the spam and letting all "non-spam" thru to the list, but still a lot of spam got thru. Then Barry solicited volunteers to help administrate the list (and I volunteered), and we started approving non-member (non-spam) posts, and rejecting non-member (spam) posts. At this point 2 new issues surfaced.
The percentage of spam kept increasing until it was much too difficult for the owners and moderators to keep up with the moderation duties. Some days we would have upwards of 100 spam posts that had slipped past the initial spam filters and were in the moderation queue, and perhaps only a handful of on-topic posts that needed to be approved.
Some -users were replying "to the list" only - assuming that the person who asked was subscribed to the list and would see the reply - meanwhile the user didn't get their question answered (so they thought) and then posted the same question again.
I take the blame (for good or bad) of persuading Barry that due to the changing environment it was not unreasonable to require a mailman user to subscribe to the mailman-users list before posting. Once Barry agreed we changed the list to reject all non-member posts. If a mailman user had a question for -users, they had to subscribe and confirm before posting. New users on that list are not moderated. When we made this change we had to change the list info pages, the welcome message, and the text describing the mailman-users link on many different webpages. Getting this all sorted out took several months and there may still be links out there that imply that mailman-users goes to a "person" rather than being an address for a discussion list where one has to subscribe before posting.
So, that's how we ultimately dealt with the moderation problem you presently have when we encountered it on the mailman-users list.
The mailman-developers list is different. The primary purpose of -dev is for discussion about "development" of mailman code. Feature requests are a gray area - are we discussing code development, or are we discussing "using" mailman? Many feature request *discussions* are better held on -users where more actual "users" of mailman can participate. We also had problems with discussions that weren't actually about developing mailman becoming a predominant part of the list traffic on -dev, overwhelming the subscribers on -dev that only wanted to discuss actual development issues.
But, as you noted, the feature request process on sourceforge suggests you mail the -dev list when you submit a new request. We haven't quite figured out how to address this item with our current list policies. I'd love to hear your suggestions on this topic!
So I do that. I have to subscribe to the mailing list first. Not to be able to post -- but to have it looked at by a moderator for posting. A little bit involved, but okay. I'm actually am lucky that the initial post was accepted.
The primary reason that new subscribers to -dev are moderated is that for a while we were getting a lot of users who thought that their particular problem with mailman was the type of problem that they need "advanced help" with and that the people who could help would only be found on -dev. But they hadn't read the documentation, searched the FAQ, searched the -users archive, or asked on -users first. A high percentage of these "help me" posts belong on -users. A high percentage of first posts by new subscribers falls into this category.
When this problem first surfaced we tried to resolve it a different way. For a few months we added text to the confirmation message asking the subscriber to email the list admin address with their reason for wanting to join -dev, so that we could quickly approve their subscription request. Once their subscription request was approved, then they could post immediately (no moderation of the subscriber or post). A very high percentage of subscription requests were never followed up, even when we (the list admins, primarily Brad and myself) repeatedly emailed the subscriber asking for their reason for joining so we could approve their membership request. Finally we decided that this wasn't working so we changed to the current process. This allows us to head off new subscribers who shouldn't be posting to -dev, but makes it easier for people to subscribe for non-posting reasons (to lurk on the development discussion), and only introduces a small delay to the first post by first-time on-topic posters.
Normally, when the first moderated post is on-topic and thus approved we also clear the user's moderation flag. Brad didn't do that with your first post but it might have just been something he overlooked - I've overlooked doing that myself a few times.
As part of the feature request, I describe the motivation for why I think the feature helpful. And now it seems as though whether or not the *moderators* think the way to get this accomplished is by adding a feature (as I guess I am not convincingly making my case) or as some other way to set up a mailing list now determines whether or not I can discuss or even *defend* my request for a feature on mailman-developers.
I assure you that the moderators are NOT trying to interfere with your ability to make your case and engage in discussion. Our role in this is ONLY to ensure that the discussion takes place on the correct list, -users or -dev. The reason for sending some discussions to -users is to keep -dev from being flooded with posts that aren't about development, which drives some people off the list and ultimately results in fewer people developing mailman (which would be a Bad Thing, right?). There is nothing sinister about our role, and I apologize if we weren't more clear about this in our prior posts.
Finally, there is a bit of irony with respect to the spam-infested moderator-lacking list which got me to request this and the views and treatment of the mailman-developers list.
It's very hard in today's spam infested email environment to develop systems and policies that keep spam out and let on-topic discussions in without occasionally introducing delays of some sort. As you can see, we have tried several systems on these lists over the years, and it's still not a perfect system.
As the co-maintainer (but not the primary or main author) of that mailing list with the too much spam per valid posting, when the issue arose I suggested exactly the tight-fisted approach that seems to be in effect on mailman-developers list. That is, make people register if they want to post. (Actually, I wasn't going to then suggest moderating them *after* registering so I guess I am a bit more liberal.)
Your suggested new policy is the very policy we currently have in effect on -users, so IMHO it's an excellent policy for that type of list. :-)
However the main author felt very strongly that people should not have to subscribe to a group in order to ask for help or post bugs on the mailing list he set up. And interestingly, the person who sent the garbage-man solicitation to GNU developers feels exactly the same way.
Barry used to feel that way too. Very strongly, in fact. See above for why we changed to the solution we now use. We have been very happy with the results since we made the change.
But here's the part that is very relevant here: others may not share the mailman-developer moderator's view of how mailing lists should be managed or maintained.
Brad and I help moderate and administrate these lists but we try very VERY hard to make our decisions based on what Barry has told us he wants. When we have felt that the list configuration or policy should change we have had lengthy 3-way email threads with Barry to work out something that Barry approves of, and then only when Barry approves have we made the changes. So in the end, these are still Barry's lists and they are being run in a way that Barry approves. Brad and I help deal with the daily administrivia so that Barry and other key developers can devote their spare time on actually developing mailman code, instead of squandering their precious time on administrivia matters.
And an important goal of my software projects is to allow others to do things in ways that maybe I don't necessarily personally use. So again, in sum although the *moderators* may decide that the way to handle the problem described is using mailman a different way -- again -- I don't (yet). It's a feature request.
Fair enough!
Here's a suggestion that might solve the problem on your lists in the fashion you propose - create a moderator's list. Moderation requests are sent to that list. Anyone can subscribe/confirm to the moderator's list. The welcome message would give them the moderator username and password for the main list. Now they can receive the moderator requests and act on them.
For example, your main list is foo-list@example.com. Create a list called foo-moderators@example.com. Add foo-moderators@example.com to the moderators for foo-list. J Doe subscribes and confirm to foo-moderators. The welcome message tells J. Doe that the moderator's username is foo-mod and the password is foobar. When a non-member post is sent to foo-list, it goes out to all subscribers of foo-moderators. J. Doe (or any other subscriber of foo-moderators) can click on the link to the admin page, enter the username of foo-mod and the password of foobar, and then approve or reject each held post.
One risk is that a spammer may find it worthwhile to join foo-moderators so that they can approve their spam to be sent on to your list. Since the spammer could be any of the subscribers of foo-moderators it would be hard to find out which one was the spammer and remove them (and of course the spammer could just resubscribe with another email address). There may be other drawbacks with this suggestion and if so I'm sure that someone will let us all know. :-)
Leap second passed by a few minutes ago. Happy New Year everyone!
jc - volunteer moderator and admin for mailman-user and -dev
Thanks also for the suggestion of setting up a list just to send out moderator passwords. I'll pass that suggestion and the one by Robby on global detection of mailing-neglect back to the the GNU discussion group. I hope that will help. Should they go that route, I'll try to withdraw the sourceforge feature request.
Where I think something inside GNU Mailman could be a little better than a second list is that the integration could enforce that the email associated with person logging in to the webpage or sending moderation by email is also *currently* subscribed to the list***. The theory here is that spammers don't want to receive the spam they spew.
***If I have this correct, where GNU mailman seems to differ from say sourceforge bug and feature trackers is that in GNU Mailman where there is a password associated with a moderator and an administrator *account*, in sourceforge tracker, there is a moderator or administrator *flag* is associated with a account(s) to grant access. So to moderate or administer an account one uses one's selected user account and password. As a result, is easier to effect such an enforcement described above.
I guess sometimes things are not what they may seem initally, so many thanks for the detailed explanation; it all makes sense. It is also interesting to learn that the GNU mailman mailing lists have the same problems as other GNU lists. But it sounds like the GNU mailman lists have very dedicated moderators.
Again at the risk of beating this horse dead, what we're looking for is a way for mailing lists to distribute the burden of moderation such as by having the mailing list be more self moderating as it appears that the wiki works. (I could be wrong here about the wiki.) The observation is that right now, a number of mailing lists at least GNU mailing lists are just getting neglected, and this suggests something is wrong. Maybe it's just a global misunderstanding of how to set up a general help list (e.g. a documentation change), but I have a feeling it's not just that.
I don't know how to or have a suggestion as to how to deal with concerns of the getting discussions to the right user/developer group or what should be indicated when making a feature request. However I do see the wisdom in discussing things in the right venue. After all, what's important is getting ideas and solving this problem, not bothering or using up the bandwidth of the wrong people. So if this discussion should be moved to the user list, please let me know.
Again thanks.
At 12:15 PM -0500 2006-01-01, R. Bernstein wrote:
***If I have this correct, where GNU mailman seems to differ from say sourceforge bug and feature trackers is that in GNU Mailman where there is a password associated with a moderator and an administrator *account*, in sourceforge tracker, there is a moderator or administrator *flag* is associated with a account(s) to grant access. So to moderate or administer an account one uses one's selected user account and password. As a result, is easier to effect such an enforcement described above.
The current version of Mailman does not really properly support a database, which I think would be required for the kind of features you're talking about. Yes, there are at least one or two database MemberAdaptors of one sort or another, but all they do is take the existing Mailman method of working and adapt that to be compatible with databases, whereas for the kinds of features you're talking about, the reverse would really be required.
The next major version of Mailman (Mailman3) will be much more database-aware, and this would be an excellent idea to get onto their plate now.
Again at the risk of beating this horse dead, what we're looking for is a way for mailing lists to distribute the burden of moderation such as by having the mailing list be more self moderating as it appears that the wiki works. (I could be wrong here about the wiki.)
Check the recent news about WikiPedia.
The lesson is that any project which grows sufficiently large, will have such issues if they are permissive in terms of what they allow their rank-and-file subscribers to do.
I certainly occasionally hear about similar problems with the MoinMoin wiki on python.org, and it's not anywhere near as large as WikiPedia.
On another site I help administer, we take a more restrictive approach with TWiki -- accounts are free and automatically given, but you at least have to sign up for an account before you are allowed to modify anything, and certain pages are locked down as to which administrative groups are allowed to modify them -- and I haven't heard of any such issues there. On the other hand, we're also much smaller than the MoinMoin wiki on python.org, so it's hard to say what is a result of our tighter security measures and what is a result of our being a lot smaller.
-- Brad Knowles, brad@stop.mail-abuse.org
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755LOPSA member since December 2005. See http://www.lopsa.org/.
R. Bernstein wrote:
I guess sometimes things are not what they may seem initally, so many thanks for the detailed explanation; it all makes sense. It is also interesting to learn that the GNU mailman mailing lists have the same problems as other GNU lists. But it sounds like the GNU mailman lists have very dedicated moderators.
<blush>
I don't write code - my role in projects is as a product manager. Helping administer/moderate the mailman lists is one of the ways I can help "contribute" to mailman.
Again at the risk of beating this horse dead, what we're looking for is a way for mailing lists to distribute the burden of moderation such as by having the mailing list be more self moderating as it appears that the wiki works. (I could be wrong here about the wiki.)
There are a lot of differences between editing a wiki and moderating a list. Most people edit a wiki by adding content in areas where they have knowledge. Sometimes this contribution is prodded by going to the wiki to *get* the information and discovering that it's not there, and realizing that they are well suited for putting it there. There's also immediate positive reinforcement, their words are now on the web for all to see. When they need to refer someone to the content they can say "go to the wiki" and their words will be there for the other person to refer to. So they get value (something they made is "there" and can be used later) and recognition from this activity, and that positively reinforces their efforts and encourages them to do more of it.
The process of digging thru spam to find on-topic posts that should go to a mailing list is not nearly so rewarding. (The term "Thankless task" comes to mind.) Without receiving reminders that there are posts waiting for moderation, there is no event to nudge moderators to go moderate. Once they have moderated the posts, there is no recognition that they discarded all that spam, that they were the ones who "freed" the held posts for delivery on to the list. I don't think you will get a lot of participation from a wide range of your list membership. I think that you will find that a very small number of your list members regularly do the moderation duties and that occasional moderation by other list members is very very rare.
Another option for the solution I proposed is to just give out the moderator's username and password in the footer of the main list, in addition to having a moderators list. Now a would-be moderator has 2 different ways they can participate - they can just randomly log in from time to time to see if there is anything that needs moderating, or they can subscribe to the moderator's list to receive notices when there are posts that need moderating. You still don't have any way to track who moderated the post, but you would make participation easier because they don't have to subscribe to the moderator's list to get the username and password.
In your original proposal you suggested a box or flag that allows anyone who is a subscriber to the list to moderate the list, which provides the individual activity tracking. If we were to add this, I think that this should be a *member* setting (mod-access) rather than a *list* setting, and then it can be added to the new member config options. A list owner could then configure the list to have new members automatically included in the people who can moderate the list, and the mod-access flag can be turned off (or back on) member by member for existing members.
The observation is that right now, a number of mailing lists at least GNU mailing lists are just getting neglected, and this suggests something is wrong. Maybe it's just a global misunderstanding of how to set up a general help list (e.g. a documentation change), but I have a feeling it's not just that.
Moderating a mailing list is a different type of activity than contributing code. For best results you need to enlist, encourage, and reward (with recognition from the list owners or key developers) the people who do this work, even if you do all the reward and encouragement in private email to your helpers. This goes a long way towards keeping them happy. I do this work on the mailman lists as a service to the mailman community, but when Barry says "thanks" that's a real motivator for me to continue. I'm pretty sure Brad feels similarly.
I don't know how to or have a suggestion as to how to deal with concerns of the getting discussions to the right user/developer group or what should be indicated when making a feature request. However I do see the wisdom in discussing things in the right venue. After all, what's important is getting ideas and solving this problem, not bothering or using up the bandwidth of the wrong people. So if this discussion should be moved to the user list, please let me know.
The -dev list is fairly quiet right now, so it's not a bad thing to have this discussion here. You might want to post on -users as well, you will reach more people, different people, and get some additional perspectives on your problem and possible solutions. -users is a better place to drum up support for the feature request - if we get many other list owners who say "hey, we could use this on our lists too" then that helps move the feature request priority up and encourages a developer to consider writing the code.
jc
On Sun, 2006-01-01 at 12:15 -0500, R. Bernstein wrote:
***If I have this correct, where GNU mailman seems to differ from say sourceforge bug and feature trackers is that in GNU Mailman where there is a password associated with a moderator and an administrator *account*, in sourceforge tracker, there is a moderator or administrator *flag* is associated with a account(s) to grant access. So to moderate or administer an account one uses one's selected user account and password. As a result, is easier to effect such an enforcement described above.
Yes. This sucks about Mailman, and it's something we plan to fix in MM3 by having a real user database. ;)
-Barry
"R" == R Bernstein rocky@panix.com writes:
R> Where I think something inside GNU Mailman could be a little
R> better than a second list is that the integration could enforce
R> that the email associated with person logging in to the webpage
R> or sending moderation by email is also *currently* subscribed
R> to the list***. The theory here is that spammers don't want to
R> receive the spam they spew.This is little help. The spammer simply uses a throwaway address that they have no intention of reading. That's part of the spammers' manual by now. Total cost per week: $0.23.
R> But it sounds like the GNU mailman lists have very dedicated
R> moderators.They do. It's not an accident. Part of the reason is that Mailman is Python culture. Python's development community is very business- oriented; they have a healthy respect for good administration. It's not just a question of of eating your own dogfood; it's question of making the big dogs who eat your food feel welcome to come in and help with the process, and paying them due respect even though they can't even cook up spam (the Monty Pythonic kind). This is resoundingly successful for Mailman because developing list software is its business, but as Brad occasionally mentions he also works on the general Python lists, too. I don't think that's an accident. And, of course, the Python and Mailman communities are large.
The typical GNU project (or Sourceforge, for that matter) _can't_ work this way. Usually the mailing list owner and moderator is also the project lead. Mailing list management (including the parts that AI is not yet I enough for, like spam management) is not what they imagine themselves doing. I don't blame them, but I also have no ideas for reducing the burden to the levels they imagine.
R> Again at the risk of beating this horse dead, what we're
R> looking for is a way for mailing lists to distribute the burden
R> of moderation such as by having the mailing list be more self
R> moderating as it appears that the wiki works. (I could be wrong
R> here about the wiki.)You're wrong about comparing the mailing list to the wiki. :-) Wikis have a substantially lower burden on both ends. First, spamming wikis is both more expensive (wiki input has no equivalent to RFC 2821) and less productive for spammers. Email (and netnews) spamming is push; the readers get it whether they ask for it (that particular post, of course they asked for the list or newsgroup) or not. Wikis are pull; the readers are in an unreceptive mood: they're looking for something else _specifically_ when they follow a link.
Not only that, but they have the power to do something about *that particular spam*. This means that the half-life of spam on a wiki is short; in mail, it lives until somebody (or a smart-enough spam-filter) reads that copy. In other words, the "casual moderator" gets the satisfaction of nuking the spammer that bit her on the wiki, whereas with a mailing list it's "paying forward" to the other users for _future_ spams ... those user have already received this one. Not as satisfying.
R> The observation is that right now, a number of mailing lists at
R> least GNU mailing lists are just getting neglected, and this
R> suggests something is wrong. Maybe it's just a global
R> misunderstanding of how to set up a general help list (e.g. a
R> documentation change), but I have a feeling it's not just that.It is "just that". You need dedicated staff to handle spam on an open list.
That's all there is to it. Spammers are a hostile entity, always looking for ways to break down your security, banging on your door every day. Unlike GNU volunteer moderators, they get paid in hard cash for what they do. And it's a lot more fun to screw the moderators than to be one (for the perverts who enjoy breaking into things, anyway). So there's only so much a machine can do to combat that.
All of the above, though stated as fact for emphasis, is of course IMO only.
R> So if this discussion should be moved to the user list, please
R> let me know.I think you'll get much more fruitful discussion there. The Mailman Developers list is primarily about how to implement the specification. "Stop Spam" is not a specification, it's a requirement that will interact with others to constrain the specification. Although many of us on Mailman Developers are active in list administration and moderation, you'll get a much broader and more casual audience on Mailman Users ... and your whole point is to find ways to get the casual moderator to be more active. That's also a requirement, not a specification. :-)
-- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.
First let me say that I think JC and Brad are doing a great job moderating the lists, and I /greatly/ appreciate their help with this!
Second, I think there's one more use case that might work well for general help lists like mailman-users (but not mailman-developers). There should be a way for non-members to "self-moderate", essentially using a technique similar to subscription confirmations. If you were a non-member poster who replied to the confirmation, your message would go through. Non-confirmed posts would be automatically discarded or bounced after a certain amount of time.
Come to think of it, a list like mailman-developers could use a variant similar to the confirm-and-approve for subscriptions. Admins would only see confirmed messages in their queue. At that point, most spam should be deleted and the moderator only as to decide whether the message is on-topic or not (something that will always be a judgment call).
-Barry
At 9:14 PM -0500 2006-01-01, Barry Warsaw wrote:
Come to think of it, a list like mailman-developers could use a variant similar to the confirm-and-approve for subscriptions. Admins would only see confirmed messages in their queue. At that point, most spam should be deleted and the moderator only as to decide whether the message is on-topic or not (something that will always be a judgment call).
If confirmations were required for posting by non-members (before the messages would make it into a moderation queue), I think that would pretty much completely solve all the moderation problems that I have personal experience with.
But then we're getting dangerously close to tools like Active Spam Killer or TMDA, which I am generally violently opposed to.
Maybe those kinds of tools are appropriate for mailing list use but not personal use, I dunno....
I'll have to think long and hard on that topic.-- Brad Knowles, brad@stop.mail-abuse.org
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755LOPSA member since December 2005. See http://www.lopsa.org/.
"Brad" == Brad Knowles brad@stop.mail-abuse.org writes:
Brad> But then we're getting dangerously close to tools like
Brad> Active Spam Killer or TMDA,Technically, yes.
Brad> which I am generally violently opposed to.
Brad> Maybe those kinds of tools are appropriate for mailing
Brad> list use but not personal use, I dunno....I wouldn't make that distinction. Rather, I would say, does this address have to be well-known and open? (Bug and help lists, yes.) Can potential users be informed that the address is protected by a challenge-response system? (In the README and on the home page, yes.) Is it better than the alternative of requiring them to subscribe (and optionally set themselves to no-mail)? (Not clear, if subject to further moderation.)
Although I quit TMDA as soon as I realized I'd forgotten to whitelist my Mom, I'd still consider using it for the address I publish on my home page, _if it were uniquely for people who view that page_. Ie, if I don't ever write mail from that address (or perhaps only in response to inquiries to that address).
Of course IMHO FWIW YMMV. HTH.
-- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.
On Sun, 2006-01-01 at 22:10 -0600, Brad Knowles wrote:
But then we're getting dangerously close to tools like Active Spam Killer or TMDA, which I am generally violently opposed to.
I think they're different use cases. My main problem with such tools is when people email me first, I try to be helpful, and then have to go through extra dances to get that response to them.
That wouldn't be the case with Mailman. In our case, we're actually reducing the dance people have to go through to get their message posted. The biggest danger is from abuse by replybots though, so we have to think about that. It's also a potential problem with subscription requests, and I see those and what I'm proposing as being very closely related.
-Barry
On Dec 31, 2005, at 23:22, Brad Knowles wrote:
some lists have as many as 100 messages waiting in the queue to be moderated, and some of those messages date back to May of 2005. I think that this is a problem that needs to be addressed within the Mailman package, and not just something that can be observed externally through tools like "mmdsr".
Here's what I've done for somewhat unrelated reasons:
patch bin/discard to support rejecting held messages and providing rejection comments.
add a cron job that rejects held messages older than 10 days, with the following comment:
"Your message was automatically rejected after being on hold too long without moderator action."
The reason I set out to expire held messages was not because of absentee moderators, but because of overworked moderators who had trouble with the sheer workload of deleting spam from batches of lists they run. With expiration in place, they can simply pick out and approve the few legitimate posts every so often, leaving the rest to rot.
I mention this because you're on the subject of ridiculously long-held messages, which my changes eliminate entirely. But also, for lists with absentee moderators, held message expiration should have two harmless effects:
removing all held spam eventually, by way of removing all old held posts.
informing legitimate moderated senders that the moderator is likely absent, and definitely did not discard their post. So if they know of some other way to post without incurring moderation or some other way to contact the moderator they should use it.
If I had this to do over, I would probably say the timeout and action (discard, reject with configurable comment, approve) for expiring held messages ought to be configurable sitewide and/or per-list rather than hardwired in a cron job. Some people take longer vacations than others, and for some lists the failure mode of rejecting all posts is undesirable.
I would also want to consider the relationship of any such configuration with mm_cfg.PENDING_REQUEST_LIFE. It appears that some subscription requests and confirmation cookies for held posts may already expire on their own schedule, and that the rationale for this might inform the design of held message expiration.
--RobbyAt 3:48 AM -0500 2006-01-01, Robby Griffin wrote:
Here's what I've done for somewhat unrelated reasons:
patch bin/discard to support rejecting held messages and providing rejection comments.
add a cron job that rejects held messages older than 10 days, with the following comment:
"Your message was automatically rejected after being on hold too long without moderator action."
I like both of these modifications. Have you already submitted patches for them to SourceForge? If not, could I talk you into doing that?
I'd certainly like to apply these modifications to the other site I help administer, and I'd like to talk to Barry about incorporating these features on python.org.
If I had this to do over, I would probably say the timeout and action (discard, reject with configurable comment, approve) for expiring held messages ought to be configurable sitewide and/or per-list rather than hardwired in a cron job.
Agreed. But I would think that this would be a relatively minor enhancement over the original modification.
I would also want to consider the relationship of any such configuration with mm_cfg.PENDING_REQUEST_LIFE. It appears that some subscription requests and confirmation cookies for held posts may already expire on their own schedule, and that the rationale for this might inform the design of held message expiration.
That's also a good idea.-- Brad Knowles, brad@stop.mail-abuse.org
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755LOPSA member since December 2005. See http://www.lopsa.org/.
On Jan 1, 2006, at 13:51, Brad Knowles wrote:
At 3:48 AM -0500 2006-01-01, Robby Griffin wrote:
Here's what I've done for somewhat unrelated reasons:
patch bin/discard to support rejecting held messages and providing rejection comments.
add a cron job that rejects held messages older than 10 days, with the following comment:
"Your message was automatically rejected after being on hold too long without moderator action."
I like both of these modifications. Have you already submitted patches for them to SourceForge? If not, could I talk you into doing that?
I'll go ahead and post what I have as it relates to 2.1.4, and point out that held message expiration in 2.1.7 already exists but could use minor improvements.
I don't have a lot of time to work on it right now, and as I started to think about putting together clean diffs against 2.1.7, I observed that my changes are *almost* obsolete: sometime after 2.1.4, a per-list config parameter for "max_days_to_hold" was added, and bin/checkdbs uses it to expire held messages. But it supports only discard, and not reject/comment or approve. Also, it does not deal with stale held messages whose lists have since been deleted.
See patch #1394949.
--RobbyOn Sat, 2005-12-31 at 22:22 -0600, Brad Knowles wrote:
Okay, now that is truly weird. I thought it was kind of off-topic myself, but I thought that it would be one that either you or Barry would have approved of, so I approved it on that basis.
I definitely think it's on-topic for mm-dev.
-Barry
On Sat, 2005-12-31 at 18:56 -0800, JC Dill wrote:
The main problem I think Rocky is experiencing is the problem of absent moderators, period. Rather than some automated method of turning the moderator tasks over to others, I suggest that a better way is to more closely oversee pending moderator tasks so that the list owner and the list server administrator receive notices when a moderator's queue has not been recently attended to, and address the lack of moderation while the queue is still small and relatively fresh.
One of the problems that I have with the moderation workflow is that I have to log into every list I'm going to moderate, and then that login authentication is lost when I kill my browser.
I don't know how common my experience is but I've been terrible lately in moderating the dozen or whatever lists I'm an admin for. If it was just one list, and if I didn't have to go through the login dance every time, I think I'd do more moderating. Or if I could log in once and get to all my lists, that would be much better too. Of course, that requires the federated user database that MM3 is all about.
When I do have tme to moderate all my lists, it takes me a long time to do so, which is why I don't do it very often. Aside from the login issues, I think the admindb web interface is just so crappy that it's really hard to easily separate the wheat from the chaff. I find that my typical approach is to scan the summary, opening any potential ham in a tab window ($1M to whoever thought up /that/ particular browser feature!). Then I approve all the hams and go back to the summary list, using Skip Montanaro's (IIRC) awesome "discard-all-deferred" feature to finish up the list.
So I'd be interested to hear ideas for improving the admindb interface. Ultimately, my dream is to have an IMAP interface to the admin queue, then I could just move the ham to one special folder and just delete the spam. I'm not sure exactly how to do rejects, but a "reply" or "forward" is probably good enough.
-Barry
At 8:57 PM -0500 2006-01-01, Barry Warsaw wrote:
One of the problems that I have with the moderation workflow is that I have to log into every list I'm going to moderate, and then that login authentication is lost when I kill my browser.
That's why I never kill my browser anymore.I find that mytypical approach is to scan the summary, opening any potential ham in a tab window ($1M to whoever thought up /that/ particular browser feature!). Then I approve all the hams and go back to the summary list, using Skip Montanaro's (IIRC) awesome "discard-all-deferred" feature to finish up the list.
I do exactly the same. For smaller lists, or lists with lower moderation load, that works okay.
For the larger ones, I'd like to see something like Skip's "mmfold.py" script that could run locally on the same server where the lists are located, so that no use of a web browser is required, and so that the program could directly access the Python pickles in question. That would make it a lot easier for me to manage some of the lists on the other main site where I volunteer.
So I'd be interested to hear ideas for improving the admindb interface.
The admindb interface is one thing that needs improvement. But I'd also like to see alternatives we could use that completely avoid the use of any web browser, etc....
Ultimately, my dream is to have an IMAP interface to the admin queue, then I could just move the ham to one special folder and just delete the spam. I'm not sure exactly how to do rejects, but a "reply" or "forward" is probably good enough.
IMAP would probably be an improvement over what we have now, assuming you've got a decent IMAP client -- that's not necessarily a valid assumption. But my experience is that IMAP falls down too (especially depending on the IMAP server implementation), and you need something even scalable when that happens.
-- Brad Knowles, brad@stop.mail-abuse.org
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755LOPSA member since December 2005. See http://www.lopsa.org/.
On Sun, 2006-01-01 at 22:05 -0600, Brad Knowles wrote:
For the larger ones, I'd like to see something like Skip's "mmfold.py" script that could run locally on the same server where the lists are located, so that no use of a web browser is required, and so that the program could directly access the Python pickles in question. That would make it a lot easier for me to manage some of the lists on the other main site where I volunteer.
I'm actually thinking we need /less/ magic in command line scripts, especially for typical user and admin tasks, because I think increasingly, fewer people have access to the command line (or know what to do with it when they've got it).
The admindb interface is one thing that needs improvement. But I'd also like to see alternatives we could use that completely avoid the use of any web browser, etc....
I'm keen on the idea of making Mailman access available via xmlrpc or somesuch, and then we can provide scripts that can be run on the client w/o requiring a browser.
IMAP would probably be an improvement over what we have now, assuming you've got a decent IMAP client -- that's not necessarily a valid assumption. But my experience is that IMAP falls down too (especially depending on the IMAP server implementation), and you need something even scalable when that happens.
True. (Aside: why do all mail clients suck so much? :)
-Barry
Barry Warsaw wrote:
I'm actually thinking we need /less/ magic in command line scripts, especially for typical user and admin tasks, because I think increasingly, fewer people have access to the command line (or know what to do with it when they've got it).
Wearing my product manager's hat here - I request that EVERY administrative function be usable in all 3 methods - via the command line, via email, and via the admin webpage. The underlying function would always be the command line task but it could then be called via the other 2 methods. If this is not already a feature of MM3, I'm formally making it a request now. Please???
As a work-around for those who don't have direct command line access, and for ease of implementation in the web UI, I suggest we build a tool that takes a line of text via web form input, processes it on the command line, and spits the resulting command line text back out on a web page (concatenated with previous (in the past x minutes) commands and their results from this user, e.g. a screenshot of the command line interface). This tool would be a work-around for all the places where we haven't built a more elegant web interface for the given command line tool/function. The server admin should have options to enable or disable this access when installing mailman, or when installing/configuring each new list. Are there security implications with this that are not easily addressed?
Finally, to address Barry's concern that many people don't know what to do with the command line - even if they don't know what to do, it's still useful for them to have access to it. I've done a lot of work on other people's PCs where I access the command line and type a few commands and this gets me info to help me solve their problem. In some cases I talk them thru using the command line themselves (e.g. tell them how to do a ping, or tracert). If this tool was not available at all, it would make it much harder for me to help them fix their problems. I expect that similar things will happen when experienced mailing list server admins try to help novices, so we avoid designing a system without the tools that the experienced server admins need to get the job done.
jc
At 12:07 PM -0500 2006-01-03, Barry Warsaw wrote:
I'm actually thinking we need /less/ magic in command line scripts, especially for typical user and admin tasks, because I think increasingly, fewer people have access to the command line (or know what to do with it when they've got it).
The command-line scripts are not for your average joe-user sites. The command-line scripts are for people like me, Chuq, Skip, and anyone else who operates or may want to operate a larger site, and has not written such a tool for themselves -- at least, not yet.
That is, unless you can build an admin interface that can deal with hundreds of thousands of queued messages without killing both the server and the client.
I'm keen on the idea of making Mailman access available via xmlrpc or somesuch, and then we can provide scripts that can be run on the client w/o requiring a browser.
I'm not opposed to that, but I'd want to make sure those kinds of tools could also be run on the server where the list is hosted.
IMAP would probably be an improvement over what we have now, assuming you've got a decent IMAP client -- that's not necessarily a valid assumption. But my experience is that IMAP falls down too (especially depending on the IMAP server implementation), and you need something even scalable when that happens.
True. (Aside: why do all mail clients suck so much? :)
All mail servers suck, too.-- Brad Knowles, brad@stop.mail-abuse.org
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755LOPSA member since December 2005. See http://www.lopsa.org/.
"BAW" == Barry Warsaw barry@python.org writes:
BAW> One of the problems that I have with the moderation workflow
BAW> is that I have to log into every list I'm going to moderate,
BAW> and then that login authentication is lost when I kill my
BAW> browser.I simply have a local file that puts each of about 18 (way too many, but no time to clean up :-( ) XEmacs lists in a separate frame.
I would assume I could use the
http://USER:PWD@lists.DOMAIN.TLD/lists/admindb/LIST
form to autologin. Haven't tried, I'm anal-compulsive about password protection, and my browser usually lives for a couple months at a time.
BAW> I find that my typical approach is to scan the summary,
BAW> opening any potential hamI assume you mean "ham = on-topic, spam = off-topic, possibly but not necessarily UCE"?
Our lists don't have a topicality problem, so I don't think I've ever had need to open a post. The summary subject invariably shows spam vs. ham. Unfortunately, you can't open a subscription request. I know, the text doesn't show much in most cases, but we could look for header forging. I don't understand why this distinction was made; would it cost resources to give access to the subscription requests?
My only problem with the current interface form is that the form is a little too big to be conveniently used in a format of 3 columns of 6 rows of frames.
So from my point of view improving the admin interface is not that high-priority.
-- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.
At 12:21 PM +0900 2006-01-03, Stephen J. Turnbull wrote:
Our lists don't have a topicality problem, so I don't think I've ever had need to open a post. The summary subject invariably shows spam vs. ham.
I can't speak for Barry or anyone else, but when I use Mailman to handle mailing lists for webmaster, postmaster, etc..., there is a 99% chance that any one particular message is spam, and I have to take a look at the remaining 1% to see if they've managed to forge a plausible subject line on something that we would rather not be allowed through to the list.
Since one known tactic of spammers is to take list archives and slice off message bodies and replace them with their own, I think that this is a necessary step -- for me, on the mailing lists I help manage, the way I help to manage them.
My only problem with the current interface form is that the form is a little too big to be conveniently used in a format of 3 columns of 6 rows of frames.
Which I think is part of why Skip created mmfold.py.-- Brad Knowles, brad@stop.mail-abuse.org
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755LOPSA member since December 2005. See http://www.lopsa.org/.
"Brad" == Brad Knowles brad@stop.mail-abuse.org writes:
Brad> I can't speak for Barry or anyone else, but when I use
Brad> Mailman to handle mailing lists for webmaster, postmaster,
Brad> etc..., there is a 99% chance that any one particular
Brad> message is spam, and I have to take a look at the remaining
Brad> 1% to see if they've managed to forge a plausible subject
Brad> line on something that we would rather not be allowed
Brad> through to the list.If it's really necessary to look so that you can get from 99% to 100%, then there needs to be some improvement in the UI.
Suggestion: provide a spam-oriented (rather than netiquette-oriented) moderator screen option.
All the ban-author options should go, they take up _way_ too much space. In all the lists I've ever subscribed to, I've only seen one case where they would have been appropriate, and that guy quickly learned not only how to change from, sender, and envelope, but also his IP addresses. I've never seen a case on XEmacs lists (ie, in long but limited-scope experience as a moderator).
There are lists where identifiable senders _are_ a problem, so this should be optional. I think everybody has a spam problem, though---I'd vote for the spam-oriented layout as the default.
I would sort/group on (prefix-scrubbed) subject rather than sender; non-whitelisted senders rarely send more than one topic in a short period, although they often get frustrated by moderation and mail system delays and repost. And spammers often use multiple fake authors for multiple tries of a given subject. Both would be conveniently trapped by this sort.
Where possible, the information _and the controls_ for a single entry should be on a single line. I think it's reasonable to assume as a default that the moderator has at least a 1024px width screen and can read small enough type to put 100 characters on a line, and provide an alternative format for people who moderate from their cellphones or need inch-high fonts. (Obviously with
80 characters per line you need the vertical rules to separate fields.) I'd try arranging as | Sender | CCs | controls | Subject | to optimize eye and mouse movement.
The Defer/Approve/Reject/Discard options can be enormously compressed by getting rid of the tags. For graphical browsers, use rotated text (SVG or prerotated PNGs) in column headers, repeated every 20 rows (#rows should be configurable). For non-graphical browsers, use initials (D/A/R/X).
It would be very nice if it could be arranged that each column was of a fixed width but with a horizontal scrollbar every twenty rows or so. This would allow most froms to be identified in 15-20 characters, but convenient scrolling if you wanted to see more. I'm not sure how to arrange that in HTML, offhand, but I suspect it can be done for common browsers.
-- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.
At 5:32 PM +0900 2006-01-03, Stephen J. Turnbull wrote:
- All the ban-author options should go, they take up _way_ too much space. In all the lists I've ever subscribed to, I've only seen one case where they would have been appropriate, and that guy quickly learned not only how to change from, sender, and envelope, but also his IP addresses. I've never seen a case on XEmacs lists (ie, in long but limited-scope experience as a moderator).
I find that I use those functions pretty frequently on the various lists that I help administer at ntp.isc.org. I don't think I've used them yet in helping to moderate lists at python.org, however.
There are lists where identifiable senders _are_ a problem, so this should be optional. I think everybody has a spam problem, though---I'd vote for the spam-oriented layout as the default.
I could support that view. For myself, I would turn those options back on, but that would be more of a personal thing.
For me, the problem is not one of screen space. The problem is one of server performance. I can hit "page down" pretty frequently and get through a list of messages reasonably fast. But when I've got a thousand messages queued up for moderation, my entire machine grinds to a halt as it tries to render that page -- very, very, very, very, very slowly.
This is why I want those command-line server-side tools.
- I would sort/group on (prefix-scrubbed) subject rather than sender;
Agreed.
- Where possible, the information _and the controls_ for a single entry should be on a single line. I think it's reasonable to assume as a default that the moderator has at least a 1024px width screen
Now there, I disagree. My machine is a few years old, but there are still plenty of laptops being built and shipped today that have relatively small screens, and laptops are quickly becoming the default computer instead of desktops.
Morever, we can't know the typeface/font size choices that the moderator has made in their web browser, so what may fit on your one line may wind up being effectively three poorly formatted lines for someone who is visually impaired.
The Defer/Approve/Reject/Discard options can be enormously compressed by getting rid of the tags.
Based on my other disagreements above, I think it's pretty obvious that anything built on top of those premises would get further and further into the "bad idea" category.
- It would be very nice if it could be arranged that each column was of a fixed width but with a horizontal scrollbar every twenty rows or so.
IMO, this violates the concept of getting everything onto one line, so that you can compress things as much as physically possible. Either go with an idea or don't, but don't go with an idea and then muck it up at the last moment.
From everything you've said, I think you would like Skip's mmfold.py script. I think you should check it out.
-- Brad Knowles, brad@stop.mail-abuse.org
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755LOPSA member since December 2005. See http://www.lopsa.org/.
"Brad" == Brad Knowles brad@stop.mail-abuse.org writes:
- Where possible, the information _and the controls_ for a single entry should be on a single line. I think it's reasonable to assume as a default that the moderator has at least a 1024px width screen
Now there, I disagree. My machine is a few years old, but
there are still plenty of laptops being built and shipped
today that have relatively small screens, and laptops are
quickly becoming the default computer instead of desktops.Ah, the disadvantages of living in Japan, Inc. The option of a laptop with less than 1024x768 hasn't been available to me for several years in this country. (Might have something to do with kanji requiring high resolution, too.)
Morever, we can't know the typeface/font size choices that the
moderator has made in their web browser, so what may fit on
your one line may wind up being effectively three poorly
formatted lines for someone who is visually impaired.Isn't that what I just said (and you snipped)? I'm well-aware of the problem; I have to read Japanese, which (for comfort as a non-native) requires fonts with approximately twice the minimum resolution I can reasonably use for English.
My reason for proposing that as default, though, is that if somebody requires bigger fonts or smaller screen, then really, shouldn't somebody with good eyes or equipment volunteer for that burden? Of course sometimes they gotta or they wanna, so we *must* keep the current format (or an incremental improvement on it) as an option. But I would expect that those with even mild impairment would self-select out of that job on average.
Brad> From everything you've said, I think you would like
Brad> Skip's mmfold.py script. I think you should check it out.I already do like it. Most of the moderators I know don't have the necessary shell access, though.
-- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.
At 11:38 PM +0900 2006-01-03, Stephen J. Turnbull wrote:
My reason for proposing that as default, though, is that if somebody requires bigger fonts or smaller screen, then really, shouldn't somebody with good eyes or equipment volunteer for that burden?
I don't think you can make that assumption. Many people are just barely getting by on their own, and we've even got a lot of hosting sites running Plesk or crap like cPanel or MacOS X Server, or with heavily customized "normal" Mailman configurations, and yet they get absolutely no site administrator support at all.
Any default change like this would have to be something that a list moderator could configure for themselves, without any intervention on the part of the list administrator, and especially without any intervention on the part of the site administrator.
But I would expect that those with even mild impairment would self-select out of that job on average.
When you're in a ghetto and no way out, when the power & gas company starts sending you invoices that are not intelligible and your heating bill goes up by a factor of ten in a single month, what do you think people are going to do?
Brad> From everything you've said, I think you would like Brad> Skip's mmfold.py script. I think you should check it out.I already do like it. Most of the moderators I know don't have the necessary shell access, though.
All you need is shell access somewhere. It does everything over HTTP, so it doesn't have to be run on the server where the list is hosted. That should make the job a lot easier, albeit still not as simple as pointing their existing favourite web browser at the appropriate admindb page.
-- Brad Knowles, brad@stop.mail-abuse.org
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755LOPSA member since December 2005. See http://www.lopsa.org/.
On Tue, 2006-01-03 at 12:21 +0900, Stephen J. Turnbull wrote:
I would assume I could use the
http://USER:PWD@lists.DOMAIN.TLD/lists/admindb/LIST
form to autologin. Haven't tried, I'm anal-compulsive about password protection, and my browser usually lives for a couple months at a time.
its a form so not quite like that - try http://lists.DOMAIN.TLD/lists/admindb/LIST?adminpw=yourpassword
Personally I have a bookmarks folder within Firefox with all the lists I handle as bookmarks within that set up with password. I then just right click on the folder, "open in tabs" and have all the list admin interfaces opened at once...
[I'm reasonably relaxed about having the list moderation or admin passwords available in clear on my box - I think its a reasonable trade off compared to the other options. I *always* log off my box (so close the browser) when I'm going to be away for more than a couple of hours, so keeping a browser running for days is not an option]
Nigel.-- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ]
On Tue, 2006-01-03 at 09:09 +0000, Nigel Metheringham wrote:
its a form so not quite like that - try http://lists.DOMAIN.TLD/lists/admindb/LIST?adminpw=yourpassword
Personally I have a bookmarks folder within Firefox with all the lists I handle as bookmarks within that set up with password. I then just right click on the folder, "open in tabs" and have all the list admin interfaces opened at once...
Brilliant!
[I'm reasonably relaxed about having the list moderation or admin passwords available in clear on my box - I think its a reasonable trade off compared to the other options. I *always* log off my box (so close the browser) when I'm going to be away for more than a couple of hours, so keeping a browser running for days is not an option]
I'm also not worried about it. I almost never work on a multi-user box anyway.
-Barry
On Tue, 2006-01-03 at 12:21 +0900, Stephen J. Turnbull wrote:
BAW> I find that my typical approach is to scan the summary, BAW> opening any potential hamI assume you mean "ham = on-topic, spam = off-topic, possibly but not necessarily UCE"?
In this context, yep!
Our lists don't have a topicality problem, so I don't think I've ever had need to open a post. The summary subject invariably shows spam vs. ham.
Often, but not always. I probably find myself tricked about 10% of the time. ;)
Unfortunately, you can't open a subscription request. I know, the text doesn't show much in most cases, but we could look for header forging. I don't understand why this distinction was made; would it cost resources to give access to the subscription requests?
Probably not. I'm sure there was a "good" reason buried in history, but it's not a bad idea to revisit this.
-Barry
participants (7)
-
Barry Warsaw -
Brad Knowles -
JC Dill -
Nigel Metheringham -
R. Bernstein -
Robby Griffin -
Stephen J. Turnbull