Re: Opposing strict time limits

[Russ Allbery]

Felix Lechner  writes:
> On Mon, Nov 8, 2021 at 9:49 AM Russ Allbery  wrote:

>> If your point is, instead, that Wouter's general system is undesirable
>> yes, I largely agree

> Without reflecting on either proposal, I merely cautioned that
> constitutional amendments should be based on sound premises.

...okay?  I truly don't understand why you felt moved to caution me about
that, but sure, I agree with that principle.  I believe my constitutional
amendment is based on sound premises; if I didn't, I wouldn't have made
it.  :)

> As to the point between you and Wouter, is there perhaps a simpler
> measure when a discussion is over—such as one week without a proposal
> that attracted at least three novel supporters (in total)?

I think this is functionally equivalent to Wouter's proposal except even
weaker (you've replaced 6 with 3), so I would prefer Wouter's proposal to
that one.

I suppose the counter-balance is that you say "proposal," by which I
assume you mean ballot option, so each group wanting to delay further has
to produce a concrete proposal, but that makes me less comfortable with it
because it creates an incentive to essentially "spam" the ballot with
proposals in order to achieve the desired goal of extending the discussion
period.  Wouter's proposal seems better since it allows people to ask
directly for what they want (a delay) without having to work around the
spirit of the rules to achieve it.

This is also an advantage of Wouter's proposal over mine: my system also
creates an incentive to add a ballot option only to extend the discussion
period.  That's also not ideal; I just couldn't see a way of avoiding it
without adding what felt like too much complexity.  In my system, that
extension is limited to (normally) an additional week (the intent is to
give people some time to absorb the implications of a new proposal), so I
think the incentive for new ballot options as a procedural maneuver rather
than a true option is lesser and probably won't be an issue in practice.
I also wanted to allow addition of a placeholder option that could be
fleshed out later, and this seemed the simplest way to do that.

-- 
Russ Allbery (r...@debian.org)  

Re: Opposing strict time limits

[Felix Lechner]

Hi

On Mon, Nov 8, 2021 at 9:49 AM Russ Allbery  wrote:
>
> If your point is, instead, that Wouter's general system is undesirable
> yes, I largely agree

Without reflecting on either proposal, I merely cautioned that
constitutional amendments should be based on sound premises.

As to the point between you and Wouter, is there perhaps a simpler
measure when a discussion is over—such as one week without a proposal
that attracted at least three novel supporters (in total)?

Kind regards
Felix Lechner

Re: Do we want to Handle Secret Ballots in the same GR as Voting Changes

[Holger Levsen]

On Mon, Nov 08, 2021 at 10:38:01AM -0700, Sam Hartman wrote:
> Holger> all of this and additionally personally I'd also find it
> Holger> disrespectful to hijack/piggyback (on) Russ' work.
> I'm frustrated reading this message because it sounds like you've jumped
> to the assumption that I'm  hijacking Russ's work without coordinating
> with him.

I'm frustrated you read "I would find it disrectful" as disrespectful.
I didn't know whether you coordinated with Russ and I did not claim
anything in that regard.

*I* find it disrespectful to piggyback on Russ' proposal and I respect
you and Russ disagree with me.

> I hope that in similar future situations, you ask rather than jumping to
> disrespect.

Same same.

And, I'd hope that in the future a GR on secret ballots will fail. Because,
they won't be secret (because they cannot be in technical terms) and 
they would fuel a cabal.

And there should be less cabals in Debian.

If you find this opinion disrespectful as well...


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Life may not be the party we hoped for, but while we're here we might as well
dance!


signature.asc
Description: PGP signature

Re: Do we want to Handle Secret Ballots in the same GR as Voting Changes

[Russ Allbery]

Holger Levsen  writes:
> On Mon, Nov 08, 2021 at 12:12:33PM -0500, Louis-Philippe Véronneau wrote:

>> I'd tend to be in favor of making this a separate GR.
> [...]
>> Adding yet another change to this proposal would only make things more
>> complex and make the issues at hand harder to understand.

> all of this and additionally personally I'd also find it disrespectful to
> hijack/piggyback (on) Russ' work.

Sam asked me explicitly if I would mind if he took this approach before
bringing it up here and I have (and had) no objections.  (I have no strong
feelings either way about whether to run this as a separate GR and am
happy to go with whatever the project consensus seems to be.)

-- 
Russ Allbery (r...@debian.org)  

Re: Do we want to Handle Secret Ballots in the same GR as Voting Changes

[Felix Lechner]

Hi

On Mon, Nov 8, 2021 at 9:38 AM Sam Hartman  wrote:
>
> rather than jumping to disrespect.

Please let's not fight fire with fire. I found Holger's comment quite
compassionate—at least compared to the comments he directed at me—and
would like to congratulate him.

He did not know that his facts were off. Neither did anyone else.

Kind regards
Felix Lechner

Re: Opposing strict time limits

[Russ Allbery]

Felix Lechner  writes:

> The question did not have an answer. [1] To avoid pain, the project
> prefers shorter discussions on controversial topics. It is the opposite
> of what you wrote.

I think the detail that you may be missing is that under Wouter's system
for extending the discussion period, it doesn't matter what the project as
a whole wants.  The extension is not decided by vote; opposition is not
counted.  Rather, any six (K+1) Developers can extend the discussion
period, regardless of anyone else's opinion of whether that's a good idea.

What I wrote, which kicked off this subthread, was:

This preserves the same minimum discussion period (1 week), but makes
it very easy to extend it to two weeks and moderately easy to extend
it to three weeks.  This will probably happen for all but the most
urgent and uncontroversial GRs.

I believe it is correct to say that, should we adopt a system such as that
modification of Wouter's proposal, one will be able to find at least 6
Developers to extend the discussion period two two weeks for all but the
most urgent and uncontroversial GRs, and that it is highly likely that one
will be able to find 12 Developers to extend it to three weeks.  It's a
very low bar of support: about 3% of the voting membership to extend to
three weeks.  As we've seen in the discussion, some folks believe the
discussion period should be longer for (nearly) all votes as a matter of
principle, and would presumably routinely support such an extension.

That proposed system may still be a bad idea, to be clear.  I think it
provides a rather dramatic simplification of the discussion period length
over either my proposal or Wouter's original proposal (and over the
existing constitution), which has a lot of appeal at least to me.  (All
things being equal, I think simpler systems are better than more complex
systems.)  But it does place a burden on people to propose an extension
for any GR whose discussion period should be longer than a week, which may
not be desirable.

If your point is, instead, that Wouter's general system is undesirable
because it allows the discussion period to be extended longer than the
project as a whole may wish discussion periods extended, since the project
as a whole may prefer shorter discussions on controversial topics, well,
yes, I largely agree, which the root of why I prefer my original proposal
over Wouter's.

To add some more detail to that, I think there is a trade-off.  Longer
discussion periods do produce better proposals and a richer variety of
options, plus are simply better from a democratic perspective since they
give people more time to become aware of the proposal and to think about
it in detail.  But I think we can all agree that there is a point of
diminishing returns (although we may disagree about where that point is).

For example, making the discussion period of every GR take a minimum of
one year would probably produce better-crafted final results (I do know of
one organization whose bylaws work this way), but I don't think that's
what we want.  It sacrifices timeliness and it requires anyone who wants
to make a change sign up for an extended effort.

Also, for Debian, the other aspect of the trade-off is that, for
controversial GRs, the pattern has been that the discussion gets more
heated and divisive as it goes on.  People start repeating themselves,
they get angrier that no one is changing their mind, the messages get more
personal, and I felt like I could watch people's views become more
entrenched and less generous to those with whom they disagreed.  So I
believe there is also some harm that is done by extended discussion
periods, and we have to balance that against the benefit achieved by
having better proposals and more time for people to absorb the proposal.

My proposal (not the modification of Wouter's but the one that I'm
bringing to GR) chooses to strike that balance by putting it at roughly
the same place the balance lies today with the existing system (the
current minimum is two weeks and for recent controversial GRs we've gone
three weeks), but making that timing more predictable so that people have
clear deadlines to work towards and the timing of the vote isn't as
susceptible to strategic maneuvering.  It's not a very ambitious change;
it probably shortens the formal discussion period a bit on average, but
not a lot.

My theory is that we're probably not too far off from the right balancing
point in that trade-off right now, and the DPL retains the ability to vary
things by a week in either direction if, for a given GR, they believe that
the balance isn't quite right.  My theory is also that three weeks is a
sufficiently long time to absorb a proposal and come up with a
counter-proposal if everyone knows there is a deadline, so that the
original GR proposer doesn't have an unfair advantage.

One certainly may disagree with those theories!  I believe Wouter does,
and hence his alternate proposal, which 

Re: Do we want to Handle Secret Ballots in the same GR as Voting Changes

[Richard Laager]

Your proposal seems fine at first glance. I would prefer to see this 
handled as a separate GR. If they don't conflict textually, you could 
run them in parallel, but honestly I'd prefer to see them run in series. 
A few more weeks of delay doesn't seem to be a problem for this topic.


--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

Re: Do we want to Handle Secret Ballots in the same GR as Voting Changes

[Sam Hartman]

Holger> all of this and additionally personally I'd also find it
Holger> disrespectful to hijack/piggyback (on) Russ' work.


I'm frustrated reading this message because it sounds like you've jumped
to the assumption that I'm  hijacking Russ's work without coordinating
with him.
I don't think you've asked either Russ or me that.
As it turns out, Russ, Pierre-Elliott and I have been discussing voting
changes for months, and we've been splitting the energy of who  works on
what.
Pierre-Elliott was originally working on secret ballots, but got busy
and was in favor of me bringing the question forward.

I hope that in similar future situations, you ask rather than jumping to
disrespect.

--Sam

Re: Draft GR for resolution process changes

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Sam Hartman  writes:
Charles> - About the sponsors, if there are too many, then the
Charles> proposer is more at risk to face vetos when accepting
Charles> amendments.  (I write that as I accepted major changes as
Charles> the proposer of a GR option some years ago.)  Would it make
Charles> sense to limit the total number of sponsors, and to only
Charles> allow developers to sponsor one option ?

>> I don't understand this concern very well.  If some of your
>> sponsors don't like an amendment you accepted you can withdraw.
>> So long as you have k sponsors remaining, the option can stay on
>> the ballot.

>> What am I missing that leads to your concern?

It sounds like what russ and Charles are talking about is the following:

* You as a proposer want to accept an amendment

* A sponsor objects, and so you can't even though you would have been
  able to if you had fewer sponsors.

I have an alternate proposed fix:

If the proposer accepts the amendment and there are k sponsors who have
not objected, the amendment is accepted.
(I think it's okay even if we end up counting new sponsors to get to k
who have not objected)


Obviously sponsors who don't like the amendment can go off and propose
their own ballot options.

My rationale is that we'd rather not have things be dependent on
strategic ordering of who gets accepted as a sponsor etc.


In the current constitution, the proposer of the resolution is all sorts
of special, and has special powers and so we want to carefully control
what amendments they can accept.

But under Russ's approach, the whole amendment process is really just a
convenience to make it easier to update an option with less withdrawing
and  re-proposing.
I think we want to let proposers change their text provided they have
enough support at the end of the day, so let's effectively say that.

I am sympathetic to the desire to avoid having seconds/sponsorships pile
on.
And yet, I'd prefer not to have a hard limit.
I know I've found myself in cases where it was quite important to me to
be seen as expressing strong support for an option in a situation where
for example I'd been involved in helping draft the option.
And yet I wasn't faste enough on the email.
I think the same has happened to others.
So, I definitely  support social conventions to limit number of
sponsors, but I'd prefer not to have a hard and fast constitutional
rule.


signature.asc
Description: PGP signature

Re: Do we want to Handle Secret Ballots in the same GR as Voting Changes

[Holger Levsen]

On Mon, Nov 08, 2021 at 12:12:33PM -0500, Louis-Philippe Véronneau wrote:
> > I'd like to ask the community whether we'd like to handle secret ballots
> > now, or in a separate GR.
> I'd tend to be in favor of making this a separate GR.
[...]
> Adding yet another change to this proposal would only make things more
> complex and make the issues at hand harder to understand.

all of this and additionally personally I'd also find it disrespectful to
hijack/piggyback (on) Russ' work.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Bottled water companies don't produce water, they produce plastic bottles.


signature.asc
Description: PGP signature

Re: Opposing strict time limits

[Felix Lechner]

Hi,

On Mon, Nov 8, 2021 at 7:43 AM Russ Allbery  wrote:
>
> Maybe you could
> try rephrasing in the hope that I may understand a different version of
> the question better?

The question did not have an answer. [1] To avoid pain, the project
prefers shorter discussions on controversial topics. It is the
opposite of what you wrote.

Secret votes will reduce fear, but for a wholesome remedy contributors
have to forgo provocation and punishment and instead seek compromise
and common ground. Both will lead to a lasting peace.

Kind regards
Felix Lechner

[1] https://en.wikipedia.org/wiki/Rhetorical_question

Re: Do we want to Handle Secret Ballots in the same GR as Voting Changes

[Louis-Philippe Véronneau]

On 2021-11-08 12 h 01, Sam Hartman wrote:
> 
> 
> Russ made a final call for informal discussion.
> I'd like to ask the community whether we'd like to handle secret ballots
> now, or in a separate GR.

I'd tend to be in favor of making this a separate GR.

Although I welcome Russ' & al. efforts in modernising our voting
mechanism, I have to say the proposed changes are already complex enough
that I haven't found the time and energy to go through them seriously.

Adding yet another change to this proposal would only make things more
complex and make the issues at hand harder to understand.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_signature
Description: OpenPGP digital signature

Re: Draft GR for resolution process changes

[Timo Röhling]

* Russ Allbery  [2021-11-08 08:18]:

Probably the simplest fix would be to add something like this as a new
point A.0.3.  Do people think it would be worth adding something like
this?

   If a proposal (or ballot option; see section §A.1) requires some
   number of sponsors N, only the first N Developers indicating they
   sponsor the proposal become sponsors for the purposes of the
   subsequent process. Further sponsorships are not counted. Similarly,
   if more sponsors are needed (such as in cases of withdrawal; see
   section §A.2), only the number of Developers required to meet the
   minimum number of sponsors are added as sponsors. The Project
   Secretary determines the order in which sponsors indicate support.

(I'm really not happy with the wording of that, and am finding it
difficult to word clearly for some reason.  Suggestions welcome, if folks
think this is something the proposal should try to address.)

Given that any Developer can propose a new ballot option anyway, it
feels overly restrictive that a single dissenting voice can block
amendments. Instead, I'd like to treat this more like a fork; anyone
objecting to a change is free to introduce the original version as
their own ballot option, subject to the usual sponsorship
requirements. In practise, this should work like this:

1. The proposer amends their ballot option.

2. If no sponsor objects to the change, we are done.
   Otherwise, continue.

3. If someone objects, the proposer decides if he wants to revert
   the amendment. If yes, we are done. Otherwise, continue.

4. The first objector becomes new proposer for the original
   ballot option, and the original proposer becomes proposer
   for the amended version.

5. Any Developer can sponsor or withdraw from both versions as they
   see fit. By default, i.e. if no other statement is issued, any
   sponsor who objected to the amendment is assumed to have withdrawn
   from the amended version and still sponsoring the old version. All
   other sponsors are assumed to have withdrawn from the old version
   and are sponsoring the amended version.

6. Any version that lacks the required number of sponsors will be
   withdrawn.

Cheers
Timo


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Do we want to Handle Secret Ballots in the same GR as Voting Changes

[Sam Hartman]

Russ made a final call for informal discussion.
I'd like to ask the community whether we'd like to handle secret ballots
now, or in a separate GR.

The rationale for handling things now is that we can get it done with
and if a controversial GR comes up, we'll have the option of secret
ballots if that's how we decide things.

The rationale for delaying is that it may make Russ's vote easier.
we may also have a large number of ballot options if there end up being
a significant number of amendments to Russ's proposal.

Here's what a simple proposal for making all votes secret ballot might
look like.
If we choose to  handle things this time around, someone (I'd be happy
to) could propose this as an amendment when Russ makes his formal GR.
I suspect Russ probably wouldn't accept the amendment just so we could
have both options on the ballot.
Given the discussions so far we'd probably have four ballot options
(secret ballots times  the two approaches to managing discussion
periods).



Resolved that the Debian Developers make the following changes to the
Debian Constitution:

4.1.3:
old:
3. Votes are taken by the Project Secretary. Votes, tallies, and
   results are not revealed during the voting period; after the vote
   the Project Secretary lists all the votes cast. The voting period
   is 2 weeks, but may be varied by up to 1 week by the Project
   Leader.

new:
3. Votes are taken by the Project Secretary. Votes, tallies, and
   results are not revealed during the voting period; after the vote
   the Project Secretary lists all the votes cast. The identity of a
developer casting a particular vote is not public.  The voting period
   is 2 weeks, but may be varied by up to 1 week by the Project
   Leader.

rationale: I think we still want the ballots public because there's a
lot of useful analysis you can do on that.
Minimally state that the votes are not public without providing any
mechanism for how that works; that's up to the secretary.  There was
some discussion of using a DEP to provide specific mechanisms for
handling this; the secretary could of course take advantage of such
a DEP if it emerged.


4.1.6:
old:
6. Votes are cast by email in a manner suitable to the Secretary. The
   Secretary determines for each poll whether voters can change their
   votes.

new:
6. Votes are cast in a manner suitable to the Secretary. The
   Secretary determines for each poll whether voters can change their
   votes.

rationale:
Some of the systems being proposed for anonymous voting would work
better if they didn't need to use email.
Leave how that works up to the secretary.

5.2.5:
old:
5. The next two weeks are the polling period during which Developers
   may cast their votes. Votes in leadership elections are kept
   secret, even after the election is finished.
new:
5. The next two weeks are the polling period during which Developers
   may cast their votes.

rationale: no need for a special case for leadership elections any more.


signature.asc
Description: PGP signature

Re: Draft GR for resolution process changes

[Russ Allbery]

Sam Hartman  writes:

> Charles>  - About the sponsors, if there are too many, then the
> Charles> proposer is more at risk to face vetos when accepting
> Charles> amendments.  (I write that as I accepted major changes as
> Charles> the proposer of a GR option some years ago.)  Would it make
> Charles> sense to limit the total number of sponsors, and to only
> Charles> allow developers to sponsor one option ?

> I don't understand this concern very well.
> If some of your sponsors don't like an amendment you accepted you can
> withdraw.
> So long as you have k sponsors remaining, the option can stay on the
> ballot.

> What am I missing that leads to your concern?

I think it's a little bit inobvious that the correct thing to do in this
case is to withdraw as proposer of the original proposal and then make a
new ballot option proposal and have the non-dissenting sponsors of the
original sponsor that one instead, although I agree that ends up at the
same place.  Hm, and fixing the number of sponsors, while it may make
needing to do that less likely, doesn't remove the chance that one may
need to do that to accept a major amendment.

I was also thinking of the fact that Kurt has had to ask people in the
past to not "pile on" more sponsorships because it makes his tracking for
the web site and similar purposes more tedious, so if we have some other
reason to fix this anyway, it might be worth taking care of that.

-- 
Russ Allbery (r...@debian.org)  

Re: Towards more GRs

[Sam Hartman]

> "Felix" == Felix Lechner  writes:

Felix> Hi,
Felix> On Fri, Nov 5, 2021 at 2:45 PM Joerg Jaspert  
wrote:
>> 
>> I am pretty sure that was a 100% calculated move to go directly
>> to this.

Felix> It was impromptu. The mail was intentional only in the sense
Felix> that I hoped to find a topic to unite people. (Who likes
Felix> slavery, anway?)  Let's lose the fear of referendums. Our
Felix> fellow contributors are our trusted partners in this noble
Felix> endeavor!

We're in the middle of approaching what are  I hopo two relatively
uncontroversial referendums:

* A proposal to update our voting process (which looks like it will have
  a couple of options on the ballot)

* A proposal to have secret ballot votes as an option/requirement.

No action was required to get some practice with referendums that
hopefully will not be painful.

Re: Draft GR for resolution process changes

[Sam Hartman]

Charles>  - About the sponsors, if there are too many, then the
Charles> proposer is more at risk to face vetos when accepting
Charles> amendments.  (I write that as I accepted major changes as
Charles> the proposer of a GR option some years ago.)  Would it make
Charles> sense to limit the total number of sponsors, and to only
Charles> allow developers to sponsor one option ?

I don't understand this concern very well.
If some of your sponsors don't like an amendment you accepted you can
withdraw.
So long as you have k sponsors remaining, the option can stay on the
ballot.

What am I missing that leads to your concern?

Re: Draft GR for resolution process changes

[Russ Allbery]

Charles Plessy  writes:

> thank you very much for proposing these changes.  Overall they are very
> convincing and would already vote for it today, but there are two things
> that I wonder:

>  - (Not just to you:) Would it be possible to test them in real befoe
>adopting them?  Maybe with some kind of role-playing game where some
>random people are assigned adversarial roles?

I'm quite happy to participate in this, although I don't know how to get
started or how to organize it.  I've mentally run through various
scenarios to try to anticipate them in the draft, but since I wrote it I
have blind spots and I definitely welcome anything that would help us go
over the implications carefully.

