Contributing Code

We do all of our development on GitHub and are generally open to pull requests and proposals for new community-maintained projects. We would especially like help with reviving projects that CC's engineering team does not have the time to actively work on (such as our WordPress plugin and license chooser widget). We're also looking to improve our documentation and increase our automated test coverage across pretty much all our projects, so help with that would be greatly appreciated.

If you are not familiar with GitHub, here is an excellent guide to get started.

Working on an existing project

Here's a list of all our current projects.

We are actively working on documenting and licensing them and adding self-contained contribution guidelines but we still have a lot of work ahead of us. We're open to contributions on any of our public projects, as long as they have a license. The license for a project is located in a file named LICENSE in the root directory of the repository. If the repository you want to contribute to has no license file, please create a GitHub issue attached to that repository and we'll prioritize setting those up.

You may also create GitHub issues for any other missing infrastructure such as a README file.

Working on open issues

We track all our work via the GitHub issues associated with a repository and that's where you can find things to work on. First, check the labels on the issue you're interested in:

  • Issues labeled "in progress" are generally not available, but may be available if there has been no activity on the issue or related PR for over a week.
  • Issues labeled "help wanted" or "good first issue" have been identified as available for community contribution. Feel free to work on issues labeled "good first issue" even if it is not your first issue.
  • If the issue does not have either of those labels, it may still be open for contribution.

Once you have identified an issue you'd like to work on, follow these steps:

  1. Comment on it and say you'd like to work on that issue.
  2. Wait for someone to confirm that you may work on the issue before writing any code. The person who confirms will add an "in progress" label to the issue to indicate that the issue has been assigned.
  3. Once the issue has been updated to "in progress", write your code and submit your pull request (be sure to read and follow the Pull request guidelines guide below!)
  4. Wait for code review and address any issues raised as soon as you can.

Even if you're not done with the issue, create a draft pull request and push your code early and often. If we haven't heard from you in over a week and someone else expresses interest in that issue, we may assign it to the new person.

Proposing a new issue

If you want to work on something that there is no GitHub issue for, then propose the change in one of our community forums or create a a new GitHub issue associated with the relevant repository amd propose your change there. Be sure to include implementation details and the rationale for the proposed change.

If the project has a roadmap documented in the README, checking the roadmap to see if the feature is already in our pipeline would be a good first step.

When in doubt, ask a question on one of our community forums.

Pull request guidelines

We aim to review pull requests within three business days.*. If it has been over three business days and you have not received any feedback, feel free to follow up.

  • Read and follow the contributing guidelines and code of conduct for the project. Here are screenshots of where to find them for first time contributors and previous contributors.
  • Use the format specified in pull request template for the repository if one exists.
  • Describe your change in detail. Too much detail is better than too little.
  • Describe how you tested your change.
  • If a reviewer is not assigned automatically, manually request a review from either the repository maintainer (if you have that information) or @creativecommons/engineering.

Code guidelines

  • Write comprehensive and robust tests that cover the changes you've made in your work.
  • Follow the appropriate code style standards for the language and framework you're using (e.g. PEP 8 for Python).
  • Write readable code – keep functions small and modular and name variables descriptively.
  • Document your code thoroughly.
  • Make sure all the existing tests pass.
  • User-facing code should support the following browsers:
    • Chrome (Webkit-Blink / 22+)
    • Firefox (Gecko / 28+)
    • Edge (Chromium based / 12+)
    • Opera (Chromium-Blink / 12.1+)
    • Safari (Apple’s Webkit / 7+)
    • IE 11 (Trident)

* CC staff work Monday through Friday and are not available on weekends and national holidays (the specific holidays observed vary based on the person's location). CC is closed between Christmas Eve and New Years' Day every year and for a few days following the CC Global Summit. Also, our availability during events such as the CC Global Summit and our biannual staff meetups is limited.

New projects

We are also open to working on or hosting projects that are related to the Creative Commons licenses or general mission. Our Google Summer of Code project ideas list is a good place to find ideas we'd like implemented. If you're interested in working on one of them, please propose it in one of our community forums (you don't need to be a student, anyone is welcome to work on those ideas) and work out implementation details with CC staff members before you write any code. If you want to suggest a new project idea, follow the same process.

In general, we'd like any new projects to use Python, WordPress/PHP, and/or JavaScript (our framework of choice is Vue.js) so that our team can help review and maintain the project.

Back to top