1 |
On Fri, Jul 4, 2014 at 10:39 AM, Jorge Manuel B. S. Vicetto |
2 |
<jmbsvicetto@g.o> wrote: |
3 |
> On Fri, 4 Jul 2014, Rich Freeman wrote: |
4 |
>> 1. Announced elections, membership changes, etc. When these things |
5 |
>> happen, publish it on -project, or at least on the team page. Make it |
6 |
>> easy for everybody to see what is going on with the |
7 |
>> membership/leadership of ComRel. There is no need for the annual lead |
8 |
>> election to be secret. |
9 |
> |
10 |
> |
11 |
> If you mean the ballots should be public, I disagree... |
12 |
> If you mean that the result of an election should be public, I agree. |
13 |
|
14 |
We're on the same page here. |
15 |
|
16 |
> I agree with you that changes to policies should be discussed in the mls. We |
17 |
> did that a few years ago. We definitely need to publish the resulting policy |
18 |
> so everyone is aware of it. |
19 |
|
20 |
Again, we're actually on the same page here. I wasn't suggesting a |
21 |
free-for-all with conflict resolution. |
22 |
|
23 |
> |
24 |
>> 3. This is a bigger change, but I'd advocate doing with ComRel what |
25 |
>> was done last year with QA. Have the team self-governing for the most |
26 |
>> part, but with the Council having to confirm the lead and basically |
27 |
>> having the effective ability to take over if necessary. I'd highly |
28 |
>> discourage the Council ever doing that, but I'd look at it a bit like |
29 |
>> being able to Impeach or Recall an elected official - just a way to |
30 |
>> have accountability and the mandate that goes along with that. |
31 |
> |
32 |
> |
33 |
> I strongly object to this idea, just like I did with QA. |
34 |
> The goal / purpose of ComRel is not to be "cozy" team that everyone feels |
35 |
> great with. To have an effective ComRel team, it needs to be made of people |
36 |
> with certain traits (level headed, fair, independent, trustworthy) that do |
37 |
> their work with the best interest of Gentoo "at heart". That's why it can't |
38 |
> be a "open to everyone" team. |
39 |
> Besides, the council can always revert ComRel decisions and it always had |
40 |
> the power to deal with a "rotten" ComRel or ComRel lead. |
41 |
|
42 |
I'm not actually sure we're disagreeing here. This isn't about the |
43 |
Council picking the members of QA or ComRel. This is about having |
44 |
both teams govern themselves, but submitting their choice of leads to |
45 |
the Council to be blessed. I just view it as a way of "legitimizing" |
46 |
the teams, and making the elected Council members accountable for |
47 |
their actions. |
48 |
|
49 |
I was not proposing having open elections for these teams, or open |
50 |
membership as with most Gentoo teams. |
51 |
|
52 |
> |
53 |
> Even though I agree that there's a more visible QA team now, I don't |
54 |
> necessarily agree that we're better now. I hope and expect the new team will |
55 |
> get better with time, but they've been dragged into many and noisy |
56 |
> conflicts, which have even lead to complaints to ComRel. |
57 |
|
58 |
So, I can't say that I've agreed with how every issue has been |
59 |
handled, but it is a new team and I believe that creffet has been |
60 |
working hard to try to get the team to find the right balance between |
61 |
inactivity and overactivity. Of course a QA team that actually does |
62 |
things will trigger more ComRel complaints than one that does nothing |
63 |
- that's just the nature of the beast. The last month or two seems to |
64 |
have been fairly quiet judging from the lists and Council agendas. |
65 |
|
66 |
> Your setting of a precedent also worries me as a way for any particular new |
67 |
> council to decide it's time to replace QA, just because the 2013/2014 |
68 |
> council did it. |
69 |
|
70 |
The Council didn't replace QA, it populated it. There basically |
71 |
weren't any active members in QA when we did it. The GLEP clearly |
72 |
outlines how this year's Council agreed to do it in the future (not |
73 |
that future Councils couldn't change this). The QA lead basically |
74 |
holds the final say over what QA does, as is the structure of all of |
75 |
our projects in theory. In practice they shouldn't be ruling with an |
76 |
iron hand. QA chooses its own members, and they elect the lead. The |
77 |
lead then has to be confirmed by the Council, and I would generally |
78 |
expect that to be a rubber stamp most of the time. However, if there |
79 |
is an issue that is an opportunity for reform. |
80 |
|
81 |
But, if for whatever reason things really got out of hand, then |
82 |
Council absolutely should clean house if that is what they feel is the |
83 |
best option. What is the alternative? We can't have a Gentoo with |
84 |
half a dozen self-governing fiefdoms all doing whatever they feel is |
85 |
best regardless of what the overall developer community thinks. |
86 |
|
87 |
I'm not an advocate of the Council stepping on teams like |
88 |
QA/ComRel/Infra, but these are special teams that I believe require |
89 |
some kind of mandate. If your team isn't going to let any developer |
90 |
join, even if for good reason, then there needs to be some kind of |
91 |
accountability to the rest of the community. Otherwise people start |
92 |
complaining about cliques/etc. |
93 |
|
94 |
So, I'm an advocate of the Council being the buck-stops-here team, and |
95 |
if developers have a problem with our performance, they get the |
96 |
opportunity to get rid of us. Then all the grievances get aired, and |
97 |
we can all look at the results of an election and agree that they are |
98 |
fair. Sure, we'll still have our differences, but at least we can say |
99 |
that the majority of devs are happy with what is going on. |
100 |
|
101 |
But, accountability of ComRel is something for the next Council to |
102 |
decide on. I've been clear on my views - I want QA/ComRel/Infra to be |
103 |
subordinate to the Council, but self-governing in the day-to-day. I |
104 |
don't have strong feelings on whether ComRel/Infra are subordinate to |
105 |
the Council vs the Trustees - I think that they should be under one or |
106 |
the other but it could go either way. I also have stated before that |
107 |
I think that QA >> ComRel > Infra as far as priority of reform goes as |
108 |
well - QA was dysfunctional last fall and needed immediate action, |
109 |
ComRel and especially Infra are less broken and thus we shouldn't be |
110 |
in as much of a rush to "fix" them. |
111 |
|
112 |
Rich |