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
Attachment:
signature.asc
Description: PGP signature