Pegasus Enhancement Proposal (PEP)

PEP #: 336

Title: OpenPegasus Community Review and Approval Process

Version: 1.3

Created: 15 September 2008

Authors: Denise Eckstein

Status:  Approved

Version History:

Abstract:  The purpose of this PEP is to define an offline review and approval process for enhancements, controversial bug fixes and Concept and Functional PEPs.  This process has been specifically designed for a geographically dispersed community.  In addition, it serves as a transition step towards moving the OpenPegasus Community to a meritocracy modeled after the Apache Software Foundation (ASF) meritocracy process, How the ASF works.

Definition of the Problem

Requirements

1. Increase community visibility and involvement in Architecture Team design discussions.
2. Allow full participation in the process by a geographically distributed community.
3. Increase the quantity and quality of patch and enhancement proposals.
4. Reduce the number of, or potentially eliminate, Architecture Team meetings.
5. Grow the number of OpenPegasus experts.

Proposed Solution

Significant portions of this proposal are based on policies defined by various Apache Projects, http://www.apache.org/.

Organizational Structure

Project Management Committee (PMC)

The OpenPegasus Project Management Committee (PMC) was established by the OpenPegasus Steering Committee to be responsible for the active management of the OpenPegasus Project.

The role of the PMC is two-fold.  The first role of the PMC is oversight.  It is the responsibility of the PMC to ensure that OpenPegasus contributors follow approved procedures.  The second role of the PMC is stewardship.  The PMC is  tasked with making decisions that foster the long term development and health of the OpenPegasus Community and source repository.

The PMC may be terminated at any time by resolution of the OpenPegasus Steering Committee.

Community Roles

The following roles are defined for members of the OpenPegasus Community:

User

A user is someone that uses the OpenPegasus software. They contribute to the OpenPegasus Project by providing feedback to developers in the form of bug reports and feature suggestions. Users participate in the OpenPegasus Community by helping other users on the OpenPegasus user mailing list, pegasus-l@openpegasus.org . Passive users are also known as lurkers.

Developer

A developer is a user who contributes to the OpenPegasus Project in the form of code or documentation. They take extra steps to participate in the project, are active on the Pegasus Architecture Team mailing list, pegasus-architecture@openpegasus.org, participate in discussions, provide patches, documentation, suggestions, and constructive criticism. Developers are also known as contributors.

Committer

A committer is a developer who has demonstrated expertise in one or more areas of OpenPegasus and has been granted write access to the code repository by the PMC.   A committer must have a signed OpenPegasus Project Contribution Agreement on file.   Committers are allowed to make short-term decisions for the project in their areas of expertise.  All short-term changes are reviewed by the Community and either approved, either implicitly or explicitly,  into permanency or rejected.  Remember that the Community makes the decisions, not the individual people.

A developer who makes a sustained contribution to the project may be invited, by the PMC, to become a committer. Contributions are not limited to code.  Contributions include code review, helping out users on the mailing lists, documentation, etc.

Committer rights are granted and may be revoked by vote of the PMC.  A committer is considered "emeritus" by their own declaration.  An emeritus committer may send a reinstatement request to the PMC. Such reinstatement is subject to vote by the PMC. An "emeritus" committer is not considered an active committer.

Project Management Committee (PMC) Member

A Project Management Committee (PMC) member is a committer who has demonstrated both a commitment to the OpenPegasus Project and a high degree of expertise across the breadth of the Project.  They have write access to the code repository, the right to vote on community-related decisions and the right to propose an active user for committership or PMC membership. The PMC as a whole is the entity that controls all technical aspects of the project.

A developer who makes a sustained contribution to the project may be invited, by the PMC, to become a PMC member. It is not strictly necessary to be a committer first in order to become a PMC member. In some cases, the PMC may feel that an individual brings needed management expertise to the project.  Any such newly accepted PMC members will be given committer status.

Membership in the PMC is granted and revoked by vote of the PMC.  A PMC member is considered "emeritus" by their own declaration. An emeritus member may send a reinstatement request to the PMC. Such reinstatement is subject to vote by the PMC.  An "emeritus" member is not considered an active member.

