[CCing Ian on Debian Constitutional drafting question; moving to -project; please direct any follow-ups there]
Hi Sean, At 2025-04-09T09:44:31+0800, Sean Whitton wrote: > On Tue 08 Apr 2025 at 01:09pm GMT, Holger Levsen wrote: > > > The Technical Committee may: > > > > Decide on any matter of technical policy. > > Decide any technical matter where Developers' jurisdictions overlap. > > Make a decision when asked to do so. > > Overrule a Developer (requires a 3:1 majority). > > Offer advice. > > > > They all seem to be way more collaborative to me, than - once again > > - immediatly escalating this to -vote and threatening a GR. > > This is not fair. > > Firstly, the TC [Technical Committee --GBR] cannot overrule delegates. > This is well established. I was going to ask you to cite the relevant clause of the Constitution here, and then thought, "I could be more useful if I looked it up myself and shared it". ...but I'm having trouble finding that provision. https://www.debian.org/devel/constitution We have the introduction to §2. DC> Each decision in the Project is made by one or more of the DC> following: DC> DC> The Developers, by way of General Resolution or an election; DC> The Project Leader; DC> The Technical Committee and/or its Chair; DC> The individual Developer working on a particular task; DC> Delegates appointed by the Project Leader for specific tasks; DC> The Project Secretary. DC> DC> Most of the remainder of this document will outline the powers of DC> these bodies, their composition and appointment, and the procedure DC> for their decision-making. The powers of a person or body may be DC> subject to review and/or limitation by others; in this case the DC> reviewing body or person's entry will state this. _In the list DC> above, a person or body is usually listed before any people or DC> bodies whose decisions they can overrule or who they (help) appoint DC> - but not everyone listed earlier can overrule everyone listed DC> later._ The last sentence is both apropos but also slanted/italicized and...I have forgotten, if I ever knew, what the typeface change means, and the document does not shed light on the issue. In the U.S. legal tradition, we distinguish in appellate court opinions between "holdings" (binding precedent) and "dicta" (non-binding rationales and explanations), and in legislation between "resolutions" (which express the "sense" or sentiments of the legislature, often as a signal to other branches of government, to foreign governments, or to the private sector) and "bills" (which generally construct, amend, or repeal statutory law). But it's fairly well known that Ian is not an American; the U.K. common law tradition he's likely more familiar with and the related U.S. one have been diverging roughly since Blackstone (1769).[1] Later, we have in Article 6 establishing the Technical Committee: [the TC can:] DC> § 6.1.4 Overrule a Developer (requires a 3:1 majority). DC> DC> The Technical Committee may ask a Developer to take a particular DC> technical course of action even if the Developer does not wish to; DC> this requires a 3:1 majority. For example, the Committee may DC> determine that a complaint made by the submitter of a bug is DC> justified and that the submitter's proposed solution should be DC> implemented. Here, if italics were to be used for non-binding "dicta", I'd expect the second sentence to be slanted/italicized, but it is not. So, to me, the TC's view of the limitation on its power in this respect is anything but clear. It may be a working assumption of the team as presently embodied, and that's fine--teams generally get to organize and devise procedures for themselves in whatever ways they find expedient, barring conflicts with the Constitution, the DPL, or the Developers by way of GR--but if that's the case it's not necessarily "well established" to the rest of the membership or to the public. 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. > During my recently-completed TC term, there was no doubt within the > committee that we could only deal with disputes among package > maintainers/contributors, not anything involving DPL delegates. "Could" or "would"? This internally imposed constraint may have served the TC and even the entire Project well in the past, and possibly in the future, but if it's mandated by the Constitution, I'm not seeing it. It's important when executing a constitutional office to clearly distinguish between the powers granted to and prohibitions imposed on you by the governing document on the one hand, and the working practices and standard operating procedures you have on the other. Both arrogation of power prohibited to your office and neglect of power entrusted to it erode the efficacy of the Constitution as a governing document. In plain language, our Constitution promises everyone one thing but we proceed to do another. If I'm wrong about this (and have not simply missed a usage of the word "overrule", which I _did_ mechanically search for), then under your interpretation it is as if Constitution §2 said: FakeDC> Each decision in the Project is made by one or more of the FakeDC> following: FakeDC> FakeDC> The Developers, by way of General Resolution or an election; FakeDC> The Project Leader; FakeDC> Delegates appointed by the Project Leader for specific tasks; FakeDC> The Technical Committee and/or its Chair; FakeDC> The individual Developer working on a particular task; FakeDC> The Project Secretary. ...but it does not. This difference, I suggest, _must_ be meaningful. If someone cannot validly correct my interpretation of the Constitution, I reckon I'll need to follow-up with the TC. Recalling the real Constitution's list: DC> The Developers, by way of General Resolution or an election; DC> The Project Leader; DC> The Technical Committee and/or its Chair; DC> The individual Developer working on a particular task; DC> Delegates appointed by the Project Leader for specific tasks; DC> The Project Secretary. I'd need to (1) ask the TC to prominently document their policy of non-override of Delegates--and presumably the Project Secretary[2]-- (also recall that the provision of overriding an individual Developer is explicitly covered by §6.1.4) and (2) ask them to weigh the possibility of proposing a GR to amend the Constitution to reflect the reduced level of authority they're willing to exercise. But before I'd proceed with (2), I'd want to hear from Ian Jackson, as primary drafter of the Constitution, what he recalls of his reasoning and intentions behind the ordering of the foregoing list, and whether he's found any cause to reconsider that ordering in the years since. And also what the use of italics means. Regards, Branden [1] https://en.wikipedia.org/wiki/Commentaries_on_the_Laws_of_England [2] I initially thought, "when and why would the TC _ever_ override the _Project Secretary_?!", as if the possibility were absurd. But then I remembered that the Project Secretary (PS) is tasked with drafting the final content of ballot options and the determination of which, if any, supermajority requirements attach to each one. For example, the question of whether a ballot option entails a supermajority requirement sometimes arises, and it can be a question of interpretation whether the text of a ballot option supersedes a provision of a "Foundation Document" (like the DFSG) and therefore demands a 3:1 supermajority to pass. This is not a theoretical matter. I recall that when Manoj Srivastava served as Project Secretary, it came up in real life. (Yes, we argued about it.) The following sequence of events is therefore conceivable: (1) a Debian Developer, specifically a package maintainer ("Maintainer"), elects to put some arguably non-DFSG-free material into a package targeted at "main". (2) Others Developers contest Maintainer's decision and submit a grievance to the TC. (3) The members of the TC vote by a 3:1 supermajority (§6.1.4) to override the Maintainer. (4) The Developers propose a GR to override the TC, and acquire sufficient seconds for the GR to proceed to ballot. (5) The PS must then decide whether this proposal requires a 2:1 majority to "override any decision authorised by the powers of the Technical Committee" (§4.1.4) or a 3:1 majority to override the provisions of a "Foundation Document" (§4.1.5.3). The DFSG is a Foundation Document (id.) If the PS selects the 2:1 supermajority requirement because the PS concurs with the Maintainer that the contested material is not non-DFSG-free, then, as I read the Constitution, the TC can in fact override this decision by the PS and direct the PS to enforce the higher supermajority requirement of 3:1. May it never come to pass--y'all thought the systemd thing was bad...
signature.asc
Description: PGP signature
