FOSSCUFOSSCU Logo
Home
/
contribution-guide

CONTRIBUTION GUIDELINES

We do all of our development on GitHub. If you are not familiar with GitHub or pull requests, here is an excellent guide to get started.

FINDING AN ISSUE

Here's a list of all our current projects. We use GitHub issues associated with each project to track the work associated with that project. That's where you can find things to work on.

We make extensive use of issue labels to designate the priority, status, and beginner-friendliness of various issues. We have a standard set of labels across all projects, documented here. Here are some of the ones that are most relevant to finding a good issue to work on:

  • Issues available for community contribution:

    • The following tags mark issues that are open for community contribution:
      • help wanted: Open to participation from the community but not necessarily beginner-friendly
      • good first issue: Open to participation from the community and friendly towards new contributors
    • You do not need our permission to work on one of these issues.
    • You may work on an issue labeled good first issue even if it's not your first issue.

  • Issues not available for community contribution:

    • The following tags mark issues that are not open for community contribution:
      • 🔒 member only: Requires infrastructure access or institutional knowledge that would be impractical to provide to the community
    • Do not work on these.

  • Issues not ready for work:

    • The following tags mark issues that are not open for community contribution:
      • 🚧 status: blocked: Blocked by other work that needs to be done first
      • 🧹 status: ticket work required: Needs additional work before it is ready to be taken up
      • 🚦 status: awaiting triage: Has not been triaged by a maintainer
    • Do not work on these.

  • Issues without any of the above labels:

    • These issues may (or may not) be open for contribution.
    • Please add a comment asking one of the maintainers to triage the issue and label it as appropriate.

Check the issue comments/labels to see whether someone else has indicated that they are working on it. If someone is already working on it and there has been activity within the last 7 days, you may want to find a different issue to work on.

Contribution process

Once you've found an issue you'd like to work on, please follow these steps to make your contribution:

  1. Comment on it and say you're working on that issue. This is to avoid conflicts with others also working on the issue. If you've followed the guidelines above, you don't need to ask permission to start work on an issue.
  2. Write your code and submit your pull request. Be sure to read and follow our pull request guidelines!
  3. Wait for code review and address any issues raised as soon as you can.

A note on collaboration: We encourage people to collaborate as much as possible. We especially appreciate contributors reviewing each other's pull requests, as long as you are kind and constructive when you do so.

Proposing a new issue

If you want to work on something that there is no GitHub issue for, follow these steps:

  1. Create a new GitHub issue associated with the relevant repository and propose your change there. Be sure to include implementation details and the rationale for the proposed change.

    • We are very reluctant to accept random pull requests without a related issue created first.

  2. The issue will automatically have the 🚦 status: awaiting triage label applied. Wait for a project maintainer to evaluate your issue and decide whether it's something that we will accept a pull request for.

  3. Once the project maintainer has approved the issue and removed the 🚦 status: awaiting triage label, you may start work on code as described in the "Contribution process" section above.

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

DONATIONS

Recurring donations to Free and Open Source Software Community can be made via Sponsor @FOSS-Community on GitHub Sponsors.

PROJECT LIST

This is a list of all active open source software projects that Creative Commons maintains.

Please read the Contributing Code page for general information on how to get involved. Contribution guidelines specific to an individual project can be found in the README and the CONTRIBUTING files in the root folder of every repository. If you have any questions, don't hesitate to reach out to us through one of our community forums or open a GitHub issue.

website-fossc

fosscu-app

Quickfire

paste.py 🐍

PR GUIDELINES

We ask that contributors to FOSSCU projects submit a pull request with your changes. If you're not familiar with pull requests, please read this GitHub documentation. Here are our expectations for pull requests; following them will expedite the process of merging your code in.

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.

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

  • Make A Branch

    • Please create a separate branch for each issue that you're working on. Do not make changes to the default branch (e.g., master, develop) of your fork.

  • Push Your Code ASAP

    • Push your code as soon as you can. Follow the "early and often" rule.
    • Make a pull request as soon as you can and mark the title with a "[WIP]". You can create a draft pull request.
      • Screenshot: How to create a draft PR?

  • Describe Your Pull Request

    • Use the format specified in the pull request template for the repository. Populate the stencil completely for maximum verbosity.
      • Tag the actual issue number by replacing #[issue_number] e.g. #42. This closes the issue when your PR is merged.
      • Tag the actual issue author by replacing @[author] e.g. @issue_author. This brings the reporter of the issue into the conversation.
      • Mark the tasks off your checklist by adding an x in the [ ] e.g. [x]. This checks off the boxes in your to-do list. The more boxes you check, the better.
    • Describe your change in detail. Too much detail is better than too little.
    • Describe how you tested your change.
      • Check the Preview tab to make sure the Markdown is correctly rendered and that all tags and references are linked. If not, go back and edit the Markdown.
      • Screenshot: Populated pull request

  • Request Review

    • Once your PR is ready, remove the "[WIP]" from the title and/or change it from a draft PR to a regular PR.
    • If a specific reviewer is not assigned automatically, please request a review from the project maintainer and any other interested parties manually.

  • Incorporating Feedback

    • If your PR gets a 'Changes requested' review, you will need to address the feedback and update your PR by pushing to the same branch. You don't need to close the PR and open a new one.
    • Be sure to re-request review once you have made changes after a code review.
      • Screenshot: How to request re-review?
    • Asking for a re-review makes it clear that you addressed the changes that were requested and that it's waiting on the maintainers instead of the other way round.
      • Screenshot: Difference between 'Changes requested' and 'Review required'

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)