On Fri, May 10, 2019 at 03:57:52PM -0400, Sam Hartman wrote:
> In my platform, one of the things I focused on is trying to drive the
> decision process forward.
>
> I imagine it won't be uncommon to get to a point where the right next
> step is to develop technical or non-technical policy about something.
>
> I'd like to focus in this message about what I as DPL do when I believe
> we need to develop technical policy about some issue. Typically this
> will be after we'd had some project discussion and hopefully reached
> some degree of consensus on the driving principles/overall approach for
> the project.
>
> Examples of the sorts of things I'm talking about would include
> potential policy on use of dh after a discussion about our direction
> there.
>
> It seems that we have two overlapping groups that might be involved: the
> policy editors (and more generally the consensus policy process) and the
> Technical Committee.
>
> Here's how as DPL I see things today. I'm very open to changing my
> mind, and this is very much just a starting position.
>
> first, I've read
> https://lists.debian.org/debian-project/2014/01/msg00044.html
>
> I agree that the policy process can be delegated to the policy editors
> by that mechanism and have no desire to change how policy works or
> change the policy editors or anything like that. I wouldn't mind seeing
> the TC and policy editors work more closely together, and perhaps my
> thoughts in this area are influenced by that.
>
> That said, ultimately, I think the Technical Committee is the authority
> on what our technical policy is under constitution section 6.1.1.
>
> 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.
>
> But at least under the current process, the policy editors cannot just
> use their personal judgment to decide what policy is absent a consensus.
>
>
> In contrast, while the TC cannot develop solutions, they can establish
> policy using the collective judgment of the committee.
> There's obviously some ambiguity in what it means to develop solutions
> vs refining/wordsmithing proposals.
>
> So, if I want to delegate deciding on a policy, who should I send it to?
>
> My preference is to always send it to the TC. But there's a big caveat
> that I'll get to in a moment.
>
> Why the TC?
> A couple of reasons.
>
> Ultimately they are the ones who can decide.
> If things get stuck, they are in a position to make a decision.
>
> The constitution makes it easy for the DPL to delegate almost anything
> to the TC.
>
> Once a specific decision is delegated, removing that delegation can be
> thorny. I think procedurally it's OK to remove a delegation because the
> decision is stuck or no progress is being made. However distinguishing
> that from a situation where the delegate is making a decision (which
> cannot be overturned by the DPL) can be thorny.
>
> By delegating to the TC (and getting the TC to agree to accept a
> delegated decision) I'm asking them to take ownership. Once we agree
> that they are handling it, we have agreement that the issue is important
> enough to move forward.
>
> But, and here's the caveat I talked about. I think a reasonable way for
> the TC to move forward on most issues I might bring to them is to give
> the normal policy process including the policy editors a chance to come
> to consensus.
> "Ask someone else" is sometimes a great way to make something happen.
>
> I think the TC procedurally could involve debian-policy for most policy
> questions that come to them. I think that it typically doesn't make
> sense. In a lot of cases it's clear that the normal policy process
> isn't going to reach a consensus. In cases where the normal policy
> process hasn't been tried it might simply be reasonable for the TC to
> decline to take up the issue until that has been tried. But I can
> imagine other cases where the approach I'm proposing would be
> appropriate.
>
> Of course the TC could turn around and tell me that I should try the
> normal policy process first. And if I do a bad job of identifying
> issues that are important to the project or a bad job of guiding the
> initial discussion, probably they should. My hope is that if as DPL I
> bring an issue that's actually important to the project to the TC, they
> would be willing to track it, help me make sure we're making forward
> progress, even if the first (and perhaps only) step is to build
> consensus within debian-policy.
>
> In effect, I'm asking the TC to help things move smoothly forward and to
> become more involved if that becomes necessary.
> I'm also asking the TC to work closely with debian-policy where
> appropriate.
>
> What are people's thoughts about this?
>
> Will this approach work for the TC and policy editors?
In my view it is detrimental for the policy proces for the Debian policy
to include decisions