[Zope-dev] the Zope Framework project

[Martin Aspeli]

Stephan Richter wrote:
> On Monday 02 March 2009, Martin Aspeli 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.
> 
> I would like to hear more how the framework team works out for the Plone 
> community, because it is in effect what Martijn is suggesting here.

Sure. :)

In brief:

  - A team of 5-7 people is selected for each release.

  - The previous team is responsible for the selection. This involves a 
general call for nominations, a review, a private discussion to 
determine the best team (also including former team members), and a 
public announcement. The team is selected on criteria such as technical 
competence, knowledge of the stack, commitment, ability to work in a 
team, and the desire to have a spread of skills and backgrounds on the team.

  - The new team nominates a release manager (this is usually a 
formality) to the Plone Foundation Board, who vote on whether to confirm 
the nomination.

  - The release manager and framework team work out and publish a 
schedule. This normally involves:

   - A call for proposals
   - A proposal deadline
   - A deadline for commenting on the merit of the proposals received
   - A deadline for submitting 'review buildouts' for the team to review 
the code behind a proposal (if applicable, some proposals are not code 
related)
   - A deadline for the team to review the proposals, request 
fixes/updates form the author, vote, and make a final recommendation to 
the release manager
   - A deadline for merging accepted proposals
   - A general alpha/beta/rc/final release schedule

The review process normally involves a primary and secondary reviewer 
who look at the code in detail and report back to the framework team on 
their public mailing list. Members then vote +1 or -1.

Other community members are encouraged to join the discussion around 
each proposal, though their votes will not officially count.

The release manager does have the final say, and can override the 
recommendations of the team, though this happens rarely.

  - The team normally stays on to help steer minor releases, and to 
select a new team (and new release manager) for the next major release.

Regards,
Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book