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.robin...@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 (r...@debian.org) <https://www.eyrie.org/~eagle/>
