[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: infrastructure team rules



On Tue, Oct 16, 2007 at 07:00:08PM +0200, Stefano Zacchiroli wrote:
> On Tue, Oct 16, 2007 at 01:54:12PM +0200, Josip Rodin wrote:
> > Sorry, but that won't work. The Constitution already empowers the DPL to do
> > things that nobody else is explicitly in charge of, yet none of them ever
> > did anything substantial to e.g. bop DSA to be more active. If we explicate
> 
> Fine to me that you think that won't work, but let me disagree. AFAIK
> none of our foundation documents explicitly states that DSA (since we
> all know that is the *current* problem) is under the "control" of DPL.
> So the other powers you're mentioning above do not (unfortunately)
> apply. I do think that we, as the developer body, need to make a move
> and state that the DPL is in power of un-delegating, or whatever you
> want to call that, DSA members.
> 
> I do believe this can solve the problem, but I understand you disagree
> on this. Your proposal is, in principle, fine with me, but I do fear the
> large amount of bureaucracy it will add to various teams.
> 
> > I think having agreed-upon rules is the best way to proceed. I don't
> > want to give the DPL or the existing team members a blank cheque
> > authority over infrastructure teams. They are nobody's personal
> > playground, they are a common good and they need to be governed as
> > such.
> 
> Being under the authority of the DPL is not being in someone's personal
> playground, since the leader is elected by the developer body. To me
> that would just be a instance of representation, and the DPL already
> represents Debian in various contexts.

See, I can't reconcile these two sets of statements. If the leader
rightfully represents the developer body and that allows him to exercise his
powers, why is there any dilemma whatsoever as to whether the DPL is
authorized to exercise any of his powers in the matter of Debian machines,
like in any other matter where they also represent the developer body?

Furthermore, if the leader having been elected by a vote of the developer
body isn't sufficient proof that the developer body authorized them to act
upon their constitutional duties, which also includes Debian machine
matters, what hope do we really have that another vote by the developer body
would make any difference to the issue?

In any case, we have strayed from the general point to the specifics of that
case. The general point should be...

> I do fear the large amount of bureaucracy it will add to various teams.

My answer is, sadly, this - it's that kind of reasoning that is the root
of our problems with disorganized teams. People dislike documenting,
communicating, distributing, organizing - so they avoid doing it.
Sometimes even just a token amount of those activities is skipped, because
nobody could be bothered. Some time later, we learn why those activities
were necessary in the first place, the hard way - things don't get
documented, too few people are told how they work, not enough people help
carry the burden, the team is a mess.

Taking half an hour of time every four months (to have a look at incoming
mails about new candidates), and another hour or two every two years
(weighing possible expansion options) is not supposed to be a problem.

-- 
     2. That which causes joy or happiness.



Reply to: