1 |
Rich Freeman wrote: |
2 |
> |
3 |
> I think that we need a simple policy like: |
4 |
> Write up Changelogs for any change that impacts what gets installed on |
5 |
> our user's computers. |
6 |
> |
7 |
> Then we can write up some guidelines about how to apply this policy in practice. |
8 |
> |
9 |
> I think the problem is that we're getting a bit legalistic here. I |
10 |
> have no idea why we even needed the policy change. IMHO what should |
11 |
> happen is: |
12 |
> |
13 |
> 1. Dev does something significant and doesn't update a Changelog. |
14 |
> 2. QA or another dev calls them on it. Tells them not to do it again. |
15 |
> 3. Dev does it again. |
16 |
> 4. QA or another dev escalates to devrel. Devrel deals with the |
17 |
> issue, resulting in either a dev who takes the rules more seriously or |
18 |
> one less dev. |
19 |
> |
20 |
> What it almost sounds like to me is that step 4 is breaking down. |
21 |
> Perhaps somebody is arguing "well, it isn't clear in the rules so you |
22 |
> can't do anything to me." To that my only answer is "sure we can!" |
23 |
> When it comes to money and taxes we need to have pretty clear rules |
24 |
> for legal reasons, but when it comes down to expecting devs to be |
25 |
> mature and team players, I don't think that we really need 14 appeals |
26 |
> and a team of lawyers to eliminate every loophole in our policies. If |
27 |
> a misunderstanding is genuine then everybody should get past it |
28 |
> quickly and maybe we update the policy to be more clear. When |
29 |
> policies are flaunted despite explanation, and the authority of devrel |
30 |
> or QA or whatever and ultimately the council (on appeal) is |
31 |
> questioned, then we're not playing like a team. It is amazing what |
32 |
> intelligent people can fail to understand when getting something they |
33 |
> want depends on it. |
34 |
> |
35 |
> More rules will never save an organization. Sometimes you need rules, |
36 |
> but I think that for a group like Gentoo to work well we need to keep |
37 |
> them to a minimum. "Well, that's not written in black and white so I |
38 |
> won't cooperate until it is" is no reason for anybody to pause even a |
39 |
> moment before escalating. Unclear policies are a reason to assume |
40 |
> good intentions - not a reason to overlook obvious bad intentions. |
41 |
> You can't solve a people problem with a better algorithm. |
42 |
> |
43 |
> Just my two cents... That, and in the big scheme of things this is a |
44 |
> bit of a tempest in a teapot but I do share concerns that QA is an |
45 |
> attitude and small problems today just lead to big ones tomorrow. |
46 |
> |
47 |
> Rich |
48 |
> |
49 |
> |
50 |
|
51 |
I'm not a dev, just a user but I do follow this list and read most |
52 |
things posted here. |
53 |
|
54 |
The point of the discussion is this. Someone didn't log something that |
55 |
should have been logged. Even after it was posted that the change is |
56 |
supposed to be logged, the person that didn't think he should log it |
57 |
said the rules didn't say he had to log it. So, it appears that #1, #2 |
58 |
happened but the rules wasn't clear enough so it was changed. |
59 |
|
60 |
I think the point of the discussion is this. The rules wasn't clear |
61 |
enough so they were changed to be much clearer. From my understanding, |
62 |
the NEW rules say if you touch it, log it. Thing is, that seemed to |
63 |
have went to far. So, round two is to smooth out the edges and get it |
64 |
back to what it was except in writing this time. That way, if this |
65 |
happens again, another dev, user, devrel or whatever can point to the |
66 |
rules and settle the argument quickly. |
67 |
|
68 |
It would be nice if when this originally started, the reply would have |
69 |
been "sorry, I didn't realize. It won't happen again". That could have |
70 |
been the end of it and it would have ended loooooong ago. :-) |
71 |
|
72 |
I do agree with your post tho. Sometimes you etch something in stone |
73 |
then realize you misspelled the thing. |
74 |
|
75 |
Dale |
76 |
|
77 |
:-) :-) |