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. 1) 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. 2) 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 [EMAIL PROTECTED] Create a list called [EMAIL PROTECTED] Add [EMAIL PROTECTED] 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 _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
