Version 5 (modified by cotto, 11 years ago)

add an explicit time for review

Note: This is a proposed restructuring of Parrot's developer community, not a reflection of its current state. This proposed structure is still in flux and we are actively soliciting feedback. If you have feedback, please reply to the thread on the parrot-dev mailing list or pose your question during the next #parrotsketch meeting,

How teams work

Team Structure

Each team consists of a team lead and zero or more members, all of whom are focused on a single aspect of Parrot and its community. These areas of focus are listed below under "Teams and Responsibilities". Developers are strongly encouraged to join teams that match their interests and skills. Membership in a team is not a prerequisite for contributing to Parrot.

Teams consisting of a single member may exist, but we believe that teams of 2-4 will generally be more robust and reliable.


Team leads are required to commit to performing their duties for a period of 6 months. A brief review and request for renewal will be presented at the first #parrotsketch meeting after the x.0.0 and x.6.0 releases. When a team lead wishes to step down, he may select a new lead through whatever method he feels is most fitting. The requirements for team membership are left to the discretion of the team leads.

Team membership is a formalization of a developer's prior actions. If a developer wants to join a team, he should talk to the team lead and start contributing to that team's goals. A track record of contributions toward a team's goals is generally the best way to convince a team lead to allow a developer to join. A list of team leads and members is documented on ParrotTeamMembers (TODO).


Once these rules are finalized and accepted by the community, we will provide an opportunity to discuss what's working and what needs improvement. This will happen during the #parrotsketch meeting after each supported release (every 3 months). Questions can be raised at any time; this review is just a time that's explicitly set aside for concerns and comments.


Maintaining a functional team is the responsibility of the team lead. In the rare case that a team ceases to function effectively or becomes unresponsive, that team may be dissolved and re-formed by a unanimous vote of the other team leads. The precise reasons for dissolution are left to the discretion of the team leads but the primary criteria is that the lead is unable or unwilling to carry out his responsibilities. We expect this to be extremely uncommon.

Teams and Responsibilities


This team is responsible for the overall vision and direction of Parrot. Their job is to determine where Parrot needs to go, keeping an eye toward the future. They have the final say in conflicts between the Project Management Team and the Product Management Team, should they arise.

Project Management

This team is responsible for taking the Architecture Team's vision and allocating resources with the aim of reaching that goal on an immediate, practical level.

Community Management

This team acts as the face of Parrot to other communities. They are responsible for attracting new developers to Parrot and directing interested developers toward places where their interests and skills can be put to effective use. They also serve as an advocate for current Parrot developers.

Product Management

This team is responsible for the vision of Parrot as a user-facing product. They also act as an advocate for the needs of Parrot's users (e.g. HLLs and libraries such as Rakudo and Kakapo) and as an intermediary between Parrot and its users.

Quality Assurance

This team is responsible for ensuring that Parrot has good, current documentation and a high degree of test coverage on a ma, that existing tests are run regularly on a maximal number of platforms and that tests are added for new features and bug fixes. This team may not be distinct from Project Management, but it is a distinct and vital responsibility.