[ZF] Please comment! Re: Zope Development Process
Steve Alexander
steve at canonical.com
Thu Sep 28 06:16:59 EDT 2006
> Note that ZF projects, as described in the *current* by laws, membership
> agreement and IP policy:
>
> - Have a project management committee
>
> - Have representation on a 3 councils
>
> - Have charters that define, among other things how new project members
> are added
>
> IOW, projects as defined by the current documents are pretty heavyweight.
I would call this kind of Zope Foundation stuff something other than a
"project". Maybe a "Project's governance". It relates more to
representative and transparent governance of a project than actually
fulfilling the project's aims.
I'd say a project's aims are to produce software, get software used in
particular ways and places, release software, maintain software. None
of these activities involves a project management committee or any kind
of representation on councils. ZF projects are "meta-projects" or
"project governances".
I don't think we need more than one ZF "project governance" right now.
Any more should be added only when it is clear that having a single
governance is not working.
> I think we need lightweight projects. They seem to be different from ZF
> projects. Perhaps Martijn's idea of development projects, which I'd be
> happy
> to call products, is what you are talking about.
A project needn't be about developing a particular piece of software.
For example, I can imagine people coming together to write a book, or to
produce a marketing campaign for Zope. I'd call all these things
"projects", and call the Zope Foundation thing something that is more
consistent with its role of transparency, governance, and managing
copyright bureaucracy.
>> 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.
>
> Or maybe what the ZF docs call projects are projects in Launchpad and
> what Martijn calls development projects are products in launchpad.
Projects in Launchpad are meant for large endeavours, such as the Gnome
Project, the Mozilla Project, Ubuntu... large units of activity in the
open source world. So, I think there would be just one Zope Foundation
project 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.
>
> See above. What do projects get?
The owners of a project have some administration powers over products
that are associated with that project. This allows the project leaders
to intervene if a project's leadership goes AWOL. Projects are also
there to aggregate things that are common across a group of products.
We haven't done a whole lot with this so far; it's mainly been used for
pointing at a default bugtracker (such as a Bugzilla) for a group of
products that all use the same bugtracker.
> FWIW, I have a non-demo product in Launchpad, zc.buildout:
>
> https://launchpad.net/products/zc.buildout
>
> This illustrates some basic use of the bug tracker and feature manager.
>
> I've been abusing pypi to provide a homepage:
>
> http://www.python.org/pypi/zc.buildout
>
> One thing I'm missing is a good way to communicate with buildout users,
> like a mailing list or blog or some such. Are there any plans for
> Launchpad to help there?
I know of plans to run "planets" for projects and products in Launchpad
on demand. A planet is an aggregation of various RSS feeds, typically
from blogs. We'd aggregate blog entries from members of a project who
supply an RSS link. Here are some examples of planets.
http://planet.gnome.org/
http://planet.ubuntu.com/
We also have plans to integrate Launchpad's management of launchpad
accounts and teams of people with Mailman, to provide mailing lists for
projects and products and arbitrary other teams, on demand. I'm looking
forward to this, as it will mean a single sign-on and registration for
many mailing lists I'm on, and an easy way to create new mailing lists
as needed.
> Also, does Launchpad have any mechanism for importing or exporting data
> such as bugs and features?
There's an XML bug export coming very soon. The code's been written for
this, and it is waiting to be deployed on the live servers.
There will be an XML export for specifications. We have an unsupported
page for this now, but it will be changing to be consistent with the bug
data export.
I can arrange for bug and feature data to be imported into Launchpad.
There is no standard way to do this right now, although we can import
bugs from SourceForge as we had to do that for the Python bug tracking
competition. We can do it either by screen-scraping, or from a database
dump of some sort. For the Zope proposals, James Henstridge wrote a
screen-scaper for the Zope wikis that knows about the various ways
people have represented metadata in proposals.
--
Steve Alexander
More information about the Foundation
mailing list