Kumba wrote:
- 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.
I'm not sure about stuff in -core becoming publicly accessible. After
all, isn't it in the private list for a reason? Perhaps summaries of
-core discussions being forwarded to -dev would be a better option.
However, I'm new to -dev, so if this is what already happens I don't know.
- 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).
Here's where we want the non-devs to get access. After all, not all
development and debugging is done by devs. All the current devs were,
at one point, users. Where did they get their start? My bet is they
entered via the -dev mailing list, learned the ropes here, and
eventually earned their dev status. If the -dev list is closed, where
do the new dev-wannabes learn the ropes and get their voices heard?
* 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).
Would it perhaps be better to send announcements to -dev-announce, and
have that list forward to -dev? That way we avoid issues if a subject
starts with [ANNONUCEMENT], for example
* 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.
If these messages will be machine-like, why not have them
machine-generated? When you become a dev, someone (you? the person
that -dev-ifie's you?) fills out a form, and the information from the
form is forwarded to the list.
[snip -project]
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.
I agree with this. Also, it gives a transition time for people to get
used to the new idea. Don't create -project, then 3 months later say
"that didn't work, we need to moderate -dev". Give it a little more
time than that. Ensure that people are reminded, especially at the
beginning, that there may be a more appropriate forum.
Simply put: One Step At A Time.
Cheers,
--Kumba
My 2 non-dev cents,
Kevin
--
[EMAIL PROTECTED] mailing list
