Hi, everyone.
Now that we have concluded deciding our GR procedure, I'd like to come
back to the question of secret ballots that we decided to defer from the
last round.
As a reminder, that discussion started at https://lists.debian.org/tslilx2fuo8.fsf@suchdamage.org


In <87a6ic6wl1.fsf@arioch.leonhardt.eu>, Carsten LEONHARDT noted that in addition to being suitable to the secretary, the manner in which votes
are cast needs to be suitable to the developers.

At the time, I proposed that one way to handle this would be to
introduce a mechanism for developers to override a decision of the
secretary.
That handles a more general problem than the one Carsten identified.
There are a couple of alternatives I can think about focused
specifically on the manner of voting, but I think solving the general
problem is good.

So, I propose to allow the voters to override a decision of the
secretary just as they can override the TC, the DPL, or the DPL's
delegates.

For most cases, I think it would be fine for the developers to override
by a simple majority.
There are two cases that stand out where I think that would be
inappropriate:

1) The secretary's determination of what super majority is required for
a particular ballot option.
Imagine someone proposing to "interpret" the DFSG as not actually
requiring source code for programs. The secretary decides that's not so
much an interpretation of the DFSG as an actual change to the DFSG, and
thus requires a 3:1 super majority.
We wouldn't want to make it easier than 3:1 to decide that no, that's
really not a change, and thus only needs a simple majority.

2) The secretary's determination of election outcome. I hope this never
gets overridden, but you could imagine cases where there is a debate
about whether to count certain votes or the like.
Especially if any options on the ballot had super majorities, changing
the election shouldn't be easier than these super majorities.


I propose that both of these cases require a 3:1 super majority to
override the secretary.
(That is currently the highest super majority we require for anything
including changing the constitution.)

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.

I'd appreciate comments on this proposal and on the general issue.
Assuming the discussion resolves reasonably quickly, I propose to send
out a new version of the secret ballot proposal including a fix to this
issue in around a week.

-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQSj2jRwbAdKzGY/4uAsbEw8qDeGdAUCYfVmMwAKCRAsbEw8qDeG dLTMAP9roPo8tSn9/zByGSVcuPZexIU42m6zfYENz1N6+1+JAgEA8Htnca2Hu4qm V4Et/ZRot6Q91woxgkvL9+Rhg7xo5A4=
=92PZ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sam Hartman <hartmans@debian.org> writes:

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.

I'd appreciate comments on this proposal and on the general issue.
Assuming the discussion resolves reasonably quickly, I propose to send
out a new version of the secret ballot proposal including a fix to this
issue in around a week.

The question this raises for me is who runs the vote to decide whether to override the Project Secretary? I would completely trust Kurt to run that vote, but in the general case the Project Secretary running a vote on
whether to override the Project Secretary is a clear conflict of interest.

We could require that such a vote be done by public ballot regardless of
any secret ballot mechanism for other votes, which gives us some built-in defense against any problems, but it still makes me a little bit leery to
set up a situation where someone is running a vote about overriding a
decision that they may feel strongly about.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Personally I am not sure that the secretary needs a challenging process,
given how he/she/they is chosen and how the general vote process works. However, when he/she/they needs to take a decision, it is because the constitution enables him/her/them to do it, for defined situations. The question of secret vote does not make part of them, if I remember
correctly the constitution and the debate, so the debate was about
intrepreting the text about this.

This matter is extremely important for me, as soon as Debian starts
voting political/social GRs and not only technical ones. So I would like
to focus on the secret vote instead of a general change of the secretary override, but it is just my feeling. I think that the vote should
explicitly be secret, except a decision from the majority of the
developers. It is really a GR I would like to see.

Regards,


Jean-Philippe MENGUAL
Debian Developer non uploading
Community team member
Accessibility team member
debian-l10n-french team member
President of Debian France non-profit organization

Le 29/01/2022 à 17:07, Sam Hartman a écrit :

Hi, everyone.
Now that we have concluded deciding our GR procedure, I'd like to come
back to the question of secret ballots that we decided to defer from the
last round.
As a reminder, that discussion started at https://lists.debian.org/tslilx2fuo8.fsf@suchdamage.org

In <87a6ic6wl1.fsf@arioch.leonhardt.eu>, Carsten LEONHARDT noted that in addition to being suitable to the secretary, the manner in which votes
are cast needs to be suitable to the developers.

At the time, I proposed that one way to handle this would be to
introduce a mechanism for developers to override a decision of the
secretary.
That handles a more general problem than the one Carsten identified.
There are a couple of alternatives I can think about focused
specifically on the manner of voting, but I think solving the general
problem is good.

So, I propose to allow the voters to override a decision of the
secretary just as they can override the TC, the DPL, or the DPL's
delegates.

