[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Thinking about Delegating Decisions about Policy



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 made by the TC, because this leads to a situation
where some policy text is frozen because the policy editors cannot change
it without potentially overriding the TC.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 


Reply to: