Hi,
>>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
Ian> Manoj Srivastava writes ("Re: Bug#30036: debian-policy could include
emacs policy"):
>> Hi,
>> >>"Adam" == Adam Di Carlo <[EMAIL PROTECTED]> writes:
>>
Adam> I still don't really understand what is intended by moving
Adam> sub-policies into the policy manual. Is it intended that the Debian
Adam> Policy group take editorial control over the documents?
>>
>> Yes. If it is important enough to be policy, it needs to come
>> under more democratic and open control.
Ian> I think this is an absolutely dreadful idea.
And I think this is a mostly content-free knee jerk reaction
to the word ``democratic''. Even then, I think this is untenable.
Even technical issues are better not decided by fiat by an individual
-- unless they are very simple. Individuals are fallible. Faced with
complex issues, individuals may fail to consider all possible
ramifications and effects (perhaps for configurations different from
their own).
Even our tech committee is a committee -- we do not have a
tech czar, and this by itself is acknowledgement of the underlying
fallibility of individuals.
All major standards are formed by a technical stanards
committee -- and that includes RFC's, and the protocols that the
internet is set up on.
Ian> Technical decisions should be made by the relevant experts, according
Ian> to their own views, and matching the code that they have written or
Ian> plan to write.
Then think of the -policy group as being composed of experts,
and experts in training, and systems integration and Debian are their
areas of expertize.
I also think that policy should not be dictated by any author
of a software package. The project should be free to decide on a
technical policy on the merits of the policy, and be free to
commision other people to write software meeting the reuirements, or
at least freeze to a version ofsoftwarte that is acceptable until a
replacement that follows policy is found.
Incidentally, my proposal would indeed vest powers with the
authors in the initial design and implementation phase, when the code
is fluid, and rapid and drastic changes are often required. However,
when the alpha phase ends, and the software reaches matrity, and
indeed, is supposed to be implementing an aspect of Debian policy,
policy that other people depend on, I think that
Ian> So, in this example, the menu policy should remain with the menu
Ian> package.
So how do we decide non-technical policy? Does the project
leader dictate by fiat? Does the much vaunted tech committee dictate
by fiat? Do we let policy be dictated by whoever writes the software?
Ian> If someone feels is some problem with them menu policy and they and
Ian> the menu maintainer cannot agree then the Technical Committee will
Ian> decide.
This is not something I would accept being dictated to me by
the project leader, and/or the cohorts, the technical committee. The
project is no longer a cosy old boys network -- we have grown beyond
that, to a point that we need broader mechanisms of coming to an
agreement, with built in deadlock resolution.
I reject the theseis that the technical committee can indeed
vote on policy issues (and believe me, consensus there may be harder
to achieve than one thinks), and this grioup can not.
Even technical issues are better not decided by fiat by an
individual -- unless they are very simple. Individuals are
fallible. Faced with complex issues, individuals may fail to consider
all possible ramifications and effects (perhaps for configurations
different from their own).
Even our tech committee is a committee -- we do not have a
tech czar, and this by itself is acknowledgement of the underlying
fallibility of individuals.
All major standards are formed by a technical stanards
committee -- and that includes RFC's, and the protocols that the
internet is set up on.
I am aware of the proposals of the mythical man month
(remember, they were proposed when editors, and even OS's, routinely
fitted in 64KB, and gargantuan software projects, with the associated
complexity, were mostly in the future). Even projects begun by highly
technical individuals have now been turned over to larger groups for
polishing and maintainence (take the languages C, C++, et al).
Ian> Technical decisions must not be left to democracy.
I am sure the ISO committee voting on C++ standardization
shall be amused by this.
Though I reject the hypothess that policy be formed by fiat, I
also acknowledge the requirement for ensuring that common sense
prevails -- I think that the mechanisms now in place in the
constituiotn and the policy formulation mechanisms allow for input
from a larger body while still preventing the hijacking of the
process by uninformed individuals.
My thesis is that we have to find a balance between fiat and
rule of the mob -- I think that we can still trust the developers to
separate the wheat from the chaff, to have the judgement to
distinguish the technically competent from the novice, and to come
close enough to a consensus (if not actually achieve it) on a
technical issue that is quite workable.
On non technical issues, I see no other recourse than voting.
manoj
--
"I'll tell you what kind of guy I was. If you ordered a boxcar full
of sons-of-bitches and opened the door and only found me inside, you
could consider the order filled." Robert Mitchum
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.golden-gryphon.com/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
