1 |
Markos Chandras schrieb: |
2 |
> On 08/14/2011 02:07 PM, Thomas Sachau wrote: |
3 |
>> Markos Chandras schrieb: |
4 |
>>> On 08/14/2011 01:15 PM, Thomas Sachau wrote: |
5 |
>>>> Markos Chandras schrieb: |
6 |
>>>>> Hi all, |
7 |
>>>>> |
8 |
>>>>> This is the first of the items I would like to discuss for the |
9 |
>>>>> next Council agenda (or a later one). |
10 |
>>>>> |
11 |
>>>>> Some time ago, few people proposed to have Council appointed |
12 |
>>>>> leaders for QA and DevRel. |
13 |
>>> |
14 |
>>>> My first question: Why is your proposal restricted to QA and |
15 |
>>>> DevRel? |
16 |
>>> |
17 |
>>> Cause I believe these teams are crucial to the continuity of |
18 |
>>> Gentoo project. |
19 |
> |
20 |
>> How do you weight one project against another one? I see it the other |
21 |
>> way round: QA and DevRel are only important, if there is some issue |
22 |
>> not resolved otherwise. But many other projects are always important, |
23 |
>> since they have to maintain things continuously. While the council |
24 |
>> could still decide, if DevRel or QA are gone (they just take some |
25 |
>> workload away), you wont be able to get the council to e.g. maintain |
26 |
>> our infrastructure, ebuilds or docs. |
27 |
> |
28 |
> 1) If another project slacks, then bad luck for you. Just mask and |
29 |
> remove the ebuilds ( see recent zope thread ). There is nothing we can |
30 |
> do about that. |
31 |
|
32 |
If QA or DevRel slacks, this causes even less work, since they dont even maintain ebuilds to mask |
33 |
and remove. It may result in less QA fixes or less mediation between developers, but in any case, |
34 |
where you need a decision, you could always call for the council. Those projects do just some |
35 |
delegated work, which is of course nice, if it comes to the daily work and also, because it reduces |
36 |
the work, that needs to be done by the council. But neither is unreplaceable and the decisions of |
37 |
both teams can already be checked by the council, so i see no real requirement for additional |
38 |
bureaucracy for those 2 specific teams. |
39 |
|
40 |
Either you want to move more control to the council, then it should do the checks and votes for all |
41 |
teams or you leave it like now, where the teams do decide themselves. |
42 |
|
43 |
> 2) Infrastructure is a sensitive team, and does not deal with ebuild |
44 |
> maintenance and portage directly. |
45 |
|
46 |
And if infra slacks? Bad luck for you, just mask and remove the hardware? :-) |
47 |
|
48 |
>>>>> I like the idea because this way the Council can ensure that |
49 |
>>>>> the team is active or either force some activity in case the |
50 |
>>>>> current leader slacks big time. |
51 |
>>> |
52 |
>>>> If there is noone active in a team, noone prevents other devs to |
53 |
>>>> join the team and vote themselves for the lead. So even if there |
54 |
>>>> is no activity, it should be no problem to get activity, if |
55 |
>>>> someone is interested to do the work. |
56 |
>>> Right now, you can't join any of these teams unless a lead approves |
57 |
>>> you. Have a look at gentoo-qa ML. |
58 |
> |
59 |
>> Please re-read my lines. I talked about _noone being active_. The QA |
60 |
>> team is not empty/inactive, neither is DevRel team empty/inactive, so |
61 |
>> this does not apply to the current situation. |
62 |
> Well, clearly we have a different definition for the word "active". If |
63 |
> you think that QA is active then there is no reason for me to try to |
64 |
> convince you for the opposite. |
65 |
|
66 |
Maybe you should first tell me, how you define activity for QA (and DevRel)? |
67 |
|
68 |
>>>> If the team is inactive and noone interested, the Council wont be |
69 |
>>>> able to create any activity either, since they cannot force |
70 |
>>>> anyone to do something. |
71 |
>>> You can't just join a dead team and become a lead :). There are |
72 |
>>> some bureaucracy procedures to follow. |
73 |
> |
74 |
>> You cant? who prevents you from doing so? And if there are just some |
75 |
>> procedures to follow, this just means some initial activity/workload |
76 |
>> to do so, but again: If the team is dead, who could prevent you from |
77 |
>> joining it and then becoming the lead? |
78 |
> Existing members, who claim to be active, may prevent you. Remember what |
79 |
> happened last time Patrick tried to resurrect GMW, and all of a sudden, |
80 |
> Joshua claimed that he can't do that because he wasn't the lead. |
81 |
> Unless I misunderstand your definition for "dead" word. You mean empty |
82 |
> project pages? Or just pages with 14 members and 0 commits/year? |
83 |
|
84 |
I would see a project as "dead", if there is no activity at all, also there is a need for activity |
85 |
(like open bugs for an ebuild, which never get processed or no newsletter sent out at all). |
86 |
|
87 |
I dont mind about asking the council to decide, who can take over a dead project, if more than one |
88 |
person wants to take it and those people dont get to a consensus. |