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

Re: infrastructure team procedures (fourth edit)



On Fri, Nov 09, 2007 at 07:11:42PM +0000, Ian Jackson wrote:
> No, it doesn't _compel_ the DPL to do anything.  Because the DPL can
> always claim to have done such a verification.  At best it encourages
> the DPL to act in a reasonable way.
> 
> I agree that it is good to encourage the DPL to act in a reasonable
> way.  But one of the controversies is whether infrastructure teams are
> currently, and should be, subject to the authority of the DPL.
> 
> When I wrote the constitution I intended them to be, but in practice
> that authority hasn't been exercised.  By now, subordinating
> infrastructure teams to the DPL is a substantial change.
> 
> If that's the change you are proposing, then fine, but you should do
> so more clearly.

Got it. This is an essential component of my proposal - that somebody gets
explicitly empowered by a general resolution of the developers to handle
problems with teams expanding; and because DPL is convenient and
democratically elected, they seem like a good vict... targ... candidate. :)

I'll try to redo the wording.

> I would get rid of a lot of the detailed rules about team management
> and leave that more up to the teams.  Something like this, to replace
> the second half of your proposal:
> 
>  Debian developers resolve the following:
> 
>  * Whether a team in Debian constitutes an infrastructure team is
>    decided by the Debian Project Leader.
>  * Infrastructure teams should publish their own processes and
>    guidelines for adding and removing members, which may be detailed
>    or not as the team pleases.
>  * Teams must enable suitably competent and motivated Developers to
>    join and become full members, following only reasonable expenditure
>    of time and effort.
>  * If in the Leader's view an infrastructure team is failing in
>    the duties set out here, the Leader may intervene as follows: the
>    Leader should set out a timetable for improvement (for example, for
>    addition of new members).  If the timetable is not met, or the
>    improvements are unsatisfactory to the Leader, the Leader may then
>    add one or more new members to the team.
>  * The Leader should limit such interventions to the minimum
>    necessary, in the Leader's opinion, to rectify the problems.

I see where you're coming from on this, but I'm not sure if it will help
unfreeze the leaders in this regard. People will still be able to complain
that timeframes or criteria set by the leader are arbitrary and this will
make DPLs hold back both on setting deadlines and on adding members after
they pass.

> Firstly because I don't think empowering the Leader in this way is a
> conducive to good relations with the teams.

Well, how does that differ from your text above? :)

> Secondly because in practice past DPL's have been very reluctant to
> exercise of powers of this form even when they felt they had them.

I have tried to keep that concern in mind.

> I think instead you should create a duty of the DPL to resolve
> complaints.

This has merit, although it's also a slippery slope because it goes beyond
general composition issues. I'd rather start with a general recommendation
to the leader for them to start paying attention to team compositions,
through a verbiage that will actually accomplish what I said at the top,
and then that will greatly alleviate the number and scope of complaints
(this is my experience of how it works in practice).

-- 
     2. That which causes joy or happiness.



Reply to: