Re: Policy process
>>"Ian" == Ian Jackson <ian@davenant.greenend.org.uk> writes:
Ian> Jason Gunthorpe writes ("Re: Policy process"):
>> I also object, I find Manoj's argument about 20 some-odd policy jobs to be
>> a rather compelling reason to think this is a bad idea. .
Ian> You'll have to remind me. It's some time since we had this discussion
Ian> the first time round and your search term hasn't produced any hits in
Ian> my mental database of arguments on this subject :-).
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).
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:
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.
This is if we can even get this behemoth off the ground in the
first place. What do I mean by this?
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.
Lets examine this proposition in some detail, and see how it
stands up to a process of thinking it through.
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).
1) Emacs policy
2) X policy
3) Java
4) KDE/Gnome
5) SGML (we may have sgml tools and docbook peple taking action here)
6) XML (and yes, it does require a separarte section, despite the
naive supposition that XML is merely a SGML subsaet (which it
isn't, technically)
7) Security
8) LSB
9) IPv6
10) IPSEC (umm, on the merits, I do think the expertise may be
sufficiently different that security and IPv6 expoerts may not
suffice here; depends on the experts in the other areas)
11) Clustering
12) boot floppies
13) Quality assurance
14) web team
15) package pool, ftp, and archive policy, as it may impact how
packages are handled
16) autobuilders, make world process
17) HURD experts
18) Multimedia and convergence expets
19) ALPHA people
20) SPARC people
21) M68K people
22) IA64 people
23) Distributed and parrallel computing people
24) QoS people (this is a big one)
25) Debian for kids project
26) The Deian documentation team
27) The Debian translation follks
28) The internationalization effort
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.
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.
And if you have any ideas at all, and are not blueblooded
enough to belong to this elite aristocracy, you have to get the sign
off from the propah goldlet in the area your ideas happen to impinge
upon.
Frankly, I don't think this is possible.
Ian> Apart from the problems with the current process making mistakes (both
Ian> of commission like the `unplanned' FHS change and of omission like my
Ian> bug about .so files.),
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.
The problem is that the un-sexy bugs just slip off
peoples horizon; and something like a weekly report, especially on
that mentioned idle time, would entice people to make the extra
effort.
Look at how much response there is to the RC bug postings.
Ian> there is another serious problem which I hinted at in the other
Ian> discussion. At the moment this mailing list is hard to use
Ian> because it is full of administrivia.
Ian> I've now done a bit of research about this, prompted by the fact that
Ian> when I visited -policy in my newsreader today for the first time in a
Ian> few days there seemed to be very little of any use and a lot of noise.
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.
Until the DPL steps in and decides on the modus operandi, and
authorizes one or more people to break the deadlocks and sweep the
backlog into some kind of order, it would be folly to expect much of
a signal to noise ratio.
manoj
--
On soap operas all whites are in personal touch with (a) a doctor and
(b) a lawyer. -- James L. Davis
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: