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.
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
** No cross posts or HTML encoding! **
(Related lists -