[CentOS-devel] Re: centos-d] Mailing List issues
R P Herrold
herrold at owlriver.com
Thu Dec 8 03:38:57 UTC 2005
On Thu, 8 Dec 2005, Karanbir Singh wrote:
> We all know that something needs to be done about the signal
> to noise issue on the CentOS Mailing List. Traffic is
> something we can all live with, and is a good sign - the
> Project is getting popular - but the s/n ratio seems to be
> going down the wrong path.
smile -- I have taken some heat for functionally driving away
"contributor's" who are OT, or wrong, or pests, or not willing
to follow minimal rules of channel courtesy, in the main IRC
channel. By my lights, I will continue to enforce minimal
order, in the interest of preventing a cesspool from
resulting (see, eg, #fedora).
Example is not the main thing in influencing others. It is
the only thing. -- Albert Schweitzer
I kicked a long time developmental friend from testers-list a
week or two for looking me in the eye and flooding after
warning. He got over it, I think (I hope); I know taking a
long view that it had to be done for the good of the breed.
I have consciously been prepping a couple backups in the
reasonable light moderation I do (one added newly in the
control channel), so that the moderation continues, even when
I am not present to 'swing the trout'
> To blame might have been an odd few people, but looking at
> the list in its present shape - we seem to have developed a
> general mindset thats contributing to the issues. But whats
> the problem :
Foreward: In looking back, over several years running LUG
lists, I and a couple others arrived at:
which it seems we have not had to touch since 2000; I think
of the main centos list (and the IRC channel) as our
equivalents of LUG presentations and meetings, respectively.
The second bullet:
"... their posters [sic] may be silently dropped from
the list. Long running bouncing accounts are silently
unsubscribed by the MailMan program, or manually if a mail
blockage is detected by the list administrators. Repeat
offenders will be silently removed from the list."
seems harsh, but has as it turns out only drawn two protests
in ten years. The LUG's list, the LUG's rules -- If you don't
like it? Fine and goodbye.
> 1. Drive by postings - people read a post, reply irrelevant content
Q. Does top-posting make sense?
This is of course true -- an untrimmed post, if not obviously
containing relevant content to me or a thread I am interested
in, within the first 24 lines (including a few for header as I
read it in pine), is simply going to be skipped by me with the
D key. If the poster will not take care to post relevant
content within that space, my time is too valuable to do their
work for them.
Obviously, either one has to trim heavily, or top-post to get
my attention ;)
> 2. General mindset of no moderation -
This is harder -- I have had this approach with other lists I
have run over the years -- it is a slippery slope that once
you start moderation of a few posters, you need continuous
coverage to avoid cries and claims of capricious moderation;
also, one profuse poster in centos I watch has been tosed off
the SLUG, the JAX-LUG, and is about to get tossed off the
Alpha list; he will simply re-subscribe another address and
We might try to set up a '-politics' lists, but without strong
social pressure to relocate pesky threads, that approach will
not work; we lack the physical immediacy which a local LUG
list has to enforce social conformity.
It is good manners in any social situation to go along
with what the majority are already doing when you arrive
- e.g. not lighting up in a non-smoking room, or
complaining about smoke in a designated smoking area, or
stripping to the buff in a convent, or hugging your overcoat
around you at a nudist camp.
-- a found quote at:
So I do not think bans or moderation work; the 'public health'
approach of driving offenders away works in IRC with its
ephemeral nature, but works less well in an archived list. It
reflects poorly, ex post, sometimes in a Google review of what
seemed to be reasonable conduct in the heat of the chase.
With the possibility of a potential employer or contractual
engagement downticking the moderator for pursuing the
thankless job of light moderation, I do not see that we should
seek, nor can get any volunteers for that post. ;(
> 3. Thread deviation - almost every thread seems to be
> getting blown into a few directions
>From a technical point of view, we could add a killfile for
certain Subject: regex's after a few days, or a few posts,
after a 'last call' notification -- this may work.
It might work better if we used the ad hoc content publishing
facility of the site's bbs -- I am NOT advocating a wiki --
and build a few more FAQ entries; I find that I write
(hopefully well) what I am interested in saying clearly, and
then just post a link in IRC channel -- perhaps we can end
some threads by encouraging die-hards to organize their
thoughts and puttin up a webpage ;)
> 4. OverDose of content - A question of 'bootloader not
> working' becomes 'zen and the art of bootloader design'.
see point 1 again -- control at the receiving end with the D
> What can we do about this situation ? The options that seem to exist :
> Kick off a few people, tell them to leave ? Moderate the
> entire list ? Establish some form of moderation and enforce
> it - but dont moderate the entire list.
answered with my views inline above ... but a public hanging
or two focuses the attention of the survivors.
> Also, do we need to - at this stage, look at splitting the
> CentOS list into some subject focused Lists ? Traffic is on
> the rise - and will continue to do so, which I consider a
> good thing. Do we at this stage now want to split some of
> this traffic up ?
We tried wayyy too many lists a while ago when we first
started -- if the list doesn't lure posters, it is useless.
Let's add just centos-politics (or whatever we want to call
it), with a charter and mandate that it is intentionally:
anything goes, with the topics and answers there are wide
open, and one enters only with a thick skin, and see if it
provides an outlet.
Having a pattern response for the cadre of senior centos
hands, with the mandate to post: "This thread relocated to
X-politics, and continuation should only occur there"; and
adding a killfile entry may be our only hope to either snuff
out flamefests which need to die or at least get rid of them
from the wider view in the main list channel which drowns out
other signal content.
This means devising a protocol to make sure the killfile has a
proper entry, accountably added; we may need to find or write
some code for procmail to use as a frontend to mailman,
hopefully the use of which does not require physically logging
in as root on the ML host.
> If so - what subjects / directions are we going to need ?
> Lets try and think about things as they would be 12 months
> down the road and 24 / 36 months away, what do we need to do
> to prep for that ?
Thanks for raising the issue -- hope this sheds some light.
-- Russ Herrold
More information about the CentOS-devel