Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #13790 > unrolled thread

Re: a Constitutional interpretation question

Back to article view | Back to linux.debian.project

Contents

  Re: a Constitutional interpretation question Gerardo Ballabio <gerardo.ballabio@gmail.com> - 2025-04-10 14:00 +0200
    Re: a Constitutional interpretation question Ian Jackson <ijackson@chiark.greenend.org.uk> - 2025-04-10 20:10 +0200
      Re: a Constitutional interpretation question "G. Branden Robinson" <g.branden.robinson@gmail.com> - 2025-04-10 21:30 +0200
        Re: a Constitutional interpretation question Philipp Kern <pkern@debian.org> - 2025-04-11 13:20 +0200
      Re: a Constitutional interpretation question Gerardo Ballabio <gerardo.ballabio@gmail.com> - 2025-04-14 14:00 +0200
        Re: a Constitutional interpretation question Russ Allbery <rra@debian.org> - 2025-04-14 21:10 +0200
          Re: a Constitutional interpretation question Ian Jackson <ijackson@chiark.greenend.org.uk> - 2025-04-15 17:50 +0200
            Re: a Constitutional interpretation question "G. Branden Robinson" <g.branden.robinson@gmail.com> - 2025-04-15 18:00 +0200
            Re: a Constitutional interpretation question Soren Stoutner <soren@debian.org> - 2025-04-16 01:00 +0200
              Re: a Constitutional interpretation question Bart Martens <bartm@debian.org> - 2025-04-17 00:20 +0200
            Re: a Constitutional interpretation question Sean Whitton <spwhitton@spwhitton.name> - 2025-04-16 03:20 +0200

#13790 — Re: a Constitutional interpretation question

IMHO, any time there is a dispute on a technical issue, the Technical
Committee is the natural place where the issue should be brought if it
can't be resolved between the persons involved, regardless of whether
they are DDs, delegates, DPL or whatever, *and* it should have the
power to ultimately enforce a decision if it needs to.

If that isn't what the Constitution currently says, or even if it's
just unclear whether it actually does, it may be appropriate to amend
it.

Ian Jackson wrote:
> > (1) ask the TC to prominently document their policy of
> > non-override of Delegates ... and (2) ask [maybe]
> > propose a GR to amend the Constitution to reflect [this]
>
> 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. If amending the Constitution would prevent such
threads from happening again in the future, I'd say that would be
indeed a useful use of our time.

Gerardo

[toc] | [next] | [standalone]

#13793

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.

[toc] | [prev] | [next] | [standalone]

#13794

[Multipart message — attachments visible in raw view] — view raw

Hi Ian,

A brief message from me this time!

At 2025-04-10T17:50:16+0100, Ian Jackson wrote:
[...]
> You're right that we're suffering because of the lack of working
> mechanisms, short of GR, for situations like this.

I agree with you and Russ that my interpretation "challenge" is not an
urgent matter.

Since I'm in a minority of one in my views (just like the good old
days!), I think people can understand that I'm also in no hurry to see
cement poured over rejection of my interpretation.  ;-)

(...without exploration of the perverse consequence I think arises from
said rejection...)

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

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.

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

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

Regards,
Branden

[toc] | [prev] | [next] | [standalone]

#13795

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

[toc] | [prev] | [next] | [standalone]

#13797

Ian Jackson wrote:
> 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.

I get your point, and I mostly agree.
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.
In other words, it looks like the DPL's power to "oversee" delegates
is explicitly limited by the Constitution, and a GR is indeed the only
way to overrule them, unless the TC is empowered to do that.

> A similar situation doesn't arise for TC decisions about packages,
> because there we have NMUs which can be used to implemente a decison.

The difference is only that in this case there is a straightforward
way to work around the resistance of a "person who does not want to do
a task" (as per 2.1.1). I'm not convinced that this is enough reason
why the TC shouldn't act also when there isn't.

Gerardo

[toc] | [prev] | [next] | [standalone]

#13798

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

[toc] | [prev] | [next] | [standalone]

#13799

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.

[toc] | [prev] | [next] | [standalone]

#13800

[Multipart message — attachments visible in raw view] — view raw

At 2025-04-15T16:45:40+0100, Ian Jackson wrote:
> 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.

I vigorously endorse these observations (and the rest of your message).

The price of cowardice is to be governed by bullies.

Regards,
Branden

[toc] | [prev] | [next] | [standalone]

#13801

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#13803

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



-- 

[toc] | [prev] | [next] | [standalone]

#13802

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.project

csiph-web