[ZF] Please comment! Re: Zope Development Process

[Darryl Cousins]

Hi Jim and all,

For what it's from a minor player.

On Wed, 2006-09-27 at 06:23 -0400, Jim Fulton wrote:
> There have been very few comments on this.  This is important.   
> Please let us know what you think.  We need input from more than the  
> usual suspects.
> 
> 
> On Sep 25, 2006, at 5:44 PM, Jim Fulton wrote:
> 
> > 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.

Better than now? I think that those who have the ability and willingness
to fix bugs and/or add features readily show themselves. That coming
from someone who has done neither. I'm still very much still in the
content and simple utilities level.

> >
> > - 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.

Discipline controls along the lines of Stephan's proposal, perhaps
including better than average documentation and additional information.
A website and/or mailing list dedicated to the project demonstrates more
than average commitment. I can imagine that eggs and build outs will be
a part of that discipline in the future. Guided anarchy.

> >
> > - We need a way to invite committer members.

Not like selling cigarettes though, and no spamming. ;-)

> >
> > 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. :(

I agree to a seperation, or at least a heirarchy of membership.

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

Decision making. I honestly have a minimum of industry experience and
therefore would be a poor contributor at best and an ignorant one at
worst.

> >
> > 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.


Change Exhibit D to provide a separation of membership from commit
access.


> >
> > 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?

>From my viewpoint I am comfortable with the repository as it is and I'm
sure I'd get used another layout. I've been following the 3.3 branch for
the last few months. I am accustomed to checking what is in the zc and
z3c namespaces, and generally browsing the svn.zope.org repository.

I guess the main zope bits are Zope2, Zope3 and ZODB and I'd be happy to
see zc, lovely and z3c alongside.

Best regards,
Darryl

> >
> > 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
> >
> >
> >
> 
> --
> 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
> 
> 
> 
> _______________________________________________
> Foundation mailing list
> Foundation at zope.org
> http://mail.zope.org/mailman/listinfo/foundation