Re: Updating the Policy Editors delegation
On Sun, Jan 12, 2014 at 02:56:10PM +0900, Charles Plessy wrote:
> Le Sat, Jan 11, 2014 at 05:22:01PM +0100, Secretary - Kurt Roeckx a écrit :
> > On Wed, Jan 08, 2014 at 12:10:08PM +0000, Neil McGovern wrote:
> > As there has been no comments on the draft text I'll make that
> > the official response. I want to thank Neil from writing this
> > all down.
> Hi Kurt and Niel,
> thank you for the prompt in-depth analysis that you gave us.
> I was slow to react because I was puzzled by the discussion (why trying to
> change a delegation text that the delegates themselves agree with ?) and wanted
> to give to others the opportunity to express positive opinions first, before
> coming with my criticism.
> It think that it would have been fair to either set upfront a deadline for
> answering, or make a last call for comments. Also, less than a week (not even
> including a week-end) is quite a short delay.
In my opinion we had a long discussion about this. I don't see
why we should even have published a draft in the first place.
> > > * Debian policy editors are a delegatable position by the DPL, but only
> > > if the DPL wishes to delegate the power to *set* policy, rather than to
> > > simply document current practice.
> I do not see a difference between documenting current practice and setting the
> policy, because in many cases it is unclear what the current practice is, and
> somebody needs the final call on this, similar to the role of the Secretary for
> interpreting the Constitution.
The key here is who is responsibile (for what). See the previous 2 points.
> The Debian Policy Editors:
> - Guide the work on the Debian Policy Manual and related documents as a
> collaborative process where developers review and second or object to
> proposals, usually on the debian-policy mailing list .
> : https://lists.debian.org/debian-policy/
> - Count seconds and weight objections to proposals, to determine whether
> they have reached sufficient consensus to be included, and accept
> consensual proposals.
> - Reject or refer to the Technical Committee proposals that fail to
> reach consensus.
> - Commit changes to the version control system repository used to
> maintain the Debian Policy Manual and related documents.
> - Maintain the "debian-policy" package. As package maintainers, they
> have the last word on package content, releases, bug reports, etc.
> Here are my interpretations point by point.
> Disclaimer: based on material posted earlier on mailing lists and the wiki, I
> wrote the text of the delegation.
> 1) The possibility of editing the Policy out of a collaborative process is not
> delegated. This does not say how the Editors should decide within a
> collaborative process, it only says that changes decided in closed comittee are
> not in the scope of the delegation. The link to the mailing list might be
> removed, however, for newcomers I find it more useful than harmful.
"Delegates may make decisions as they see fit". This means that
any delegate can make any decisions without the need for anybody
else to be involved or to follow a process. The DPL can not say
which process you should follow.
But the delegates themself can of course decide which process to
> 2) "Count seconds" could be removed indeed, to allow the Editors to accept
> a proposal that did not attract enough attention, but that they estimate
> consensual. The whole paragraph could also be removed, on the grounds that
> it is redundant with the Constitution's section 8.3 asking to the delegates
> to seek concensus. But on the other hand, because it is redundant, I think
> that it can not be anticonstitutional.
This is yet again a process.
> 3) is indeed redundant with the section 6.3.6 of our Constitution. Maybe we
> should point to this section instead or even quote it.
> 4) and 5) may be too obvious as well, but I like the idea that, on top of
> making decisions, the Editors are also expected to do some more trivial work
> regarding formatting documents and commiting changes, therefore I think that
> these paragraphs, which do not restrict how decisions are taken, are useful.
You can agrue that 4) and 5) fall under 3.1.1.
The delegation should only cover responsibilities and decisions.