"G. Branden Robinson" <g.branden.robinson@gmail.com> writes:

Looking only at the Constitution itself, I see the following.

1. "a person or body is usually listed before any people or bodies
whose decisions they can overrule or who they (help) appoint - but
not everyone listed earlier can overrule everyone listed later."

2. The DPL is placed _above_ the TC in the overruling precedence chart.

3. The DPL's delegates are generally understood to be capable of
exercising any power the DPL can, pursuant to the DPL's explicit,
specific delegation of same. But...

4. The TC is placed _above_ the DPL's delegates in the overruling
precedence chart.

To me, from a Constitutional perspective, then, your claim that

the TC cannot overrule delegates.

...does not appear to be well-founded. Again, it's fine if the TC has adopted, for comity or any other reason, a working principle that it
will not overrule delegates, but that seems to be a self-imposed
restriction, and should be communicated to the Developers as such.

I am not the project secretary, just one random developer, but for
whatever it's worth, I think this interpretation of the constitution is incorrect and the TC does not have the ability to override a delegate.

The main weight of your argument seems to rest on a (to me) novel interpretation that the order in which bodies are listed in section 2 is normative, not informative. This seems clearly incorrect given the plain wording of the subsequent paragraph, which does not say the order is significant, only that it is informative. The normative text says that overrides will be explicitly noted:

The powers of a person or body may be subject to review and/or
limitation by others; in this case the reviewing body or person's
entry will state this.

The clear implication is that if the entry does *not* state this, then the powers are *not* subject to review by that body or person.

The non-normative text then elaborates (emphasis mine):

In the list above, a person or body is *usually* listed before any
people or bodies whose decisions they can overrule or who they (help)
appoint - *but not everyone listed earlier can overrule everyone
listed later.*

I think it's much clearer and simpler to note that the TC has a list of specifically enumerated powers in section 6.1 and overriding Project
Delegates is not one of them. The TC can override Developers, as you
quoted, but I would interpret that to mean Individual Developers (i.e.,
section 3), and the constitution clearly puts Project Delegates in a
separate category (section 8).

Compare to 4.1.3, which says quite explicitly that a GR can override the
DPL or Project Delegates. This language is conspicuously absent from the
list of powers of the TC, and I believe that should be read normatively.

Obviously Kurt has the final say, but if he were to ask me my opinion,
that's what I'd tell him.

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

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

On Wed, Apr 09, 2025 at 11:31:24AM -0700, Russ Allbery wrote:

Obviously Kurt has the final say, but if he were to ask me my opinion,
that's what I'd tell him.

Is there a need for me to actually make a ruling, or is this just a
theoretic question? I prefer not to make a ruling unless it's actually
needed. I'm likely to agree that the TC does not have that power.

Kurt

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

Russ Allbery <rra@debian.org> writes:

I am not the project secretary, just one random developer, but for
whatever it's worth, I think this interpretation of the constitution is incorrect and the TC does not have the ability to override a delegate.

I am the current TC Chair; what follows is my opinion (which obviously
impacts on my actions while wearing the TC Chair hat), but is not a
formal policy statement on behalf of the TC.

My understanding of the Constitution as it pertains to the powers of the
TC roughly follows what Russ has written here. During the time I've been
on the TC we have not been asked to consider overruling a delegate. If
we were asked to do so (in a not-obviously-frivolous manner) then I
would ask the Secretary per 7.1.3 to tell me whether the TC was so
empowered.

Regards,

Matthew

--
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org

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

I'm not sure there's much utility in going back and forth on this more,
since I think we've both adequately stated our opinion, but I couldn't
resist adding a bit more explanation.

"G. Branden Robinson" <g.branden.robinson@gmail.com> writes:

Yes, but the list _is_ in upright rather than slanted text, making it normative per Appendix B, and its ordering _is_ given significance.

This is the core of our disagreement: I do not believe its ordering is
given normative significance. It is in upright rather than slanted text
because it is normative for what that section explicitly says it is
normative for:

Each decision in the Project is made by one or more of the following:

It is a normative list of the people or bodies who can make decisions. The *ordering* of that list is implicitly defined as non-normative by being discussed only in non-normative text.

In other words, I feel like you're putting too much emphasis on meanings
that you think are implied or implicit rather than taking what the section
says literally.

At 2025-04-09T11:31:24-0700, Russ Allbery wrote:

The non-normative text then elaborates (emphasis mine):

In the list above, a person or body is *usually* listed before any
people or bodies whose decisions they can overrule or who they
(help) appoint - *but not everyone listed earlier can overrule
everyone listed later.*

I think you have reinterpreted the aforementioned normative sentence of
§2 in a way that _nullifies_ the informative text. If you're right,
then the informative text can be _deleted_ since the normative sentence exhausts all possibilities: review and/or limitation of the exercise of
any power is strictly limited to express statement; the order of the
list is immaterial and ultimately superfluous.

The informative text is neither meaningless nor nullified in my
interpretation. It says that the bodies are listed in an order that
usually lists the overriding body earlier.

"Usually" remains true regardless of whether the TC, specifically, can
override project delegates, specifically. I'm applying what I believe to
be the normal and conventional definition of "usually": most of the time,
but not always, so if you need to know in a specific case, you need to
look at that specific case.

In other words, the point of the informative text is to say "you can get a
feel for the order of precedence by taking a quick glance at this list,
but if you need to know the specific details, you need to go read the
text."

The views of today's body of Developers are important too. But if
there's one thing Americans have learned about our hoary old
Constitution with its Germanic capitalizations and long ſs, it's that
the more ossified you let the language of the document get, the weirder
the meanings people manage to find in it ("a well regulated Militia
being necessary to the security of a free State" being notorious).

I am wholeheartedly in favor of periodically revising our foundation
documents to clarify misunderstandings or to correct for problems we ran
into. I know I promised another round of that with the Social Contract and
its legacy references to CDs before I seriously burned out on Debian
politics and took a rather abrupt and not-well-communicated break. I keep thinking I am ready to go pick up the many, many balls that I dropped, and
then keep not having the time, but I am certainly happy to support and
vote for other people's efforts in that regard.

The TC can override Developers, as you quoted, but I would interpret
that to mean Individual Developers (i.e., section 3), and the
constitution clearly puts Project Delegates in a separate category
(section 8).

I don't perceive the sharp distinction you do, because §8 also says that Delegates are empowered (as is the DPL, by explicit reference) to "designat[e] people as Developers who do not maintain packages".

This text doesn't quite come out and say that no person may serve as a Delegate who is not a Developer, but it does imply that such a
restriction would be pointless because the DPL is empowered to designate whomever they please as a Delegate _and_ as a Developer, and the text is forthright that the latter power can itself be delegated--not a
surprise, that's the sustaining principle of the Debian Account Managers (DAM) team, and maybe to an extent the New Maintainers Front Desk too.

One minor correction here: the DPL is quite explicitly *not* allowed to designate anyone a Developer. See 8.1.2. This power *has* to be delegated;
it cannot be exercised directly by the DPL.

Consider that your interpretation could mean that the DPL can with a
single proclamation immunize _all_ Developers from override by the
Technical Committee by issuing them a delegation coextensive with
whatever their current powers are (§3.1.1 most significantly).

Correct. The DPL in general needs to be overridden by GR. The purpose of
the Technical Committee is not to override the DPL; it's to make technical policy and adjudicate technical disputes between Developers in the normal course of work.

In my opinion, this is as it should be given that the DPL is elected and
the TC is not. A direct conflict between the DPL and the TC needs to be resolved by GR; I wouldn't want it any other way. The TC works best when
it serves as a group of respected technical experts with a lot of
experience in detailed technical problems, not when it is trying to tackle problems that are more structural or political than technical.

Note that nothing prevents the TC from being asked (under 6.1.3) to make a decision. In particular, it seems worthwhile for the DPL to consider
invoking 6.1.3 to ask the TC to make decisions in cases of Delegate
conflicts that are highly technical in nature.

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

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

Gerardo Ballabio writes ("Re: a Constitutional interpretation question"):

Ian Jackson wrote:

I'm not sure this cleanup is a useful use of our time.
There are more fundamental problems.

We've just been having a several-dozen-messages-long thread on -vote
about a GR proposal that you put forward exactly because the TC can't override delegates.

You're right that we're suffering because of the lack of working
mechanisms, short of GR, for situations like this.

But there are other reasons, besides the lack of constitutional power,
why the TC wouldn't have been a great option anyway. The technical disagreement isn't the core blocking problem - after all, we agreed a compromise about that in 2024. Matthias's summary in <3f9ff339-7417-47c1-8f62-0f97252a5e51@urlichs.de> may help explain.
A similar situation doesn't arise for TC decisions about packages,
because there we have NMUs which can be used to implemente a decison.

Instead, the Leadership is supposed to be the front-line mechanism for oversight of Delegates, but it isn't working. That's one of the "more fundamental problems" that I was suggesting would be a better focus.

Ian.

--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.

Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

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

On Thu, Apr 10, 2025 at 02:14:47PM -0500, G. Branden Robinson wrote:

I add that more Developers should be thinking about questions of Constitutional interpretation more often, if they want to preserve the democratic governance structures that we have, including ones that
haven't been weakened by failures to oversee Delegates.

Funny enough, given that we now have more delegates than ever - actually codifying what the responsibilities of the delegates are. In the past we instead ran off cabals with undefined responsibilities.

There's never a dull moment I guess.

To some Developers, such practice may feel awkward, and the muscles of parsing legalistic language may require unaccustomed exercise. But it's worth doing.

We actually have a person for this. Who can do it when it's actually
necessary.

...if we want to keep our democratic form of government.

If we don't, we can expect to be governed by personal cliques, fear, and intimidation.

Citizenship, whatever the polity, is incompatible with passivity.

Luckily Debian is not a country. There are other values that'd generally
apply in that case.

Kind regards
Philipp Kern

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

Gerardo Ballabio <gerardo.ballabio@gmail.com> writes:

However, I wonder how that fits with 8.2: "The Project Leader may not
make the position as a Delegate conditional on particular decisions by
the Delegate"

As I understand it, that means that the Leader cannot say "I give you
this delegation, but you must do X". It may be argued that, by the same token, the Leader cannot say either "you must do X or I'll revoke your delegation", and even "since you don't want to do X, I'm appointing
another delegate who will do it" seems questionable, for it's clearly a
way to work around that prohibition.

The traditional interpretation in the project as I understand it is that
the DPL cannot do the first two actions that you describe above, but can
do the third. In other words, the DPL cannot make or override the decision
or appoint someone conditional on making a specific decision, but they can remove a delegate for making decisions they don't like and appoint a
different person (provided that person is a Developer; see 5.1(1)). That
person may then be able to overturn those earlier decisions.

The intent here as I understand it is not to absolutely prevent the DPL
from reversing delegate decisions they don't like, but rather to slow this process down and require the DPL work through other people who have the authority to make different decisions. The backstop on all of this is, of course, a GR, so I believe the intent is not so much to provide a strong procedural obstacle as to require the DPL work hard enough to do this that
the project has an ample chance to stop it if the project doesn't like
what the DPL is doing.

That said, we have not put a lot of weight on this portion of the
constitution that I can recall. One of the areas in which the Debian constitution is the most murky is around persistence of decisions. Can a newly-appointed delegate change the decision just made by the previous
holder of that delegation? Can a developer who was overridden by the
Technical Committee go back to their original decision after some period
of time? Can a delegate who was overruled by a GR then make a decision
that doesn't match that GR after some period of time? (A month? A year?
Ten years?)

This has always been rather murky, and we have always resolved this via assuming good faith and assuming people will do something reasonable, and
for the most part it's worked out. It's hard to nail this all down in
detail without creating other problems.

In general, I personally fall on the side that says attempting to make constitutions bulletproof is going to fall prey to the halting problem
anyway. Debian isn't a government: We don't have prisons, people with
guns, weapons of war, or the ability to force anyone to live under our
rules. We are a volunteer association, which means the final backstop for
any decision made in Debian is that Debian has to retain its volunteers or
it will cease to exist. The constitution is there to help us make
decisions that are sufficiently supported by the community of volunteers
that make up the project such that the project doesn't fall apart. It
doesn't need the rigor of a parliament or court system.

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

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

Russ Allbery writes ("Re: a Constitutional interpretation question"):

The backstop on all of this is, of course, a GR,

In particular, the DPL has the power to make a GR all by themselves.

If a DPL has a serious disagreement with some Delegates, but thinks
the Delegates are otherwise reasonable and should stay in post, it
would be entirely appropriate for the DPL to propose a GR. The
project as a whole would then have a choice between supporting the
Delegates' view, or the DPL's.

In practice, one would hope that the existence of this route would
usually make its actual exercise unnecessary. The DPL would write to
the Delegates and negotiate them, making it clear that if agreement
can't be reached, the DPL was inclined to go to -vote with a draft GR.

That only works of course, if anyone thinks it might happen. Like any
other formal corrective mechanism, merely knowing that it's on the
table as a serious possibility has a salutory effectd.

Conversely, if everyone knows that formal accountability mechanisms
are off the table, we end up with a complete lack of accountability.
It takes great strength of character for an unaccountable power
not to eventually turn into a toxic cabal. That we have so many
approachable temas is a testament to quality of our people.

Looking at the responses to Sean and my draft GR proposal last month,
it seems that a several people were upset that we were trying to use
the formal governance mechanism at all. A lot of electrons were
expended trying to find reasons why we shouldn't have done that, or
shouldn't have done it yet. Frankly, I think we would have got
similar responses no matter how we'd gone about it. No amount of
waiting, or cajoling, or attempts at mediation or negotiation, would
have been enough.

I think this is because there's a substantial contingent in Debian who
"hate politics". They see us "doing politics" and dislike us for it.
They think think Debian can avoid politics (spoiler: it's a project of thousands of humans, we can't) and therefore they think the drama is
the fault of whoever is complaining.

In these circumstances it is hardly surprising that we have some teams
that are well-known to be dysfunctional and toxic, but which nothing
is ever done about. Anyone who tries to take them on gets punished,
because taking on toxicity is by definition political.

I wish we could get *better* at doing politics. If we did it better,
we would have much a nicer environment *and* we would probably spend a
lot less emotional energy on the politics, overall.

Ian.

--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.

Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

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

On Tuesday, April 15, 2025 8:45:40 AM Mountain Standard Time Ian
Jackson wrote:

Looking at the responses to Sean and my draft GR proposal last
month, it seems that a several people were upset that we were
trying to use the formal governance mechanism at all.

This was surprising to me as well when I recently proposed a GR. As
if even proposing a GR were an attack on Debian.

In my case, the GR failed to receive seconds. I considered that to
mean that there wasn’t sufficient interest among other Debian
Developers. So, for me, I considered that the end of the matter.

In that regard, I think the GR process did exactly what it was
supposed to do.

--
Soren Stoutner
soren@debian.org
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEJKVN2yNUZnlcqOI+wufLJ66wtgMFAmf+1MYACgkQwufLJ66w tgOykRAAlkSdz3vgAJbSFtV5BFLo32sGK6zbkU0zGyqbuOnZow8bH5UfAs+iQ0w7 3pLGy6+yRB84sPlDwIbbb2PPJX7Ttx6opQ0sNRW63xK38zUgZpHw1CqTjQUWMmn/ HxHZImqwA+G0cGjmmxIGudbEJVgRCaAYoAUOrAhs+eFTeB1t0Vk0hzwX69w2h1ux bNjWGyYfYEGrorYzbFSd0QAHBUQevyZPK/uCfzLWTYwCg/G5GGugDE/zOVX9C6wG 6N5OxpbxDgmRh2PVFOPgoKEp0DoBBfqUN2NanMxKhQV9LT6iWRt4P+eeDiz77Rix 4a1bdN5l9lB4DwlF92aD7hrM07qLGFtFAuPDrWc3X4gL/kKiX18h7uZfNBZ0Afd4 xH0qHgE+C9NIyZpvUSeNfOwOLeleuEyTiRlJfvXKpphmIIbnOtJieJezZ3GNVSO8 tZkf2L78PJdwsTHgZpDTlFzwn1jklPz0RZbofy6JTYh2hWGHu86Ehukv1Xa9jaOZ fsIffphr8OJqYGFe/4z559ADSeSUGDpHCh2OivGpFfm/9nnTDQutzXRHqtmi83ls MsWpmc2R2owS/0SKQn6dpNsjdezMLO0SekrdfzLKHPUj5M77UyTi0TO+qs2iMcQj bLA5LxcFufE3JuLQn6g4ZOR3RnXJWba3pFw8G8NWwTOx5USwnZQ=
=GIWg
-----END PGP SIGNATURE-----

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

Hello,

On Tue 15 Apr 2025 at 04:45pm +01, Ian Jackson wrote:

Looking at the responses to Sean and my draft GR proposal last month,
it seems that a several people were upset that we were trying to use
the formal governance mechanism at all. A lot of electrons were
expended trying to find reasons why we shouldn't have done that, or
shouldn't have done it yet. Frankly, I think we would have got
similar responses no matter how we'd gone about it. No amount of
waiting, or cajoling, or attempts at mediation or negotiation, would
have been enough.

I think this is because there's a substantial contingent in Debian who
"hate politics". They see us "doing politics" and dislike us for it.
They think think Debian can avoid politics (spoiler: it's a project of thousands of humans, we can't) and therefore they think the drama is
the fault of whoever is complaining.

In these circumstances it is hardly surprising that we have some teams
that are well-known to be dysfunctional and toxic, but which nothing
is ever done about. Anyone who tries to take them on gets punished,
because taking on toxicity is by definition political.

I wish we could get *better* at doing politics. If we did it better,
we would have much a nicer environment *and* we would probably spend a
lot less emotional energy on the politics, overall.

Right.

And note that this is *entirely* orthogonal to the "free software
should/should not be apolitical" disagreement that comes up over and
over again with the same points of view repeatedly rehearsed.

This is just the simple fact that we are a large group of people trying
to work together.

--
Sean Whitton

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

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

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmf/ALcZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQGocD/4xYNf+gW1zypDxsNXQnBkz iZF2tXJM5vVm7MsnvmchmloG7J4EUrd55hKscn7t3LD5k2/Y7kCjIG4X4++Vlazg yvf1yHsEokM6TCxDZH20B+cYfevSrvmubXsM1E9V4F9R74XVvsS8I6oKnluoNHEv HBNiGcck+Yx1zTtO4S2nkeC0X/jqtRoQ/2cn2Ha3d9aerSoQnQl4qBrKM35JGg9Y /rNvjoRdKOTByb/iwGZPVzABr62puKah4SyJ9s3MfhcF9idQySK1Xqwf17xRBnbj sffLqqP4q9bjpt2CnU3i2KuJqinP3TowwnOolDJUa0/HZtme2qhkxwqKPpFaYa6m 1ZO2gq+1qVy2oVh9bDqqekdbj8F53jKK652Xc3fqoZm5ksgTL+fri3FexOTFNOn5 GShrff7SnBykfSBeEbYSoJeZDsDnpJeIijx8vgxV1ujXFOkFNIlUPyHdfSovOCNu PZQZk646UOxLJizAd13gRICjmSRQe1mDl76PnuMP6BxM6u6vgNcq8Sbe6D9h9SUs QuhHGAHuEyhI5Zubi6yhjnIiFynJlOa2c4U1516TyKkPM+u8s1cnVy0Zq3AM4fr1 ov6Gb3sNsT6qH/rZ+vG8tqH9voR8/3uQz9cjbTNTwzBzXuF3swU/naQ80BHNVFio nbVhPD5lygeOV2dKfkihWA==Ogm4
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

On Tue, Apr 15, 2025 at 02:51:02PM -0700, Soren Stoutner wrote:

On Tuesday, April 15, 2025 8:45:40 AM Mountain Standard Time Ian
Jackson wrote:

Looking at the responses to Sean and my draft GR proposal last
month, it seems that a several people were upset that we were
trying to use the formal governance mechanism at all.

This was surprising to me as well when I recently proposed a GR. As
if even proposing a GR were an attack on Debian.

I'm also surprised that proposing a GR can cause a tsunami of strong negative reactions.

In my case, the GR failed to receive seconds. I considered that to
mean that there wasn’t sufficient interest among other Debian
Developers. So, for me, I considered that the end of the matter.

In that regard, I think the GR process did exactly what it was
supposed to do.

Exactly.

--
Soren Stoutner
soren@debian.org

--

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

]] "G. Branden Robinson"

But Sean is right that this is a view that multiple TCs have
expressed
on multiple occasions.

Acknowledged. I would then simply urge the current TC to keep
in mind
that this limitation is one that they have _chosen_, not one
that has
been imposed on them. With luck, the distinction will not
become
important soon, if ever.

No, it's not something the TC has chosen. See https://lists.debian.org/debian-ctte/2016/10/msg00060.html and
the
reply from the secretary, https://lists.debian.org/debian-ctte/2016/10/msg00067.html .

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

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