Re: Thinking about Delegating Decisions about Policy

[Wouter Verhelst]

On Fri, Sep 06, 2019 at 11:32:06AM +0200, Bill Allombert wrote:
> On Thu, Sep 05, 2019 at 09:17:59AM +0200, Didier 'OdyX' Raboud wrote:
> > 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.
>   
> The way the TC members are selected is not compatible with taking the role
> of a steering committee (which need to be properly elected rather than
> self-selected).

If we're going to change the rules about what the TC does -- or create a
whole new committee -- it makes sense to change this part of it, too. So
while I agree with you that this is a concern, it doesn't have to be a
fatal problem.

> (To avoid misunderstanding, I am not in favor of Debian getting a
> steering committee. The steering should come from the DPL, who is
> elected)

I agree that whoever does "steering" needs to be elected. However, I am
not convinced that one elected representative is good enough for that;
both for long-term stability (DPLs change up to once a year, which is
hardly enough for a long-term vision) as well as for allowing multiple
viewpoints (the DPL is just one person with his or her own biases; no
matter how well the DPL represents the viewpoints of the project at
large, it is always better to have multiple people in a position with
this kind of power).

So I think that Debian could have some limited benefit from a steering
group, but I do agree that it needs to be an elected group, not an
appointed one.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Thinking about Delegating Decisions about Policy

[Didier 'OdyX' Raboud]

Le vendredi, 6 septembre 2019, 11.32:06 h CEST Bill Allombert a écrit :
> On Thu, Sep 05, 2019 at 09:17:59AM +0200, Didier 'OdyX' Raboud wrote:
> > 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.
> 
> The way the TC members are selected is not compatible with taking the role
> of a steering committee (which need to be properly elected rather than
> self-selected).

Agreed. For me, that's also why "steering" decisions have always been hard: 
hard because handed to the TC at a late stage, as last resort; hard decisions 
to take for the TC, with high stakes and emotions, etc. I feel it's also the 
main reason behind the refusal to _be_ the Roadmap Team from the TC.

> (To avoid misunderstanding, I am not in favor of Debian getting a
> steering committee. The steering should come from the DPL, who is
> elected)

It seems that this is what is intended by the current constitution. But we 
should really discuss what we need; and I'm not convinced that a steering 
group designated by an elected DPL [delegate] is that much better than a self-
selected group vetted by the elected DPL [TC]. If we do give powers to a 
steering group, we could (and I argue we probably should) make it a body of 
elected individuals with fixed terms (renewability, grace periods, term 
overlaps, etc are important details of course).

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Thinking about Delegating Decisions about Policy

[Bill Allombert]

On Thu, Sep 05, 2019 at 09:17:59AM +0200, Didier 'OdyX' Raboud wrote:
> 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.
  
The way the TC members are selected is not compatible with taking the role
of a steering committee (which need to be properly elected rather than
self-selected).

(To avoid misunderstanding, I am not in favor of Debian getting a
steering committee. The steering should come from the DPL, who is
elected)

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: Thinking about Delegating Decisions about Policy

[Wouter Verhelst]

On Thu, Sep 05, 2019 at 09:17:59AM +0200, Didier 'OdyX' Raboud wrote:
> 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.

I hadn't looked at it from that angle before, but you're right. In fact,
if you look at other distributions, they all have some form of a
steering body: Ubuntu has their BDFL, Fedora has the FESCo, OpenSUSE has
an elected steering body, and FreeBSD has their core team. I'm sure much
of this is true for other distributions as well.

Debian does not have a body like this. In some way, this is a feature;
we don't have an overarching body that says "X, not Y", and therefore we
do both X and Y, and people can just use what they want. Sometimes,
however, that doesn't work; when X and Y conflict, we need someone to
choose one of the two options. The TC indeed isn't really set up to do
this properly, but it gets closest, and therefore it gets to do the job
by default.

If we are going to make a "steering committee" of sorts, however, or
adapt the TC so it can take the role, then I do think we should keep in
mind what our historic behaviour has been; that is, that we usually
allow multiple options to coexist, and that that isn't necessarily a bad
thing as long as they either don't conflict, or a default can be chosen
without too much disagreement.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Thinking about Delegating Decisions about Policy

