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

Re: [DRAFT] Maximum term for tech ctte members



On 18/11/14 at 11:33 +0100, Stefano Zacchiroli wrote:
> Here is a draft GR text which builds on Anthony's work and implements
> some of the aspects discussed in this thread. See below for
> comments/rationales and the attachment for a wdiff.
> 
> ==============================================================================
> The Constitution is amended as follows:
> 
> ---------------------------------------------------------------------------
> --- constitution.txt.orig	2014-11-17 18:02:53.314945907 +0100
> +++ constitution.txt.new	2014-11-18 11:12:13.665659796 +0100
> @@ -299,8 +299,28 @@
>         Project Leader may appoint new member(s) until the number of
>         members reaches 6, at intervals of at least one week per
>         appointment.
> -    5. If the Technical Committee and the Project Leader agree they may
> +    5. A Developer is not eligible to be appointed to the Technical Committee
> +       if they have been a member within the previous 12 months.
> +    6. If the Technical Committee and the Project Leader agree they may
>         remove or replace an existing member of the Technical Committee.
> +    7. Term limit:
> +         1. Membership of the Technical Committee is automatically
> +            reviewed on the 1st of January of each year. At this time, the
> +            terms of the 2 most senior members automatically expire
> +            provided they were appointed at least 54 months ago.
> +         2. A member of the Technical Committee is said to be more senior
> +            than another if they were appointed earlier, or were appointed
> +            at the same time and have been a member of the Debian Project
> +            longer. In the event that a member has been appointed more
> +            than once, only the most recent appointment is relevant.
> +         3. At each review round expiries are processed sequentially, most
> +            senior member first.
> +         4. No expiry can reduce the size of the Technical Committee to
> +            3 members or fewer. (It might thus happen that up to 4 members of
> +            the Technical Committee remain in charge with more than 54 months
> +            of seniority on January 1st. In that case, up to 2 of them will
> +            expire at the next review round, provided that the committee has
> +            been further staffed.)
>  
>    6.3. Procedure
>  
> ---------------------------------------------------------------------------
> 
> As a transitional measure, if this GR proposal is passed after 2015-01-01,
> then the first automatic review of membership of the Technical Committee
> happens immediately.
> ==============================================================================
> 
> - The main change wrt the original text by Anthony is that the provision
>   of not expiring senior members if less-senior ones have resigned is
>   gone. In its stead, there is a provision that inhibits expiries from
>   reducing the CTTE size below 4 members. As a result, the math part
>   with N and R is gone, IMHO simplifying the text.

Hi,

I thought about that change, and I am unsure that this is a good thing.

(Elaborating on the context a bit given the discussion spread over some
time -- two options have been proposed:
- expire the 2 most senior members
- expire the 2-R most senior members, with R the number of resignations
  over the last 12 months)

What we want to encourage is, I think, a sane and healthy turnover in
the TC. Ideally, this would happen automatically: members would just
resign when they feel that bringing fresh manpower is profitable to the
TC overall. However, there's a number of social reasons why this doesn't
work so well.

So what we are proposing here is to force the renewal of some members.

Now, let's assume that I'm a member of the TC, not among the two most
senior members, and that I feel a bit exhausted about that, not really
motivated, and not really up to the task anymore. Ideally, I should be
encouraged to resign.
With the 'strictly 2' schema, I have an additional incentive NOT to
resign: if I resign, I cause 3 renewals instead of 2, which might weaken
the TC a bit too much.
With the '2-R' schema, I have an additional incentive to resign: if I
resign, I 'save' someone else more senior than me from getting expired.
(And given I'm not so active anymore, instead of weakening the TC further,
my resignation might even reinforce the TC).


The '2-R' schema could even result in an internal TC discussion: "OK,
the Project wants us to change two members. Are there people that feel
like resigning now? Or should we just fallback to the default of expiring
the two most senior members?"
I think that if this happened, it would be very healthy for the TC.

What do you think?

Lucas

Attachment: signature.asc
Description: Digital signature


Reply to: