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 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141120192253.GA6120@jtriplet-mobl1
