Roles in OSAF Projects
Participants in OSAF projects can take on a number of roles. These roles are determined by the nature of a person's activities and are not a function of their employment. We will probaby be expanding these roles to include a role for designer contributors that is analgous to the role of code committers.
are people that use our software. We hope that they will contribute to the project they use by reporting bugs and making requests for features. We also hope that they will become part of the project community, by helping other users and telling other people about our software.
- Request new features
- Report bugs
- Request help
are people who contribute to one of the OSAF projects via design, code, documentation or testing. Contributors are active participants in the project mailing lists and provide design ideas, code changes, or documentation changes.
- Report bugs
- Contribute design ideas and participate in design discussions
- Contribute code patches and participate in development discussions
- Contribute documentation and participate in documentation discussion
Code contributors may also become Committers
. Contributors who have been given commit status have demonstrated a history of making useful contributions, the ability to work with existing committers, and the ability to work according to OSAF project practices. As a recognition of this history, committers are given the ability to commit changes directly into the project source code. Committer status is a recognition that a contributor has become a trusted member of the project's community.
- Actively participate in the appropriate user and developer mailing lists for the project. This participation is required since the day to day operation of the project takes place on the mailing lists.
- Proactively participate in relevant development discussions on the mailing lists for their projects
- Work with the design community for their project by subscribing to the appropriate design list and participating in relevant discussions
- Use the projects bug tracking system to manage their bugs. This includes creating new bugs, updating the status of open bugs, updating the status of bugs as they are worked on, and closing bugs when they have been fixed.
- Work within the governance framework of OSAF projects
- Be on the lookout for contributors who should become committers
- Becoming a committer
- Commit status is earned on the basis of past contribution, not the promise of future contribution. Also committers is not coupled to employment status. Committers are free to change employers without jeopardizing their involvement as a committer. It is part of the responsibility of the existing committers to be proactive in inviting new committers.
- Criteria - this is going to be slightly different for every project because there is some subjectivity in this process
- A history of useful contributions - Have patches been submitted, reworked (if necessary) in responses to feedback from a committer, and ultimately committed by an existing committer? Do the person's recent contributions still require code review and rework before they can be committed? Is this history long enough to ensure that the person will continue to contribute? Is the person consistently making substantial enough contributions to become a committer?
- Ability to work with existing committers - has this person had their patches reviewed and/or committed by more than one person (preferably 3, which would give 3 +1 votes when the person is proposed as a committer).
- Ability to work according to OSAF project practices - appropriate use of e-mail, IRC/IM, voice. Understands and operates according the the OSAF project governance principles.
- Would it be obvious from the person's public record that they should be granted commit status?
- An existing committer proposes a person for commit status on the project's private list
- After a suitable period of discussion, a vote is held on this list. The candidate must receive at least 3 +1 and no -1 votes
- Useful questions to keep in mind:
- Has the contributor made substantial (either in difficulty or in volume) contributions to the codebase?
- Do these contributions need to be heavily reviewed? The assumption here that all of us need reviews, as our use of review-then-commit during code freeze demonstrates
- Has this contributor reached the point where they can correctly review other contributor's code submissions -- that is, do you trust this person to become part of the group of people who decide what gets into the code base or not. Also, keep in mind that this person will also gain the ability to propose other contributors as committers
- Does the contributor have a sufficiently long history with the project that we feel that they are committed - judging this is squishy - in various open source proejcts there are variances of between a few months, 6 months, and as long as 2 years
- If this contributor becomes a committer, are you prepared to respect their right to veto decisons on the codebase?
- The vote should run for a clearly defined period - 72hours is a good default
- The candidate is notified privately of an offer of commit status
- If the candidate accepts, this is announced publicly on the projects development list, along with the names of those commmitters who voted.
- Before a committer's write access/account is actitvated, they must sign and return a Contributor License Agreement (CLA) (PDF), which asserts their legal ability to make contributions to OSAF projects.
- IT activates the person's ability to commit to the repository, and adds them to the appropriate private list.
- Revocation of commit status
- A committer's commit status can be revoked for several reasons:
- Disruptiveness or failure to operate according to OSAF project governance principles.
- Lack of active participation or an extended period of inactivity
- A committer's commit status can be revoked by a 2/3 vote of existing project committers, or by (some action by an OSAF project owner -- for now to be handle on a case by case basis)
- 24 2006