Richard Laager writes:
> 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.
I'm not feeling like the conversation is circular at all, to
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
Richard Laager writes:
> 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
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
Richard Laager writes:
> 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
On Mon, Sep 27, 2021 at 06:51:05PM -0700, Russ Allbery wrote:
> Hello everyone,
>
> Below is an initial proposal for a revision to the GR and Technical
> Committee processes, offered to start a project discussion.
You've made various changes to your draft since. Can you send an
updated draft?
On Tue, Sep 28, 2021 at 08:50:08PM -0700, Russ Allbery wrote:
> [...] My goal is a proposal that anyone
> can support as long as they agree that:
>
> * We currently need an explicit and clearly-specified decision-making
> process for the Technical Committee and the Developers via General
>
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
> "Russ" == Russ Allbery writes:
Russ> I've been thinking about this because I like the idea in
Russ> theory but can't see how to make it work in the process
Russ> without introducing new problems including tactical voting
Russ> issues. I have also been wondering why it
Thank you so much for the kind words, Bdale. I echo Sam's gratitude for
your work helping Debian make decisions. I couldn't have said it better.
Bdale Garbee writes:
> FWIW, the idea that any TC vote so evenly split that a casting vote
> might be required by the chair should instead
> "Bdale" == Bdale Garbee writes:
Bdale> Russ Allbery writes:
>> 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.
Bdale>...
Russ Allbery writes:
> 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
* Russ Allbery [2021-09-28 20:50]:
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
Karsten Merker writes:
> 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
Felix Lechner writes:
> Thank you for your lengthy and thoughtful reply. Sorry if it seems
> like I hijacked your thread.
No, no, this is great. The whole point is to have an open discussion.
Thank you very much for your thoughtful message! I think you're raising
some very interesting issues
Timo Röhling 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.
Oh, I
> "Felix" == Felix Lechner writes:
Felix> The constitution's projection of hardened confrontation
Felix> entails a terrible reflexivity: A 3:1 supermajority leaves no
Felix> gray area. There is no gentle nudge and no room for
Felix> measurement. The maintainer was so wrong,
* Russ Allbery [2021-09-28 09:04]:
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
Hi Russ,
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 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
Sam Hartman writes:
> 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
Hubert Chathi writes:
> On Mon, 27 Sep 2021 18:51:05 -0700, Russ Allbery 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
On Mon, 27 Sep 2021 18:51:05 -0700, Russ Allbery 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
> "Russ" == Russ Allbery writes:
Russ> I don't recall the "when the outcome is no longer in doubt"
Russ> provision having been a problem in the past, so I admit my
Russ> bias is towards fixing the wording but maintaining the current
Russ> process. I'm not sure there's a need
Karsten Merker 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
Felix Lechner writes:
> 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
Hi,
On Tue, Sep 28, 2021 at 6:24 AM Adrian Bunk wrote:
>
> whenever there is no clear majority in the TC ...
> the TC should ... propose a GR instead
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
> "Russ" == Russ Allbery writes:
Russ> Procedurally, I don't believe we should automatically start a
Russ> GR because I think there's benefit to going through the normal
Russ> GR process. For example, who is the proposer of the GR for
Russ> the purposes of making subsequent
"Theodore Ts'o" writes:
> 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"?
I think I confused matters by how I
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
Richard Laager writes:
> 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).
Correct.
> That could be another option here, which would
Timo Röhling writes:
> 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
* Russ Allbery [2021-09-28 09:24]:
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:
7. The default option has no proposer or sponsors, and cannot be amended
or
Thank you for the clarifications.
On 9/28/21 11:04 AM, Russ Allbery wrote:
3. Another TC member calls a vote, possibly immediately after making some
last minute change to the ballot (which is allowed).
If I understand correctly, the updated GR process handles this
differently, by extending
The Wanderer writes:
> 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
Russ Allbery writes:
> 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
"Dr. Bas Wijnen" writes:
> 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
Karsten Merker writes:
> 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
Richard Laager writes:
> 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
On 2021-09-28 at 11:44, Russ Allbery wrote:
> Gard Spreemann writes:
>
>> Russ Allbery 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
Gard Spreemann writes:
> Russ Allbery 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
>
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
Russ Allbery wrote on 28/09/2021 at 03:51:05+0200:
> [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.
Note that
On Tue, Sep 28, 2021 at 01:38:48PM +0100, Simon McVittie wrote:
>...
> 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
On Tue, 28 Sep 2021 at 13:56:21 +0200, Karsten Merker wrote:
> In this case the chair surely wouldn't vote to overrule
> themselves as that would be a completely nonsensical behaviour,
The casting vote cannot be used to select an option that is not in the
Schwartz set (loosely: it can only be
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
> >
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
Hello, and thank you for this effort.
Russ Allbery 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
Hello everyone,
Below is an initial proposal for a revision to the GR and Technical
Committee processes, offered to start a project discussion.
This is not a GR proposal. Please do not second it at this time. Since
this is a constitutional change that will require a 3:1 majority, it will
48 matches
Mail list logo