[Didier 'OdyX' Raboud]

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 

Re: Thinking about Delegating Decisions about Policy

[Bill Allombert]

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.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: Thinking about Delegating Decisions about Policy

[Wouter Verhelst]

On Fri, Jul 26, 2019 at 06:45:35PM +0200, Guillem Jover wrote:
>   * This is a body composed of members that come and go, these might have
> wide experience in Debian in general (although not necessarily) or
> might had expertise in specific fields. The problem is that this body
> gets unbounded topic issues about anything. You cannot expect anyone
> w/ no prior experience to have "taste" or "intuition" about things
> they have not experienced/practiced for a long time. This is not,
> say, a java-ctte composed of Java experts.

To be fair, this used to not be the case, but then GR 2014-004 changed that.

Although I voted in favour of doing that, in hindsight I'm not sure it
was the right decision.

[...]
>   * 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.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Thinking about Delegating Decisions about Policy

[Margarita Manterola]

Thanks a lot Guillem for this message.

It's very timely as we just had a discussion around these issues during
DebConf19 in Curitiba, and many of the problems that we identified and
discussed matched what your were saying.

I think the TC needs to keep working on these issues and figure out
how we want to move forward. Your input is super valuable for this.

Thanks!

--
Regards,
Marga

Re: Thinking about Delegating Decisions about Policy

[Guillem Jover]

Hi!

Thanks for sending this out Ian, part of this matches exactly what I've
been thinking for a long time, and the reason for my continued public
opposition and deep dissatisfaction with the tech-ctte as a body. I've
mentioned in the past [P] I'd put my thoughts in a more structured form,
but I always find this topic to be too exhausting and demotivating.

  [P]  

On Mon, 2019-05-13 at 15:28:11 +0100, Ian Jackson wrote:
> Rather than see the TC's role enhanced, I would like to abolish it and
> replace it with something completely different.

Full ack! And like Ian, I pretty much have a problem with the structure
and the body, not its members!

Some of the problems I see myself which I've probably covered in the
past are:

  * It has multiple conflicting roles (arbiter of disputes, mediator
of conflicts, advice giver, etc.), so there's always the worry that
something brought forward might be morphed/redirected/switched into
one of the other powers, which can bring unanticipated power
dynamics (f.ex. I don't think mediation can work well or at all when
the mediating party has also the power to adjudicate).

- If it was just an advisory board of elders/oracles or similar,
  with no powers of authority, besides the ones coming from knowledge,
  experience, track record, etc., it would seem perfectly fine for
  any party, including, say the policy editors, to request advice on
  contentious or uncertain issues from that advisory board, because
  it would be just another input to consider when doing the actual
  decision.

- If it was a social-ctte (not arbiters but mediators or resolvers
  of conflict, w/o authority) to deal with interpersonal conflicts,
  that would also seem fine, and my take is that the different
  parties might be more open to be mediated this way.

  * It has the power to impose final decisions into others:

- While not being involved (as a body) in the design nor the
  implementation, nor long-term maintenance, nor any consequence
  and fallout from those, which seems completely unfair within the
  confines of a volunteer project.

- Which also seems like a way to sidestep one of the core tenets of
  the project ("volunteers cannot be forced to do anything"), which
  might force them to do things they otherwise would not do, and
  giving them pretty much the options of complying or stepping down.

  * When conflicts are brought up, in most cases they are at a point
where the positions of the opposing factions/parties are so hardened,
and/or communication has broken down so badly, that a decision will
just be a win/lose scenario, which further destroys/erodes the social
fabric of the project, bringing with it possibly rancour and hard
to repair relationships between members in the project.

  * Reaching good decisions or deciding at all is important, but how
we reach them is IMO as important, or more (the ends do not justify
the means):

- Forced decisions coming out of the tech-ctte, by way of wielding
  authority instead of convincing arguments and wide adoption, means
  they are way less legitimate than ones that would have been reached
  by (rough) consensus, or incremental adoption.

  * It still has the very unfair power imbalance I pointed out some years
