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

Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to