For most cases, I think it would be fine for the developers to override
by a simple majority.
There are two cases that stand out where I think that would be
inappropriate:

1) The secretary's determination of what super majority is required for
a particular ballot option.
Imagine someone proposing to "interpret" the DFSG as not actually
requiring source code for programs. The secretary decides that's not so
much an interpretation of the DFSG as an actual change to the DFSG, and
thus requires a 3:1 super majority.
We wouldn't want to make it easier than 3:1 to decide that no, that's
really not a change, and thus only needs a simple majority.

2) The secretary's determination of election outcome. I hope this never
gets overridden, but you could imagine cases where there is a debate
about whether to count certain votes or the like.
Especially if any options on the ballot had super majorities, changing
the election shouldn't be easier than these super majorities.

I propose that both of these cases require a 3:1 super majority to
override the secretary.
(That is currently the highest super majority we require for anything including changing the constitution.)

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.

I'd appreciate comments on this proposal and on the general issue.
Assuming the discussion resolves reasonably quickly, I propose to send
out a new version of the secret ballot proposal including a fix to this
issue in around a week.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Jean-Philippe" == Jean-Philippe MENGUAL <jpmengual@debian.org> writes:

Jean-Philippe> secret vote does not make part of them, if I remember
Jean-Philippe> correctly the constitution and the debate, so the
Jean-Philippe> debate was about intrepreting the text about this.

The specific question that rose to this discussion is how should we give developers an ability to object if the manner in which the secretary
wants to conduct a vote is objectionable. For example say a secretary
wanted to use a Google form rather than an email vote.

In my proposal all ballots would be secret, and the secretary would not
make a determination about that.

--Sam

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Sam,

On Sat, Jan 29, 2022 at 03:22:24PM -0700, Sam Hartman wrote:

In my proposal all ballots would be secret, and the secretary would not
make a determination about that.

how do you define 'secret' here?


--
cheers,
Holger

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

Make racists afraid again.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmH2tbUACgkQCRq4Vgaa qhwDWQ/+N04PAka0fwadTTG5yxO72Z3Z4R9EFE9QU0zWfp2a1ydT00u0zAsUc04n +bZENCjrNOr4cDA9tWbHEqbRDzsDR/sirSUBqHH+F2KsugUikrGbhd1kKF/WhyT9 zlnex7E50XVz3630CzqCSNo6IwhVZkuv0+mxCNbPMw9dsqGsu3N4JJiR5/ehjp2D MsUUbwd69UITbrt/1wxUAXKclWoi42QblHfHvJX9S/TsfLDmtCf9dBaMiX/Ha1A5 WBsl31gQdmv8MR90nmLiyT2BiCDA3tdKWZ+f/skEVNZQt4Wk0c00JwzJeeZrUGg5 8ZMa/BbDmQo5luyKST5ORkVv3jaFOibs9471xRhr5z48Akj7Sli2aGW+I0/G7pw3 t1fzJOCwAD+wxzKF195E1sawQVO+JktbpuugtqWK6VCLsxbraozlJhlLEZC2uidT kW9BQb8grX6If9GF0YUVhwYK+/OoWvOFLAr2KNP9rH/qD6qfVjQIjDUD0bGhTGz6 PVVChT+VXh/5amCvkuh4POWfnnGpWuYpxrePcLi2lmaEWRfgvrrTsfVMIjGeHj69 blX3BPSvUcI/mqKl+MHkUuSq82BodK6VD062//3uGMhD+s+GX9R098B6OqYjdTcw bn3k+dZgnGO4azN38evO

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?

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQSj2jRwbAdKzGY/4uAsbEw8qDeGdAUCYf1LdgAKCRAsbEw8qDeG dOHYAP4oY1JQkT7kAS1yuB+qn2GiSck3zHiw6H6iISwsJzMSsAD/Zy4L0yPxkEC6 sCP9af9wWgG3VPu3ekQ6j4Yoq0jsyA8=TTFL
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 04 Feb 2022, Sam Hartman wrote:

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.

I think the plainest reading is #1, but I can see the argument that #2
was the intention.

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?

Yes. I think the additional complexity of requiring a 3:1 majority to
overrule the secretary isn't enough to always have the desired effect if §4.1.7 isn't also modified accordingly.

That said, if a majority uses the blunt force of §4.1.7 to try to get
its way by removing people, I'd be more concerned about the health of
the project than whether we had written rules to prevent it.

--
Don Armstrong https://www.donarmstrong.com

Herodotus says, "Very few things happen at the right time, and the
rest do not happen at all. The conscientious historian will correct
these defects".
-- Mark Twain _A Horse's Tail_

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I plan to release a complete proposal for secret ballots including the
proposed 4.1.8 within the next couple of days.

