On Mon, May 26, 2014 at 07:58:45PM -0700, Russ Allbery wrote: > I'm still skeptical that something built around people typically serving > for eight years is the sort of turnover we want, but it's the conservative > approach and doesn't change too much at once. Which has some definite > merits.
I'm not sure that two terms would necessarily be the normal case; I suspect some of that is just that having to quit and appoint a new member to the ctte is work and it's always easier to just let things be. Having thought about it some more, I don't think "longest serving ctte member's term ends on <date>, unconditionally" is a good rule. For one thing, it means that on day-before-<date>, the longest serving ctte member can resign and force the second longest serving ctte member's term to end "prematurely". I might have another go at seeing if I can word it for rolling twelve months, to see if that's workable. > > Possible candidacy rules: > > - A developer is not eligible to rejoin the committee if they have > > been a member for more than four of the past five years. > > (Max two consecutive terms, roughly) > I think this is my preference. Yeah, it seems plausible. > > - When considering candidates for inclusion in the committee, the ballot > > must include at least one candidate who has not been a member of the > > committee in the previous four years. > > (Enforce considering new members, not necessarily having them) > The social pressures here don't work very well. In general, any approach > that has the existing committee decide whether to retain a member who's > already on the committee has the potential for hard feelings, creating > future difficulties working together, and so forth. Yeah, that's a fairly persuasive argument. > > - Any eligible developer nominated by the DPL or by at least two > > developers in the period between August 1st and August 16th will be > > considered for appointment to the committee, and be included on the > > next ballot. Any developer so nominated may, however, withdraw their > > nomination if they so choose. > I'm not sure there's any need to say something about this, Me either. Cheers, aj -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140530093749.ga20...@master.debian.org
