Aeolus Team Leads

Jaromír Coufal jcoufal at redhat.com
Thu Jan 10 10:56:38 UTC 2013


On 9.1.2013 20:41, Hugh Brock wrote:
> On Wed, Jan 09, 2013 at 07:32:48PM +0000, Martyn Taylor wrote:
>> Gents,
>>
>> We are stuck in a pattern where, after hours/days of frustrating debate, we create
>> delicate balances of agreement on topics only to have our consensus break
>> when a new point of view is interjected or another conversation
>> takes place.  I really think it is time to add some layer of
>> leadership to the team.  Our team is simply too large to act as a
>> democracy.
>>
>> I realise that the Tech Cabal is an attempt to address the
>> aforementioned problems, but I do not feel that adding another sub-democracy
>> can help us in this issue.  The Cabal has its advantages
>> when trying to solve integration/cross project problems, but I don't
>> think it helps us steer individual projects.  I really think we need
>> technical leads that have the power to make decisions, or at the very least to
>> decide when debate is closed and carry forward ideas that have been agreed upon.
>> This is how the majority of projects both inside and outside of RedHat operate.
>> I'm not sure why we do not have this in Aeolus, but I'd be much
>> happier in my position if I had some clear direction on approach,
>> whether I agreed with that approach or not.  Let me be clear and say
>> I don't expect Team Leads to simply make all and every decision
>> alone and dictate to the rest of the team.  Rather, we need someone who
>> listens to all points of view and makes a decision and takes
>> responsibility for it.
>>
>> How do you guys feel about this idea?
>> Would you be willing to give up some control for clear direction?
> I like this idea and I agree we have probably grown to the point that
> it's necessary.
I think that the Tech Cabal is here to address this sort of decision 
making (at least higher importance decision making level - let's say 
project related issues).

Martyn pointed out, that it is another sort of democracy within 
democracy and that we are getting stuck in conversations anyway. So I 
think this needs to be solved. Currently Tech Cabal consists of 
representatives of our projects. I think they should be responsible for 
issues within their projects. If there is some important issue or 
decision which needs to be taken, I would say, that representative of 
the project to which it is related, should be responsible, that this 
issue is opened, discussed and decided (by voting if necessary) in some 
reasonable time. From my point of view, bigger decisions themselves 
should be taken by Tech Cabal, but the process of decision making should 
be leaded by the project representative, to ensure that it is solved.

Or you think that we split our projects to different formations (e.g. 
that we address API, UI, CLI, etc. separately) and have sort of smaller 
decision making level?

Maybe it might work in a model where we have sort of leaders for smaller 
units who decides on minor issues and Tech Cabal (project 
representatives) to address bigger issues such as project related 
decisions.

> How would you propose we choose team leads, and do you envision a way of
> rotating the position or do you think it should be permanent (at least
> until the lead gets tired of it or decides to go do something else)?
I think that project representative should be part of Tech Cabal, 
because he needs to be involved in related discussions anyway. And I 
would suggest sort of nominations and elections by team members once a, 
let's say, half year...?

If we talk about leaders of smaller units, might be the same case - 
nominations, elections of related team members and maybe half-year cycle 
(same as Tech Cabal)...?

Current representative or leader might be re-elected as much times as he 
would like to continue in his function.

> --H

Just thinking loudly and throwing out ideas. What do you think?

-- Jarda

-- 
Jaromír Coufal

Interaction Designer
Red Hat Czech s.r.o.

Mobile: +420 724 595 508
E-mail: jcoufal at redhat.com
IRC: jcoufal at #cloudforms-ui, #aeolus, #brno



More information about the aeolus-devel mailing list