Re: Managing Frozen text when the TC Decides Policy
Hello, On Sun 19 May 2019 at 09:14am -0400, Sam Hartman wrote: > >> 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: > > Sean> Thank you for taking the time to think about this carefully, > Sean> but I would like to suggest that we set is aside until and > Sean> unless we have a concrete situation in which the Policy > Sean> Editors feel that we can't make a change to the Policy Manual > Sean> because of a particular T.C. decision. > > Well, we have a situation now where a member of our community (Bill) is > uncomfortable with the TC being asked to take on one of the tasks that > our constitution lets the TC take on. > I think that concern is something that we should address now since it > has arisen. > > If you as policy editors think that you can reassure Bill and tell him > that you believe you could work with the TC were that situation to come > up, then I think you could adress Bill's concern now without addressing > specifics. > > Right now we have a situation where someone is concerned that one part > of Debian could not work with another. > I'd like to get that cleared up. If the policy editors are confident > that they can defer things, I think that would be a fine solution. I'm sorry that I wasn't able to reply to this sooner. I feel able to reassure everyone that, indeed, the Policy Editors would be able to work with the T.C. to avoid the sort of situation Bill is worried about. When I took on the role of Policy Editor I subscribed myself to the T.C.'s mailing list. I consider it part of the role to keep abreast of their activities. In light of the present thread, I'll keep in mind the need to flag to the T.C. places where decisions they are about to take might have an impact on the practicalities of the Policy Changes Process, such as the issue of frozen text. -- Sean Whitton signature.asc Description: PGP signature
Re: Managing Frozen text when the TC Decides Policy
> "Sean" == Sean Whitton writes: Sean> Hello Sam, Sean> 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. Sean> We actually already have this situation with several bits of Sean> text that the Policy Editors don't consider ourselves able to Sean> edit without ftpmaster approval. See, for example, #904729 Sean> and #912581. These cases look like cases where you have frozen requirements not frozen text. That is, it doesn't look like you'd have any trouble rewording the requirements, but that when you are documenting archive acceptance criteria, you must be consistent with ftpmaster. That makes a lot of sense. >> 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: Sean> Thank you for taking the time to think about this carefully, Sean> but I would like to suggest that we set is aside until and Sean> unless we have a concrete situation in which the Policy Sean> Editors feel that we can't make a change to the Policy Manual Sean> because of a particular T.C. decision. Well, we have a situation now where a member of our community (Bill) is uncomfortable with the TC being asked to take on one of the tasks that our constitution lets the TC take on. I think that concern is something that we should address now since it has arisen. If you as policy editors think that you can reassure Bill and tell him that you believe you could work with the TC were that situation to come up, then I think you could adress Bill's concern now without addressing specifics. Right now we have a situation where someone is concerned that one part of Debian could not work with another. I'd like to get that cleared up. If the policy editors are confident that they can defer things, I think that would be a fine solution. --Sam
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
Managing Frozen text when the TC Decides Policy
I'm not really sure that the point you bring up is all that related to the question I was asking. But I think the point you bring up is important and I hope relatively easy to solve, so let's discuss it and try to solve it. > "Bill" == Bill Allombert writes: Bill> In my view it is detrimental for the policy proces for the Bill> Debian policy to include decisions made by the TC, because Bill> this leads to a situation where some policy text is frozen Bill> because the policy editors cannot change it without Bill> potentially overriding the TC. Thanks for bringing this up. 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. I hope we don't run into that situation with the TC very often, and can't see a lot of reasons why we would if we handle things correctly. I want to solve this because I think it would be very detrimental if our policy documents didn't reflect technical policy of the project. And If we decide it's detrimental for the policy document to include technical policy that the TC decides under section 6.1.1 of our constitution, we're effectively saying that we don't want the TC to decide technical policy. I don't want a situation where people need to go look at the policy document and then separately go look through all the TC resolutions. Now, some TC resolutions are quite specific to a specific package or situation and aren't within the scope of policy. Others aren't even setting technical policy. But when the TC sets technical policy that packagers should know about, I want to see that reflected in our policy documents so that our policy documents remain useful. I agree with you having frozen text in policy documents is undesirable, and unless there's a good reason to do so we should avoid it. 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: Dear Technical Committee: We wanted to clarify how we we handle situations where you exercise your power to set technical policy under Constitution section 6.1.1 and where that decision should be reflected in Debian Policy. Often it will make sense for you to include a diff to Policy in your decision. We will apply that diff. As with all contributions to free software, we will continue to refine and improve the contribution over time. In other words, we assume your decision is the intent of the policy, and your text is intended as your best attempt to reflect that in our document at the time you make the decision. If there's text that you do not want refined, please call that out and if we have any concerns about that we will raise that. As part of our normal process of evaluating changes to Policy, we will consider whether those changes are consistent with decisions of the TC and whether we need to ask for an override. If we think their might be a perception of conflict we'll let the TC know or ask for a specific decision depending on how likely we think it is there is a conflict. If you think we've introduced changes into Policy that conflict with TC decisions please open a bug. In pa particular: I don't think the specific text that the TC proposes is generally frozen. I think that's rarely the TC's intent. I also think that because of the separation between policy editors and TC, it's not really clear to me that the TC can freeze text in Policy even if they can set technical text for the project. Thy can set policy; they probably help everyone out by showing how that would fit into our current Policy document. The editors need need to produce a Policy document that is consistent with the technical policy established by the TC. Of course if the editors think they can't do that they can throw up their hands and quit (or more constructively point out the problem to the TC). Even beyond that, TC decisions are made based on a lot of context. I don't think it always needs a TC override to actually go against the decision if the context has changed enough. Sometimes the TC is good about specifying the limits of the context. For example as I recall they were debating what the default init system would be for a particular release, not as standing policy. But even if the TC is imprecise about context, it shouldn't require an override if that context has changed enough. As an example, I don't think anyone needed to go back to the TC to ask about using /usr/bin/node for
