Mike Doty wrote:
All-
We're going to change the -dev mailing list from completely open to where
only devs can post, but any dev could moderate a non-dev post. devs who
moderate in bad posts will be subject to moderation themselves. in addition
the gentoo-project list will be created to take over what -dev frequently
becomes. there is no requirement to be on this new list.
This will probably remove the need for -core(everything gets leaked out
anyway) but that's a path to cross later.
We're voting on this next council meeting so if you have input, now would be
the time.
Hmm, given that I'm the one who planted the seed for -project, I have to wonder
if the seed has grown in a way that might be useful. Or if it has merely become
a weed now, and should be pulled from the garden.
Here's what my thinking was when I put out the initial e-mail calling for
-project, including thoughts now on how they should be laid out now:
- I envisioned three mailing lists, essentially:
* core
* dev
* project
- core: private, dev-only mailing list for internal discussion
* Possibility: becomes read-only to the public after
a set time limit, possibly 1, 2, 4, or 6 months.
Certain messages and threads could be marked (via
some feature, for example) to remain permanently
private, and thus would never be readable by the
public. This policy would NOT apply retroactively.
- dev: open, dev and user mailing list for technical discussions about
the gentoo project. Topics would include package
addition/removal/masking announcements, EAPI discussions,
package development questions/inquires (i.e., from users,
but NOT help -- gentoo-user exists for that).
* Possibility: Package changes, such as moves,
deletions, additions, and so forth could also be
routed automatically to a -dev-announce ML, possibly
by prefixing the subject field with "[ANNOUNCEMENT]:"
(This prefix, would of course, be stripped by the
automatic mailer before posting to -dev-announce).
* Possibility: topics could also include developer
recruitment and developer departure emails. However,
these may need to be sparse and impersonal (almost
machine-like) where-in it may be announced who joined
(First/Last name, developer name, IRC handle, etc..),
herd they'll be joining, and duties they'll perform,
including packages they may be maintaining. These can
also be routed to a -dev-announce ML.
- project: open, dev and user mailing list for non-technical discussions
of the gentoo project. Topics can include pretty much
anything non-technical, including topics with high
flammability content, but it would be advised that people
maintain their composure and at least try to be respectful of
other developer and user viewpoints. One may not have to
agree, but one should at least give respect.
* Possibility: Automated greeting e-mail sent to people
who sign up to the list reminding them to conduct
themselves accordingly. Overall, the list should
moderate itself, because most of us are adults after
all. Those who maintain a track record of NOT
moderating themselves, could be forced off the list
(after discussion/inquiry/vote) by some responsible
party (which I won't attempt to detail any further as
to whom this party should/should not be).
Moderation just doesn't sit very well with me. One, it's got an overhead
burden, and likely, most devs will ignore the queued messages. Those with
enough idle curiosity might take a peek at them, but by and large, I think this
puts up barriers for some potential future great idea to come along and get
quietly shuffled away into /dev/null.
Two, wayward devs and users who post the wrong message to the wrong list can be
pointed in the right direction with a simple reminder that takes all of 2mins to
compose. I see it done all the time for the types that try emailing
"unsubscribe" to an ML. In the event they continue, then they can be blocked
for a time.
Basically, moderation is a tool to me, a tool that should be used sparingly.
Not used as a blanket cover, with the occasional someone lifting up that blanket
to peek outside (save that for the monster under the bed). That said, however,
I don't think we should totally dismiss the idea of blanket moderation.
Rather, I think we should first implement -project, put out enough information
to get people to use it, and watch it for a few months. By and large, we may
discover that simply giving another list for the non-technical discussions may
fix the problems on -dev, and moderation won't be needed on either list. If, on
the other hand, problems still arise on -dev that -project did not address (or
may've been potentially created by -project's creation), then we can revisit the
option of blanket moderation then.
Simply put: One Step At A Time.
Cheers,
--Kumba
--
Gentoo/MIPS Team Lead
"Such is oft the course of deeds that move the wheels of the world: small hands
do them because they must, while the eyes of the great are elsewhere." --Elrond
--
[EMAIL PROTECTED] mailing list
