>>>>> "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