Is https://salsa.debian.org/rra/webwml/-/commit/3f0f679ae97095915eea4b7299f16d74874c80da
my best starting point for a diff?

"Don" == Don Armstrong <don@debian.org> writes:

Don> On Fri, 04 Feb 2022, Sam Hartman wrote:
>> 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> I think the plainest reading is #1, but I can see the argument
Don> that #2 was the intention.

Unless I hear objections I will propose text clarifying this to be unambiguously #1.

>> 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?

Don> Yes. I think the additional complexity of requiring a 3:1
Don> majority to overrule the secretary isn't enough to always have
Don> the desired effect if §4.1.7 isn't also modified accordingly.

Don> That said, if a majority uses the blunt force of §4.1.7 to try
Don> to get its way by removing people, I'd be more concerned about
Don> the health of the project than whether we had written rules to
Don> prevent it.

For this reason, I don't currently plan to propose to modify 4.1.7.
The project is fairly good about interpreting the reasons behind
proposals.
I actually think in practice it would be harder to remove a secretary
for doing their job and making a controversial call about what super
majority was required than it would be to get a 3:1 majority behind
anything.

On the other hand, I can see cases where the project would try to take advantage of an override that was lower than the super majority.
I'm not even imagining situations where people are trying to abuse the process--just a case where they disagree with the secretary, and where
if we don't have language in the constitution, the override vote could
be easier than winning the super majority itself.

That said, I'd certainly be happy to revise things if we get a consensus
here.
I think most of what we're discussing would be things I'd rank well
above NOTA.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sam Hartman <hartmans@debian.org> writes:

I plan to release a complete proposal for secret ballots including the proposed 4.1.8 within the next couple of days.

Is https://salsa.debian.org/rra/webwml/-/commit/3f0f679ae97095915eea4b7299f16d74874c80da
my best starting point for a diff?

You should now start from the master branch of webmaster-team/webwml.
My diff is already merged (thanks, Laura!), along with an HTML syntax fix
that I'd missed.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Jan 30, 2022 at 03:58:50PM +0000, Holger Levsen roughly wrote:

On Sat, Jan 29, 2022 at 03:22:24PM -0700, Sam Hartman wrote:

In my proposal all ballots would be secret, and the secretary would not make a determination about that.

what's the definition of 'secret' here?

I'd still like to hear an answer to this question and thus I hope
it will be addressed in the upcoming proposal.

(Transparency note: I reworded my own quote slightly to make it better.)


--
cheers,
Holger

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

The apocalypse is here now, it’s just not equally distributed.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmIGVAIACgkQCRq4Vgaa qhzLTRAApdWdGnpB3SeE9+0fYBZrU4oO3Wsy6+3m3Ke88WYnXGtAaEHmbty6V1MX z3q6skGaY7irEqe09to8qM0x0p4RbZiI1G++yj7RacHGEVkJ3HR/ewi2IUcYdGtJ NUz9F8BGHmkZJh0PtZkwcGUtc+T3PT9VAIKejmoDRzCHBClzzRAy/hJ4UiMo+J3R JAaT/5Bf+zHH9Iveoq7QY2Z9OPAcx8xY8LlnYA9enJFIKcdNrGY4j6sOhdfG+RaL rd8cn2a+CbyMaTUa1FOdgxLucQiAXGfjFVfQivDLAfIelFlzFkSckcNtXxm7VFrB 8vTLeC4Lz8xschg/0UI9fL3rSjdTNzp4qoWSHZNuLwzi18JFTUnQJ70cufo9p/av d9xlARLZxqsljl7pzuqRrT1rm8p3pr+gV3GsRQOonqNmaqPZyFbfVoQAc/uEZLaU beq6I20hum9dwrUVZMXY+0wL7U5Ly1gwPK4P6IKtDQoX+kc4K4dxQKC9CYzbd5au ubSSJ5tK/uH5nu7kp3gFb529axFp/uZwRd+JnhRocOjfCEInUB9lEmpNCujao46d WESNfdNOossG9H7Q/OtKFFgzZQDFUp9+NETWAGtxV/ZW2J7B

On Fri, Feb 11, 2022 at 02:30:53PM +0100, Philip Hands wrote:

