Le mercredi, 4 septembre 2019, 23.53:06 h CEST Bill Allombert a écrit : > On Wed, Sep 04, 2019 at 11:04:57PM +0200, Wouter Verhelst wrote: > > > * Most decisions are not just technical decisions, in many/most cases > > > > > > the decisions have answers that are all correct, but it just depends > > > on the weight of specific trade-offs. How those are weighted depends > > > heavily on each individual. This also seems rather unfair, as it's > > > taking the natural and expected biases of a small set of people in > > > the project and forcing them into the entire project. > > > > Honestly, if the answers are all correct and we've been going around in > > circles since like forever, then having a small team decide that one of > > these correct answers is now the preferred one and we're going with it > > (after listening to all the arguments) hardly seems unfair to me. > > But then it become a steering committee and not a technical commitee.
Actually, it seems that the Technical Committee has kinda always been doing
both of these things: arbitration, and steering.
In arbitration, the TC has had to decide on disagreements; either by looking
at current documentation or at current practice; ending up ruling about who
was "right" [0]. It hasn't necessarily always been controversial, or between
people in disagreement; the TC has also sometimes arbitrated questions put
forward; pretty much on the tunes of "we're not sure what do here, could you
tell us with a more distant view what is it that the project expects us to be
doing?".
Now, in terms of steering, I can think of some past issues: #727708 "default
init" obviously, #741573 "menu systems", #717076 "JPEG library", etc. In
these
cases [1], it hasn't really been about breaking ties, or just arbitrating
between existing options. The TC really had to agree, and decide which was the
right [2] path forward, for the good of the Project, really in a "steering"
position. And by exercising that "steering" function for the project, the TC
has taken decisions that have put some people off; mostly because, by the mere
nature of the questions asked, it couldn't satisfy every party, while still
allowing the project to "go on".
I have come to wonder if these two functions shouldn't be separated, in
different bodies (eventually with different nomination rules, etc.). This
"steering" question had also been phrased, slightly differently, by Mehdi,
during his DPL term, with the idea of a "Roadmap team". [As I understand it, a
Roadmap team would pilot the Debian ship with a vision on how to sail the
sees, where the TC, when "steering", decides on a case-by-case in a ship
without captain]. Uncomfortable, for political and availability reasons, the
TC declined to take that role back then.
From there, does the project want/need, any of these two bodies?
- an arbitration group, with the power to break gordian knots, and help
greasing the wheels of the project;
- a steering group, to establish and pilot a vision for the project, deciding
on conflicting points when needed (several intensity variants are of course
possible; from a case-by-case steering, to a much "stronger" plan
enforcement).
My point, I guess, is that the TC is currently doing mostly arbitration (which
doesn't seem very controversial, but for the affected ones), and a little
steering (which seems bound to always be controversial). And when it _does_
steering, it is constrained by §6.3.5 "No detailed work".
One step forward, could be to completely remove all "steering" powers from the
TC, to make it a purely arbitration body. But who would decide on the complex
"steering" issues; who would have decided on the default init system?
Of course, the question of how "progressive" any steering body should be is a
complex one. As Ian puts it:
Le lundi, 13 mai 2019, 16.28:11 h CEST Ian Jackson a écrit :
> I also think that the TC is far less conservative than it ought to be
> and is much more willing to risk damaging (or is blind to the risk of
> damaging) the project's social cohesion, in the name of what is called
> technical progress but often seems to me to be a narrowing of the
> project's focus.
I don't necessarily agree, but I also clearly understand [3] that when the TC
said (in #741573), that "(it) resolves that packages providing a .desktop file
shall not also provide a menu file for the same application", it took a
steering stance on where it saw the project going, and gave a strong pushback
to the volunteers working on providing a good "menu" experience.
As long as the TC is this "steering group", it will be as progressive as its
members, and I make no mystery of my fondness of a "progressive" TC on
steering questions [4]. But if the project wants more conservative (or just a
different) steering, then we should be discussing about how to make this
hypothetical "steering group" more aligned with the aspirations of the project
at large. Removing the super-majority requirements for a GR override could be
one way.
In conclusion; I don't think the TC's setup is set in stone, and we have 20+
years of history now to help us change it for better; and I'm glad we're
having that discussion!
Cheers,
OdyX
[0] Not in the moral sense, but more in the "the project, through its
documentation, or practice, was expecting you, in your role as ${role}, to
have done this, not that".
[1] which have needed much more emotional involvement from all parties.
[2] or least horrible
[3] https://lists.debian.org/2534944.fjzomkj...@odyx.org
[4] And, for the record, I am quite confident that the answers given to the
past steering questions by the TC were quite aligned with the project at
large.
--
OdyX
signature.asc
Description: This is a digitally signed message part.
