Re: Bug#30036: debian-policy could include emacs policy

[Manoj Srivastava <srivasta@golden-gryphon.com>]

Hi,
>>"Ian" == Ian Jackson <ian@chiark.greenend.org.uk> writes:

 Ian> Manoj Srivastava writes ("Re: Bug#30036: debian-policy could include emacs policy"):
 >> Hi, 
 >> >>"Adam" == Adam Di Carlo <apharris@burrito.onshore.com> 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     <srivasta@acm.org>    <http://www.golden-gryphon.com/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E