Alternative proposal: focus on term limits rather than turnover
Stefano Zacchiroli wrote:
> - 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. Membership of the Technical Committee is automatically
> + reviewed on the 1st of January of each year. At this time, the
> + terms of members who were appointed at least four and a half
> + years (54 months) ago automatically expire. Expiry occurs in
> + order of seniority, most senior members first, and is limited
> + to at most 2 members per year.
> + 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.
This approach seems like it focuses too much on aggregate committee
turnover, rather than just setting a term limit. In particular, I don't
see any obvious reason to limit expiry to 2 members per year (given that
we have a process for appointing new members, and that we're about to do
so), or to tie expiry to the calendar year (rather than the member's
appointment), and I think the break before re-election could be
incorporated into the term limit. What about something like this:
"""
No Developer may serve on the Technical Committee for more than 4 years
out of any 6 year period. A Developer's term on the Technical Committee
expires if they would exceed this limit.
"""
Exact numbers open for bikeshedding, but does the principle seem sound?
We can leave it implicit that a developer whose term would immediately
expire is not eligible for appointment, since doing so would be
pointless. We don't need rules allowing a developer to stay on the
committee despite their term expiring; we can easily predict such dates
and plan on appointing new members by that time, just as we do for DPLs.
That also eliminates any issues of relative seniority, since we evaluate
each member's term limit in isolation. It also eliminates any
transitional issues, both because we don't link the expiry to any
particular calendar date, and because by the time we pass this we'll
have enough developers on the committee whose terms will *not*
immediately expire that we won't have to appoint more in a rush.
So, the complete diffstat of this proposal is +3-0, rather than +15-1.
:)
- Josh Triplett
Reply to: