Difference between revisions of "Project Governance/New Contributor and Access Policy"
(→Problems With Your Account) |
m (Dan Mills moved page Governance/New Contributor and Access Policy to Project Governance/New Contributor and Access Policy: A concern was raised that "Governance" could be confused to mean CC-wide governance, which is not true (CC has a formal l...) |
||
(2 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
− | |||
− | |||
== Introduction == | == Introduction == | ||
Line 85: | Line 83: | ||
If you suspect your account has been compromised, or are having trouble accessing your account, please [https://github.com/creativecommons/governance/issues/new file a new issue] with the "Account problem" label (preferred), or if you are not able to access Github, please send an email to [mailto:admin@creativecommons.org admin@creativecommons.org]. | If you suspect your account has been compromised, or are having trouble accessing your account, please [https://github.com/creativecommons/governance/issues/new file a new issue] with the "Account problem" label (preferred), or if you are not able to access Github, please send an email to [mailto:admin@creativecommons.org admin@creativecommons.org]. | ||
+ | {{ApprovedChangesOnly}} | ||
{{IncludesContentWithLicense|site=www.mozilla.org|page=hacking/committer}} | {{IncludesContentWithLicense|site=www.mozilla.org|page=hacking/committer}} | ||
{{IncludesContentFrom|site=www.mozilla.org|page=hacking/commit-access-policy}} | {{IncludesContentFrom|site=www.mozilla.org|page=hacking/commit-access-policy}} |
Latest revision as of 17:27, 3 October 2013
Contents
Introduction
This document outlines the policy and procedure for getting and maintaining direct commit access to any source code or document repository that is managed under the Creative Commons Module System.
These rules do not apply to those contributing by submitting patches or pull requests. In those cases, a contributor with appropriate access will (at their discretion and following the rules of the relevant modules) perform the direct commit.
Our goal is to balance technical and social means of controlling access to CC repositories. On a technical level, only those who follow the procedure in this document and meet the requirements will be given access to directly commit to CC repositories. On a social level, having commit access implies a certain level of responsibility and adherence to the rules of the project or the individual repository. These rules are in place to enable all contributors to participate, while also minimizing both management overhead and also risk to the development process. In other words: just because you have an account with write access doesn't mean you can commit anything you want, wherever you want.
Requirements
The following is a summary of the requirements necessary for a new contributor. See the procedure below for details.
- A Github account and email address
- All levels of access require both a Github account and an email address.
- A new bug/ticket for the request
- All levels of access require that the contributor open a ticket, so that we can document that all requirements have been met.
- Contributor Agreement
- A legal agreement. All levels of access require that contributors sign and submit this agreement (possibly electronically).
- Voucher(s)
- Another existing member of the project must vouch for the contributor. Depending on the level of access, more vouchers, or from specific roles, may be necessary.
Access Levels
There are currently two levels of commit access to CC repositories, regardless of where they might be hosted (e.g., Github or code.creativecommons.org). Each repository should be labeled as "level 1" or "level 2", but in its absence "level 2" is assumed. However, there are some exceptions where a "level 1" contributor may contribute to specific portions of a "level 2" repository, see below for details.
- Level 1 (basic access)
- Repositories marked "level 1" require any other contributor to vouch for the new contributor.
- This level is generally appropriate for new repositories still in an experimental phase. It is also appropriate for access to localization files, even for "level 2" projects, *except* where the content being localized is legal in nature.
- Level 2 (general access)
- Repositories marked "level 2" require two vouchers: one from a top-level module owner (of any module), and one from a peer of code stored in any "level 2" repository.
- This level is generally appropriate for most code and website content, except for legal content (e.g., legal code).
- Level 3 (sensitive repositories)
- Repositories marked "level 3" require two vouchers, as in level 2, but one of them must be of the owner of the level 3 repository the contributor wishes to contribute to. Unlike other levels, gaining level 3 access does not grant access to all level 3 repositories, but rather only the level 3 repository approved by the module owner. Gaining access to additional level 3 repositories requires only one voucher from the responsible module owner.
- This level is generally appropriate for specific, sensitive documents such as core code of a product or legal code.
Requesting Access
Here is a list of the steps that need to happen to become a CC committer. Employment with any particular entity (including Creative Commons HQ or Affiliates) does not change the need to follow these steps.
- Read this document carefully and decide which level of access you need to apply for.
- Open a new issue for your request. Add the "Repository Access Request" label and make sure you include:
- your name
- your email address
- the level of access you are requesting
- if you are requesting access to any level 3 repositories, list them
- If you have not already done so, complete the Contributor Agreement (see Contributor Agreement section below).
- Ensure all the required vouchers for the level and repository in question are in the issue (as comments).
- A CC representative will double-check that the needed info is recorded and, if so, give you the necessary access or next steps.
Contributor Agreement
All contributors must agree to the Contributor Agreement. A copy of the agreement is here (link TBD...). In order to agree, you must:
- Be sure you have read and agree to the agreement.
- Create a new issue with:
- Title: "..."
- Body: "...
Name: <name>
Email address: <address>"
(perhaps something like https://www.mozilla.org/hacking/notification/acceptance-email.txt ?)
Vouchers
New contributors will need one or more vouchers, depending on the level of access being requested. Each voucher must come from a someone that already has commit access and be confident enough in you to be associated with your contributions. Your vouchers are responsible for your any problems you cause in the unfortunate event that you break things and leave. They are responsible for making sure you know and follow the rules in general, act promptly to fix regressions, are aware of and commit procedures and repository rules, etc. The vouchers' responsibility extends for three months after you are granted source code commit access. If you've lived in the tree without significant issues for three months, we assume you're ready to stand on your own. If somehow there are persistent problems during the first three months, the vouchers have the authority to request revocation of your access during this period. Vouching is a big responsibility, so people will make this commitment only after due consideration. A voucher who helps people who aren't prepared get access to the source tree will find that his or her own credibility suffers as well.
Revoking Commit Access
If someone consistently causes difficulties with these source repositories due to poor behavior or other serious problems then commit access may be revoked. The process for this is for one or more committers with concerns to notify the owner of the New Contributor and Access Policy sub-module with clear examples of the problem. Do not do so carelessly, based on passing irritation, or without a sense that you are not alone in your concerns. The New Contributor and Access Policy owner will investigate or cause an investigation to occur, privately at first and perhaps completely privately.
Dormant Accounts
If your account in a particular repository is inactive for more than 6 months, it may be deactivated. However, the knowledge that you have achieved a particular level of access is retained. Therefore, getting your account reactivated is a simple matter of filing a new issue requesting access be reinstated. No additional vouchers are necessary.
Problems With Your Account
If you suspect your account has been compromised, or are having trouble accessing your account, please file a new issue with the "Account problem" label (preferred), or if you are not able to access Github, please send an email to admin@creativecommons.org.
Do not edit this page unless you are confident you are allowed to do so. See this page for details. |
www.mozilla.org|wiki.mozilla.org}}{{#if:hacking/committer|/hacking/committer|}} {{#if:www.mozilla.org|www.mozilla.org|wiki.mozilla.org}}{{#if:hacking/committer|/hacking/committer|}}], and is licensed under CC BY-SA 3.0. |
www.mozilla.org|wiki.mozilla.org}}{{#if:hacking/commit-access-policy|/hacking/commit-access-policy|}} {{#if:www.mozilla.org|www.mozilla.org|wiki.mozilla.org}}{{#if:hacking/commit-access-policy|/hacking/commit-access-policy|}}]. |