>  - About the sponsors, if there are too many, then the proposer is more
>at risk to face vetos when accepting amendments.  (I write that as I
>accepted major changes as the proposer of a GR option some years
>ago.)  Would it make sense to limit the total number of sponsors, and
>to only allow developers to sponsor one option ?

This is a very good point.  Currently, nothing except social convention
prevents people from continuing to sponsor GRs or amendments (ballot
options in the new proposal) after they've already reached the necessary
number of sponsors.  I tried to limit the impact of this a little by
saying that only people who had already sponsored the ballot option at the
time an amendment is proposed can object to it (the current constitution
appears to allow someone to sponsor a GR just to object to an amendment),
but that doesn't entirely fix the issue.

Probably the simplest fix would be to add something like this as a new
point A.0.3.  Do people think it would be worth adding something like
this?

If a proposal (or ballot option; see section §A.1) requires some
number of sponsors N, only the first N Developers indicating they
sponsor the proposal become sponsors for the purposes of the
subsequent process. Further sponsorships are not counted. Similarly,
if more sponsors are needed (such as in cases of withdrawal; see
section §A.2), only the number of Developers required to meet the
minimum number of sponsors are added as sponsors. The Project
Secretary determines the order in which sponsors indicate support.

(I'm really not happy with the wording of that, and am finding it
difficult to word clearly for some reason.  Suggestions welcome, if folks
think this is something the proposal should try to address.)

-- 
Russ Allbery (r...@debian.org)  

Re: Draft GR: Resolution process changes

[Russ Allbery]

Wouter Verhelst  writes:

> I have a few outstanding things I'd like to change to my proposal, but
> I'm currently on holiday until the 15th without access to my laptop. I
> had intended to post those updates before I left, as well as notify
> people that I'm off, but things got a bit busy just before I left and it
> completely slipped my mind; please accept my apologies.

> I would appreciate it if you could wait just a little bit.

No problem.  I'll aim for November 20th instead, assuming that works for
you.

-- 
Russ Allbery (r...@debian.org)  

Re: Opposing strict time limits

[Russ Allbery]

Felix Lechner  writes:
> On Sun, Nov 7, 2021 at 5:13 PM Russ Allbery  wrote:

>> I don't understand the question.  That system does not currently exist,
>> and therefore this could not have happened

> Without wanting to take up too much bandwidth, I believe that deductive
> logic misses key insights. [1]

> More broadly, you are not the only one who thinks I have strange
> feathers. I mean, what is this guy talking about? He has so much to
> learn! Perhaps this short video [2] can shed some light on how two
> parties might examine the same subject from two sides. In some form, it
> will solve Debian's social issues.

My response was not intended as a critique of your way of thinking.  I
really did mean my response literally: I don't understand your question.
That makes it hard for me to respond to it, or to take into account any
key insights that it contains.

I tried to explain why I didn't understand the question.  Maybe you could
try rephrasing in the hope that I may understand a different version of
the question better?

-- 
Russ Allbery (r...@debian.org)  

Re: Draft GR: Resolution process changes

[Wouter Verhelst]

Russ Allbery  schreef op 7 november 2021 22:33:48 GMT+02:00:
>Hi all,
>
>I think the discussion has mostly died down on my draft GR.  Wouter's
>alternative proposal has some support, but not the sort of overwhelming
>support that would lead me to believe I should drop my proposal in favor
>of his, so I think that will be best handled as an additional ballot
>option.
>
>Below is the draft GR as I intend to propose it.  There are no substantive
>changes from the previous draft, but I added a rationale and changed the
>text to clearly describe the changes to make to the constitution.
>
>I intend to propose this formally as a GR on November 13th and ask for
>sponsors.  Please let me know if this would cause problems for anyone that
>would warrant further delay.
>
>This is also the last call for any discussion or changes before this
>becomes a formal GR and the discussion period clock starts.  (Obviously,
>people can still propose changes during the discussion period.)
>
>Draft GR begins here:
>
>Rationale
>=
>
>We have uncovered several problems with the current constitutional
>mechanism for preparing a Technical Committee resolution or General
>Resolution for vote:
>
>* The timing of calling for a vote is discretionary and could be used
>  strategically to cut off discussion while others were preparing
>  additional ballot options.
>* The original proposer of a GR has special control over the timing of the
>  vote, which could be used strategically to the disadvantage of other
>  ballot options.
>* The description of the process for adding and managing additional ballot
>  options is difficult to understand.
>* The current default choice of "further discussion" for a General
>  Resolution has implications beyond rejecting the other options that may,
>  contrary to its intent, discourage people Developers ranking it above
>  options they wish to reject.
>
>The actual or potential implications of these problems caused conflict in
>the Technical Committee systemd vote and in GRs 2019-002 and 2021-002,
>which made it harder for the project to reach a fair and widely-respected
>result.
>
>This constitutional change attempts to address those issues by
>
>* separating the Technical Committee process from the General Resolution
>  process since they have different needs;
>* requiring (passive) consensus among TC members that a resolution is
>  ready to proceed to a vote;
>* setting a maximum discussion period for a TC resolution and then
>  triggering a vote;
>* setting a maximum discussion period for a GR so that the timing of the
>  vote is predictable;
>* extending the GR discussion period automatically if the ballot changes;
>* modifying the GR process to treat all ballot options equally, with a
>  clearer process for addition, withdrawal, and amendment;
>* changing the default option for a GR to "none of the above"; and
>* clarifying the discretion extended to the Project Secretary.
>
>It also corrects a technical flaw that left the outcome of the vote for
>Technical Committee Chair undefined in the event of a tie, and clarifies
>responsibilities should the Technical Committee put forward a General
>Resolution under point 4.2.1.
>
>Effect of the General Resolution
>
>
>The Debian Developers, by way of General Resolution, amend the Debian
>constitution under point 4.1.2 as follows.  This General Resolution
>requires a 3:1 majority.
>
>Section 4.2.4
>-
>
>Strike the sentence "The minimum discussion period is 2 weeks, but may be
>varied by up to 1 week by the Project Leader."  (A modified version of
>this provision is added to section A below.)  Add to the end of this
>point:
>
>The default option is "None of the above."
>
>Section 5.2.7
>-
>
>Replace "section §A.6" with "section §A.5".
>
>Section 6.1.7
>-
>
>Replace "section §A.6" with "section §A.5".
>
>Add to the end of this point:
>
>There is no casting vote. If there are multiple options with no
>defeats in the Schwartz set at the end of A.5.8, the winner will be
>randomly chosen from those options, via a mechanism chosen by the
>Project Secretary.
>
>Section 6.3
>---
>
>Replace 6.3.1 in its entirety with:
>
>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.
>
>   2. Any member of the Technical Committee may propose additional
>  ballot options or modify or withdraw a ballot option they
>  proposed.
>
>   3. If all ballot options except the default option are withdrawn,
>  the process is canceled.
>
>   4. Any member of the Technical Committee may call 

Re: Opposing strict time limits

[Felix Lechner]

Hi,

On Sun, Nov 7, 2021 at 5:13 PM Russ Allbery  wrote:
>
> I don't understand the question.
> That system does not currently exist, and therefore this could
> not have happened

Without wanting to take up too much bandwidth, I believe that
deductive logic misses key insights. [1]

More broadly, you are not the only one who thinks I have strange
feathers. I mean, what is this guy talking about? He has so much to
learn! Perhaps this short video [2] can shed some light on how two
parties might examine the same subject from two sides. In some form,
it will solve Debian's social issues.

Kind regards
Felix Lechner

[1] https://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_theorems
[2] https://www.youtube.com/watch?v=LltoUg_WL2k

Re: Draft GR for resolution process changes

[Charles Plessy]

Hi Russ,

thank you very much for proposing these changes.  Overall they are very
convincing and would already vote for it today, but there are two things
that I wonder:

 - (Not just to you:) Would it be possible to test them in real befoe
   adopting them?  Maybe with some kind of role-playing game where some
   random people are assigned adversarial roles?

 - About the sponsors, if there are too many, then the proposer is more
   at risk to face vetos when accepting amendments.  (I write that as I
   accepted major changes as the proposer of a GR option some years
   ago.)  Would it make sense to limit the total number of sponsors, and
   to only allow developers to sponsor one option ?

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Re: Renaming the FTP Masters

[Thomas Goirand]

On 11/4/21 8:14 PM, Paul R. Tagliamonte wrote:
> The hardest part may very well be changing all the CNAME/A
> records[1][2]

Thanks for volunteering! :)

Cheers,

Thomas Goirand (zigo)