Re: Managing Frozen text when the TC Decides Policy

2019-06-23 Thread Sean Whitton
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

2019-05-19 Thread Sam Hartman
> "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

2019-05-15 Thread Sean Whitton
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