My reason (and maybe Holger's too) is I'd say that there is no
possibility of guaranteeing real permanent absolute secrecy in a vote
that we can practically conduct over the Internet (at least, not one
where the results are also trustworthy), so there is going to be some
sort of compromise, and it is essential to understand the nature of that compromise in order to come to any conclusion about whether it might be
a good idea to do the the thing that we're really talking about.

yes, exactly this. Thank you.


--
cheers,
Holger

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

This too shall pass.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmIGZ8EACgkQCRq4Vgaa qhyK/Q//TrB4ctWwW3FcoDSWNJxBvpjwwz7wB3/zGrkNuWNLxjwq+ymlcTZXJp59 nxIT1yTZ9rMd2SHuPjL1XZmk+eN3EUCmXhK4K2O/dXyho+T65kqdpbubjXgjw4SC 1eAKqafvQv39cvUxRQIU33aJgu75YlwQr5VatkV+2Lg1oGhst9/kCSjOVgyhOpel 3r4tOXUz0VvSExFl04CimuQe6h8RT/A7q+LzbC8euPrZstUPu/IYSzFV0NOnwGCC 8kkzHyPyNSU9uygNK8V4GIixeCbLtx/wMZBrtoXPGGbhbCtUXp37hPwsZjaAIVc2 J/9+SZnl69caq2vgpwJ6+PfdJjtccY9oCzeL4mmFpcUVifp4g0nIfvIyjwf8RD0b AXgcl5VO7Jgg4pQhD8aZn47KPvaEGtF6o+yIzdQjj4ukKXKqQK6z8BuTZwW5fkhy FNkcqDwMdId68uckk8tpuhB4HKrNDUlGg8QQe5ZzcGHlqY81eeBpjGwiZgX5Tpit Pr4M1Y5nAfjMXmN3uNs9QF6B+TEsJPIHDNXlsuhnVBuvU7rcLUj+Ns+tbmHEdABg BoS3/sB7x4x8a/ovFVJ/nweaCh4p7vILvXEpCe/GXXZv/zKxLBZvwtEsUkmHTKgp xYZSVmA+MSrqvoVjmMAU5ChANy

Holger Levsen <holger@layer-acht.org> writes:

On Sun, Jan 30, 2022 at 03:58:50PM +0000, Holger Levsen roughly wrote:

On Sat, Jan 29, 2022 at 03:22:24PM -0700, Sam Hartman wrote:

In my proposal all ballots would be secret, and the secretary would not
make a determination about that.

what's the definition of 'secret' here?

I'd still like to hear an answer to this question and thus I hope
it will be addressed in the upcoming proposal.

I too would also like an answer to that.

My reason (and maybe Holger's too) is I'd say that there is no
possibility of guaranteeing real permanent absolute secrecy in a vote
that we can practically conduct over the Internet (at least, not one
where the results are also trustworthy), so there is going to be some
sort of compromise, and it is essential to understand the nature of that compromise in order to come to any conclusion about whether it might be
a good idea to do the the thing that we're really talking about.

Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/ http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3/FBWs4yJ/zyBwfW0EujoAEl1cAFAmIGZQ0ACgkQ0EujoAEl 1cC5/xAAogcXZVgMDB+XuHyeihWNaOwglZFefCaYpqx2/Iu+CilED52PVcIRtZkx /eni1LEW5FSezCOUGrbn5DajS8YBcnm7qWmWHfjkn+XlQoZ1Tpq5zjkt1dPnTyAb EnsJGlOe8L2ocoOw5yFOG+++u7ANiL2AF3sN58+qlLddPaHeTcsAPBA4stsSjPF/ OX5pjQBqH5JJy4o51qT53waSL5Ca7qm8k+dtZ0nweey5sOcwF7LLc8pdJkfCL1Vf A/1Q+EWFVRC+lLf1gv8zDZaXWsM1yQeMk8Y7pZ4jjBAxY4ZrPZZfZEmcCPJrzW+U jn2gt9l/rbOn1r+ggNJpRjDWRSGbWhYOc+9CjZROkP0JPCet0RwfD9eJa6Uc/nAn ld/a2kS99wGkMOiWRSBonxqBJPcOaou87KP7Ld5vgTLe+4JBWlE3D0GrN4r9ifiw +WDhR5EdbEHMw3pyUeqGArddV6ch4i+ndeFW6bbFR4b4ucC8jn3v5nmCUmpdZmPA TbG5/5YMmvgjL5sqaYKBVqAkVZtgzI0iZqafd4qedXmw4G0S+dAv5imuWrqyqS6y 5BocKPxx7qcFNVLwRVY3WiqMQYCniIOmQDr8d/bbMleDpXnwX6Is3n+jJF/KNGhM YdZv0ChBMZvg/0P

Hi,

On Fri, Feb 4, 2022 at 9:22 PM Don Armstrong <don@debian.org> wrote:

That said, if a majority uses the blunt force of §4.1.7 to try to get
its way by removing people, I'd be more concerned about the health of
the project than whether we had written rules to prevent it.

I'd be more concerned about the health of the secretary. Such an
extreme effort by the members might suggest a lack of capacity or
other serious illness.

Kind regards
Felix Lechner

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)