1 |
On Thu, 2007-07-12 at 13:24 -0700, Mike Doty wrote: |
2 |
> All- |
3 |
> |
4 |
> We're going to change the -dev mailing list from completely open to where only |
5 |
> devs can post, but any dev could moderate a non-dev post. devs who moderate in |
6 |
> bad posts will be subject to moderation themselves. in addition the |
7 |
> gentoo-project list will be created to take over what -dev frequently becomes. |
8 |
> there is no requirement to be on this new list. |
9 |
> |
10 |
> This will probably remove the need for -core(everything gets leaked out anyway) |
11 |
> 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 |
It is rare enough that I actually respond to something on -dev (or any |
17 |
ml for that matter) so you know I have to care... |
18 |
|
19 |
Personally, I rather dislike this proposal, mostly because I see it as a |
20 |
bunch of unnecessary work... |
21 |
|
22 |
I as a developer find it very difficult to cut though what I consider |
23 |
noise to find the bits that I consider important to being able to |
24 |
continue being an effective developer on a list that I am *required* to |
25 |
be subscribed to. We have considered the likes of a moderated list, an |
26 |
announce only list and now this sillyness to help in cutting down on |
27 |
what a lot of us see as noise. How about we try something else....a self |
28 |
moderated quasi-announce list... |
29 |
|
30 |
1). Create 1 (ONE) new list, which, for the purposes of this discussion |
31 |
I will call it gentoo-dev-info (the name matters not). The requirement |
32 |
for subscription for all devs would shift from gentoo-dev to |
33 |
gentoo-dev-info. |
34 |
|
35 |
2). All *new* threads should cross post (regardless of whether it is |
36 |
from a dev or a user) to both gentoo-dev and gentoo-dev-info. Those that |
37 |
don't cross post (either by ignorance or accident) can be forwarded by |
38 |
someone to the missing list. |
39 |
|
40 |
3). The reply-to header for gentoo-dev-info should be set to gentoo-dev. |
41 |
|
42 |
4). No further e-mail will be sent to gentoo-dev-info on this new thread |
43 |
until a resolution on what actions if any need to be undertaken. |
44 |
|
45 |
5). If a thread topic is posted that interests you as a developer (or a |
46 |
user for that matter), you can either a). sub to gentoo-dev to continue |
47 |
discussion there, b). utilize any of the archives to follow the topic |
48 |
and contribute without being subscribed or c) have already been |
49 |
subscribed and only pay attention to this one thread sending the rest |
50 |
to /dev/null (yay! procmail). |
51 |
|
52 |
6) After the thread has petered out, if, and only if, any action is |
53 |
being taken, be that a change in policy, a clarification of policy or an |
54 |
actual change in behavior of some component, the dev or devs who are |
55 |
going to take said action send a notice describing it as a follow up |
56 |
notice to both gentoo-dev and gentoo-dev-info. |
57 |
|
58 |
Using that model devs and any users that want to subscribe as well can |
59 |
be aware of every new thread that gets started and choose to participate |
60 |
or not. This also gives them a new list that should have almost no |
61 |
noise, every thread will be at most two e-mails long, the initial e-mail |
62 |
and the resolution (if any). If you don't care about a topic all you see |
63 |
is that it was discussed and what the outcome of said discussion was, if |
64 |
you do care, you involve yourself in the discussion at your pleasure. |
65 |
|
66 |
We can trust people on their honor not to post to gentoo-dev-info in any |
67 |
manner other then that described above. This way we avoid the whole |
68 |
overhead of having to moderate the list, if people misbehave and post |
69 |
additional crap to the list consider moderating that one user...but |
70 |
honestly since there is a list *with the same thread* meant for |
71 |
discussion already this should only happen out of ignorance of policy or |
72 |
malicious action...the latter should be clearly identifiable and dealing |
73 |
with it should be easy. |
74 |
|
75 |
No need to change the status quo for dev, no need to privatize core, |
76 |
just create one list, post the rules and off you go... |
77 |
|
78 |
--Dan |