| 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----- |
Archives