>>>>> "Kurt" == Kurt Roeckx <kurt@roeckx.be> writes:
Kurt> On Sat, Nov 16, 2019 at 11:35:27AM -0500, Sam Hartman wrote:
>>
>> The secretary requested that I have each choice be
>> self-contained. So I'm folding the header into each choice.
>>
>> The line of dashes separates each choice. I formally propose
>> these general resolution options.
Kurt> Can you please clarify with which had you're doing this. I
Kurt> think you intended to do this as DPL, but you used your
Kurt> hartmans@debian.org email address.
I'm doing this as DPL. I've spent a lot of time trying to facilitate an
understanding in this space. It became clear based on policy editor
comments and based on the patterns of behavior I've seen that we're not
going to easily come to consensus on this issue, and that the project
would be better off if we had a decision.
So, as DPL, I've introduced a GR to try and facilitate that decision.
Thus, I consider it reasonable to introduce the GR with the DPL hat on.
You made several comments that you thought it sounded like the GR was
overriding a delegate or was setting policy. No. If one of these
options passes, the project is describing what it wants at this point in
time. Just as a debian-devel discussion has no formal power, this GR
will not have formal power. However, section 8.2 of the constitution
says that delegates including the policy editors, and the release team
are supposed to take into account consensus of the project and project discussions.
Similarly, the DPL has responsibilities to listen to the project.
I have high confidence that a decision in this space will give the
policy editors the tools they need to break the consensus deadlock
without having to resort to overriding them or setting policy as a
project. That is, in this case, a non-binding statement that we know
the project supports will be sufficient to unblock things. So I've
proposed several such non-binding statements that the project could
make.
An informal statement is better anyway. If the policy editors run into
some problem implementing this, they can come back to the project
Likely we'll be able to get consensus on a way forward without resorting
to another GR.
If we set policy here, then we run the risk of denying our delegates
flexibility to handle things they find moving forward.
We probably could craft a resolution to avoid that risk.
It is far easier to simply let the delegates know what the project wants
in a non-binding way. If that ends up not being sufficient, we have
several tools available to us later including revising delegations or
future GRs.
I also don't think it is appropriate to consider something overriding a
delegate unless it is overiding a specific decision of a delegate.
I think it is entirely reasonable to have delegations with overlapping
responsibility or to propose delegating a specific decision to a group
different than a group that might handle general issues in that space.
That's not what I'm proposing here.
Attachment:
signature.asc
Description: PGP signature