ago, about a GR requiring a super-majority to override its decisions.

  * This is a body composed of members that come and go, these might have
wide experience in Debian in general (although not necessarily) or
might had expertise in specific fields. The problem is that this body
gets unbounded topic issues about anything. You cannot expect anyone
w/ no prior experience to have "taste" or "intuition" about things
they have not experienced/practiced for a long time. This is not,
say, a java-ctte composed of Java experts.

  * It is a self-selected body, where things like being uncomfortable
with or not being able to work with other specific members, might
bias the selection process, while this body is supposed to serve
the project interests at large and not the individual body members'.
(And to be clear having a body with members that cannot or do not
enjoy working together would be pretty terrible, but given the purpose
of the body, having that limit its composition seems pretty bad too.)

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


Thanks,
Guillem

Re: Thinking about Delegating Decisions about Policy

[Margarita Manterola]

Hey Sam,

Sorry it took us so long to get back to you on this.

Sean and Ian already had quite some interesting discussion on this 
subject. And

we also talked about this issue during our monthly meeting in June [1].

The rough consensus from our discussion is that the technical committee 
can
always be consulted when policy editors don't see consensus among 
developers,
but we feel it's the role of policy editors (and not the TC) to decide 
on what

to do about policy, informed by what the whole project is doing.

At least this advisory role is our understanding of how the Constitution
defines the role of the TC.

Of course, there is scope for doing more in the way of constructive 
consensus
building, and you've been doing some great stuff in that direction.  
There
doesn't seem to be anything that makes the TC in any way uniquely 
qualified for
this work (possibly the reverse), so people that are good at that should 
just
get on with it regardless of whether they are TC members, DPLs, or 
anyone else.


There's been a lot of unhappiness sort-of-recently regarding the role of 
the
TC. In particular, the fact that raising an issue to the TC causes a lot 
of
friction and people need to almost be having a flame-war before coming 
to us.
So, it might make sense to actually discuss the role of the TC and how 
this
situation can be improved during the TC BOF at DebConf19 next week 
(Friday July

26th - 14:30 DebConf time).

[1]: 
http://meetbot.debian.net/debian-ctte/2019/debian-ctte.2019-06-19-18.59.log.html


--
Regards,
Marga (with input from Phil and David)

Possible improvements to the Policy Changes Process (was: Re: Thinking about Delegating Decisions about Policy)

[Sean Whitton]

Hello Ian,

On Thu 16 May 2019 at 11:19am +0100, Ian Jackson wrote:

>> My current strategy, when
>> - it seems like something is important and should be changed, but
>> - it has not yet been implemented in the archive, or
>> - in some other sense lacks a clear consensus,
>> is to refer the case to the T.C.
>>
>> I think your suggestion is that in at least some such cases we should
>> lower our standards for what is required for a clear consensus?  If so,
>> am I right in thinking this would not actually require any changes to
>> the Policy Changes Process?
>
> I'm not sure exactly what you mean by "has not yet been implemented".
> I am going to assume you mean "most packages have not yet been
> updated", not that no packages have been changed, or the underlying
> core implementation is missing, or something.
>
> I don't recognise "has not yet been implemented in the archive" as
> "[a] sense [in which X] lacks a clear consensus".
>
> I think the fact that most packages in the archive have not been
> updated to have change X does *not* mean there is not rough consensus
> in the project that change X is usually a good thing.  It often means
> that the bulk of the project hasn't thought about it, or that the
> change is just part of our ongoing backlog of outstanding work.
>
> Having a clear document, with authoritative status, saying that X is
> usually a good thing, and how precisely X should be done, is immensely
> valuable to making X actually happen, and happen well.
>
> Furthermore, if we make recommendations that X should *usually* be
> done, then in most cases only very *rough* consensus is needed.
> People who disagree that X should be done in a particular case, or at
> all, can not do it.
>
> So what I am suggesting is that the policy editors should cease to
> treat "many packages do not yet do X" as a reason to delay
> recommending that packages should do X.

I think my descriptions must have misrepresented current practice,
because I basically agree with everything you've written here.  The
working prerequisite for updating Policy is not that the majority of the
archive has been switched over to use some new mechanism/follow some new
convention.  The usual prerequisite is only that the work has been
started and the underlying core implementation, as you put it, is in
place.

We don't treat "many packages do not yet do X" as *on its own* a reason
to delay recommending that packages should do X.  We do require that at
least some packages do X.  Also, we might take the fact that many
packages do not yet do X to be a reason to doubt that there is in fact a
project consensus that packages should do X.  But the mere fact that
many packages do not yet do X does not block Policy changes.

With regard to recommendations that something should usually be done,
discussion in #930666 has shown that the way we currently define
must/should/may/required/recommended/optional makes this more difficult
to do than it might be.

>> > Additionally I think the formal proposer/seconder scheme can be
>> > awkward.  Again I think the policy editors adopted it because they
>> > didn't want to be in the line of fire when difficult decisions are
>> > being made, and perhaps because they didn't want to try to become
>> > experts in everything.  But it means that uncontroversial changes can
>> > languish.
>>
>> Do you (or anyone else) have any concrete ideas for simplifying the
>> proposer/seconder scheme, without significantly reducing the oversight
>> on changes, even uncontroversial ones?
>
> I would suggest instead that for changes which the policy editors
> like and which seem likely to be uncontroversial, the policy editors
> would publish a notice giving a deadline for comments/objections.
>
> Probably the notice would be sent to some announce list, and also CC'd
> to any roles that seem specifically implicated or interested.
> Possibly for small changes and normative clarifications they could be
> bundled up into a digest and sent to d-d-a.

So the change would be to replace the seconding requirement, in
uncontroversial cases, with asking for comments/objections, and setting
a deadline for those?  This seems like a good idea to avoid bugs waiting
for seconds for months and months.  We'd need to think about what
happens when there are objections -- do we immediately fall back to the
seconding scheme?

Perhaps you could file a bug against the Policy Changes Process appendix
so we can hash out the details of this?

> Another idea would be to make it easier to revert or suspend a change
> which turns out to be controversial.  You could say that a change will
> be reverted if, in the opinion of the policy editor, an
> post-promulgation objection is made which raises a substantial issue
> that ought to be dealt with.
>
> While vacillation is undesirable, making it easier and less socially
> costly to handle mistakes, will make it easier to make changes.

I agree that this could help a lot.  I have certainly felt hesitation

Re: Thinking about Delegating Decisions about Policy

[Sam Hartman]

> "Sean" == Sean Whitton  writes:

Sean> Hello Sam,
Sean> On Fri 10 May 2019 at 03:57PM -04, Sam Hartman wrote:

>> What are people's thoughts about this?
>> 
>> Will this approach work for the TC and policy editors?

Sean> I think that the concrete suggestion you're making is that
Sean> when a question that comes before the T.C. is something that
Sean> could be solved by patching the Policy Manual, the T.C. should
Sean> respond to the question by opening a bug against the Policy
Sean> Manual, and suspending the T.C. bug until it becomes clear
Sean> whether or not that debian-policy bug is going to reach
Sean> consensus?

That's an over simplification, but it's approximately correct.

I'm saying that this is an approach the TC could use, rather than an
approach that the TC should use.  I'd hope the TC would evaluate whether
they thought it would be productive rather than blindly using any
procedure.
Similarly, I'm hoping that in such a case individual TC members might
consider being involved in the policy process where appropriate.

--Sam

Re: Thinking about Delegating Decisions about Policy

[Sean Whitton]

Hello Sam,

On Fri 10 May 2019 at 03:57PM -04, Sam Hartman wrote:

> What are people's thoughts about this?
>
> Will this approach work for the TC and policy editors?

I think that the concrete suggestion you're making is that when a
question that comes before the T.C. is something that could be solved by
patching the Policy Manual, the T.C. should respond to the question by
opening a bug against the Policy Manual, and suspending the T.C. bug
until it becomes clear whether or not that debian-policy bug is going to
reach consensus?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Thinking about Delegating Decisions about Policy

[Sean Whitton]

Hello Ian,

On Mon 13 May 2019 at 02:50PM +01, Ian Jackson wrote:

>> we delegated managing the process to the policy editors, but not the
>> actual policy decisions.  They make consensus calls.  They use their
>> judgment in a lot of ways.
>
> That is a decision *of* the policy editors.  When the constitution was
> first adopted, and for some time afterwards, the policy editors
> themselves made judgement calls about merit, rather than simply trying
> to assess consensus.
>
> [...]
>
>> But at least under the current process, the policy editors cannot  just
>> use their personal judgment to decide what policy is absent a consensus.
>
> The policy editors collectively could decide to change the process.
> The process is a creation of the policy editors, not of the DPL nor of
> the rest of the project.

Firstly, let me confirm that I share this understanding of what powers
the Policy Editors formally possess.  I actually wrote it into Policy in
a recent release, section 1.3.2.

(I am also responsible for moving the Policy Changes Process into the
Policy Manual itself as an appendix.  It was not my main motivation at
the time, IIRC, but in fact the change has made the status of the Policy
Changes Process a bit clearer than when it was just a wiki page.)

> IMO the biggest problem is the principle that policy should always
> follow practice rather than lead it - even if the project has rough
> consensus about the direction.  I really don't think that is best.
>
> There is a missed opportunity here.  The policy editors and the policy
> list have a good reputation and a lot of legitimacy.  That comes from
> their practice of caution, of consulting widely, and seeking rough
> consensus.
>
> I wouldn't want to change that dramatically but a small change from
> the policy editors would go a long way.  For example, to be willing to
> countenance making recommendations which have rough consensus, and
> seem to the editors like a good way forward, but which are followed
> only occasionally or patchily.
>
> That would not involve goring anyone's ox, so it would not undermine
> the policy team's political capital.  Obviously any change might be
> opposed by someone but I doubt such a change in policy practice would
> meet much opposition.

The idea that Policy should always lag behind practice is something that
I find very difficult to assess.  If you are thinking of Debian as a
large number of people furiously innovating at the borders and
exchanging ideas with each other in the form of uploads, then it makes
complete sense.

On the other hand, to the extent that we're a group of people struggling
to communicate best practices to large numbers of people working largely
independently on mostly maintainance work, it seems a lot less helpful.

(Debian is, of course, both of these things.)

My current strategy, when

- it seems like something is important and should be changed, but
- it has not yet been implemented in the archive, or
- in some other sense lacks a clear consensus,

is to refer the case to the T.C.

I think your suggestion is that in at least some such cases we should
lower our standards for what is required for a clear consensus?  If so,
am I right in thinking this would not actually require any changes to
the Policy Changes Process?

> Additionally I think the formal proposer/seconder scheme can be
> awkward.  Again I think the policy editors adopted it because they
> didn't want to be in the line of fire when difficult decisions are
> being made, and perhaps because they didn't want to try to become
> experts in everything.  But it means that uncontroversial changes can
> languish.

Do you (or anyone else) have any concrete ideas for simplifying the
proposer/seconder scheme, without significantly reducing the oversight
on changes, even uncontroversial ones?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Thinking about Delegating Decisions about Policy

[Ian Jackson]

Sam Hartman writes ("Thinking about Delegating Decisions about Policy"):
> Why the TC?
> A couple of reasons.

I'm going to go off on a rant about the TC now.  I've been told that
this mail sounds like sour grapes but I think it's important.

I think it would be a bad idea to use the TC to push forward technical
change.  I think the TC as an institution[1][2] lacks:

1. wide enough political legitimacy

2. enough sensitivity to the concerns of those other than
the maintainers or teams whose decisions are being impugned

3. even, sadly, enough of a grip on detailed technical matters

4. structured communication and decisionmaking processes, which would
IMO be needed to: systematically capture the facts, and the
implications of the options; help the "losers" feel heard, and
feel that the decision was properly made; deliver clear
conclusions, but compassionately.

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.


Rather than see the TC's role enhanced, I would like to abolish it and
replace it with something completely different.

Right now it is almost useless as a tool to overturn bad decisions by
maintainers: the costs of invoking it are far too high.  This is
partly because it always implies a public flamewar[1] and partly
because the TC itself generally seems to strongly prioritise the
emotional comfort of maintainers, and the notion of "progress"; it
disregards the emotional comfort of people who want their existing
stuff to keep working, and the autonomy of a package's users.

As a tool to make project-wide decisions on the desirability of a
mandating certain kind of progress, it lacks legitimacy amongst
significant proportions of the community, because of the way it made
decisions in the past and also to an extent because of the content of
those decisions.


Ian.

[1] I should say that I think the individual members of TC are and
have been people of generally very high caliber.  IMO the failings are
emergent properties of the structure, context and framing.

[2] Much of this is, I think, ultimately my fault.  I invented this
setup.  All I can say is that I was young and naive.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Thinking about Delegating Decisions about Policy

[Ian Jackson]

tl;dr:

 IMO a better way is for the policy editors feel more empowered to
   - lead practice rather than follow it (e.g. to follow
   rough consensus on desirable changes to Debian, rather
   than only document what is already widespread)
   - make judgement calls
 This could be done by encouraging the policy editors to amend the
 policy process, and by giving them political cover as they change
 their practice.


Sam Hartman writes ("Thinking about Delegating Decisions about Policy"):
> I imagine it won't be uncommon to get to a point where the right next
> step is to develop technical or non-technical policy about something.
...
> So, if I want to delegate deciding on a policy, who should I send it to?

Do you mean you as the DPL or you as a maintainer of some program or
sub-policy or something ?

I think you mean as DPL.  As the DPL you do not have any power to set
policy so you cannot delegate that to anyone.  An attempt do so ([1]
for example) is beyond the powers of the DPL, and therefore void.
("ultra vires" as a laywer would say. [2])


> we delegated managing the process to the policy editors, but not the
> actual policy decisions.  They make consensus calls.  They use their
> judgment in a lot of ways.

That is a decision *of* the policy editors.  When the constitution was
first adopted, and for some time afterwards, the policy editors
themselves made judgement calls about merit, rather than simply trying
to assess consensus.

Note that debian-policy is only one of the packages containing
technical policies.  Many other packages have bits of policy in them.
It is only debian-policy whose maintainers have decided to adopt this
consensus scheme and to lag practice.

IMO the biggest problem is the principle that policy should always
follow practice rather than lead it - even if the project has rough
consensus about the direction.  I really don't think that is best.

There is a missed opportunity here.  The policy editors and the policy
list have a good reputation and a lot of legitimacy.  That comes from
their practice of caution, of consulting widely, and seeking rough
consensus.

I wouldn't want to change that dramatically but a small change from
the policy editors would go a long way.  For example, to be willing to
countenance making recommendations which have rough consensus, and
seem to the editors like a good way forward, but which are followed
only occasionally or patchily.

That would not involve goring anyone's ox, so it would not undermine
the policy team's political capital.  Obviously any change might be
opposed by someone but I doubt such a change in policy practice would
meet much opposition.


Additionally I think the formal proposer/seconder scheme can be
awkward.  Again I think the policy editors adopted it because they
didn't want to be in the line of fire when difficult decisions are
being made, and perhaps because they didn't want to try to become
experts in everything.  But it means that uncontroversial changes can
languish.


> But at least under the current process, the policy editors cannot  just
> use their personal judgment to decide what policy is absent a consensus.

The policy editors collectively could decide to change the process.
The process is a creation of the policy editors, not of the DPL nor of
the rest of the project.


Ian.

[1] https://lists.debian.org/debian-devel-announce/2017/06/msg5.html
[2] https://en.wikipedia.org/wiki/Ultra_vires

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Thinking about Delegating Decisions about Policy

[Ansgar]

Bill Allombert writes:
> In my view it is detrimental for the policy proces for the Debian policy
> to include decisions made by the TC, because this leads to a situation
> where some policy text is frozen because the policy editors cannot change
> it without potentially overriding the TC.

Then the TC should (always) state explicitly that changing this using
normal processes is allowed.

The "Debian Maintainer" role was introduced via GR which also specified
implementation details ("DM-Upload-Allowed" in source packages, jetring
to be used to maintain the keyring on Alioth, ...).  Quite a bit of
which has changed without a second GR as it was assumed that "The
initial policy for ... will be ..." meant the policies could be changed
via normal processes, usually by the responsible people agreeing on a
change.

So I think having parts of policy frozen can be avoided even when the TC
sets it; I even agree that it should be avoided.

Ansgar

Re: Thinking about Delegating Decisions about Policy

[Bill Allombert]

On Fri, May 10, 2019 at 03:57:52PM -0400, Sam Hartman wrote:
> In my platform, one of the things I focused on is trying to drive the
> decision process forward.
> 
> I imagine it won't be uncommon to get to a point where the right next
> step is to develop technical or non-technical policy about something.
> 
> I'd like to focus in this message about what I as DPL do when I believe
> we need to develop technical policy about some issue.  Typically this
> will be after we'd had some project discussion and hopefully reached
> some degree of consensus on the driving principles/overall approach for
> the project.
> 
> Examples of the sorts of things I'm talking about would include
> potential policy on use of dh after a discussion about our direction
> there.
> 
> It seems that we have two overlapping groups that might be involved: the
> policy editors (and more generally the consensus policy process) and the
> Technical Committee.
> 
> Here's how as DPL I see things today.  I'm very open to changing my
> mind, and this is very much just a starting position.
> 
> first, I've read
> https://lists.debian.org/debian-project/2014/01/msg00044.html
> 
> I agree that the policy process can be delegated to the policy editors
> by that mechanism and have no desire to change how policy works or
> change the policy editors or anything like that.  I wouldn't mind seeing
> the TC and policy editors work more closely together, and perhaps my
> thoughts in this area are influenced by that.
> 
> That said, ultimately, I think the Technical Committee is the authority
> on what our technical policy is under constitution section 6.1.1.
> 
> we delegated managing the process to the policy editors, but not the
> actual policy decisions.  They make consensus calls.  They use their
> judgment in a lot of ways.
> 
> But at least under the current process, the policy editors cannot  just
> use their personal judgment to decide what policy is absent a consensus.
> 
> 
> In contrast, while the TC cannot develop solutions, they can establish
> policy using the collective judgment of the committee.
> There's obviously some ambiguity in what it means to develop solutions
> vs refining/wordsmithing proposals.
> 
> So, if I want to delegate deciding on a policy, who should I send it to?
> 
> My preference is to always send it to the TC.  But there's a big caveat
> that I'll get to in a moment.
> 
> Why the TC?
> A couple of reasons.
> 
> Ultimately they are the ones who can decide.
> If things get stuck, they are in a position to make a decision.
> 
> The constitution makes it easy for the DPL to delegate almost anything
> to the TC.
> 
> Once a specific decision is delegated, removing that delegation can be
> thorny.  I think procedurally it's OK to remove a delegation because the
> decision is stuck or no progress is being made.  However distinguishing
> that from a situation where the delegate is making a decision (which
> cannot be overturned by the DPL) can be thorny.
> 
> By delegating to the TC (and getting the TC to agree to accept a
> delegated decision) I'm asking them to take ownership.  Once we agree
> that they are handling it, we have agreement that the issue is important
> enough to move forward.
> 
> But, and here's the caveat I talked about.  I think a reasonable way for
> the TC to move forward on most issues I might bring to them is to give
> the normal policy process including the policy editors a chance to come
> to consensus.
> "Ask someone else" is sometimes a great way to make something happen.
> 
> I think the TC procedurally could involve debian-policy for most policy
> questions that come to them.  I think that it typically doesn't make
> sense.  In a lot of cases it's clear that the normal policy process
> isn't going to reach a consensus.  In cases where the normal policy
> process hasn't been tried it might simply be reasonable for the TC to
> decline to take up the issue until that has been tried.  But I can
> imagine other cases where the approach I'm proposing would be
> appropriate.
> 
> Of course the TC could turn around and tell me that I should try the
> normal policy process first.  And if I do a bad job of identifying
> issues that are important to the project or a bad job of guiding the
> initial discussion, probably they should.  My hope is that if as DPL I
> bring an issue that's actually important to the project to the TC, they
> would be willing to track it, help me make sure we're making forward
> progress, even if the first (and perhaps only) step is to build
> consensus within debian-policy.
> 
> In effect, I'm asking the TC to help things move smoothly forward and to
> become more involved if that becomes necessary.
> I'm also asking the TC to work closely with debian-policy where
> appropriate.
> 
> What are people's thoughts about this?
> 
> Will this approach work for the TC and policy editors?

In my view it is detrimental for the policy proces for the Debian policy
to include decisions 

Thinking about Delegating Decisions about Policy

[Sam Hartman]

In my platform, one of the things I focused on is trying to drive the
decision process forward.

I imagine it won't be uncommon to get to a point where the right next
step is to develop technical or non-technical policy about something.

I'd like to focus in this message about what I as DPL do when I believe
we need to develop technical policy about some issue.  Typically this
will be after we'd had some project discussion and hopefully reached
some degree of consensus on the driving principles/overall approach for
the project.

Examples of the sorts of things I'm talking about would include
potential policy on use of dh after a discussion about our direction
there.


It seems that we have two overlapping groups that might be involved: the
policy editors (and more generally the consensus policy process) and the
Technical Committee.

Here's how as DPL I see things today.  I'm very open to changing my
mind, and this is very much just a starting position.

first, I've read
https://lists.debian.org/debian-project/2014/01/msg00044.html

I agree that the policy process can be delegated to the policy editors
by that mechanism and have no desire to change how policy works or
change the policy editors or anything like that.  I wouldn't mind seeing
the TC and policy editors work more closely together, and perhaps my
thoughts in this area are influenced by that.

That said, ultimately, I think the Technical Committee is the authority
on what our technical policy is under constitution section 6.1.1.

we delegated managing the process to the policy editors, but not the
actual policy decisions.  They make consensus calls.  They use their
judgment in a lot of ways.

But at least under the current process, the policy editors cannot  just
use their personal judgment to decide what policy is absent a consensus.


In contrast, while the TC cannot develop solutions, they can establish
policy using the collective judgment of the committee.
There's obviously some ambiguity in what it means to develop solutions
vs refining/wordsmithing proposals.

So, if I want to delegate deciding on a policy, who should I send it to?

My preference is to always send it to the TC.  But there's a big caveat
that I'll get to in a moment.

Why the TC?
A couple of reasons.

Ultimately they are the ones who can decide.
If things get stuck, they are in a position to make a decision.

The constitution makes it easy for the DPL to delegate almost anything
to the TC.

Once a specific decision is delegated, removing that delegation can be
thorny.  I think procedurally it's OK to remove a delegation because the
decision is stuck or no progress is being made.  However distinguishing
that from a situation where the delegate is making a decision (which
cannot be overturned by the DPL) can be thorny.

By delegating to the TC (and getting the TC to agree to accept a
delegated decision) I'm asking them to take ownership.  Once we agree
that they are handling it, we have agreement that the issue is important
enough to move forward.

But, and here's the caveat I talked about.  I think a reasonable way for
the TC to move forward on most issues I might bring to them is to give
the normal policy process including the policy editors a chance to come
to consensus.
"Ask someone else" is sometimes a great way to make something happen.

I think the TC procedurally could involve debian-policy for most policy
questions that come to them.  I think that it typically doesn't make
sense.  In a lot of cases it's clear that the normal policy process
isn't going to reach a consensus.  In cases where the normal policy
process hasn't been tried it might simply be reasonable for the TC to
decline to take up the issue until that has been tried.  But I can
imagine other cases where the approach I'm proposing would be
appropriate.

Of course the TC could turn around and tell me that I should try the
normal policy process first.  And if I do a bad job of identifying
issues that are important to the project or a bad job of guiding the
initial discussion, probably they should.  My hope is that if as DPL I
bring an issue that's actually important to the project to the TC, they
would be willing to track it, help me make sure we're making forward
progress, even if the first (and perhaps only) step is to build
consensus within debian-policy.

In effect, I'm asking the TC to help things move smoothly forward and to
become more involved if that becomes necessary.
I'm also asking the TC to work closely with debian-policy where
appropriate.

What are people's thoughts about this?

Will this approach work for the TC and policy editors?

Thanks for your consideration,

--Sam


signature.asc
Description: PGP signature