Re: Draft proposal for resolution process changes
Richard Laager <rlaager@debian.org> writes:
> First off, let me say I have no objections to your positions on
> this. Also, I'm honestly not trying to argue in circles. I'm
> specifically trying to confine my replies to only newly presented
> issues.
I'm not feeling like the conversation is circular at all, to note. It's
been very helpful! I'm only slow to respond because I've been distracted
by non-Debian travel and day-job things.
> On 10/10/21 1:41 PM, Russ Allbery wrote:
>> This wouldn't change anything if the TC vote result is further
>> discussion, since in that case there's no decision to override and, as
>> you point out, the GR would stay at a 2:1 majority required if the
>> developers wanted to exercise the powers of the TC. (In practice, most
>> likely the GR would be phrased as a statement on issues of the day,
>> which is technically nonbinding and only requires a simple majority but
>> which everyone is likely to honor.)
> Your comment about the "statement on issues of the day" made me think a
> bit... if it's the case that GRs will use "statement on issues of the
> day" to make decisions anyway (as e.g. on systemd), is that a reason to
> eliminate the 2:1 supermajority to _make_ TC decisions?
This is a great question and it made me go back and read the constitution
more carefully, at which point I discovered that I confused the whole
issue by mentioning issues of the day because the constitution
specifically constrains those to *non-technical* issues of the day:
Issue, supersede and withdraw nontechnical policy documents and
statements.
These include documents describing the goals of the project, its
relationship with other free software entities, and nontechnical
policies such as the free software licence terms that Debian software
must meet.
They may also include position statements about issues of the day.
So basically there's just a bias in the constitution against making
technical decisions by GR in general. To make any technical decision via
GR requires exercising the powers of the TC, which requires a 2:1
majority. Weird how I've read the constitution innumerable times and that
nuance didn't entirely sink in until just now.
There's a lot of complexity hiding in the definition of "technical" here.
For example, I think one could argue that some of the options in the
systemd GR are technical, particularly the options that lay out more
detailed constraints on package behavior, although it turned out to not
matter since most of those options exceeded a 2:1 majority anyway. I
don't think I'd entirely registered that at the time.
Anyway, for the purposes of this specific GR, I think that I'm talking
myself into not wanting to make changes to GR overrides of TC decisions,
or making TC decisions, at the same time as all the other changes since
they seem a bit separate and I'm worried about both complexity creep and
changing too many things at once. But that's a weak position and I can
certainly be talked into making changes here if more of a consensus
emerges about exactly what changes to make than has appeared so far.
> A related question... if a GR makes a decision, what's the situation
> with the TC overriding that at some point? In other words, if the
> developers make a decision in a GR, obviously the TC shouldn't
> immediately override it, but are we "stuck" with that GR decision
> forever even if facts change? I think the real-world answer to this is
> that if the facts change, the TC could change the position and if nobody
> objects, it's fine. If they do, then you get another GR.
This is a great question and it's highly unspecified in the constitution.
It's come up in the past, most notably for
https://www.debian.org/vote/2007/vote_003
which mandates a specific implementation strategy that we then later
wanted to change. I think the constitutional answer is that the Project
Secretary would need to decide, and there isn't a ton of guidance in the
constitution about how long decisions (and overrides) persist, once made.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: