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