Creative Commons - User contributions [en]

File:Bj0.jpg

2014-08-12T22:59:53Z

Dan Mills: Dan Mills uploaded a new version of "File:Bj0.jpg"

File:Bj0.jpg

2014-08-12T22:59:36Z

Dan Mills:

MediaWiki:Anonnotice

2014-06-25T19:21:24Z

Dan Mills:

<div style="background: #37FF84; padding: 1em;">Please note: An account is needed '''only''' to edit the CC Wiki. If you need an account, please email webmaster at creativecommons org and we'll make you an account.</div>

MediaWiki:Anonnotice

2014-06-25T19:20:33Z

Dan Mills:

Please note: An account is needed '''only''' to edit the CC Wiki. If you need an account, please email webmaster at creativecommons org and we'll make you an account.

MediaWiki:Anonnotice

2014-06-12T21:17:27Z

Dan Mills: Created page with "If you need an account, please email webmaster at creativecommons org and we'll make you an account."

If you need an account, please email webmaster at creativecommons org and we'll make you an account.

User:Meryl

2014-06-12T21:04:32Z

Dan Mills: Dan Mills moved page User:Meryl to User:Meryl Mohan: Automatically moved page while renaming the user "Meryl" to "Meryl Mohan"

#REDIRECT [[User:Meryl Mohan]]

2013-10-03T17:55:47Z

Dan Mills: Dan Mills moved page Governance/Community Guidelines to Project Governance/Community Guidelines

TBD - possibly something modeled after:

[https://www.mozilla.org/en-US/about/policies/participation/ https://www.mozilla.org/en-US/about/policies/participation/]

{{ApprovedChangesOnly}}

Governance/New Contributor and Access Policy

2013-10-03T17:27:59Z

Dan Mills: 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...

#REDIRECT [[Project Governance/New Contributor and Access Policy]]

Project Governance/New Contributor and Access Policy

2013-10-03T17:27:45Z

== 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., [https://github.com/creativecommons/ Github] or [http://code.creativecommons.org/ 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 [https://github.com/creativecommons/governance/issues/new 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 [https://github.com/creativecommons/governance/issues/new new issue] with:
#* Title: "..."
#* Body: "...<br>Name: <name><br>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 [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}}
{{IncludesContentFrom|site=www.mozilla.org|page=hacking/commit-access-policy}}

Governance/License Policy

2013-10-03T17:27:01Z

Dan Mills: Dan Mills moved page Governance/License Policy to Project Governance/License Policy: A concern was raised that "Governance" could be confused to mean CC-wide governance, which is not true (CC has a formal legal structure with a nonprofit corpor...

#REDIRECT [[Project Governance/License Policy]]

Project Governance/License Policy

2013-10-03T17:26:46Z

TBD - possibly something modeled after:

[https://www.mozilla.org/MPL/license-policy.html https://www.mozilla.org/MPL/license-policy.html]

{{ApprovedChangesOnly}}

Governance/Modules

2013-10-03T17:24:53Z

Dan Mills: Dan Mills moved page Governance/Modules to Project Governance/Modules: A concern was raised that "Governance" could be confused to mean CC-wide governance, which is not true (CC has a formal legal structure with a nonprofit corporation, etc). S...

#REDIRECT [[Project Governance/Modules]]

Project Governance/Modules

2013-10-03T17:24:38Z

{{Module
|name=Governance
|description=Policies and process for how we distribute authority and govern ourselves; including:
* Development and Implementation of new policies as appropriate for delegation of authority and responsibility
* Management of the source tree
* Balancing different constituencies of the project
* Maintaining the CC identity as we take on new activities

[http://www.mozilla.org/about/roles.html#ultimate-decision-makers Ultimate authority] within the project rests with the owner and peer(s) of this module, and project decisions can be escalated to here.
|owner=[mailto:dan@creativecommons.org Dan Mills]
|peers=
|glist=governance
|url=[[Governance]]
}}

===Governance Sub Modules===

{{Module
|name=Module Ownership System
|description=Healthy operation of the module ownership system, including topics such as:
* Filling vacant roles where appropriate
* Ensuring module owners are fulfilling their responsibilities, and replacing those who are not
* Creating and staffing new modules where new parts of the project evolve.
* Figuring out what to do if a module isn't getting enough attention
* Resolving conflicts among module owners
|owner=[mailto:dan@creativecommons.org Dan Mills]
|peers=
|url=[[Governance/Module_System]]
}}

{{Module
|name=New Contributor and Access Policy
|description=Procedures for new contributors and for requesting and determining commit access.
|owner=[mailto:dan@creativecommons.org Dan Mills]
|peers=
|url=[[Governance/New_Contributor_and_Access_Policy]]
}}

{{Module
|name=Licensing Policy
|description=Policies for deciding how contributors should license code and content created for the project, as well as for determining whether 3rd-party code or content may be imported or used.
|owner=[mailto:dan@creativecommons.org Dan Mills]
|peers=
|url=[[Governance/License_Policy]]
}}

{{ApprovedChangesOnly}}
{{IncludesContentWithLicense|page=Modules/All}}

Governance/Module System

2013-10-03T17:22:48Z

Dan Mills: Dan Mills moved page Governance/Module System to Project Governance/Module System: A concern was raised that "Governance" could be confused to mean CC-wide governance, which is not true (CC has a formal legal structure with a nonprofit corporat...

#REDIRECT [[Project Governance/Module System]]

Project Governance/Module System

2013-10-03T17:22:33Z

== Introduction ==

Creative Commons software products and technical activities are diverse and larger than what a single person can (or should) directly do by themselves. Moreover, we wish to be as open, inclusive, and transparent as possible, given the nature of our organization and our values. Thus, we seek to organize ourselves in a way that delegates decision-making authority to the edges, while at the same time promoting individuals who prove themselves to be trustworthy and capable. In other words: we self-organize as a meritocracy, insofar as it is possible for us to do so.

Taking the template from the Mozilla governance system (see [https://www.mozilla.org/hacking/module-ownership.html here]), we break up our code and activities into "Modules", each of which has a Module Owner. A module is, in the case of code, a piece of functionality, or in the case of non-code, an activity, with reasonably well-defined boundaries. Some of the below explanation is code-focused, but analogous points can be made for non-code.

The work of the module owners and the health of the system are overseen by the owner and peers of the "Module Ownership" module. A number of larger modules (for example, the Governance module) have sub-modules subordinate to them. The module owner and peers of the appropriate module is responsible for sub-module ownership appointment and removal in those areas.

These wiki pages are used to document the rules and policies of the system, as well as the current set of modules, module owners, and peers.

== The Module Owner Role ==

A "module owner" is the person to whom leadership of a module's work has been delegated. The responsibilities of module ownership might include, in the case of a code module: improving code quality, implementing revisions and innovations as appropriate, coordinating development with that of the rest of the codebase, developing and maintaining a shared understanding of where the module is headed, developing APIs where appropriate, documenting as much as possible, responding appropriately to code contributions, design suggestions and stated needs of the community, and creating an environment where competent newcomers are welcomed and included.

A module owner's OK is required to check code into that module. In exchange, we expect the module owner to care about what goes in, respond to patches submitted by others, and be able to appreciate code developed by other people. Module owners have a fair amount of flexibility in how they do this. We do not have an elaborate set of rules or procedures for how module owners manage their modules. If it works and the community is generally happy, great. If it doesn't, let's fix it and learn.

Module Owners need not do all the work of managing the module themselves. Module owners may identify others who can also approve code for check-in into a module. These developers are known as "peers" and ought to possess many of the qualities of a good module owner. Module owners must designate to a peer the evaluation of their own code; module owners are not permitted to review their own code. If there is no module owner, the OK of a peer is sufficient to check code into that module.

Module owners are not tyrants. They are chartered to make decisions with input from the community and in the best interests of the community. Module owners are not required to make code changes or additions solely because the community wants them to do so. (Like anyone else, the module owners may write code because they want to, because their employers want them to, because the community wants them to, or for some other reason.) Module owners do need to pay attention to patches submitted to that module. However "pay attention" does not mean agreeing to every patch. Some patches may not make sense for our project; some may be poorly implemented. Module owners have the authority to decline a patch; this is a necessary part of the role. We ask the module owners to describe in the relevant bug their reasons for wanting changes to a patch, for declining it altogether, or for postponing review for some period. We don't ask or expect them to rewrite patches to make them acceptable. Similarly, module owners may need to delay review of a promising patch due to an upcoming deadline. For example, a patch may be of interest, but not for the next milestone. In such a case it may make sense for the module owner to postpone review of a patch until after matters needed for a milestone have been finalized. Again, we expect this to be described in the relevant bug. And of course, it shouldn't go on very often or for very long or escalation and review is likely.

== Escalation and Review ==

The owner and peers of the Module Ownership module will get involved if controversy develops and cannot be resolved otherwise. A module owner may ask for a public statement of agreement with a particular action. Sometimes other contributors suggest ways in which a module owner might improve. Sometimes there is ongoing controversy. We prefer that the community resolve these issues when possible, but acknowledge that this can't happen all the time. We try to avoid making absolute decisions like "this must happen" but will do so if required.

== Criteria for Module Ownership ==

There are a number of important elements of good module ownership. First is the person's expertise with the area in question. But over time we've learned that a set of additional criteria is also important, and that a great hacker can be a poor module owner. The criteria that go into the mix for a good module owner include:

# Expertise with the code in or activity of the module
# Current level of involvement with the module
# Understanding/vision of where the module ought to be headed
# Ability to communicate with a diverse, geographically distributed community
# Willingness to evaluate contributions on their merits, regardless of their source (i.e., no 'not invented here' syndrome)
# Ability to consider varying perspectives and needs of different consumers of that module

And particularly for code modules:

# Appropriate understanding of the project's codebase as a whole and the module's relationship to it
# Ability to evaluate code for that module, including contributions of patches and new features
# Ability to evaluate impact of code on other parts of the codebase
# Ability to resolve different needs through factoring or other abstraction techniques when appropriate

== Designating a Module Owner ==

Appointment, removal and change of sub-module owners and peers is normally the work of the owner and peers of the module covering that area of the project. The Module Ownership Module team will generally intervene only in cases of dispute.

We prefer that an individual work with a module for some time and demonstrate the ability to fulfill most of the criteria most of the time (we're not naive enough to require perfection), and that a consensus form about designating this person as the module owner. This way the designation is more of a confirmation than an appointment. We haven't always done this, and we haven't always done it well.

This means that there will be times when there is no module owner. In particular, in some cases modules have received little attention, have started to rot, and some brave soul steps up to figure things out and get us back on track. We'll shower these folks with thanks for tackling the job, however we may not immediately designate them as module owners. Almost by definition, it will be difficult for this person to have demonstrated some of the criteria, until some time is spent working with the module. It's possible that someone's expertise is broad and so deep enough to do this, but we would expect this to be the exception rather than the rule.

In determining a module owner, the criteria above are not necessarily accorded the same weight for each module. The importance of a particular element depends on the module. For example, code criteria 1 (appropriate understanding of the codebase as a whole and the module's relationship to it) and 3 (ability to evaluate impact of code on other parts of the codebase) will be of less importance for modules that are self-contained, but of great importance for modules containing core technologies which affect other parts of the code significantly. Similarly, general criterion 6 (ability to consider varying perspectives and needs of different consumers of that module) and code criterion 4 (ability to resolve different needs through factoring or other abstraction techniques when appropriate) will be less important to a module which serves a specific, clearly defined function for a small number of contributors, and critical to a module which supports a variety of uses and a broad contributor group.

== Creating a New Module ==

Ideally, a Module should exist for all significant chunks of work or code within our project. However, we prefer to only designate modules for code or activities that are likely to remain permanently (or at least long-term) in our project. Therefore, brand new efforts are usually developed outside the module system, and new modules are created once it is evident and widely agreed-upon that a codebase or activity has met the requirements for module ownership.

If you are confident that a new module is needed, you should post a message to the [[Governance/Modules#Module_Ownership_System|Module Ownership module]].

== Poorly Maintained Modules ==

Periodically a module is not well maintained and no longer interacts well with the rest of the codebase. This can happen where there is no module owner, or when a designated module owner is too busy with other things to tend to the module. Conceivably it could happen when a module owner is active, but has an approach to a module that the community in general believes is inappropriate. We prefer that the development community identify such modules, propose a solution, and implement improvement. If this can't happen for some reason then the Module Ownership Peers will get involved to find the best possible resolution.

{{ApprovedChangesOnly}}
{{IncludesContentWithLicense|site=www.mozilla.org|page=hacking/module-ownership.html}}

Governance

2013-10-03T17:20:18Z

Dan Mills: Dan Mills moved page Governance to Project Governance: A concern was raised that "Governance" could be confused to mean CC-wide governance, which is not true (CC has a formal legal structure with a nonprofit corporation, etc). So moving for cla...

#REDIRECT [[Project Governance]]

Project Governance

2013-10-03T17:20:02Z

Creative Commons software products and technical work are developed as open source projects, and governed as a meritocracy. Our community is structured as a virtual organization where authority is distributed to both volunteer and employed community members as they show their abilities through contributions to the project.

Our governance system has been in large part modeled after the [https://mozilla.org/ Mozilla project], which operates under a '''module ownership governance system'''. You can read more about the way Mozilla defines and uses this system [https://www.mozilla.org/en-US/about/governance/ here]. However, note that although we have used this as a starting point, Creative Commons will chart its own path and set its own rules. Do not expect the systems to be identical.

=== Policies ===

* [[Governance/Module_System|Modules and Module Ownership]]
* [[Governance/License_Policy|License Policy]]
* [[Governance/New_Contributor_and Access_Policy|Becoming a Contributor and Access Policy]]
* [[Governance/Community_Guidelines|Community Participation Guidelines]]

=== Modules ===

* [[Governance/Modules|Current modules and module owners]]

{{ApprovedChangesOnly}}
{{IncludesContentWithLicense|page=Governance}}

Project Governance/Modules

2013-09-23T20:51:24Z

Dan Mills: Protected "Governance/Modules" (‎[edit=sysop] (indefinite) ‎[move=sysop] (indefinite))

{{Module
|name=Governance
|description=Policies and process for how we distribute authority and govern ourselves; including:
* Development and Implementation of new policies as appropriate for delegation of authority and responsibility
* Management of the source tree
* Balancing different constituencies of the project
* Maintaining the CC identity as we take on new activities

[http://www.mozilla.org/about/roles.html#ultimate-decision-makers Ultimate authority] within the project rests with the owner and peer(s) of this module, and project decisions can be escalated to here.
|owner=[mailto:dan@creativecommons.org Dan Mills]
|peers=
|glist=governance
|url=[[Governance]]
}}

===Governance Sub Modules===

{{Module
|name=Module Ownership System
|description=Healthy operation of the module ownership system, including topics such as:
* Filling vacant roles where appropriate
* Ensuring module owners are fulfilling their responsibilities, and replacing those who are not
* Creating and staffing new modules where new parts of the project evolve.
* Figuring out what to do if a module isn't getting enough attention
* Resolving conflicts among module owners
|owner=[mailto:dan@creativecommons.org Dan Mills]
|peers=
|url=[[Governance/Module_System]]
}}

{{Module
|name=New Contributor and Access Policy
|description=Procedures for new contributors and for requesting and determining commit access.
|owner=[mailto:dan@creativecommons.org Dan Mills]
|peers=
|url=[[Governance/New_Contributor_and_Access_Policy]]
}}

{{Module
|name=Licensing Policy
|description=Policies for deciding how contributors should license code and content created for the project, as well as for determining whether 3rd-party code or content may be imported or used.
|owner=[mailto:dan@creativecommons.org Dan Mills]
|peers=
|url=[[Governance/License_Policy]]
}}

{{ApprovedChangesOnly}}
{{IncludesContentWithLicense|page=Modules/All}}

Project Governance/Modules

2013-09-23T20:51:12Z

Dan Mills:

{{Module
|name=Governance
|description=Policies and process for how we distribute authority and govern ourselves; including:
* Development and Implementation of new policies as appropriate for delegation of authority and responsibility
* Management of the source tree
* Balancing different constituencies of the project
* Maintaining the CC identity as we take on new activities

[http://www.mozilla.org/about/roles.html#ultimate-decision-makers Ultimate authority] within the project rests with the owner and peer(s) of this module, and project decisions can be escalated to here.
|owner=[mailto:dan@creativecommons.org Dan Mills]
|peers=
|glist=governance
|url=[[Governance]]
}}

===Governance Sub Modules===

{{Module
|name=Module Ownership System
|description=Healthy operation of the module ownership system, including topics such as:
* Filling vacant roles where appropriate
* Ensuring module owners are fulfilling their responsibilities, and replacing those who are not
* Creating and staffing new modules where new parts of the project evolve.
* Figuring out what to do if a module isn't getting enough attention
* Resolving conflicts among module owners
|owner=[mailto:dan@creativecommons.org Dan Mills]
|peers=
|url=[[Governance/Module_System]]
}}

{{Module
|name=New Contributor and Access Policy
|description=Procedures for new contributors and for requesting and determining commit access.
|owner=[mailto:dan@creativecommons.org Dan Mills]
|peers=
|url=[[Governance/New_Contributor_and_Access_Policy]]
}}

{{Module
|name=Licensing Policy
|description=Policies for deciding how contributors should license code and content created for the project, as well as for determining whether 3rd-party code or content may be imported or used.
|owner=[mailto:dan@creativecommons.org Dan Mills]
|peers=
|url=[[Governance/License_Policy]]
}}

{{ApprovedChangesOnly}}
{{IncludesContentWithLicense|page=Modules/All}}

Project Governance/Community Guidelines

2013-09-23T20:50:52Z

Dan Mills: Protected "Governance/Community Guidelines" (‎[edit=sysop] (indefinite) ‎[move=sysop] (indefinite))

TBD - possibly something modeled after:

[https://www.mozilla.org/en-US/about/policies/participation/ https://www.mozilla.org/en-US/about/policies/participation/]

{{ApprovedChangesOnly}}

Project Governance/Community Guidelines

2013-09-23T20:50:41Z

Dan Mills:

TBD - possibly something modeled after:

[https://www.mozilla.org/en-US/about/policies/participation/ https://www.mozilla.org/en-US/about/policies/participation/]

{{ApprovedChangesOnly}}

Project Governance/New Contributor and Access Policy

2013-09-23T20:50:27Z

Dan Mills: Protected "Governance/New Contributor and Access Policy" (‎[edit=sysop] (indefinite) ‎[move=sysop] (indefinite))

Project Governance/New Contributor and Access Policy

2013-09-23T20:50:11Z

Dan Mills:

Project Governance/License Policy

2013-09-23T20:49:47Z

Dan Mills: Protected "Governance/License Policy" (‎[edit=sysop] (indefinite) ‎[move=sysop] (indefinite))

TBD - possibly something modeled after:

[https://www.mozilla.org/MPL/license-policy.html https://www.mozilla.org/MPL/license-policy.html]

{{ApprovedChangesOnly}}

Project Governance/License Policy

2013-09-23T20:49:35Z

Dan Mills:

TBD - possibly something modeled after:

[https://www.mozilla.org/MPL/license-policy.html https://www.mozilla.org/MPL/license-policy.html]

{{ApprovedChangesOnly}}

2013-09-23T20:40:18Z

Dan Mills: Changed protection level for "Governance" (‎[edit=sysop] (indefinite) ‎[move=sysop] (indefinite))

{{ApprovedChangesOnly}}

Creative Commons software products and technical work are developed as open source projects, and governed as a meritocracy. Our community is structured as a virtual organization where authority is distributed to both volunteer and employed community members as they show their abilities through contributions to the project.

Our governance system has been in large part modeled after the [https://mozilla.org/ Mozilla project], which operates under a '''module ownership governance system'''. You can read more about the way Mozilla defines and uses this system [https://www.mozilla.org/en-US/about/governance/ here]. However, note that although we have used this as a starting point, Creative Commons will chart its own path and set its own rules. Do not expect the systems to be identical.

=== Policies ===

* [[Governance/Module_System|Modules and Module Ownership]]
* [[Governance/License_Policy|License Policy]]
* [[Governance/New_Contributor_and Access_Policy|Becoming a Contributor and Access Policy]]
* [[Governance/Community_Guidelines|Community Participation Guidelines]]

=== Modules ===

* [[Governance/Modules|Current modules and module owners]]

{{IncludesContentWithLicense|page=Governance}}