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