1 |
All: |
2 |
|
3 |
I have intentionally stayed out of the discussion over the past |
4 |
several days. I did this because I believed that in the state that |
5 |
the discussions were I could not provide any valid input as things |
6 |
were far to heated to be useful. Now however we have seen things calm |
7 |
down and are getting to the meat of the problem. I am very happy with |
8 |
the proposed changes that have been set forth but want to elaborate |
9 |
on them a bit more. |
10 |
|
11 |
#1). We seem to be concentrating entirely on dealing with problems of |
12 |
the social nature were issues require interpretation, investigation |
13 |
and an impartial adjudication (in this particular case buy a body |
14 |
that will both serve as judge and jury in a form of summary |
15 |
judgement). I can understand why this has been the case given what |
16 |
precipitated the conversation but we have been ignoring the other |
17 |
half "HR" responsibilities that devrel carries. While it may be |
18 |
believed otherwise the QA group does not (nor should it) have the |
19 |
power to deal with problems of the technical nature when it comes to |
20 |
"punishing" developers for repeated action either due to an innocent |
21 |
lack of knowledge or malicious intent. The QA group should come to |
22 |
devrel when such problems occur. In general problems of this nature |
23 |
are more clear cut and not open to interpretation, either something |
24 |
is broken or it is not. To that end the only purpose of the |
25 |
"investigatory body" in technical matters is to determine weather the |
26 |
damage was malicious or not, a very hard task sometimes. While the |
27 |
case may be made that the punishment for this kind of action (again I |
28 |
need to stress that I am including both a totally innocent lack of |
29 |
knowledge and malicious intent) is subject to the interpretation of |
30 |
the judging body I feel that it must not be. Having subjective rules |
31 |
is scary as it means that even in an act of innocence hundreds if not |
32 |
thousands of end users can be effected without being forced to take |
33 |
steps to ensure that such a thing will not happen again. I agree that |
34 |
the "punishment" for a malicious action and the "punishment" for an |
35 |
innocent one should not be the same but it has to be understood that |
36 |
the end result of either action is indeed the same. I feel that this |
37 |
needs to be discussed...I have some ways I'd like to handle it but |
38 |
all of them require not only the intervention of devrel to decide |
39 |
what "punishments" fit such actions but infra as well; namely the |
40 |
inclusion of a branch tree for "approved" operations by repeat |
41 |
offenders) to prevent damage to the main tree (which would require |
42 |
the use of svn for our main tree btw :-/). I just feel that this |
43 |
responsibility of devrel is often overlooked. |
44 |
|
45 |
Well that was the long one.... |
46 |
|
47 |
#2). I feel the need to state that under no circumstances can devrel |
48 |
make up an investigatory body, and a judiciary of any valid size with |
49 |
it's present makeup. I think this needs to be addressed in addition |
50 |
to just formalizing the layout. We need more help from good |
51 |
developers willing to throw their weight behind the process. Not just |
52 |
for the purpose of these two bodies but also to make the "Developer |
53 |
Handbook" a more open project for developers to submit to, for the |
54 |
recruitment quiz to move with the times at an appropriate clip and |
55 |
for everything else devrel does. We have to be at the forefront of |
56 |
the development effort, anticipating development needs with |
57 |
recruiting and documentation and standing as a transparent body for |
58 |
all developers to see. |
59 |
|
60 |
Well that's my 2 cents. I also want to thank all those who have been |
61 |
vocal over the past week, on both sides of the aisle, as I feel that |
62 |
without this kind of passion we wouldn't be at the point we are |
63 |
today. It's no fun getting here but these are very necessary growing |
64 |
pains as our beloved distro grows beyond it's original bounds..... |
65 |
|
66 |
Thanks for listening, |
67 |
|
68 |
Daniel Ostrow |
69 |
Gentoo/{PPC,PPC64,DevRel} |
70 |
dostrow@g.o |
71 |
|
72 |
|
73 |
-- |
74 |
gentoo-devrel@g.o mailing list |