Hi,
>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> Could you expand on this a bit?
I'll treat this point by point.
Raul> That means to me that the proposal document ought to be talking
Raul> about
Raul> (a) documenting existing practice, and
The proposal document not only documents existing practice,
but shall be modified to detail new mothodologies and protocols as
and when they are decided, whether or not they have been in practice
prior to that ppoint or not.
Raul> (b) getting approval from relevant package developers, and
This, I believe, is the crux of my obje3ction. If we have to
get all developers to buy in whose packages may be affected, we can
never make policy that affects very many packages. And even one
developer objects, we have to rely on the tech committee, and, quite
frankly, I do not have that level of trust in that small a group of
people who are not quite accountable to any on (and half of whom seem
to have no interest in the proceedings).
Raul> (c) getting the technical committee to approve (or disapprove) a
Raul> completed proposal, and
Why do we need instructions on doing this? The proposal
document is a guidelines to how this group operates. If the tech
committee has protocols that need be followed, it should come up with
a document detailing those protocols.
They certainly do not belong in policy group guidelines.
Raul> (d) getting the developers as a whole to overturn a technical committee
Raul> decision.
Again, why do we need instructions for that in thet policy
guidelines? People can just send a mail message (possibly to -devel,
or to -ctte, and register their objections. At any rate, this has
nothing to do with this group, and the guidelines.
Raul> Reading the proposal document, I'm guessing that you're saying that
Raul> point (a) is too narrow, or you're objecting to the idea that point (b)
Raul> is important. [You can't be objecting to point c -- that's already in
Raul> the proposal document. Though perhaps you have a different definition of
Raul> "contentious" than I do. And given what little you've expressed here
Raul> I don't think you're objecting to point (d).]
I am objecting to all these things being in the policy group
guidelines.
We ahve a working, (though not complete or perfect) set of
informal guidelines. They do work for us. I see no need to bloat it
with irrelevant things, or to formalize and make the document heavy
weight.
Frankly, I see any further hardening of the guidelines, and
pulling in extraneous things as unnecesary red tape.
You may argue that the -policy group has no power to change
policy under the constituion. If so, we should get the DPL to
delegate some authority to this group, or add powers in a
constitutionsl amendment.
Emasculating this mailing list down to the powers of
an individual developer would, in my opinion, be detrimental to the
project. I think we do need an open policy crafting arm to the
project. This group has been functioning fairly well as that so far
(and we need to ensure that the glitch that caused the committee to
be called in not happen again -- we need to work out the formal
objection clause).
manoj
--
We all agree on the necessity of compromise. We just can't agree on
when it's necessary to compromise. Larry Wall
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
