[ZF] Zope Development Process

[Martijn Faassen]

Jim Fulton wrote:
[snip]
> I wonder what projects there should be.  Do we need want many
> projects?  Some obvious projects are Zope 2, Zope 3, and ZODB.  What
> about smaller efforts?  Should ZConfig be a separate project?  If not,
> what project does it fall under.  It is used by all 3 of Zope 2, Zope
> 3, and ZODB.  What about a project like zc.buildout?  Should the
> repsository contain code that doesn't fit under any project?  For
> example, zc.ngi is an experimental testable networking library that I
> plan to use in ZEO someday.  Should that be in the repository?  Should
> it be a project? Should the packages in the zc (or z3c or lovely)
> namespaces be their own projects? Should each namespace be a project?

I think it makes sense to detach 'ZF bylaw projects' from development 
projects, just like it makes sense to detach repository commit access 
from ZF Committer Member status. A development project may become a 
separate ZF Project over time, or may never reach that stage.

I definitely do not want us to be tied down by the ZF definition of 
project. I'm concerned with the process of project incubation. We need 
to be aware in practice that small projects may grow into big ones 
later. Such small projects can be under one ZF Project early on but grow 
into a separate ZF Project later on. As a silly example, let's imagine 
zc.resourcelibrary became a major new thing that had lots of people 
talking about it and lots of checkins and so on.

There needs to be some way to recognize this process and give it its own 
ZF Project. We need to make the steps a development project could take 
towards ZF Project explicit, so that people who need more facilities to 
support their growing project know who to talk to to get them.

Detaching development projects from ZF management projects could be 
supported by having a minimum number of established ZF Projects, plus 
one catch-all "Other" ZF Project:

* Zope 2 - the zope 2 core

* Zope 3 - the zope 3 core

* CMF - anything CMF related

* ZODB - the ZODB

* Other - everything else (z3c, lovely, zc, zc.buildout, etc)

We need a minimum of process in Other. There should be someone with at 
least some awareness of what is going on, and who people can talk to if 
they need something, but there shouldn't be much else. There also needs 
to be a defined process for how things in catch-all can turn into an 
established ZF project.

So, we do not *require* any project to be part of an established ZF 
project yet when it starts; anyone can start just about anything under 
the catch-all of "Other". Other is low on process. Only when there are 
people who stand up and say, hey, we want a ZF project for, say, 
everything under lovely.*, and we're willing to volunteer to back this 
up, do we proceed and make a new top-level ZF project.

Concerning development projects, we should be aware that project 
identity is important in getting developer adoption. Project identity 
can be established by having one or more web pages on zope.org, a group 
of people on a mailing list or IRC channel, a logo and motto, and so on. 
  Having a clear project identity can in my experience be a major factor 
in the formation of an open source community around this project.

I consider aspects of this valuable even for smaller projects. So, I 
believe the ZF should provide infrastructure support for these projects 
to establish such identities. In some cases this may not go much beyond 
a pointer on zope.org to a cheeseshop page similar to the TurboGears 
Cogbin, in other cases it can be much more. We should provide this 
infrastructure support at a granularity finer than ZF Project and 
without requiring that these projects move out of Other. Perhaps one 
good indicator on whether a dev project needs a separate ZF Project 
status is when the project grows its own mailing list.

Regards,

Martijn