Re: Alternative proposal (+call for seconds): Expire 2-R members every year
-----BEGIN PGP SIGNED MESSAGE-----
On 12/01/2014 02:37 PM, Lucas Nussbaum wrote:
> [ Cross post -vote, -project ; M-F-T: to -vote ]
> I am hereby formally submitting an alternative proposal, between
> double-dashed lines below (formally it's an "amendment", but I don't expect
> Stefano to accept it, as we discussed it before). I am also calling for
> seconds (see below).
The Constitution is amended as follows:
- --- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
> +++ constitution.2-R.txt 2014-11-24 10:24:42.109426386 +0100 @@ -299,8
> +299,22 @@ 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 (re)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. On January 1st of each year the term of any Committee member +
> who has served more than 54 months (4.5 years) and who is one +
> of the N most senior members automatically expires. N is +
> defined as 2-R (if R < 2) or 0 (if R >= 2). R is the number of +
> former members of the Technical Committee who have resigned, +
> or been removed or replaced within the previous 12 months. + 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.
> 6.3. Procedure
> Rationale --------- First, I think that there is wide agreement that a more
> regular turn-over among TC members would be a good thing. And both
> Stefano's and this proposal aim at addressing this, by ensuring that at
> least 2 members of the TC are replaced every year.
> However, too much turn-over, with more than 2 replacements at one point of
> time, might have negative effects too. The TC might be temporarily weakened
> by having more young members; replacing more than two members at one point
> will cause less replacements later; it increases the difficulty of finding
> new members.
> The recent situation, with three TC members resigning, should not be
> treated as exceptional in the context of this resolution. If it were to
> happen again, I don't think that we should add one or two automatic
> expirations to the three resignations.
> This proposal differs from the original proposal by counting all
> resignations and removals as part of the desirable "2 per year" replacement
> rate, so that the total number of replacements does not exceed two if only
> one or two younger members decide to resign.
> This version of the proposal could even result in an internal TC
> discussion: "OK, the Project wants two members to be replaced. Are there
> members that feel like resigning now? Or should we just fallback to the
> default of expiring the two most senior members?". I think that such a
> discussion would be a healthy way for each TC member to evaluate its
> status. The orignal proposal could have the detrimental effect of pushing
> inactive/demotivated members to stay on the TC until their expiration, to
> avoid causing additional churn.
> Note that there are a few examples to compare the behaviour of the 2-S and
> 2-R proposals in <20141126142529.GA31910@xanadu.blop.info>.
> Calling for seconds ------------------- The DPL can propose general
> resolutions or GR amendments without seeking seconds. I initially wanted to
> waive that right, to only have this option on the ballot if there's
> sufficient interest from others, but the Secretary declined (in
> <20141124232153.GA17656@roeckx.be>). I am therefore seeking seconds, and
> will withdraw this alternative proposal if it does not reach the required
> number of seconds by December 10th.
> Thanks ------ I would like to thank Stefano for organizing the discussion
> around this GR, and preparing the various versions of the resolution and
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----