Thinking about Delegating Decisions about Policy

Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Thinking about Delegating Decisions about Policy

Sam Hartman-3


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 (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thinking about Delegating Decisions about Policy

Bill Allombert-4
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 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.

Cheers,
--
Bill. <[hidden email]>

Imagine a large red swirl here.

Reply | Threaded
Open this post in threaded view
|

Re: Thinking about Delegating Decisions about Policy

Ansgar Burchardt-8
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

Reply | Threaded
Open this post in threaded view
|

Managing Frozen text when the TC Decides Policy

Sam Hartman-3
In reply to this post by Bill Allombert-4

I'm not really sure that the point you bring up is all that related to
the question I was asking.
But I think the point you bring up is important and I hope relatively
easy to solve, so let's discuss it and try to solve it.

>>>>> "Bill" == Bill Allombert <[hidden email]> writes:

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

Thanks for bringing this up.

I agree that it would generally be unfortunate if we had policy text
that could not be changed by the policy process.  I can see rare
situations where it might happen: we might have legal advice requiring
specific text be included in packages under certain circumstances.  And
in such a situation it might well be that we'd expect the policy editors
to go back and check with lawyers before changing that frozen text.

I hope we don't run into that situation with the TC very often, and
can't see a lot of reasons why we would if we handle things correctly.

I want to solve this because I think it would be very detrimental if our
policy documents didn't reflect technical policy of the project.  And If
we decide it's detrimental for the policy document to include technical
policy that the TC decides under section 6.1.1 of our constitution,
we're effectively saying that we don't want the TC to decide technical
policy.  I don't want a situation where people need to go look at the
policy document and then separately go look through all the TC
resolutions.

Now, some TC resolutions are quite specific to a specific package or
situation and aren't within the scope of policy.  Others aren't even
setting technical policy.  But when the TC sets technical policy that
packagers should know about, I want to see that reflected in our policy
documents so that our policy documents remain useful.

I agree with you having frozen text in policy documents is undesirable,
and unless there's a good reason to do so we should avoid it.

I think the policy editors could handle this by deciding amongst
themselves how they want to interact with the TC and then writing a note
to the TC along the following lines adapted based on what the policy
editors think the write answer is:

----------------------------------------

Dear Technical Committee:

We wanted to clarify how we  we handle situations where you exercise
your power to set technical policy under Constitution section 6.1.1 and
where that decision should be reflected in Debian Policy.

Often it will make sense for you to include a diff to Policy in your
decision.  We will apply that diff.  As with all contributions to free
software, we will continue to refine and improve the contribution over
time.  In other words, we assume your decision is the intent of the
policy, and your text is intended as your best attempt to reflect that
in our document at the time you make the decision.  If there's text that
you do not want refined, please call that out and if we have any
concerns about that we will raise that.

As part of our normal process of evaluating changes to Policy, we will
consider whether those changes are consistent with decisions of the TC
and whether we need to ask for an override.  If we think their might be
a perception of conflict we'll let the TC know or ask for a specific
decision depending on how likely we think it is there is a conflict.  If
you think we've introduced changes into Policy that conflict with TC
decisions please open a bug.

----------------------------------------
In pa
particular: I don't think the specific text that the TC proposes is
generally frozen.  I think that's rarely the TC's intent.  I also think
that because of the separation between policy editors and TC, it's not
really clear to me that the TC can freeze text in Policy even if they
can set technical text for the project.  Thy can set policy; they
probably help everyone out by showing how that would fit into our
current Policy document.  The editors need need to produce a Policy
document that is consistent with the technical policy established by the
TC.  Of course if the editors think they can't do that they can throw up
their hands and quit (or more constructively point out the problem to
the TC).

Even beyond that, TC decisions are made based on a lot of context.  I
don't think it always needs a TC override to actually go against the
decision if the context has changed enough.  Sometimes the TC is good
about specifying the limits of the context.  For example as I recall
they were debating what the default init system would be for a
particular release, not as standing policy.

But even if the TC is imprecise about context, it shouldn't require an
override if that context has changed enough.  As an example, I don't
think anyone needed to go back to the TC to ask about using
/usr/bin/node for nodejs.  Time had passed since the initial decision,
Nodejs had become a lot more popular, and the previous program went
away.  I don't think asking the TC was a bad idea, but I don't think it
was necessary.

Yes, you can abuse this.  If a maintainer were overridden, and a week
later reversed the TC's decision arguing that "a whole week had passed,"
that maintainer would not be acting in good faith.  The TC would
hopefully find that package needed a new maintainer very quickly and
da-manager might take notice.

If the same maintainer tried doing things the TC's way for a release and
found that it really didn't work out, well that would be different.
I'd say it would be good form to let the TC know before doing something
different.  But the context would have changed enough that I don't think
it would inherently require an override.

Basically be reasonable, let people who might have a concern know, and
explain yourself.  If you find that you're often too willing to revisit
TC decisions back off.

If we as a project find that you're not acting respecting the TC
process, we can warn you, ask you to involve co-maintainers, and
eventually can change maintainers of packages or ask the account
managers to get involved.
I think that's true for maintainers and for the policy editors.
Let's act in good faith and not make unnecessary process for ourselves.
When we are acting in good faith treat mistakes as bugs and go fix them.

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thinking about Delegating Decisions about Policy

Ian Jackson-2
In reply to this post by Sam Hartman-3
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/msg00005.html
[2] https://en.wikipedia.org/wiki/Ultra_vires

--
Ian Jackson <[hidden email]>   These 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.

Reply | Threaded
Open this post in threaded view
|

Re: Thinking about Delegating Decisions about Policy

Ian Jackson-2
In reply to this post by Sam Hartman-3
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 Jackson <[hidden email]>   These 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.

Reply | Threaded
Open this post in threaded view
|

Re: Thinking about Delegating Decisions about Policy

Sean Whitton
In reply to this post by Ian Jackson-2
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 (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thinking about Delegating Decisions about Policy

Sean Whitton
In reply to this post by Sam Hartman-3
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 (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Managing Frozen text when the TC Decides Policy

Sean Whitton
In reply to this post by Sam Hartman-3
Hello Sam,

On Sat 11 May 2019 at 01:24PM -04, Sam Hartman wrote:

> I agree that it would generally be unfortunate if we had policy text
> that could not be changed by the policy process.  I can see rare
> situations where it might happen: we might have legal advice requiring
> specific text be included in packages under certain circumstances.  And
> in such a situation it might well be that we'd expect the policy editors
> to go back and check with lawyers before changing that frozen text.

We actually already have this situation with several bits of text that
the Policy Editors don't consider ourselves able to edit without
ftpmaster approval.  See, for example, #904729 and #912581.

> I think the policy editors could handle this by deciding amongst
> themselves how they want to interact with the TC and then writing a note
> to the TC along the following lines adapted based on what the policy
> editors think the write answer is:

Thank you for taking the time to think about this carefully, but I would
like to suggest that we set is aside until and unless we have a concrete
situation in which the Policy Editors feel that we can't make a change
to the Policy Manual because of a particular T.C. decision.

It's very complicated and time-consuming to discuss in the abstract, and
it has not actually been a problem in at least the last two to three
years.

--
Sean Whitton

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thinking about Delegating Decisions about Policy

Ian Jackson-2
In reply to this post by Sean Whitton
Sean Whitton writes ("Re: Thinking about Delegating Decisions about Policy"):
> 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.

Uploads are a rather blunt instrument for communication :-).

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

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

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.

Ian.

--
Ian Jackson <[hidden email]>   These 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.

Reply | Threaded
Open this post in threaded view
|

Re: Managing Frozen text when the TC Decides Policy

Sam Hartman-3
In reply to this post by Sean Whitton
>>>>> "Sean" == Sean Whitton <[hidden email]> writes:

    Sean> Hello Sam,
    Sean> On Sat 11 May 2019 at 01:24PM -04, Sam Hartman wrote:

    >> I agree that it would generally be unfortunate if we had policy
    >> text that could not be changed by the policy process.  I can see
    >> rare situations where it might happen: we might have legal advice
    >> requiring specific text be included in packages under certain
    >> circumstances.  And in such a situation it might well be that
    >> we'd expect the policy editors to go back and check with lawyers
    >> before changing that frozen text.

    Sean> We actually already have this situation with several bits of
    Sean> text that the Policy Editors don't consider ourselves able to
    Sean> edit without ftpmaster approval.  See, for example, #904729
    Sean> and #912581.

These cases look like cases where you have frozen requirements not
frozen text.  That is, it doesn't look like you'd have any trouble
rewording the requirements, but that when you are documenting archive
acceptance criteria, you must be consistent with ftpmaster.

That makes a lot of sense.

    >> I think the policy editors could handle this by deciding amongst
    >> themselves how they want to interact with the TC and then writing
    >> a note to the TC along the following lines adapted based on what
    >> the policy editors think the write answer is:

    Sean> Thank you for taking the time to think about this carefully,
    Sean> but I would like to suggest that we set is aside until and
    Sean> unless we have a concrete situation in which the Policy
    Sean> Editors feel that we can't make a change to the Policy Manual
    Sean> because of a particular T.C. decision.

Well, we have a situation now where a member of our community (Bill) is
uncomfortable with the TC being asked to take on one of the tasks that
our constitution lets the TC take on.
I think that concern is something that we should address now since it
has arisen.

If you as policy editors think that you can reassure Bill and tell him
that you believe you could work with the TC were that situation to come
up, then I think you could adress Bill's concern now without addressing
specifics.

Right now we have a situation where someone is concerned that one part
of Debian could not work with another.
I'd like to get that cleared up.  If the policy editors are confident
that they can defer things, I think that would be a fine solution.


--Sam

Reply | Threaded
Open this post in threaded view
|

Re: Thinking about Delegating Decisions about Policy

Sam Hartman-3
In reply to this post by Sean Whitton
>>>>> "Sean" == Sean Whitton <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Managing Frozen text when the TC Decides Policy

Sean Whitton
In reply to this post by Sam Hartman-3
Hello,

On Sun 19 May 2019 at 09:14am -0400, Sam Hartman wrote:

>     >> I think the policy editors could handle this by deciding amongst
>     >> themselves how they want to interact with the TC and then writing
>     >> a note to the TC along the following lines adapted based on what
>     >> the policy editors think the write answer is:
>
>     Sean> Thank you for taking the time to think about this carefully,
>     Sean> but I would like to suggest that we set is aside until and
>     Sean> unless we have a concrete situation in which the Policy
>     Sean> Editors feel that we can't make a change to the Policy Manual
>     Sean> because of a particular T.C. decision.
>
> Well, we have a situation now where a member of our community (Bill) is
> uncomfortable with the TC being asked to take on one of the tasks that
> our constitution lets the TC take on.
> I think that concern is something that we should address now since it
> has arisen.
>
> If you as policy editors think that you can reassure Bill and tell him
> that you believe you could work with the TC were that situation to come
> up, then I think you could adress Bill's concern now without addressing
> specifics.
>
> Right now we have a situation where someone is concerned that one part
> of Debian could not work with another.
> I'd like to get that cleared up.  If the policy editors are confident
> that they can defer things, I think that would be a fine solution.
I'm sorry that I wasn't able to reply to this sooner.

I feel able to reassure everyone that, indeed, the Policy Editors would
be able to work with the T.C. to avoid the sort of situation Bill is
worried about.

When I took on the role of Policy Editor I subscribed myself to the
T.C.'s mailing list.  I consider it part of the role to keep abreast of
their activities.  In light of the present thread, I'll keep in mind the
need to flag to the T.C. places where decisions they are about to take
might have an impact on the practicalities of the Policy Changes
Process, such as the issue of frozen text.

--
Sean Whitton

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Sean Whitton
In reply to this post by Ian Jackson-2
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
before committing a change, thinking "maybe we should give people more
time to raise issues with this change", and this would avoid that sort
of situation.

--
Sean Whitton

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thinking about Delegating Decisions about Policy

Margarita Manterola-4
In reply to this post by Sam Hartman-3
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)

Reply | Threaded
Open this post in threaded view
|

Re: Thinking about Delegating Decisions about Policy

Guillem Jover
In reply to this post by Ian Jackson-2
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] <https://lists.debian.org/debian-policy/2018/08/msg00083.html>

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

Reply | Threaded
Open this post in threaded view
|

Re: Thinking about Delegating Decisions about Policy

Margarita Manterola-4
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

Reply | Threaded
Open this post in threaded view
|

Re: Thinking about Delegating Decisions about Policy

Wouter Verhelst
In reply to this post by Guillem Jover
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

Reply | Threaded
Open this post in threaded view
|

Re: Thinking about Delegating Decisions about Policy

Bill Allombert-4
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. <[hidden email]>

Imagine a large red swirl here.

Reply | Threaded
Open this post in threaded view
|

Re: Thinking about Delegating Decisions about Policy

Didier 'OdyX' Raboud-5
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.fjZomKJQ8B@...
[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 (673 bytes) Download Attachment
12