I'm okay with using launchpad more, though I do think we shouldn't
underestimate the power of a mailbox (I use gmane and a newsreader
myself :) and a document with decisions recorded. People can simply
bring up an issue again if it hasn't resolved itself, after all. I
really don't want people to have to struggle through launchpad just to
bring up an issue.
Anyway, if the steering group wants launchpad to be used more, we'll
have to get specific.
Steering group members can do in two ways:
* put issues in launchpad ourselves.
* we suggest to people to put *particular* issues in launchpad during
This will work much better than general calls to use launchpad. :)
One question is what launchpad project we should use.
The current launchpad is for "Zope 3". The steering group isn't about
Zope 3. It's about a whole bunch of libraries. Creating a separate
launchpad project for each library in the framework seems like a bit of
overkill at this stage, though it would please those people who come at
us at the perspective from libraries the most.
For now, I propose we create a launchpad project "zopeframework" and
file bugs there. If a particular component such as zope.component gets a
lot of traffic by itself, we'll open up a project for that as well (and
issues can be assigned to two projects).
Christian, can you create a zopeframework project in launchpad? Let it
be nice and empty so there's no past we have to worry about. Mining
through the current Zope 3 issues is a project all by itself.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -