Re: Updating the Policy Editors delegation
On 07/02/14 at 12:35 +0100, Joerg Jaspert wrote:
> Am 07.02.2014 11:24, schrieb Lucas Nussbaum:
> >The Debian Policy team defines Debian's technical framework,
> >including
> >the structure and contents of the Debian archive
>
> So, the FTPTeam just got that ripped out of their gut.
> Which means we can stop doing NEW and in a slightly more extreme
> interpretation
> even stop all our cronjobs. We are no longer the ones doing the
> contents,
> so how could we accept anything?
>
> The part about the structure is also very debatable, this has also
> been a part
> of FTPMaster in the past. I can see a small point in sharing this
> with the team
> that writes down Policy, but thats a small one.
>
> I think someone here has not thought about this text.
Given the discussion that followed the previous delegation update, I
tried to make sure that this one wouldn't raise any concerns, so I
assure you that I thought about this text. :-)
Additionally, that text was sent for review to 8 people:
- Ian, as the one who raised the concerns about the previous version
- the Debian project secretary and his assistant
- the policy editors delegates
- Zack, as the DPL who wrote the previous version of the delegation
None of them had any concerns with the text.
But, since you think that this delegation can be interpreted as
conflicting with the ftpmasters delegation, let me clarify.
[ what follows might be too precise for a delegation text, the goal here
is to give an idea of the general spirit through some examples ]
Policy editors define Debian's technical framework, which is
documented in the Debian Policy Manual. That includes deciding on
things such as which archive areas (main, contrib, non-free) are
needed in the archive [that's *structure*], and define the general
rules about what goes in each section [that's *contents*]. They
also define the list of priorities (required, important, etc.)
[*structure*] and define the criteria for each priority
[*contents*].
Regarding sections (admin, text, python, etc.), they delegate
the decisions on maintaining the list of sections, and their
respective contents, to the archive maintainers (see Policy, 2.4).
FTP masters maintain the archive. They decide how files and
directories are organized on Debian archive repositories, provided
that this does not conflict with the general framework defined by the
Policy editors.
They also decide, for each package, whether the suggestion made by
the maintainer (on archive area, priority, section, etc.) is a
valid one, by implementing and interpreting what is defined by the
Policy Editors, and in the DFSG (e.g. what is acceptable in
main/contrib/non-free). They are also responsible for the general
consistency of the archive.
On 07/02/14 at 12:55 +0100, Ansgar Burchardt wrote:
> Besides the issue Joerg raised, do you change the Policy team's role
> from /documenting/ consensus (as mentioned in Policy 1.3) to actually
> /defining/ policy?
Yes. See the email from the Secretary on that issue [1]:
> This means that delegations should take care not to perscribe any
> particular process, or method for working that a delegate should adhere
> to. It is up to the delegate(s) to form a team and to produce a process
> themselves. It is, of course required as above that delegates should
> attempt to implement good technical decisions and/or follow consensus
> opinion.
[1] https://lists.debian.org/debian-project/2014/01/msg00054.html
If I delegate "defining policy" to the Policy Editors, I cannot at the
same time require that they will do that by following consensus, as that
would prescribe a particular process (8.2). However, as per constitution
8.3, Policy Editors "[..] should [...] follow consensus opinion."
More concretely, If they were considering changes that impact the work
of ftpmasters, it would expected from them to discuss those changes
beforehand with ftpmasters. Policy Editors have a track record of
seeking consensual positions, so I would be extremely surprised if they
did not do that.
There's also the question of the split of roles between the Policy
Editors and the Technical Committee:
The Policy Editors are in charge of the initial and detailed design of
the technical policy.
If there's disagreement, the issue can be brought to the technical
committee (which requires a simple majority to rule on technical
policy, see 6.1.1).
I would like to add something else:
I don't think that one should read delegations in search of loopholes that
would give some team more powers than what is generally understood.
Writing delegations that are at the same time not too prescriptive, and
descriptive enough, is already quite hard. It would be near-impossible to
write them as strict legal texts that avoid all loopholes, while still not making
them too prescriptive.
What matters is the general spirit. Requests for clarification are welcomed,
as well as, generally, talking with teams that are impacted or have an impact
on one's work.
Lucas
Reply to: