[Python-Dev] Re: Feature bloat in Python

[Greg Stein]

On Sun, Jul 23, 2000 at 10:12:38AM +0200, Fredrik Lundh wrote:
> mark wrote:
> > If you can't quickly and quietly win this friendly audience over, IMO the
> > proposal has failed.  If any proposal causes even a small thread on this
> > forum that boils down to "but its not clear to me what this should do",
> > then I would have thought it self-evident that the proposal sucks.
> > Convincing us that it _should_ be obvious if only we were all a little
> > brighter and more willing to accept change for changes sake doesn't
> > help anyone, least of all the person making these statements
> 
> from the new Tcl Code Team rules:
> 
>     "A project can also be proposed by someone outside the Tcl Core
>     Team, but it can't be approved without an advocate on the Tcl
>     Core Team who will take personal responsibility for it. A project
>     must have support from at least 2 members of the Tcl Core Team
>     (including the proposer); if anyone in the Tcl Core Team objects
>     to the proposal, then there must be at least 4 members in favor
>     (including the proposer). If there are two or more "no" votes then
>     the proposal is rejected, regardless of the number of people in
>     favor.
> 
>     "The idea here is that the Tcl Core Team can only work effectively
>     if it is highly collegial; any project that generates significant contro-
>     versy should not go into the Tcl core."

Compare/contrast to Apache:

    Big changes / non-bug fixes "require consensus approval before the
    change can be committed."

    "An action item requiring consensus approval must receive at least 3
    binding +1 votes and no vetos."


Apache requires at least one maintainer for any code in the distro (sounds
like Tcl will also require one). Changes require (3) people to agree/approve
them (Tcl appears to say 2, unless a veto arrives and makes it 4). Vetos are
very harsh in Apache and can be made and held (forever) by a *single*
person. Most vetos occur simply because a particular patch/commit has some
repercussion that the author didn't see, or there is an obviously "better"
(for your particular definition of "better") way to do the thing. But a veto
is also quite permanent, binding, and respected. As a result, Apache does
tend to be cooperative to avoid vetoes on designs, but they do happen.


Something that Mark didn't seem to make clear (but I believe he intended):

    If we have problems understanding how something will work, then how can
    we possibly expect it will be understood by Python users who (almost by
    definition of their absence on this list) have less experience with
    Python than we do?

or:

    If it isn't obvious to us, then it will be opaque to the majority of
    users.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/