Re: Maximum term for tech ctte members
>>>>> "Lucas" == Lucas Nussbaum <lucas@debian.org> writes:
Lucas> Hi,
Lucas> On 21/10/14 at 17:41 +0000, Anthony Towns wrote:
>> Membership of the Technical Committee is automatically reviewed
>> on the 1st of January of each year. At this time, the terms of
>> the N most senior members automatically expire provided they were
>> appointed at least 4.5 years ago. 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 twelve months.
Lucas> Something just occurred to me.
Lucas> Given the wide range of questions brought to the TC, it makes
Lucas> sense to have some diversity in the TC in order to have
Lucas> expertise at hand covering all the possible questions. Some
Lucas> members might be more familiar with say, porting issues,
Lucas> packages inter-dependencies issues, low-level stuff, desktop
Lucas> environments or might have a tendancy to approach problems
Lucas> with a sysadmin POV, or with a developer POV.
Lucas> When replacing two members at a time, it might be a bit
Lucas> difficult to take that desirable balance into
Lucas> consideration. For example, if there are three candidates A -
Lucas> B - C in the shortlist, and A and B are basically clones in
Lucas> terms of profile, it would make sense to choose (A OR B) AND
Lucas> C. If the final decision is made via a vote, it could require
Lucas> to vote on pairs of candidates.
I've been on the IETF nomcom which does have exactly this problem.
They do vote on slates of candidates with ranked ballots similar to
Debian's ballots.
"works fine."
More generally, this procedure does not remove flexibility from how TC
members are appointed.
That process can be serialized say with two quick votes, or with slates,
or however the DPL and TC like.
Depending on the specifics it may be the case that one member is
technically appointed before another, although I'm sure any good rules
lawyer can give you 5-6 ways around that too.
I agree with your problem, but don't believe this proposal needs changes
to give the DPL and TC adequate mechanisms to address it.
Reply to: