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
> 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?
Framework-Team mailing list