Tres Seaver wrote: >> Plone, by the way, had a similar problem, and solved it by creating "the >> framework team". This is a rolling body of people who are responsible >> for putting out calls for and reviewing improvements proposals. They >> basically report to the release manager, who makes the final call. The >> release manager is nominated by the framework team, confirmed by the >> Plone Foundation, and given a small stipend for his troubles. > > Funny you should pick them as your example. I've seen members of that > team *actively deny* that the team has any role in setting technical > direction for Plone (which is ironic, given that what they actually do > is to review and approvie PEPs, as well as choosing the release manager).
I probably took the analogy a bit far: I meant to show the type of process that would enable such a team to have some degree of legitimacy as well as purpose, and that a team-based approach can work well in a community where there's no pope/dictator/whatever. The framework team has a role in setting technical direction for a single release, by virtue of what it does. The team is changed for each release, so it does not have a role in setting technical direction further than that, although of course the choices made for one release will often have some bearing on the future. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )