1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
On 01-06-2011 22:59, Rich Freeman wrote: |
5 |
<snip> |
6 |
> I think the problem is that we're getting a bit legalistic here. I |
7 |
> have no idea why we even needed the policy change. IMHO what should |
8 |
> happen is: |
9 |
> |
10 |
> 1. Dev does something significant and doesn't update a Changelog. |
11 |
> 2. QA or another dev calls them on it. Tells them not to do it again. |
12 |
> 3. Dev does it again. |
13 |
> 4. QA or another dev escalates to devrel. Devrel deals with the |
14 |
> issue, resulting in either a dev who takes the rules more seriously or |
15 |
> one less dev. |
16 |
> |
17 |
> What it almost sounds like to me is that step 4 is breaking down. |
18 |
> Perhaps somebody is arguing "well, it isn't clear in the rules so you |
19 |
> can't do anything to me." To that my only answer is "sure we can!" |
20 |
|
21 |
Rich, |
22 |
|
23 |
besides a disagreement on how to deal with policy issues (as you can |
24 |
read in my proposal to update GLEP48), the issue here is *exactly* that |
25 |
whenever developers or QA warned *repeatedly* the people that don't |
26 |
update ChangeLogs (a very restrict minority of developers), they've |
27 |
always tried to find loopholes in the policy and argued others had no |
28 |
support for their request. |
29 |
About step 4 breaking down, the DevRel process would face the same |
30 |
hurdle as the above, but then there's another important point that |
31 |
people really need to think about: Do we really want to take all |
32 |
technical issues to DevRel and in the limit fire people "only" for that? |
33 |
I'm not saying that technical issues aren't relevant for DevRel or that |
34 |
people can't get "fired" because of them, but in my experience the role |
35 |
of DevRel is more to evaluate the ability and willingness of developers |
36 |
to work in the team than to fire someone because they failed to apply a |
37 |
policy here or there - to be clear, I'm talking here about mistakes and |
38 |
ignorance, not about defiance and disregard for others and policy - |
39 |
which in my view constitute the sort of behaviour patterns that DevRel |
40 |
is meant to evaluate, help fixing and, when everything else fails, to |
41 |
remove. |
42 |
|
43 |
> When it comes to money and taxes we need to have pretty clear rules |
44 |
> for legal reasons, but when it comes down to expecting devs to be |
45 |
> mature and team players, I don't think that we really need 14 appeals |
46 |
> and a team of lawyers to eliminate every loophole in our policies. If |
47 |
> a misunderstanding is genuine then everybody should get past it |
48 |
> quickly and maybe we update the policy to be more clear. When |
49 |
> policies are flaunted despite explanation, and the authority of devrel |
50 |
> or QA or whatever and ultimately the council (on appeal) is |
51 |
> questioned, then we're not playing like a team. It is amazing what |
52 |
> intelligent people can fail to understand when getting something they |
53 |
> want depends on it. |
54 |
|
55 |
The sad fact is that increasingly it seems our developer base, or a |
56 |
significant part of it, is losing all "common sense". |
57 |
|
58 |
> Just my two cents... That, and in the big scheme of things this is a |
59 |
> bit of a tempest in a teapot but I do share concerns that QA is an |
60 |
> attitude and small problems today just lead to big ones tomorrow. |
61 |
> |
62 |
> Rich |
63 |
|
64 |
- -- |
65 |
Regards, |
66 |
|
67 |
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org |
68 |
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng |
69 |
-----BEGIN PGP SIGNATURE----- |
70 |
Version: GnuPG v2.0.17 (GNU/Linux) |
71 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ |
72 |
|
73 |
iQIcBAEBAgAGBQJN5s33AAoJEC8ZTXQF1qEPFEcP/2tLhDBXR24AF/GunN5BHKQy |
74 |
+fganpXgO1OqZcFX6tEG7h+j6fjbSFwTPaNG9CiSyrz/NsYseuL7wzkxXZawfUax |
75 |
ftiaFuOuKvLd56AizO0y0YNfrvIVxp2rTPas17yg+Noqgm3Hd5voh2J9FkN3x8X9 |
76 |
PPd8yA8f4DXA4ptdihGS694edtDtT2WwMVGbPuGl6I3U0tlLYlPyGoQDRaAhvQoB |
77 |
LnOzqrYxFxDxcEUWyae25dp3DI1rhqWw8cUc1We6lOZENOtGxiLuxToIorVB8lAs |
78 |
b3SB326WI5XJRyHWgWtcPkF9OrQvpsDXgO9YEqBbsXn3w6vsj2rD8IeswMGNt66R |
79 |
h4cmHEwXEyZ9iQPEPwJKi/UI6MZHTM5ezYJDAbBxBuLt5dPuR7RQBspHkyjSSFe8 |
80 |
/RPLDYy0UYnh0uUw1Rq7DCB5rhLf9acnGhT247q+5PNMcfdN3aBYPIK2ruqTQGKD |
81 |
SfNefj0tKJCXd/TsQUSn7GP7SLjiBNh7Ym+qy8Q5TFQs49vhYprbqRn6RdsMpPe6 |
82 |
eeHNiNzSw9Cfi6n/ZidHlvOXUM7g2yVOLzJ9ChzZRhftxABMWMJCzYvQfjE6Eqey |
83 |
+pVX372nI2G9e9UErS8/Zfxxxw/+vOE7DLLYKe9HSXeM3XdNwEzotdcN+Xxth3f/ |
84 |
R5tVPjMUL3TACOcqA/zr |
85 |
=vsto |
86 |
-----END PGP SIGNATURE----- |