[ZF] Re: [Zope3-dev] Official Zope packages

[Christian Theune]

[Moving the discussion from zope3-dev at zope.org]

Am Mittwoch, den 25.07.2007, 10:05 -0400 schrieb Jim Fulton:
> Some high-level comments.
> 
> I think you raise some good questions.
> 
> I'm not sure that what namespace package something is in is a good  
> indicator of "officialness" or quality.

It's a very simple low-tech indicator.

> I'm not sure what the value of "officialness" is.

My interest is to use it as a way to collectively decide where I (and
gocept) spend time contributing.

The repository is becoming a bit too large to randomly look at stuff and
still be efficient and effective.

I just had an Idea: It could help to think a bit different and move away
from "official" or "core" to a different concept:

The repository always hosted multiple projects. I never paid too much
attention to the CMF packages and didn't pay attention to the ZODB
initially.

Zope 2, Zope 3, ZODB, CMF are easy to distinguish as points of focus.

200+ packages sitting next too each other don't allow any focus at all,
making it hard for me to decide which of those to support.

I'm happy to support something with many packages, however, 200+ is just
too much.

Maybe establishing some working groups that take care of sets of
packages might be worthwhile. 

We could look at the existing packages and try to come up with some
groups where people could say "Hey, I'm interested in this topic in
general" and contribute.

I'd be happy to do work on low-level things, database-stuff (ZODB/RDB)
but I'm not so interested in webdav or syncing stuff to the file system.

Being in one group obviously doesn't mean one has to feel responsible
for everything in that group. I feel more like that you would join a
group if you have interest in one of the packages maintained by the
group or the topic in general. This would allow you to efficiently
ignore things you really don't care about.

We could group packages into a couple of larger chunks by topic, it
probably doesn't have to be too rigid, maybe something like this:

- Component architecture and general development infrastructure (maybe
these could be two groups really)

  zope.annotation
  zope.app.component
  zope.component
  zope.configuration
  zope.datetime
  zope.decorator
  zope.deferredimport
  zope.deprecation
  zope.event
  zope.interface
  zope.proxy
  zope.testing
  zope.schema
  [...]

- Web application server

  zope.documenttemplate
  zope.html
  zope.location
  zope.mimetype
  zope.pagetemplate
  zope.sendmail
  zope.publisher
  zope.server 
  [...]

- ...

Other groups could be much smaller. I also think that the groups and
associations with packages would probably gonna be fuzzy and maybe even
ambiguous. It could still be very helpful, though, if we end up with 5-7
groups -- a number that can easily be remembered.

"Easy to see and decide" is the value for me to have a low barrier of
deciding where to contribute and what to use.

> It might be good to have some sort of rating system to help address  
> quality.  Of course, rating systems are hard. :)
> 
> It might be good to have some processes for indicating commitment to  
> a package.  Like (brainstorming...) maybe someone should be required  
> to periodically assert that they are maintaining something, even if  
> they aren't doing any work.
> 
> Just some thoughts.

My hope is to do this as simple as possible to allow us to communicate
this efficiently to others, make it simple to maintain and use.

If we could establish working groups that have some focus, those groups
could decide to take over the maintenance of a certain package or not.
Multiple groups could also decide to maintain a package if they are
interested, this could be a simple side-effect that we don't have to
care about.

> I think this discussion might be better held on the foundation list.

Moving it there with this mail now.

Christian