Re: [gentoo-dev] ML changes

[Kumba <kumba@gentoo.org>]

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
-- 
gentoo-dev@gentoo.org mailing list