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. -- Wichert Akkerman <[EMAIL PROTECTED]> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. _______________________________________________ Framework-Team mailing list [email protected] http://lists.plone.org/mailman/listinfo/framework-team
