[ZF] Please comment! Re: Zope Development Process

Steve Alexander steve at canonical.com
Wed Sep 27 07:09:47 EDT 2006


Jim Fulton wrote:
>
> There have been very few comments on this.  This is important. 
> Please let us know what you think.

Okay.  I've sketched out what I understand to be a ZF project, and what
I believe to be the minimal requirements for a project.  I don't think
this takes much bureaucracy -- it's more about setting out what software
the ZF is managing, and telling people outside of the ZF who is
responsible for particular aspects of that software.

I believe that launchpad.net is a good match for some of the job of
keeping track of projects and who is responsible for what within a
project, so I've written about that below, too.

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

== About projects ==

What is a Zope Foundation Project?

* Some things are common to all ZF projects:

 - Committers are ZF contributor members who have been granted
   commit access and have signed a joint copyright form.

 - The code is licensed under the ZPL, and at least jointly
   owned by the ZF.

* Some things are specific to a particular project, but follow a set
pattern:

 - There is an owner, who has the power to delegate responsibility
   for things like release management, security contact, pope-ness,
   to other people or groups of people.

 - There may be a release manager.

 - There is a security contact.

 - There may be a pope of some kind, a chief maintainer.

 - The project has a name, a home page with basic information about it.

 - The project has a place in a version control system.

* Some things may be specific to a particular project in an
extraordinary way.  Let's avoid that.


== A lightweight project ==

I think I've described a very lightweight notion of what a project can
be.  At a minimum, it is one person, the project's owner.  This person
fills the roles of security contact and pope.  The project has a name, a
home page and a place in a VCS.

A project needs to publish how to report security issues, and who to
contact to ensure a security issue is being taken care of properly.

A project should publish information about where its code is available
from, when and how releases are made, if they are made at all, and what
the project is actually for.

If the project gets too large for that one person, the owner, then the
owner can delegate some of the responsibilities to others.  A common
delegation will be to delegate the security contact duties to the ZF
security contact list.  In fact, that should be the default.


== Launchpad ==

I want to suggest people look at the software I help develop, Launchpad,
to help with managing these projects.  It is at https://launchpad.net.

I should point out that I'm paid by Canonical to work on Launchpad, and
that while Launchpad is a free and well-supported service, it is not
itself open source software.  In that sense, it is like Google or
SourceForge.

Launchpad uses slightly different terminology: an organisation like the
Zope Foundation is a "project" in Launchpad.  What we've been calling
"projects" are "products" in Launchpad.

You can register a Zope Foundation project in Launchpad, and then
register a bunch of products associated with that.  Each product gets
its own description of what it is about, and you can say who are the
maintainers, security contacts, and so on.

There was some discussion of fishbowl processes, proposals, etc.  I ask
that you consider using the "feature tracker" in Launchpad for tracking
proposals.  You can see a demonstration version with Zope proposals
loaded into it here:

  https://features.demo.launchpad.net/products/zope

This is not the "live" Launchpad, but a separate server set up to
demonstrate things and allow people to experiment with the site.

The feature tracker has proved very useful for planning what goes into
particular releases of the Ubuntu Linux distribution, and having a
workflow for getting the general direction of a proposal approved by the
right "popes", and recording the development status of the proposals.

-- 
Steve Alexander


More information about the Foundation mailing list