Re: Managing Frozen text when the TC Decides Policy
Hello Sam, On Sat 11 May 2019 at 01:24PM -04, Sam Hartman wrote: > I agree that it would generally be unfortunate if we had policy text > that could not be changed by the policy process. I can see rare > situations where it might happen: we might have legal advice requiring > specific text be included in packages under certain circumstances. And > in such a situation it might well be that we'd expect the policy editors > to go back and check with lawyers before changing that frozen text. We actually already have this situation with several bits of text that the Policy Editors don't consider ourselves able to edit without ftpmaster approval. See, for example, #904729 and #912581. > I think the policy editors could handle this by deciding amongst > themselves how they want to interact with the TC and then writing a note > to the TC along the following lines adapted based on what the policy > editors think the write answer is: Thank you for taking the time to think about this carefully, but I would like to suggest that we set is aside until and unless we have a concrete situation in which the Policy Editors feel that we can't make a change to the Policy Manual because of a particular T.C. decision. It's very complicated and time-consuming to discuss in the abstract, and it has not actually been a problem in at least the last two to three years. -- Sean Whitton signature.asc Description: PGP signature
Re: Thinking about Delegating Decisions about Policy
Hello Sam, On Fri 10 May 2019 at 03:57PM -04, Sam Hartman wrote: > What are people's thoughts about this? > > Will this approach work for the TC and policy editors? I think that the concrete suggestion you're making is that when a question that comes before the T.C. is something that could be solved by patching the Policy Manual, the T.C. should respond to the question by opening a bug against the Policy Manual, and suspending the T.C. bug until it becomes clear whether or not that debian-policy bug is going to reach consensus? -- Sean Whitton signature.asc Description: PGP signature
Re: Thinking about Delegating Decisions about Policy
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 signature.asc Description: PGP signature
Re: Bits from the DPL (April 2019)
Hello Russ, On Mon 13 May 2019 at 08:40PM -07, Russ Allbery wrote: > That said, just as a matter of style and usability, we should describe the > common case first and make it clear that one doesn't have to open up the > details unless something isn't working right. > > [...] > > The path that, to me, navigates out of that difficulty is to focus on > Policy's role as an instruction manual. Rather than thinking of Policy as > a comprehensive description of one layer of the packaging ecosystem, we > can instead switch (and it is a switch -- this isn't what we've done in > the past) to thinking of Policy as a technical instruction manual for > packagers. And like a good instruction manual, it can document both the > common path for most people, and then have an "advanced usage" section > that digs into the details for special cases or difficult problems. > > The larger problem here, and what I think is a bit of the elephant in the > room, is that doing all of that requires resources, specifically time and > energy to do all the necessary writing and editing. Which we're > chronically short on. I don't think the outlook is so bleak, because I think that something like this can be implemented incrementally. Sections can be gradually rewritten so that the common case is described first, where it's not already, and people writing new sections can have "this is meant to be an instruction manual" in mind as they write. In short, large restructuring does not seem necessary in order to implement what you describe. -- Sean Whitton signature.asc Description: PGP signature
Bug#910783: Remove doc-base recommendation
On Wed, May 15, 2019 at 09:07:53AM +0200, Ansgar Burchardt wrote: > > We need a cross-distro cross-desktop standard for an index of > > docs before we can move on from doc-base like we did with menu. > I don't think so: we can just remove doc-base without providing a > replacement at the same time too. > > Personally I don't know anyone using doc-base (probably most don't even > know it exists). If doc-base has indeed no users (or very few users), > it just creates work for maintainers for no real benefit. > > As [1] says, doc-base had 20+ years to get adopted. I think it is fair > to say that it failed to do so. fully agreed. (and as said previously in this bug, I still have no idea how to make use of doc-base...) -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#910783: Remove doc-base recommendation
Paul Wise writes: > On Thu, 11 Oct 2018 17:32:52 -0700 Sean Whitton wrote: >> Instead, if there is indeed consensus, we should change it so that it >> no longer says that doc-base registration is recommended. > > We need a cross-distro cross-desktop standard for an index of > docs before we can move on from doc-base like we did with menu. I don't think so: we can just remove doc-base without providing a replacement at the same time too. Personally I don't know anyone using doc-base (probably most don't even know it exists). If doc-base has indeed no users (or very few users), it just creates work for maintainers for no real benefit. As [1] says, doc-base had 20+ years to get adopted. I think it is fair to say that it failed to do so. [1] https://bugs.debian.org/910783#13 Ansgar
