1 |
Mike Doty wrote: |
2 |
> All- |
3 |
> |
4 |
> We're going to change the -dev mailing list from completely open to where |
5 |
> only devs can post, but any dev could moderate a non-dev post. devs who |
6 |
> moderate in bad posts will be subject to moderation themselves. in addition |
7 |
> the gentoo-project list will be created to take over what -dev frequently |
8 |
> becomes. there is no requirement to be on this new list. |
9 |
> |
10 |
> This will probably remove the need for -core(everything gets leaked out |
11 |
> anyway) but that's a path to cross later. |
12 |
> |
13 |
> We're voting on this next council meeting so if you have input, now would be |
14 |
> the time. |
15 |
|
16 |
|
17 |
Hmm, given that I'm the one who planted the seed for -project, I have to wonder |
18 |
if the seed has grown in a way that might be useful. Or if it has merely become |
19 |
a weed now, and should be pulled from the garden. |
20 |
|
21 |
Here's what my thinking was when I put out the initial e-mail calling for |
22 |
-project, including thoughts now on how they should be laid out now: |
23 |
|
24 |
- I envisioned three mailing lists, essentially: |
25 |
* core |
26 |
* dev |
27 |
* project |
28 |
|
29 |
- core: private, dev-only mailing list for internal discussion |
30 |
|
31 |
* Possibility: becomes read-only to the public after |
32 |
a set time limit, possibly 1, 2, 4, or 6 months. |
33 |
Certain messages and threads could be marked (via |
34 |
some feature, for example) to remain permanently |
35 |
private, and thus would never be readable by the |
36 |
public. This policy would NOT apply retroactively. |
37 |
|
38 |
|
39 |
- dev: open, dev and user mailing list for technical discussions about |
40 |
the gentoo project. Topics would include package |
41 |
addition/removal/masking announcements, EAPI discussions, |
42 |
package development questions/inquires (i.e., from users, |
43 |
but NOT help -- gentoo-user exists for that). |
44 |
|
45 |
* Possibility: Package changes, such as moves, |
46 |
deletions, additions, and so forth could also be |
47 |
routed automatically to a -dev-announce ML, possibly |
48 |
by prefixing the subject field with "[ANNOUNCEMENT]:" |
49 |
(This prefix, would of course, be stripped by the |
50 |
automatic mailer before posting to -dev-announce). |
51 |
|
52 |
* Possibility: topics could also include developer |
53 |
recruitment and developer departure emails. However, |
54 |
these may need to be sparse and impersonal (almost |
55 |
machine-like) where-in it may be announced who joined |
56 |
(First/Last name, developer name, IRC handle, etc..), |
57 |
herd they'll be joining, and duties they'll perform, |
58 |
including packages they may be maintaining. These can |
59 |
also be routed to a -dev-announce ML. |
60 |
|
61 |
|
62 |
- project: open, dev and user mailing list for non-technical discussions |
63 |
of the gentoo project. Topics can include pretty much |
64 |
anything non-technical, including topics with high |
65 |
flammability content, but it would be advised that people |
66 |
maintain their composure and at least try to be respectful of |
67 |
other developer and user viewpoints. One may not have to |
68 |
agree, but one should at least give respect. |
69 |
|
70 |
* Possibility: Automated greeting e-mail sent to people |
71 |
who sign up to the list reminding them to conduct |
72 |
themselves accordingly. Overall, the list should |
73 |
moderate itself, because most of us are adults after |
74 |
all. Those who maintain a track record of NOT |
75 |
moderating themselves, could be forced off the list |
76 |
(after discussion/inquiry/vote) by some responsible |
77 |
party (which I won't attempt to detail any further as |
78 |
to whom this party should/should not be). |
79 |
|
80 |
|
81 |
|
82 |
Moderation just doesn't sit very well with me. One, it's got an overhead |
83 |
burden, and likely, most devs will ignore the queued messages. Those with |
84 |
enough idle curiosity might take a peek at them, but by and large, I think this |
85 |
puts up barriers for some potential future great idea to come along and get |
86 |
quietly shuffled away into /dev/null. |
87 |
|
88 |
Two, wayward devs and users who post the wrong message to the wrong list can be |
89 |
pointed in the right direction with a simple reminder that takes all of 2mins to |
90 |
compose. I see it done all the time for the types that try emailing |
91 |
"unsubscribe" to an ML. In the event they continue, then they can be blocked |
92 |
for a time. |
93 |
|
94 |
Basically, moderation is a tool to me, a tool that should be used sparingly. |
95 |
Not used as a blanket cover, with the occasional someone lifting up that blanket |
96 |
to peek outside (save that for the monster under the bed). That said, however, |
97 |
I don't think we should totally dismiss the idea of blanket moderation. |
98 |
|
99 |
Rather, I think we should first implement -project, put out enough information |
100 |
to get people to use it, and watch it for a few months. By and large, we may |
101 |
discover that simply giving another list for the non-technical discussions may |
102 |
fix the problems on -dev, and moderation won't be needed on either list. If, on |
103 |
the other hand, problems still arise on -dev that -project did not address (or |
104 |
may've been potentially created by -project's creation), then we can revisit the |
105 |
option of blanket moderation then. |
106 |
|
107 |
Simply put: One Step At A Time. |
108 |
|
109 |
|
110 |
|
111 |
Cheers, |
112 |
|
113 |
--Kumba |
114 |
|
115 |
-- |
116 |
Gentoo/MIPS Team Lead |
117 |
|
118 |
"Such is oft the course of deeds that move the wheels of the world: small hands |
119 |
do them because they must, while the eyes of the great are elsewhere." --Elrond |
120 |
-- |
121 |
gentoo-dev@g.o mailing list |