[DotGNU]Re: DotGNU leadership

[Myrddian]

> > Also, the meta-leader should be a relatively weak position,
> > with most of the actual work and decisions done by the
> > individual project leaders.
> 
> I agree that most of the actual work and decisions should be
> done by the individual project leaders.  However this does not
> mean that the meta-leader should have a weak position.

I still think that documentation should be done first before we get anything 
done, it prevents breakups not to mention feature bloat. It also prevents
individual project leaders taking up too much authority, not to mention
the meta-leader as he is also bound to obey the RFC. 
 
> I think the meta-leader should have a lot of authority, but
> exercise this authority only as necessary.

Authority a lot?!? Power corrupts.

> We could also post information on how to proceed in case someone
> is not happy with how the leader is handling things.  Something
> like, "first try to work it out in private email with the
> project leader(s) concerned and the meta-leader, if that fails
> you're welcome to start a competing project - we might even
> support you in doing that".

Err, that is bad, that is really bad, figuring what is wrong with the project 
leader is good, initiating another competing project is bad. 
It leads to forking and internal break up of the project, that is something we 
want
to avoid. The meta-leader should be in able to replace the project-leader in 
case
something has gone wrong (this is temporary replacement ) but it should work 
since an RFC/Documentation
is in place which everybody is trying to uphold.

Once the project leader is available again, or a replacement has been found the 
meta-leader gives
back the postition and goes back to his duties. 

Meta-leader: Well he should be responsible for.
           1) Co-ordination of individual projects
           2) Upholding the RFC.
           3) Talk with the FSF, or be spokesman to the project members on 
behalf of the FSF
           4) Help, act as absent project the indivual project leaders.
           5) Assingment of project leaders (in case the individual resigns, 
etc)

In neither case he should, say "I want this because of <SOME REASON>", modify 
or exert his authority 
over the individual project members or leaders. He should at all costs avoid or 
try prevent code 
forking, or break ups.

Individual project leaders will not be allowed to "I dont like this remove 
feature X" or "I think this 
is the way it should be done replace function X with this function Y" or "I 
like this
implement feature B", anything which may break, extend, cripple the specified 
RFC/Documentation

Also just the same way that the Meta-leader can replace individual project 
leaders, the individual
project leaders will also be able to replace the meta-leader should  he be 
incompetent at his job.

Having that position is no guarantee.

Why do I mention RFC/Documentation, well it's friggin important that's why, 
this project is too large
and too damn important for individual people with large egos wanting to make a 
name taking advantage of 
the situation. It has been said this is war, and in wars soldiers dont fight 
with out coordination
or with out plans. Our friggin initial plan is the Documentation/RFC we agree 
upon, then we can proceed to
invest our time to implementation of code, or design.  

I still think it's important to have a council, but if you must go with the 
meta-leader idea then go ahead, I
will continue my work. 

 
__________________________________________
Myrddian <address@hidden(nospam)au>
-------------------------------------------
"I stayed up all night playing poker with tarot cards. I got a full house
 and four people died". 

                   -- Steven Wright