A.2. Withdrawing ballot options:
[…]
4. The default option cannot be withdrawn.
6. If voting is started prior to two weeks after the original proposal
via a call for a vote by a member of the Technical Committee, but
another member of the Technical Committee objects more than two
weeks after the original proposal but before the vote completes, the
vote is still canceled. All members of the Technical Committee are
then given 24 hours to add new ballot options or modify or withdraw
the ballot options they have proposed. During this period no one may
call for a vote. Following that 24 hour period, a new voting period
automatically starts and cannot be canceled.
2. Details regarding voting.
When the Technical Committee votes whether to override a Developer who
also happens to be a member of the Committee, that member may not vote
(unless they are the Chair, in which case they may use only their
casting vote).
1. Options which do not have an explicit supermajority requirement have a
1:1 majority requirement. The default option must not have any
supermajority requirements.
2. The votes are counted according to the rules in A.6. The default option
is "None of the above," unless specified otherwise.
When the vote counting mechanism of the Standard Resolution Procedure is
to be used, the text which refers to it must specify who has a casting
vote, the quorum, the default option, and any supermajority requirement.
Below is an initial proposal for a revision to the GR and Technical
Committee processes, offered to start a project discussion.
7. [...] There is no casting vote. If there are multiple options with no
defeats in the Schwartz set at the end of A.6.8, the winner will be
chosen from those options by lot, via a mechanism chosen by the Project
Secretary.
When the Technical Committee votes whether to override a Developer who
also happens to be a member of the Committee, that member may not vote
(unless they are the Chair, in which case they may use only their
casting vote).
2. Details regarding voting.
Votes are decided by the voting counting mechanism described in A.6.
The voting period lasts for one week or until the outcome is no longer
in doubt, whichever is shorter. Members may change their votes.
Only the chair has the casting vote.When the Technical Committee votes whether to override a Developer who
also happens to be a member of the Committee, that member may not vote
(unless they are the Chair, in which case they may use only their
casting vote).
What is the reason for having a special rule for the chair compared to the other members of the TC in case of having to abstain from the vote?
This part hasn't changed from the current Constitution text either.2. Details regarding voting.
Votes are decided by the voting counting mechanism described in A.6.
The voting period lasts for one week or until the outcome is no longer
in doubt, whichever is shorter. Members may change their votes.
How can be determined that the outcome is no longer in doubt before the voting period ends if members can change their vote at any point in time until the end of the voting period?
On Tue, Sep 28, 2021 at 12:31:30PM +0200, Karsten Merker wrote:
When the Technical Committee votes whether to override a Developer who
also happens to be a member of the Committee, that member may not vote
(unless they are the Chair, in which case they may use only their
casting vote).
What is the reason for having a special rule for the chair compared to the other members of the TC in case of having to abstain from the vote?Only the chair has the casting vote.
Also, this part hasn't changed from the current Constitution text.
2. Details regarding voting.
Votes are decided by the voting counting mechanism described in A.6.
The voting period lasts for one week or until the outcome is no longer
in doubt, whichever is shorter. Members may change their votes.
How can be determined that the outcome is no longer in doubt before the voting period ends if members can change their vote at any point in time until the end of the voting period?
This part hasn't changed from the current Constitution text either.
In this case the chair surely wouldn't vote to overrule
themselves as that would be a completely nonsensical behaviour,
- There is an excemption for the chair in the rule about having
to abstain from the vote and the chair makes use of the casting
vote.
- There is no special excemption for the chair in the rule about
having to abstain from the vote, so the tie isn't resolved and
as a result the TC doesn't overrule the chair.
...
Also, I believe the rationale for this casting vote is the same as for
the existence of a casting vote in general: to make sure that the TC is always able to make a decision, one way or another, and that there is
never an unresolved situation where the outcome of the vote is "there is
no decision".
...
smcv
[Snip]
This proposal was already sufficiently complex that it does not attempt to address the secret ballot. I believe that should be a separate discussion and a separate GR since it's substantially orthogonal to this one.
Also, I believe the rationale for this casting vote is the same as for[...]
the existence of a casting vote in general: to make sure that the TC is always able to make a decision, one way or another, and that there is
never an unresolved situation where the outcome of the vote is "there is
no decision". Even if the chair is not placed in the bizarre situation
of choosing precisely how to overrule themselves, they should still be stating a decision.
In this case, the TC has not made any decision - we have not decided to overrule the chair, we have not decided to decline to overrule the chair,
and we have not even decided on Further Discussion! Once we get to the
point of holding a vote, I don't think we want this to be procedurally possible.
Russ Allbery <rra@debian.org> writes:
A.2. Withdrawing ballot options:
[…]
4. The default option cannot be withdrawn.
This is the most minor of near-useless pedantic comments on my part, but A.2.4 seems redundant: If only the proposer of a ballot option may
withdraw it (A.2.1), and the default option has no proposer (A.1.7),
then we don't really need a separate rule saying that the default cannot
be withdrawn.
In case there should be consensus about requiring the TC chair
to provide a casting vote in case of a tie, this would IMHO
require changing the wording of clause 6.3.2.
First off, thank you for working on this!
On 9/27/21 8:51 PM, Russ Allbery wrote:
6. If voting is started prior to two weeks after the original proposal >> via a call for a vote by a member of the Technical Committee, but
another member of the Technical Committee objects more than two
weeks after the original proposal but before the vote completes, the >> vote is still canceled. All members of the Technical Committee are
then given 24 hours to add new ballot options or modify or withdraw >> the ballot options they have proposed. During this period no one may >> call for a vote. Following that 24 hour period, a new voting period >> automatically starts and cannot be canceled.
Is this complexity necessary? If the vote was not called early, the vote would have started anyway on time and been uncancellable. And the
objector did not object in time. (If the objector had objected prior to
the normal starting time, we aren't in this scenario.) Why does someone
get extra time to object in this case?
2. Details regarding voting.
When the Technical Committee votes whether to override a Developer who >> also happens to be a member of the Committee, that member may not vote >> (unless they are the Chair, in which case they may use only their
casting vote).
I know this is how it is now. But it's always seemed weird. If TC members cannot vote on overruling themselves, why does the chair get to (but only
in the event of a tie)?
Is this even meaningful? Presumably they would vote against overruling themselves, if there are such options. But it seems that if they don't
vote, the measure would fail anyway? Or is this more about them choosing between multiple options (possibly all of which overrule themselves)?
1. Options which do not have an explicit supermajority requirement have a
1:1 majority requirement. The default option must not have any
supermajority requirements.
"must not" or "does not"?
2. The votes are counted according to the rules in A.6. The default option >> is "None of the above," unless specified otherwise.
This "None of the above" seems duplicative of the one above. Do we need
both?
When the vote counting mechanism of the Standard Resolution Procedure is
to be used, the text which refers to it must specify who has a casting
vote, the quorum, the default option, and any supermajority requirement.
Maybe the "The default option must not have any supermajority
requirements." should be moved here?
Gard Spreemann <gspr@nonempty.org> writes:
Russ Allbery <rra@debian.org> writes:
A.2. Withdrawing ballot options:
[…]
4. The default option cannot be withdrawn.
This is the most minor of near-useless pedantic comments on my
part, but A.2.4 seems redundant: If only the proposer of a ballot
option may withdraw it (A.2.1), and the default option has no
proposer (A.1.7), then we don't really need a separate rule saying
that the default cannot be withdrawn.
Yes, I completely agree there's no technical need for this. I
included it anyway because it felt like it added some clarity and
meant that the reader didn't have to chase the logic down through
several other provisions to be sure. There are a few other places
like this in the text (mostly around repeating phrases) where I erred
on the side of clarity rather than brevity.
I can certainly change this if people would prefer. It's possible
that I overcorrected for how tricky I find it to interpret the
current wording.
The scenario where this matters is this:
1. Vote starts. There is some controversy and discussion for a week and a
half.
2. 12 days into the voting period one TC member is away or ill or
otherwise unable to immediately respond.
3. Another TC member calls a vote, possibly immediately after making some
last minute change to the ballot (which is allowed).
4. By the time the TC member who would object returns, either the timing
for the mandatory vote has elapsed or, were the vote canceled, the
mandatory vote would start again within a matter of hours.
On Tue, Sep 28, 2021 at 04:11:44PM +0200, Karsten Merker wrote:
In case there should be consensus about requiring the TC chair to
provide a casting vote in case of a tie, this would IMHO require
changing the wording of clause 6.3.2.
I agree that if we keep the casting vote intact, it needs to be a must
in order to ensure the TC will always decide something. However, I agree
with Adrian that it would be better to instead turn the decision into a
GR in such a case.
As a possibility to consider, what about folding this into A.1.7? That already states that the default option cannot be amended, which likewise would seem to follow from the fact that it has no proposer and thus no
one to make or accept amendments.
Something like "The default option has no proposer or sponsors, and as
such, can neither be amended nor withdrawn." would seem to convey all
aspects in one concise sentence - although it does have the downside
that it would be referring to withdrawal prior to the section where withdrawal is discussed.
3. Another TC member calls a vote, possibly immediately after making someIf I understand correctly, the updated GR process handles this
last minute change to the ballot (which is allowed).
Thank you, this is a good idea. The advance reference to withdrawal is >exactly why I didn't do that originally, but on further reflection I think >it's fine. I now have as A.1.7:In this context,
7. The default option has no proposer or sponsors, and cannot be amended
or withdrawn.
and dropped the point that was A.2.4.
Am Mon, Sep 27, 2021 at 06:51:05PM -0700 schrieb Russ Allbery:
7. [...] There is no casting vote. If there are multiple options with no
defeats in the Schwartz set at the end of A.6.8, the winner will be
chosen from those options by lot, via a mechanism chosen by the Project >> Secretary.
What ist the meaning of the term "chosen by lot"? My dictionary
doesn't explain the expression in the context of a vote but only
in the context of a piece of land, which doesn't make sense here.
When the Technical Committee votes whether to override a Developer
who also happens to be a member of the Committee, that member may
not vote (unless they are the Chair, in which case they may use only
their casting vote).
What is the reason for having a special rule for the chair compared to
the other members of the TC in case of having to abstain from the vote?
2. Details regarding voting.
Votes are decided by the voting counting mechanism described in A.6.
The voting period lasts for one week or until the outcome is no longer
in doubt, whichever is shorter. Members may change their votes.
How can be determined that the outcome is no longer in doubt before the voting period ends if members can change their vote at any point in time until the end of the voting period?
4. The Project Leader has a casting vote. There is a quorum of 3Q. The
default option is "None of the above."
6.3. Procedure
1. Resolution process.
The Technical Committee uses the following process to prepare a
resolution for vote:
1. Any member of the Technical Committee may propose a resolution.
This creates an initial two-option ballot, the other option being
the default option of "Further discussion." The proposer of the
resolution becomes the proposer of the ballot option.
In this context,
6.3.1.3. If all ballot options are withdrawn, the process is canceled.
is slightly ambiguous, as the default option is technically also a ballot option. Maybe change it to "If all proposed ballot options…"?
For that reason, I would also change 6.3.1.2 to read "Any member of the Technical Committee may *propose* additional ballot options", which
also makes it consistent with the phrasing in A.1.1.2
If I understand correctly, the updated GR process handles this
differently, by extending the clock on changes and prohibiting such
changes at "the last minute" (the end of the maximum discussion period).
That could be another option here, which would have the benefit of consistency. But the TC is a different situation than a GR, and they
don't need to be exactly the same process.
On Mon, Sep 27, 2021 at 06:51:05PM -0700, Russ Allbery wrote:
4. The Project Leader has a casting vote. There is a quorum of 3Q. The
default option is "None of the above."
Should this be, "unless specified elsewhere"?
6.3. Procedure
1. Resolution process.
The Technical Committee uses the following process to prepare a
resolution for vote:
1. Any member of the Technical Committee may propose a resolution.
This creates an initial two-option ballot, the other option being
the default option of "Further discussion." The proposer of the
resolution becomes the proposer of the ballot option.
Here the default option is "Further discussion" as opposed to "none of
the above". Is this intentional, or was this a historical artifact?
Also, as stated here in 6.3.1.1, it appears that any member of the TC
may propose a resolution... on any subject they want? I'm guessing the unstated presumption is this is related to a subject under discussion by
the TC. Should this be stated explicitly?
Russ> Procedurally, I don't believe we should automatically start a"Russ" == Russ Allbery <rra@debian.org> writes:
whenever there is no clear majority in the TC ...
the TC should ... propose a GR instead
"Votes are decided by the vote counting mechanism described in A.6. By default, the voting period lasts for one week. Members may change their votes during the voting period. The TC can - even after the voting
period has started - declare the voting period to end earlier if all
members of the TC agree to that."
Karsten Merker <merker@debian.org> writes:
Am Mon, Sep 27, 2021 at 06:51:05PM -0700 schrieb Russ Allbery:
2. Details regarding voting.
Votes are decided by the voting counting mechanism described in A.6.
The voting period lasts for one week or until the outcome is no longer >> in doubt, whichever is shorter. Members may change their votes.
How can be determined that the outcome is no longer in doubt before the voting period ends if members can change their vote at any point in time until the end of the voting period?
Yeah, this wording bugs me too. It's pre-existing and I didn't try to fix it, but we probably should. The simplest fix (including a typo fix for
the first line) would be:
Votes are decided by the vote counting mechanism described in A.6.
The voting period lasts for one week or until the outcome is no longer
in doubt assuming no members change their votes, whichever is shorter.
Members may change their votes until the voting period ends.
It's still a bit awkward. Better phrasing is welcome. I'm not sure I see
a better fix; we do want members to be able to change their votes, but we don't want every vote to have to take a full week.
For a committee that effectively appoints its own members, it is
probably unwise to ask the Chair to resolve split votes except in the
most trivial of cases. A general vote, on the other hand, would supply
the broad democratic legitimacy needed to silence critics forever.
When facing that monumental and often disproportionate alternative,
some TC members may reconsider their votes. At least I would.
More generally, foundational documents do not captivate the minds of the governed when laden with procedural details. Our constitution already
shuns a common purpose with "It does not describe the goals of the
Project" (which for some reason comes right after the more positive "The Debian Project is an association of individuals who have made common
cause to create a free operating system."). In the current thread, I
miss simple language as to whether the purpose of decisions is
legitimacy or speed.
I would rely on a simple popular vote when needed (GR, and perhaps
elections) but otherwise leave the TC to its own devices—including the ability to overrule a maintainer with an absolute majority (not 3:1).
The TC has over the years proven itself to be a trusted and transparent institution with good decision-making capabilities. We act better in
groups and more wisely than as individuals, with or without rules.
Russ> I don't recall the "when the outcome is no longer in doubt""Russ" == Russ Allbery <rra@debian.org> writes:
A.3. Calling for a vote
3. Minor changes to ballot options under point A.1.5 may be made up
until 24 hours before the call for a vote is issued. However, if they
are made after or within 24 hours of the end of the discussion period,
the Project Secretary must agree the change does not alter the meaning
of the ballot option...
On Mon, 27 Sep 2021 18:51:05 -0700, Russ Allbery <rra@debian.org> said:
A.3. Calling for a vote
...
3. Minor changes to ballot options under point A.1.5 may be made up
until 24 hours before the call for a vote is issued. However, if they
are made after or within 24 hours of the end of the discussion period,
the Project Secretary must agree the change does not alter the meaning
of the ballot option...
The "must" makes it sound like the Project Secretary is obligated to
agree that any such proposed change doesn't alter the meaning, which I suspect is not what was intended. Perhaps instead,
However, if they are made after or within 24 hours of the end of the
discussion period, and Project Secretary agrees that the change does
not alter the meaning of the ballot option, the Project Secretary
will allow 24 hours for objections before issuing the call for a
vote.
However, I think we already have the complexity you are worried about:
4.2.1 permits both the DPL and the TC tto sponsor a resolution without additional developers.
I think that it's not too hard to make this useful.
Under section 6.3,
say something like
"When the Technical Committee proposes a general resolution to the
project, it may delegate the authority to accept amendments and withdraw ballot options to one of its members."
If the TC didn't choose to delegate such authority, it would presumably
have to vote on amendments.
6. If voting is started prior to two weeks after the original proposal >>> via a call for a vote by a member of the Technical Committee, but >>> another member of the Technical Committee objects more than two
weeks after the original proposal but before the vote completes, the >>> vote is still canceled. All members of the Technical Committee are >>> then given 24 hours to add new ballot options or modify or withdraw >>> the ballot options they have proposed. During this period no one may >>> call for a vote. Following that 24 hour period, a new voting period >>> automatically starts and cannot be canceled.
Basically, there is a scenario where the vote could be canceled but the >subsequent ensuing discussion period during which members can change their >ballot options is so short as to be unfair (some of the committee is
asleep) or unusable.
I'm reading this as another message of support for a tied vote in the TC
to result in an outcome of further discussion or to automatically set off
a GR. Let me know if I misunderstood.
I think the constitution is the wrong foundational document to look to for the "minds of the governed." The constitution is concerned primarily with the procedural details. We have to spell them out somewhere so that we
have a shared basis to make hard decisions in a way that we've previously agreed would be fair (even if we're on the losing side).
The reason for the rework of the TC process in this proposal is precisely because the TC's decision-making capabilities previously partially broke
down in ways that left a lot of damage behind, including accusations of unfairness. This proposal would prevent the procedural circumstances that happened previously from happening again, in a way that I hope is more transparently fair and predictable than the current process.
My experience in multiple heated debates in
Debian, and in similar problems in other governance debates and on-line communities, is that having good, clear, and previously-agreed process is exactly what creates the space for people to be gracious and collaborative even when they strongly disagree with the opinions of others.
But I think the net long-term effect is to reduce the
temperature.
Karsten Merker <merker@debian.org> writes:
"Votes are decided by the vote counting mechanism described in A.6. By default, the voting period lasts for one week. Members may change their votes during the voting period. The TC can - even after the voting
period has started - declare the voting period to end earlier if all members of the TC agree to that."
This allows any member of the TC to force the voting period to take a week even if they're a minority of one. Maybe it doesn't matter that much
because a week isn't very long, but this still doesn't seem correct (and isn't the current practice). Or, less controversially and more commonly,
it means that if one TC member is unavailable for some reason, all votes
are forced to be a week long because they're not available to agree to
make it shorter.
I don't recall the "when the outcome is no longer in doubt" provision
having been a problem in the past, so I admit my bias is towards fixing
the wording but maintaining the current process. I'm not sure there's a
need for a change.
"Felix" == Felix Lechner <felix.lechner@lease-up.com> writes:
What do you think of the following:
6. If a vote is canceled later than 13 days after the original
proposal, the mandatory vote will be postponed and start 24 hours
after the time of cancellation. Until then, no one may call for
another vote.
Thank you for your lengthy and thoughtful reply. Sorry if it seems
like I hijacked your thread.
On Tue, Sep 28, 2021 at 1:04 PM Russ Allbery <rra@debian.org> wrote:
I'm reading this as another message of support for a tied vote in the
TC to result in an outcome of further discussion or to automatically
set off a GR. Let me know if I misunderstood.
My point was broader. I envision nothing "automatic" but would leave it instead to the TC Chair, in a living process, to precipitate an outcome
that survives public scrutiny and even outcry.
Your concerns about tactical voting may be better handled by
observers—such as the press, or fearless advocates of transparency like Adrian—while the process unfolds.
For the writer of a constitution, fear weakens the document's intuitive appeal, however imprecise the wording may seem.
I think the constitution is the wrong foundational document to look to
for the "minds of the governed." The constitution is concerned
primarily with the procedural details. We have to spell them out
somewhere so that we have a shared basis to make hard decisions in a
way that we've previously agreed would be fair (even if we're on the
losing side).
Why focus solely on the defeat?
The constitution's projection of hardened confrontation entails a
terrible reflexivity: A 3:1 supermajority leaves no gray area. There is
no gentle nudge and no room for measurement. The maintainer was so
wrong, fixing it required the second-worst measure in the Debian
universe.
Procedural safeguards do not build consensus—the all-elusive
project-wide goal the constitution so decidedly disavows.
In another example of reflexivity, strong rules are a sign of conflict.
They are not needed—and rarely adopted—in peaceful and easy-going communities.
My experience in multiple heated debates in Debian, and in similar
problems in other governance debates and on-line communities, is that
having good, clear, and previously-agreed process is exactly what
creates the space for people to be gracious and collaborative even when
they strongly disagree with the opinions of others.
Please do not read my response as second-guessing your experience. I am simply using this "space ... to be gracious and collaborative even"
though I "strongly disagree with the opinions of others".
But I think the net long-term effect is to reduce the temperature.
How has it worked out so far?
On the other hand I see two issues in the current provision as a matter
of principle:
a) The constitution explicitly allows changing a vote during the
voting period, so there is the possibility of convincing
another member to change their already cast vote before the
voting period ends. From a formal point of view this means
that there is no way to determine "if the outcome is no longer
in doubt" before the regular voting period has ended, unless
each member has declared that they will not change their vote
anymore (which is equivalent to the process in my phrasing
proposal above).
b) The second concern that I have with the "majority party" (for lack of
a better term) being able to shorten the voting period without
consent from the other members is that it under certain circumstances
allows removing the ability of other members to cast a dissenting
vote with the argument "it wouldn't make a difference anyway".
This could happen if a "dissenter" can cast their vote within the
regular one-week period but not directly at the beginning and the
voting period gets declared closed after a day or two because
"further votes wouldn't make a difference".
Having the non-winning votes represented in the result is a basic
element of democracy and is important for assessing the result. For
example if somebody is pondering over starting a GR after a TC
decision it can make quite a bit of a difference whether the decision
has been taken unanimously or whether it has been nearly a 50:50
decision.
I find having an explicit process to use as a structure for navigating a >disagreement to be calming and supportive. It makes me feel like I have
firm ground under my feet and space to think when I know procedurally what
I can and can't do in order to argue my perspective.
[...]
In contrast, it's hard to imagine a stronger rule set than a written
program, which describes to a computer exactly what to do and leaves as >little ambiguity as possible. But I find computer programs relaxing and >enjoyable precisely because of that predictability.
The process I'm proposing arguably favors the opposite side from my own in the TC decision that primarily prompted this change and would have...
prevented the process that indeed happened.
But with the benefit of a few
years of hindsight and watching subsequent GRs, I think a simpler process with clearer rules and less flexibility would have had a better social outcome for the project.
I find having an explicit process to use as a structure for navigating a disagreement to be calming and supportive.
It's easy to be part of a community when everyone agrees. It's powerful
and delightful to be part of a community when people disagree but the community still works together with respect and mutual support. Creating process that allows myself and others to do this more easily is part of
how I enjoy contributing to a community.
"Bdale" == Bdale Garbee <bdale@gag.com> writes:
FWIW, the idea that any TC vote so evenly split that a casting vote
might be required by the chair should instead transition to a GR is
growing on me.
"Russ" == Russ Allbery <rra@debian.org> writes:
Hello everyone,
Below is an initial proposal for a revision to the GR and Technical
Committee processes, offered to start a project discussion.
One concern I have about eliminating the 2:1 majority for a GR to make/override a TC decision is that it might encourage things to move to
a GR unnecessarily.
A second is that it might encourage things to move to a GR too
soon. Having the TC hear something and hash out options in a smaller
group setting seems useful, even if the issue ultimately ends up at a
GR.
A way to split the difference might be to lift the 2:1 supermajority requirement under some conditions. For example: GR _options_ put forward
by the TC do not have the 2:1 supermajority. So the TC could initiate a
GR and say: these are the two or three options we think are reasonable,
we should choose one of them, but we deadlocked on which one. As long as
the Developers are choosing between those options, the majority decides (because getting _a_ decision is the goal). But if the developers choose
to exercise their right to add alternatives and (attempt to) overrule
the TC, then those alternatives must gain a supermajority of Developers.
Here is a specific textual proposal:
4. Make or override any decision authorised by the powers of the
Technical Committee, provided they agree with a 2:1 majority. If
such a resolution has ballot options proposed by the Technical
Committee, those options do not need a 2:1 majority.
I'm hesitant to make a TC tie automatically turn into a GR. If the
options are really similar, varying in some detail, that should not
trigger a GR. That's a waste of the Developers time and energy.
If we _really_ want to deal with the corner case of the TC chair having a casting vote when they are being overruled (which as I think about it is probably not that big of deal in practice),
One minor clarification: I was thinking about removing the 2:1 *override* requirement, but I don't think we should remove the 2:1 *make*
requirement.
There's some weirdness here with maintainer overrides. I'm not sure if it should be possible to override a maintainer with a simple majority GR.
(By that, I mean I'm literally not sure; I can see arguments either way.)
On 10/5/21 11:04 PM, Russ Allbery wrote:
One minor clarification: I was thinking about removing the 2:1
*override* requirement, but I don't think we should remove the 2:1
*make* requirement.
Part of the discussion about the TC was that they might deadlock on
_which_ option to choose, which then needs to go to a GR. If this
happens, the TC did not make a decision, so the developers are using
their power to _make_ a decision, not _override_ one. With what you have proposed above, the 2:1 supermajority would still apply. That may or may
not be desirable. But was that your intended result?
There's some weirdness here with maintainer overrides. I'm not sure if
it should be possible to override a maintainer with a simple majority
GR. (By that, I mean I'm literally not sure; I can see arguments
either way.)
Overriding a maintainer by a GR seems like a pretty serious thing. If
nothing else, it's probably pretty embarrassing. I'd imagine those
proposing, sponsoring, and voting in favor of such a resolution
understand that. If we get a majority of developers voting to override,
that seems sufficient to me (in the context where the 2:1 TC make supermajority is already being removed; I'm not necessarily suggesting
this change standalone).
This wouldn't change anything if the TC vote result is further discussion, since in that case there's no decision to override and, as you point out,
the GR would stay at a 2:1 majority required if the developers wanted to exercise the powers of the TC. (In practice, most likely the GR would be phrased as a statement on issues of the day, which is technically
nonbinding and only requires a simple majority but which everyone is
likely to honor.)
First off, let me say I have no objections to your positions on
this. Also, I'm honestly not trying to argue in circles. I'm
specifically trying to confine my replies to only newly presented
issues.
On 10/10/21 1:41 PM, Russ Allbery wrote:
This wouldn't change anything if the TC vote result is further
discussion, since in that case there's no decision to override and, as
you point out, the GR would stay at a 2:1 majority required if the
developers wanted to exercise the powers of the TC. (In practice, most
likely the GR would be phrased as a statement on issues of the day,
which is technically nonbinding and only requires a simple majority but
which everyone is likely to honor.)
Your comment about the "statement on issues of the day" made me think a bit... if it's the case that GRs will use "statement on issues of the
day" to make decisions anyway (as e.g. on systemd), is that a reason to eliminate the 2:1 supermajority to _make_ TC decisions?
A related question... if a GR makes a decision, what's the situation
with the TC overriding that at some point? In other words, if the
developers make a decision in a GR, obviously the TC shouldn't
immediately override it, but are we "stuck" with that GR decision
forever even if facts change? I think the real-world answer to this is
that if the facts change, the TC could change the position and if nobody objects, it's fine. If they do, then you get another GR.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 82:28:42 |
| Calls: | 6,658 |
| Calls today: | 4 |
| Files: | 12,203 |
| Messages: | 5,333,433 |
| Posted today: | 1 |