[Framework-Team] Re: plone products leaders (v2)

Wichert Akkerman wichert at wiggy.net
Fri Mar 23 07:53:05 UTC 2007

Previously Hanno Schlichting wrote:
> Hi,
> Thierry Benita wrote:
> > I was looking for leaders of plone products. I found leaders of plone
> > core, plone archetypes, but not for each plone component.
> > I don't think that there is currently a leader for every simple
> > component that is in Plone.
> There is an official maintainer which is bugged by the release manager
> for releases whenever they are needed for every package. But as the
> number of people doing that is quite small at least I don't advertise
> this maintainership of a package to heavily as I don't have the
> resources to answer questions in private about all those packages.
> > Each package has a maintainer. This way, each commit in this package,
> > each bug found, each security issue is the responsibility of the
> > package's maintainer.
> > The maintainer is included as a contact information in its packet. When
> > an issue is found, any user can contact the maintainer with BTS (a
> > general Bug Tracker System) or via email. The maintainer checks the
> > issue and corrects it if it's related to its job. If it's not, the
> > maintainer can reject the issue or forward it to the person responsible
> > of the issue. In the second case, the maintainer is still responsible
> > for the inclusion of the issue's fix in the debian package.
> We have adopted more of a group process here, where you can add bugs for
> all packages that are part of Plone the product to the plone bug tracker
> if there is no distinct tracker available (like for Zope, CMF, PAS,
> ...). You can ask questions about all of them on plone-users or discuss
> development on plone-devel mailing lists. While they are some people
> that will look into certain bug tracker categories more often, we don't
> have any official maintainer status or responsibility here.
> > When a package lacks maintainer, it is claimed as orphan. Orphans
> > packages are listed in a page of the Debian web site, and a call for
> > maintainer is sent on the members list. If there is no new maintainer,
> > the package may be removed from the core distribution. Good packages
> > always find maintainers ;)
> I think we would need to remove at least five of the core packages from
> Plone by that criteria, which we depend on heavily and in return would
> end up with an nonfunctional product. We have both a lack at people
> maintaining and evolving certain packages as well as too much old-crufty
> packages. We are getting better in this area though, as most of the new
> Python packages we introduced for Plone 3 are a lot more maintainable
> than the old-style products we had so far.
> > There should also be 'leaders architects'. For example a set of
> > components that are dependant each other, let's say archetypes or plone
> > on a higher level, should have their leaders. These leaders would be
> > elected by maintainers. Leaders can give the new
> > orientation of the global set, and say what should be done, or what
> > should not be done. This may be about architecture, writing rules or
> > whatever.
> > When the Leader gives the new rules, each component leader applies it to
> > its component.
> I'm not sure this kind of organization is applicable to the Plone
> community, but lack experience in other communities. Maybe Wichert who
> has been Debian leader for years can tell us some of his thoughts on this?

Debian does not have that either. Ubuntu does have something similar. In
general I'm not quite convinced by comparing Debian to Plone, for
several reasons:

- I no longer feel Debian is the 'best by far' distribution there is as
  was claimed. It seems that innovation is mostly happening elsewhere
  these days.

- in Debian it is no longer true that each package has a single
  maintainer. For a long time large or complicated packages have been
  maintained by groups (policy manual, X Windows) but in the last years
  a lot of packages have become group maintained. The services Alioth
  provides have certainly made that a lot easier and more popular.

- the 'leader architect' role is spread out. We do a lot of design and
  architect works at sprints with changing groups of people, which makes
  sure we always have a good combination of experience and fresh
  insight. All people who work on the 'Plone core' know each other and
  discuss things regularly.

- Each Plone component does have a maintainer, but the maintainer is
  just not always documented very visibly. With the move to eggs that
  can be improved a lot: each egg has maintainer and contact info.
  However at the moment we seem to be putting 'Plone Foundation' and
  the plone-developers list in there; we still need to figure out what
  the best approach is there. Having a template README which points
  to the plone.org product page for documentation and its issue tracker
  (or the Plone issue tracker for core products) and contact
  information would certainly help. A volunteer to update the plone
  paste templates is very welcome!

I'm not convinced that we have the problems that Thierry sees. I do see
that we have an increasing complexity and inter-dependencies between
components which will require some changes to the release process for
Plone 3.5 and later.

I also do not believe in electing leaders. Democracy works reasonably in
politics, but when you are trying to manage a product and its roadmap
you need people with a certain set of skills and experience, not people
who are popular or happen to have better social skills. Personally I
think our current system based on PLIPs and a framework team to review
them works very well.


Wichert Akkerman <wichert at wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

More information about the Framework-Team mailing list