wiki:vswitchperf_governance_model
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
wiki:vswitchperf_governance_model [2015/01/29 16:50] Maryam Tahhan |
wiki:vswitchperf_governance_model [2015/02/18 18:05] (current) Maryam Tahhan |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | **Roles:** | + | ==== vswitchperf Governance Model Proposal==== |
| - | * __Contributor:__ Any OPNFV member can be a contributor to this project. Could be a mailing list lurker who asks valuable questions or provides new features/bug fixes for code or documentation as patches. Valuable contributors could and should be invited to become committers. | + | The suggested governance model for the vSwitch Characterization project is a meritocratic model, that in terms of change/edit/review rights gives preference to committers, in other words only project committers can contribute directly to the project repository. Also only committers should be able to review suggested patches in Gerrit. However if anyone would like to become a committer, and actively contribute to the work, they will be more than welcome to formally join the project, there will be no barriers to entry in that respect. |
| - | * __Committer:__ Someone who is committed to the project. Committers will have direct access to the code repository and will be able to review/+1 others patches in Gerrit. | + | |
| + | ===Roles:=== | ||
| + | From [[https://www.opnfv.org/developers/technical-project-governance/tsc-charter|TSC-Charter]] | ||
| + | * __Contributor:__ Most Contributors work with their Committer and their component’s sub-community. They contribute code or other artifacts, but do not have the right to commit to the code base. A Contributor may be promoted to a Committer by the projects’ Committers. | ||
| + | * __Committer:__ A person with rights to commit code or artifacts to the source code management system. The Committers will be the decision makers on design, code, packaging, and patches for their project. They must responsibly participate in the consensus decisions of the project. Committer rights are earned via code contribution and community trust. Committers select and vote for new Committers. | ||
| * __Reviewer:__ Committer. | * __Reviewer:__ Committer. | ||
| * __Maintainer:__ A gatekeeper to the repository, so someone who will ensure that a patch has received the appropriate +1’s and is able to give a +2 in Gerrit. The maintainer is an admin role that provides a +2, but is not a decision maker/benign dictator per se. The Maintainer enforces the agreed process. We will need to assign an overall maintainer. | * __Maintainer:__ A gatekeeper to the repository, so someone who will ensure that a patch has received the appropriate +1’s and is able to give a +2 in Gerrit. The maintainer is an admin role that provides a +2, but is not a decision maker/benign dictator per se. The Maintainer enforces the agreed process. We will need to assign an overall maintainer. | ||
| Line 8: | Line 12: | ||
| ---- | ---- | ||
| - | **How to submit a patch:** | + | ===How to submit a patch:=== |
| Should we have our own development and discuss mailing lists? What does the community think? | Should we have our own development and discuss mailing lists? What does the community think? | ||
| ---- | ---- | ||
| - | **JIRA:** | + | ===JIRA:=== |
| JIRA will be used as a tool to allow us to achieve consensus on a feature before it’s implemented as well as a bug tracking tool. All features to be developed should be entered into JIRA and approved by project committers before implementation starts. | JIRA will be used as a tool to allow us to achieve consensus on a feature before it’s implemented as well as a bug tracking tool. All features to be developed should be entered into JIRA and approved by project committers before implementation starts. | ||
| - | **__Decision making process:__** | + | __**Decision making process:**__ |
| In general the process followed will be that of **lazy consensus**. Committers will be automatically notified (by email) when a new feature is added (For JIRA at least). They will be able to discuss/refine/disagree on the feature. | In general the process followed will be that of **lazy consensus**. Committers will be automatically notified (by email) when a new feature is added (For JIRA at least). They will be able to discuss/refine/disagree on the feature. | ||
| Line 27: | Line 31: | ||
| All bugs should be entered and tracked in JIRA. | All bugs should be entered and tracked in JIRA. | ||
| - | **Patches Review Ground rules:** | + | __**Patches Review Ground rules:**__ |
| A patch should contain a single logical change. For example each Test should be submitted as an individual patch for committers to review. | A patch should contain a single logical change. For example each Test should be submitted as an individual patch for committers to review. | ||
| Line 33: | Line 37: | ||
| Each patch should be related to a particular JIRA issue/feature. | Each patch should be related to a particular JIRA issue/feature. | ||
| - | Each submitted patch will go through a Gerrit review. To move to the next stage, the patch MUST receive two +1s in Gerrit (Under Code-Review i.e. +1 Looks good to me, but someone else must approve) from at least two committers of two different companies. | + | Each submitted patch will go through a Gerrit review. To move to the next stage, the patch MUST receive a +1 in Gerrit (Under Code-Review i.e. +1 Looks good to me, but someone else must approve) from at a committer from a different company. |
| - | Once a patch has received the two required +1s, the patch needs to be +2’d (Under Code-Review i.e. Looks good to me, approved) by the maintainer and pushed to the repo. | + | Once a patch has received the required +1, the patch should be +2’d (Under Code-Review i.e. Looks good to me, approved) by the maintainer and pushed to the repo. |
| In the case of deadlock the same decision making process as specified above will be followed. | In the case of deadlock the same decision making process as specified above will be followed. | ||
| Line 54: | Line 58: | ||
| ---- | ---- | ||
| - | **Developer's Certificate of Origin 1.1** | + | ===Developer's Certificate of Origin 1.1=== |
| + | <code> | ||
| By making a contribution to this project, I certify that: | By making a contribution to this project, I certify that: | ||
| | | ||
| Line 79: | Line 83: | ||
| maintained indefinitely and may be redistributed consistent with | maintained indefinitely and may be redistributed consistent with | ||
| this project or the open source license(s) involved. | this project or the open source license(s) involved. | ||
| + | </code> | ||
wiki/vswitchperf_governance_model.1422550207.txt.gz · Last modified: 2015/01/29 16:50 by Maryam Tahhan
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: Creative Commons Attribution 4.0 International License
