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
package.
> 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.
Ian.
Reply to: