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

Re: Policy process

Manoj Srivastava writes ("Re: Policy process"):
>  Hmm. I'll reiterate: I find your proposal very cathedral in nature;
>  indeed, I found it quite fuedalistic. And it is a sizeable increase
>  in bureaucratic hassles:
>          Each document, or part of a document, has one or more editors
>          within that maintainer team.  Only the editor(s) responsible
>          for a particular area should check in changes to that
>          section, and then only when rough consensus has been achieved
>          (see below).

Most of the time this is simply the people who have CVS commit access.

>  And, how about:
>           Standards should only be promulgated after at least rough
>           consensus has been achieved on debian-standards.  The
>           relevant standards editor should announce their intention to
>           make the change and then wait at least a week for objections
>           to be heard.
>  So now we are potentially dependent on any of about 50 odd people to
>  be around in order to edit policy. And this is enough people to lead
>  to yet another layer of disputes: 

The whole point is to prevent changes being made without an
appropriate expert agreeing.  I know you don't approve of the idea of
having experts on things, but Debian is run that way - that's why we
have package maintainers.

What I'm trying to do is make policy documents back into ordinary
packages, with just a bit of stuff to make sure there's some
consultation and a lightweight dispute mechanism.

>           In cases of dispute about who should edit a standard the
>           Project Leader will decide.  The Leader should appoint
>           additional editors for a particular standard, or remove or
>           replace editors, whenever this would benefit the project as
>           a whole.

I think that in practice this will happen rarely.  I just put it there
to make sure that the Leader doesn't feel inhibited.

In fact what will usually happen is that policy editorships will be
passed around as normal packages.

>         First, we have to figure out who is smart, and who is an
>  expert, Secondly, looking at what policy covers, there is no such
>  thing as an expert, there are experts in areas. Thridly, you have to
>  convince a growing volunteer body that the smart and expert person is
>  actually a) smart, and b) an expert on the current subject.

Without experts we are sunk.

>         Let us examine the areas in which expertise is not quite
>  common, and these areas may well see explosive growth in the next five
>  years, and may require policy decisions (I'm not even touching the
>  more esoteric areas like embedded Debian).
[list of 28 areas]
>         And probably other whole areas I have missed.
>         Now, we need to identify at least two experts in each area,
>  and name them policy sub czars, or, shall we say, policy Dukes. And
>  also a policy Baron for backup.

No, we just make (eg) the SGML policy be part of the sgml-base package
and edited by the sgml-base maintainer.  This is ultra lightweight.

We don't need to identify these people - they by and large already
exist.  They wrote the policy documents and are distributing them, but
they daren't call them Policy with a capital P or the whole thing will
be swallowed by the current awful process.

>         The the DPL or the Czar -- or perhaps a grand policy vizier --
>  has to keep tabs on all the people, making sure they are alert and
>  responsive, and competent, and replace them as needed (man -- talk
>  about bureaucracy). We already are at 54 people -- and probably more
>  named people, as other areas come into our view.

These people don't have to be mentioned in a centrally maintained
list, and there's no problem identifying them - the document will say
who they are if they aren't simply the maintainer of the relevant

>       Indeed, these are problems in the way we had of doing things. We
>  do need a chairman(chairpeople?) to address some of the issues that
>  Ian has raised:
>         a) Have delegated power from the Project leader to over ride
>            the ``clueless'' objections
>         b) Move stalled discussions along by breaking deadlocks,
>         c) create a periodic report of the state of the policy to keep
>            interest alive. 
>         d) Sweep through the so called unsexy proposals.

This still wouldn't help with eg the FHS problem.  We mustn't allow
such a grievous mistake to be made again, if we can help it.

>       Of course, the real reason is that this list is dormant at the
>  moment; I am surprised that any real work at all is being done here.


Reply to: