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.