The following table summarizes key aspects of the OpenPegasus Community roles.

Table 1 - OpenPegasus Community Roles
	Lurker	User	Developer	Committer	PMC Member
Suggests Enhancements	No	Yes	Yes	Yes	Yes
Reports Defects	No	Yes	Yes	Yes	Yes
Contributes Patches	No	No	Yes	Yes	Yes
Has a Signed Contribution Agreement on File	No	No	Maybe1	Yes	Yes
Has CVS Read Access	Yes	Yes	Yes	Yes	Yes
Has CVS Write Access	No	No	No	Yes	Yes
Grants CVS Write Access	No	No	No	No	Yes
Approves membership in PMC	No	No	No	No	Yes

¹ A developer that proposes a significant contribution to OpenPegasus may be asked to sign the OpenPegasus Project Contribution Agreement.

The current list of OpenPegasus PMC members and committers can be found at http://www.openpegasus.org/Contributors.

Voting Rules

All members of the OpenPegasus Community are encouraged to express their opinion by voting.  And although only the votes of individuals who have earned merit count (i.e., are binding),  non-binding votes provide invaluable input to those with binding rights.  The following three tables describe (1) valid voting values, (2) the types of approval used by the OpenPegasus Community and (2)  the level of approval required for various actions. 

Voting Values

A vote can be one of the following three values:

Table 2 - Voting Values
Vote	Description
Yes [+1]	"Agree" or "This action should be performed."
Abstain [0]	"No Opinion", or "I disagree with the proposed action, but not strongly enough to prevent the action from being approved."
No [-1]	"Disagree".   Note: All "No" votes must include an explanation of why the "No" is appropriate. A "No" without an explanation is void.

Approval Types

For certain actions, the OpenPegasus Community processes allow voting by "lazy consensus" or "lazy approval".  With lazy voting, "silence" is assumed to mean consent.  An action under a lazy vote is allowed to proceed after satisfying an initial set of conditions but before final approval.   During the period between initial acceptance and final approval the action is still subject to veto. 

Table 3 - Approval Types
Approval Type	Description
Consensus	For this to pass, all individuals with binding voter rights must vote and no individual with binding voter rights may vote "No [-1]".
2/3 Majority	For this to pass, 2/3 of all individuals with binding voter rights must vote "Yes [+1]".  If there are fewer than 4 individuals with binding voter rights, then all voters with binding voter rights must vote "Yes [+1]".
Lazy Consensus	For initial acceptance, 3 individuals with binding voter rights must vote "Yes [+1]" and no individual with binding voter rights may vote "No [-1]".  If there are fewer than 3 individuals with binding voter rights, then all individuals with binding vote rights must vote "Yes [+1]".   Note: The duration a vote will remain open for final approval will vary by action.  However, we strongly encourage individuals to register a veto ("No [-1]") as soon as possible.    Note: All binding vetoes on a contribution must be filed and resolved prior to achieving SF (Source Freeze) on the release containing the contribution.
Lazy Approval	For initial acceptance, at least one voter with binding voter rights must vote "Yes [+1]" and no voter with binding vote rights may vote "No [-1]". Note: The duration a vote will remain open for final approval will vary by action.  However, we strongly encourage individuals to register a veto ("No [-1]") as soon as possible.    Note: All binding vetoes on a contribution must be filed and resolved prior to achieving SF (Source Freeze) on the release containing the contribution.

Level of Approvals

The following table describes the level of approval required for various action.  The "Initial Acceptance Min Vote Duration" column defines the minimum amount of time a lazy vote must remain open before receiving initial acceptance approval.  The "Final Approval Min Vote Duration" column defines the minimum amount of time a lazy vote must be open before receiving final approval.  Both times start when the ballot is opened.  The vote duration times for a particular ballot may be extended by the ballot sponsor or by request from the Community.  The "Voter Distribution List" column defines the appropriate e-mail list to send the vote announcement. For additional details, please refer to the "Process Steps" section below.

Note: A vote may close before the minimum vote duration time,  if all individuals with binding voter rights have voted.

In the "Voter Distribution List" column,  DEVEL refers to the pegasus-architecture@openpegasus.org distribution list, PMC refers to the pegasus-pmc@openpegasus.org distribution list.

Table 4 - Level of Required Approvals by Action
Action	Approval	Individuals With Binding Rights	Voter Distribution List	Initial Acceptance Min Vote Duration	Final Approval Min Vote Duration
Grant committer rights.	Lazy Consensus	Active PMC members. Note: To receive committer rights, a developer must have at least one recognized area of expertise (e.g., CMPI, HP-UX port, etc.). Note: The PMC is responsible for defining areas of expertise.	PMC	N/A	1 week
Revoke committer rights.	Consensus	Active PMC members, with the exception of the individual in question.   Note: A committer whose rights have been revoked will not be granted emeritus status. Note: A committer must be covered by a signed Contribution Agreement.  Commit rights will be immediately revoked if the committer is no longer covered by a signed Contribution Agreement.	PMC	N/A	2 weeks
Reinstatement of an emeritus committer.	Lazy Consensus	Active PMC members.	PMC	N/A	1 week
Invite a developer to join the PMC.	Lazy Consensus	Active PMC members.	PMC	N/A	1 week
Revoke membership in the PMC.	Consensus	Active PMC members, with the exception of the individual in question. Note: An individual whose membership rights have been revoked will not be granted emeritus status.	PMC	N/A	2 weeks
Reinstatement of an emeritus PMC member.	Lazy Consensus	Active PMC members.	PMC	N/A	1 week
Approve a Concept PEP.	Lazy Consensus	Active committers.	DEVEL	N/A	1 week
Approve a Functional PEP.	Lazy Consensus	Active committers.	DEVEL	N/A	1 week
Approve an enhancement code change to the MAIN branch.	Lazy Approval	Active committers.	DEVEL	1 week	All vetoes on a contribution must be filed and resolved prior to achieving SF (Source Freeze) on the release containing the contribution.
Approve a non-trivial bug fix change to the MAIN branch.	Lazy Approval	Active committers.	DEVEL	2 days (excluding Sat and Sun)	All vetoes on a contribution must be filed and resolved prior to achieving SF (Source Freeze) on the release containing the contribution.
Approve a backport change. Note: A backport is the application of a change in the MAIN branch to the a maintenance branch of the project.	Lazy Consensus	Active committers.	DEVEL	2 days (excluding Sat and Sun)	All vetoes on a contribution must be filed and resolved prior to achieving SF (Source Freeze) on the release containing the contribution.

Process Steps

This section describes the voting process steps.

1. Creating a Ballot

For a ballot to be created, an individual with binding voter rights for the action must agree to sponsor the proposal.  The sponsoring individual is responsible for sending an e-mail to the appropriate distribution list announcing to the Community that the ballot is open. The subject line of the e-mail should include the prefix "[VOTE]".  The body of the e-mail should include a description of the item being balloted and may include a summary of any Community discussion.  For PEP and Bugzilla approvals the body of the e-mail should also include a pointer to the PEP or Bugzilla being balloted.  The sponsoring individual is responsible for defining the "Initial Acceptance" and "Final Approval" durations for the ballot.  Durations must not be less than the minimum times defined in the "Level of Approval" section, but may be increased to allow for complexity of the proposal, holiday schedules, vacation of a key stakeholders, etc..  The ballot "Initial Acceptance" and "Final Approval" closing date and time should be included in the e-mail. 

2. Voting

A non-binding vote is cast by sending a reply to the "[VOTE]" e-mail.  The reply should be sent to the same distribution list as the original VOTE e-mail.  The body of the e-mail should include the vote (i.e., "Yes [+1]", "Abstain [0]" or "No [-1]").  All developers are encouraged to express their opinion by voting.

The process for casting binding votes various by action and is documented in PEP 337, OpenPegasus Binding Vote Processes.  Individuals with binding voter rights may use the above non-binding vote process to express their opinions to the Community.  However, only votes cast using the binding votes process for the action will be counted.

Although the sponsoring individual is responsible for defining the ballot durations,  any developer may request a ballot extension of up to 1 week.  If a ballot is extended, the sponsoring individual is responsible for sending an e-mail  to the distribution list announcing the extension.  The subject line of the e-mail should include the prefix "[VOTE]".

Note: It's important to remember that, for lazy consensus and lazy approval votes, a binding veto may be cast after the patch has received initial acceptance and been submitted.  It is the responsibility of the sponsoring individual to resolve any binding vetoes.  A committed change that has been vetoed must be reversed if the veto conditions cannot be satisfied within a reasonable amount of time.

3. Tallying Votes

The sponsoring individual is responsible for tallying the votes and sending an e-mail with the results to the appropriate distribution list.  The subject line of the e-mail should include the prefix "[VOTING RESULTS]".  The body of the e-mail should document the votes as well as include a statement declaring whether or not the ballot was approved.  If the ballot approves a patch, the sponsoring individual is also responsible for adding the X.X.X_APPROVED keyword to the bugzilla.  Once the APPROVED keyword has been added to the bugzilla, the patch may be committed by the bugzilla owner.    For lazy votes with a defined initial acceptance duration period  the [VOTING RESULTS] e-mail is sent after the initial acceptance duration period has elapsed.  For non-lazy votes or lazy votes without a defined initial acceptance duration period this e-mail is sent after the final approval duration period has elapsed.

Frequently Asked Questions

1. Do I have to use this new process?
   Yes. With the approval of this PEP,  Architecture Team meetings will not longer be used to approve PEPs or patches.
   
   
   
2. Does this loosen the requirement to test patches before submitting?
   No. The following text from PEP #002, Pegasus Bug Tracking and Bug Fix Commitment Process is still applicable.
   
   

   Regardless of the etiology of any change to any OpenPegasus CVS file, or group of files, the change:
   

   1)must not break the Pegasus build
   2)must not break the automated Pegasus test cases.
   
   The OpenPegasus community's expectations with respect to build and test of new and modified code are: 1) the source must build and pass all regression tests on at least one supported platform (developer's choice) and 2) the source additionally should be tested on either Linux or Windows. Changes should not be submitted if they are known to break the build or the automated testing process on ANY platform.
   
   
   
3. Is there a statute of limitations on voicing an veto?
   Yes.  Although we strongly encourage individuals to register a veto as soon as possible, all vetoes on a contribution must be filed and resolved prior to achieving SF (Source Freeze) on the release containing the contribution.

    

4. What should I do if a committer is not addressing my veto?
   This would be considered a serious violation of the R-T-C process and should be escalated to the PMC. Committer rights are a privilege that can be revoked.

    

5. As a committer, what should I do if I feel someone is misusing their veto power?

   Any misuse of veto power, should be escalated to the PMC. Veto power is a privilege of committership that can be revoked.
    

6. During the initial acceptance period of a lazy vote I voted "Yes [+1]".  However, after further discussion and consideration, I would like change my vote.  Is this possible?

   Yes, although we would expect this to be a rare occurrence.  You have until the final approval period closes to register a veto.

    

Copyright (c) 2004 EMC Corporation; Hewlett-Packard Development Company, L.P.; IBM Corp.; The Open Group; VERITAS Software Corporation
Copyright (c) 2006 Hewlett-Packard Development Company, L.P.; IBM Corp.; EMC Corporation; Symantec Corporation; The Open Group.

Permission is hereby granted, free of charge, to any person obtaining a copy  of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

THE ABOVE COPYRIGHT NOTICE AND THIS PERMISSION NOTICE SHALL BE INCLUDED IN ALL COPIES OR SUBSTANTIAL PORTIONS OF THE SOFTWARE. THE SOFTWARE IS PROVIDED  "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Template last modified: March 26th 2006 by Martin Kirk
Template version: 1.11