Re: Thinking about Delegating Decisions about Policy
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 <ijackson@chiark.greenend.org.uk> 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 to: