Replying to two messages:
Russ> The question this raises for me is who runs the vote to decide whether to
Russ> override the Project Secretary? I would completely trust Kurt to run that
Russ> vote, but in the general case the Project Secretary running a vote on
Russ> whether to override the Project Secretary is a clear conflict of interest.
Russ> We could require that such a vote be done by public ballot regardless of
Russ> any secret ballot mechanism for other votes, which gives us some built-in
Russ> defense against any problems, but it still makes me a little bit leery to
Russ> set up a situation where someone is running a vote about overriding a
Russ> decision that they may feel strongly about.
I think delegation is the simplest solution here.
At various points the secretary has had a helper. I recall a situation
where (Niel I think) temporarily removed his access to secretary stuff,
I think because he was running for DPL.
Constitution 7.1 permits the secretary to delegate power.
Constitution 7.2 says that if the secretary is unavailable the chair of
the TC acts as secretary (or delegates that decision).
I think we have a couple choices here:
We could decide that for such overrides the decision is always delegated
and that the TC chair either runs the vote or delegates.
That's probably simplest.
I agree that the secretary should step out of the way if the decision is
controversial. In some cases it might be a matter of policy--for
example debating which specific technical mechanism to use for secret
ballots. In a situation like that I wouldn't typically mind the
secretary running the vote. Although I guess in such a situation the
project could give the secretary advice rather than overriding a
decision.
My current thinking is that if we are overriding the secretary, the TC
chair should act as secretary or delegate who conducts the vote.
(I would not explicitly rule out the TC chair delegating back to
secretary).
In researching this message, I realized that I need to correct my
proposal to allow decisions of secretary delegates to be overridden as
well.
I do not propose to have a fallback if the TC chair's decision
acting as secretary needs to have a fallback.
I think the TC chair should delegate that, but I think that will be an
unusual enough path that I don't want to figure out who it gets
delegated to by default.
I would trust the TC chair with the advice of the secretary and DPL to
find someone to run that vote.
>>>>> "don" == Don Armstrong <don@debian.org> writes:
Don> On Sat, 29 Jan 2022, Sam Hartman wrote:
>> So, to be specific, I propose to add a paragraph 8 to section 4.1
>> (powers of the developers):
>>
>> 8. Override a decision of the secretary. Overriding the
>> secretary's determination of the majority required for a ballot
>> option or overriding the determination of the outcome of a vote
>> requires that the developers agree by a 3:1 majority. The
>> secretary's determination of whether a 3:1 majority is required
>> to override the project secretary is not itself subject to
>> override.
Don> I see the intention here. My initial thought is that the
Don> constitution already enables overriding by replacing the
Don> secretary through §4.1.7, assuming the project leader and
Don> secretary disagree.
I see two ways of reading section 4.1.7:
1) If the DPL and secretary disagree on any issue then the project can
replace the secretary.
2) If the DPL and secretary disagree on the only issue where the two of
them both get to have an opinion (namely who is the next secretary), the
project decides.
So it's not clear to me that section 4.1.7 allows the secretary to be
replaced out of cycle.
If we had a big conflict with the secretary, I'd obviously argue for
interpretation 1, but that aspect of the constitution is not so clear to
me.
Don> If we add this, the intersection of §4.1.8 and §4.1.7 should be
Don> addressed when it comes to questions requiring a supermajority.
I don't understand what you mean here.
Are you worried that the project might replace the secretary with a 1:1
majority to get around a determination that some ballot option required
a 3:1 majority?
Attachment:
signature.asc
Description: PGP signature