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