[ZF] Please comment! Re: Zope Development Process

[Philipp von Weitershausen]

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.

Sorry, been busy making the book deadline.

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

I guess this means the following questions:

a) How do you become a contributor (and do they have to be ZF members 
first, or become ZF members at the same time, etc.)?

b) How do contributors contribute code?

Right?

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

Hmm, I wonder what this means. Are you talking about companies like ZC 
doing open-source rounds by importing stuff into svn.zope.org? Or are 
you talking about projects like docutils, pytz, mechanize, etc. whose 
code we reuse.

In the former case, I think it's desirable to put stuff in svn.zope.org. 
In the latter we should stop maintaining vendor imports indeed and just 
rely on their eggs.

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

Who are, afact, not the same as contributors, right?

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

How can us IANAL folks help?

>> I wonder what projects there should be.  Do we need want many
>> projects?

I don't.

>> Some obvious projects are Zope 2, Zope 3, and ZODB.

Yes.

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

How about creating a "framework project" that maintains stuff like 
zc.buildout, ZConfig, zdaemon, etc. It would be good having a "pope" or 
at least a 'maintainer' for the common infrastructure we all use.

>> For example, zc.ngi is an experimental testable networking library
>> that I plan to use in ZEO someday.  Should that be in the
>> repository?

Sure, why not. I don't see a reason not to have experimental code in the 
repository. Things like zc.ngi could be consumed by a project at some 
point (e.g. the aforementioned "framework project").

>> Should it be a project?

No, too many projects would kill us.

>> Should the packages in the zc (or z3c or lovely)
>> namespaces be their own projects? Should each namespace be a project?

That sounds like a good idea to start with.

Philipp