[ZF] Zope Development Process

[Jim Fulton]

Section 7 of the Zope Foundation By Laws,
http://www.zope.org/foundation/ZopeFoundationByLaws.pdf, calls for the
establishment of a Zope Management Organization (ZMO) and a Zope
Development Process (ZDP).  It is through these that the bulk of the
Foundation's activities seem to be governed on a day-to-day basis.  We
haven't established either of these yet.  In addition, the ZMO is
supposed to establish Architecture, Planning, and Requirements
councils made up primarily of representitives of members of Project
Management Committees.  Section 7 makes passing reference to top-level
projects, projects, and subsystems.  Exhibit D of the Membership
Agreement,
http://www.zope.org/foundation/ZopeFoundationMembershipAgreement.pdf,
also refers to project charters.  It is not clear whether a project
charter is something that applies only to top-level projects.

This is a *lot* of organization. :)

We need to put some processes in place soon.  Some issues that need to
be addressed soon include:

- We need a process for allowing people to contribute their code to
   the source-code repository.

- We need a process for contributing 3rd-party code to the
   respository. (I would like to see this kept to a minimum, if
   possible, by using eggs, rather than code copying, to manage
   dependencies on 3rd-party code.

- We need a way to invite committer members.

The first two issues are pretty urgent, as I don't think we can
establish a Foundation repository without resolving them.

Exhibit D of the membership agreement provides a process for
establishing committer members.  This has a number of problems:

- It makes no distinction between membership and commit access.  A
   committer member is given access to the repository *after* they have
   made substantial contributions.  If the contributions are source
   code, they can't make them without access to the repository or
   without getting someone else to check in code on their behalf.  I
   really want to discourage people from checking in other people's
   code.  If their contributions aren't source code, then there is no
   point in giving them repository access or in calling them
   committers.

   As I've menntioned before I *really* want to separate membership
   from commit access.  In earlier reading of these documents, I'd
   thought that commit access and membership were not coupled, but
   rereading exhibit D, I realize that I was wrong. :(

- The process requires project-management committees and projects,
   which we don't have yet.

We need to find a way to move forward, either by interpreting and
following requirements set forth on these documents, or by trying to
simplify them and following the result.

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?

Thoughts?

Jim

--
Jim Fulton			mailto:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org