Development methodology (Re: [Zope-CMF] Future CMF) (rant)

Lalo Martins lalo@laranja.org
Mon, 7 Oct 2002 15:56:08 -0300


On Sat, Oct 05, 2002 at 10:21:11AM +0200, Paul Everitt wrote:
> 
> Speaking of "Future CMF" (and thanks, Erik, for relabeling the subject  
> line), Jim's announcement of proposal on this topic has received no  
> comments:
> 
>    
> http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ 
> ContentManagementProjectsForZope3
> 
> Zero, zippo, nada.

<rant>

Have you noticed how Zope3 development has slowed down a bit?

IMO the community development of Zope3 (and other Zope-related projects in
general) is all wrong. The metodology is too documentation-oriented, there
are lots of virtual-paperwork involved in projects that otherwise would be
simple.

Community-oriented open-source development is not compatible with ISO9001.

I develop stuff because I have a need to fulfill and/or because I find the
challenge fun; I do not want to identify use cases, risk factors and whatnot
before I implement something I already know how to do.

And of course Zope3 development can't even tap the "need to fulfill" pool at
all, since it is hardly usable to fulfill any real-life need.

Additionally, most developers have little to no interest in commenting other
people's ideas before there is some code to test.

As I said in the previous rant, the fact that people find it easier to
contribute the development of Plone (or whatever other project that perhaps
duplicates effort but isn't at cvs.zope.org) than to make proposals on CMF
(or Zope or Zope3 or whatever) is a symptom that there is too much
bureaucracy involved. And I say this with the authority of someone who just
found it easier to reimplement TAL than extend the existing code.

</rant>



So... respecting the current methodology, I would propose and open for
discussion a path to revert this situation. I further propose that this path
is tried experimentally on Zope3, or alternatively on CMF1.4.

My suggestion is that we move to a model more similar to the PEP system. The
*first* artifact necessary for a project is a prototype. If the author
doesn't yet know the details, it's ok to raise a discussion on the list or
IRC, but then it isn't yet officially a "project", just a discussion.

So:

Stage 0 (optional): discussion

Stage 1: prototype

Stage 2: proposal document in the spirit of PEPs and RFCs

Stage 3: review and discussion

Stage 4: integration

[]s,
                                               |alo
                                               +----
--
            Those who trade freedom for security
               lose both and deserve neither.
--
http://www.laranja.org/                mailto:lalo@laranja.org
         pgp key: http://www.laranja.org/pessoal/pgp

Eu jogo RPG! (I play RPG)         http://www.eujogorpg.com.br/
Python Foundry Guide http://www.sf.net/foundry/python-foundry/