Committers
From Symbian Developer Community
Contents |
What is a committer?
A committer is an engineer that a package owner has granted permission to make direct contributions to the MCL/RCL repository. These people have push access to this repository and it is trusted that their contributions are reliable enough not to break builds or generate unresolved conflicts, and also that they meet foundation standards. Committers are also expected to have resolved any conflict or integration issues before pushing contributions to the managed code lines.
In addition, a committer may be required to act on the behalf of the package owner, particularly in dealing with contributions from other developers.
Committer Selection
If you are a package owner you can appoint (or retire) a committer for your package. Committers must be working for a member company that has signed the Membership Contribution Agreement (MCA).
Package users may choose to approach a package owner to request to become a committer, and package owners should actively recruit for committers from outside their own organisation.
Criteria and Principles
Package owners should select committers based on publicly recognised merits such as:
- understanding of the package’s code base and coding style
- a good understanding of how the package team works (i.e. any processes and conventions that are agreed amongst all contributors and committers of that package)
- ability to collaborate with the package team
- a track-record of contributing high-quality code to the package (a number of non-trivial features or defect fixes), and follow-through to fix issues
- ability and readiness to help other contributors
- participation in design discussions
It is important that a committer demonstrates a degree of commitment to your package: you do not want to select a committer, who will stop contributing to your package after 3 months. You can usually judge the level of commitment by engaging a contributor in discussions of future plans, and also by their track record. There are of course never guarantees: this is about judgement.
Committers should be selected following the principles outlined in Good Community Behaviour. In particular the following principles should be upheld.
- Meritocracy: Symbian is a meritocracy. The more you contribute the more responsibility you will earn. Leadership roles in Symbian are also merit-based and earned by peer acclaim. This means that contributors who have significantly added to your package and have earned your packages trust, should be considered to be nominated committers. Remember, committers do not need to work for your company.
- Openness: Symbian is open to all. Symbian provides the same opportunity to all. Everyone participates with the same rules. There are no rules to exclude any potential contributors which include, of course, direct competitors in the marketplace. This means that an individual that fits merits as listed above, should not be excluded from being nominated a committer if working for a competitor.
- Transparency: Package discussions, minutes, deliberations, project plans, plans for new features, and other artifacts are open, public, and easily accessible. This means, that decisions to nominate a package owner should be justified. Note that the procedure below requires justification. It is recognized that building a community around a package is not easy, and that initially members of the package team will need to be selected as committers.
Procedure
The procedure to add a committer is described here.
Package Owners and Committers
Package owners are free to organise their committers as they choose, according to the needs of the package and the way in which it is being developed. Different committers may have different roles, or responsibility for different codelines and areas in Bugzilla. Alternatively, committers may all have the same responsibilities. The package owner retains the final responsibility for the quality of the package and therefore it is important for the package owner to select committers carefully and lead their activities as required.
Grievances
If a contributor feels they should be nominated to be committer, but there is an issue, please discuss
- With the package owner first.
- If no resolution can be found discuss with the Contributor Community Manager, who will liase between contributor and package owner.
- The last resort would be an escalation to the respective council.
Vice versa, if a package owner feels a committer is behaving outside of the principles outlined in Good Community Behaviour discuss with the Contributor Community Manager who will then seek to find a resolution.
The future of this process
This Wiki page is the first step in an interactive process to make processes around committers, committer selection and committer elections "Contributor Friendly" as possible. If there is something wrong, please change it. Please discuss and feedback in the forums so that we can improve it.
Finals steps in this first phase include:
- Incorporating community feedback.
- Describe Committer Selection more clearly
- Transition the process from Committer Selection to Committer Election as packages build communities
- Define a process for Committer Elections (once a package has an active community, electing committers is a fairer and more transparent approach to choosing committers)
- Define criteria, when to use Committer Selection vs. Committer Elections
- Define under which circumstances a committer can be de-selected
Comments
Stichbury said...
Jma said...
The first condition in the Criteria and Principles, "understanding of how the package team works". should it be "understanding of how the package works"?
--Jma 09:16, 31 August 2009 (BST)
Sign in to comment…
Hi Lars
We're phasing out the Collaboration Processes category, so I've removed it from this post. The others left in this category are around only temporarily. They're residual from Dominic's document and Robert has it on his radar to talk to various people about (re)moving them.
Jo
--Stichbury 16:41, 20 August 2009 (BST)