1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
On 06/19/2013 10:43 PM, Petteri R¦ty wrote: |
5 |
> On 19.6.2013 23.18, hasufell wrote: |
6 |
>> While I appreciate devrel being more active in serious situations |
7 |
>> (I actually proposed that in another thread), I question the way |
8 |
>> Devrel is constituted. |
9 |
>> |
10 |
>> How was devrel formed? Who started it? What's the procedure of |
11 |
>> getting in? |
12 |
>> |
13 |
> |
14 |
> The project is old: |
15 |
> |
16 |
> revision 1.1 date: 2003-07-14 00:49:03 +0300; author: seemant; |
17 |
> state: Exp; first version of project description page |
18 |
> |
19 |
> While I have been here for a better part of the decade, older farts |
20 |
> (in dev time) are needed to comment on who started it. |
21 |
> |
22 |
>> |
23 |
>> What is a possible solution? Let the council elect all members. |
24 |
>> That way the power still comes from the dev community, although |
25 |
>> they do not vote devrel directly. The council should vote |
26 |
>> anonymously, so that no connection between council member and |
27 |
>> elected devrel member can be drawn which could otherwise affect |
28 |
>> the election of the council. This system should prevent people |
29 |
>> from thinking two steps ahead when voting the council. |
30 |
>> |
31 |
> |
32 |
> The council can already do that if they so choose. Granted if this |
33 |
> process was made explicit it could have some influence on the |
34 |
> turnover. In practice so far oversight has not been a problem |
35 |
> (though since for quite a few years I have been part of both bodies |
36 |
> the two have been quite connected). |
37 |
> |
38 |
|
39 |
If they choose... that means the current form of control over devrel |
40 |
is only of a _reactive_ nature. That nature is also necessary, but |
41 |
that is not how "control" is defined in the context I was explaining |
42 |
in the first post. |
43 |
|
44 |
What happens if power has been abused and damage is already done? The |
45 |
council can just pick up the pieces then, revert decisions (if |
46 |
possible) and try to deescalate. |
47 |
Then people will ask... who is responsible? Why was there no explicit |
48 |
election? |
49 |
That might even lead to devrel losing respect. People will think they |
50 |
just have that power because they came first. |
51 |
It's not just about saying retroactively that someone wasn't fit for |
52 |
devrel after he messed up, it's about saying who IS fit. Then people |
53 |
know why that person got that kind of authority. |
54 |
|
55 |
Also... we still don't have any rotation, except when devs resign from |
56 |
that project. |
57 |
|
58 |
Another thing: what do we do if devrel blocks actions against it's own |
59 |
members? Because that's what gentoo projects have partly evolved |
60 |
into... a group of buddies. I don't have much of a problem with that |
61 |
in general, as it can improve effectivenes from some standpoints, but |
62 |
this is not about a regular project. |
63 |
I don't even claim that current devrel is not fit or that they just |
64 |
form their group of buddies, but why should we not try to minimize |
65 |
those possibilities? |
66 |
|
67 |
If we want them to use the sledgehammer, it should be clear who gets |
68 |
that sledgehammer and why. Make it explicit, rule out uncertainties. |
69 |
Rotate that role, so people don't lose focus. |
70 |
-----BEGIN PGP SIGNATURE----- |
71 |
Version: GnuPG v2.0.20 (GNU/Linux) |
72 |
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ |
73 |
|
74 |
iQEcBAEBAgAGBQJRwiV9AAoJEFpvPKfnPDWzxscH/i4IERpirzDCmImBvJn8y8J+ |
75 |
j6gn0y/VrP8D9luOw5G3w3Q9kdODYzc4qMPNowu4TKsDGQ5SDcJFCJ6lXYIVba/7 |
76 |
Ac6mdKTZ1E7itxvYj14cShnnEZo+iv8xg3vO2ShUCx/cyi97eS2kqvSb91AUS2DK |
77 |
4bqZ686S0ZElXbEdiycmElEQVnEU86rTJF9P9fiDVzMouh8E7fYPK0HJKG6X0Oq0 |
78 |
SMbXSJnDGDzZ2CiV+7nQKXIlvcA+RpPZlKxvUeT7nB4b6evjGKLNtGubl63j4/h+ |
79 |
nUwOupFfZRvJ3P7HXRuhVssD++NOm4NWh5rRvm3q9l8G5oj4If1yumq/MJDxa24= |
80 |
=FoHI |
81 |
-----END PGP SIGNATURE----- |