👍🎉 First off, thank you for taking the time to contribute! 🎉👍
This document describes our guidelines for contributing. They are guidelines, not rules. Use your best judgment and feel free to propose changes to this document in a pull request.
This document can also be found in the AI Alliance
communityrepository.
We welcome contributions to Alliance projects, but contributors must accept certain agreements and conditions.
This project adheres to our Code of Conduct. By participating, you are expected to uphold this code. If you observe unacceptable behavior, follow the instructions in the document to report it.
The AI Alliance utilizes the Linux Foundation’s Developer Certificate of Origin (DCO) on a per-commit basis to enable contributions to Core Projects. The DCO does not require the committer to give away ownership of the contribution - your IP remains yours and others' IP remains theirs.
Using DCO is discussed in more detail below.
The AI Alliance and its members are committed to compliance with applicable antitrust and competition laws. See the AI Alliance Competition Law Guidelines for details.
The community repository contains common files, like this one, that apply to all Alliance core projects under the The-AI-Alliance GitHub organization. Note that some Alliance members also collaborate on other affiliate projects that are managed elsewhere and which were introduced to the Alliance by members seeking additional collaborators. The best way to find out about all the projects is to browse the Alliance website.
In addition, some work is tracked at a high level in GitHub "projects" here for projects that cut across different repos and GitHub organizations.
We follow normal GitOps practices. We ask that all work in a particular repo be contributed as a pull request where it will be, built automatically and tested (for code changes), reviewed by maintainers, and merged when accepted.
As an example, let's use the trust-safety-user-guide repo.
Before you start working on a contribution to this guide review the open issues and open pull requests to see if your contribution or enhancements are already proposed. You might instead be able to join forces with the people already working on these items. If you are unsure about how to contribute an idea, open an issue first to discuss your proposal idea with the maintainers.
Note: Review the Legal section below before making any commits to a repo or fork of one.
To contribute to this repo, you'll use the Fork and Pull model common in many open source repositories. You can follow this process in a local terminal or in the GitHub web UI.
- For details on the local process, check out the GitHub flow documentation from GitHub.
- For details on contributing using the GitHub webpage UI, see Contributing using the GH UI.
When your contribution is ready, you can create a pull request (PR). In general, we follow the standard GitHub pull request process. Follow the template to provide details about your pull request to the maintainers. Before submitting pull requests, run any tests or formatting constraints locally that are defined for the repository, if any. For example, does the repo have a make test command for running the unit tests?
When submitting your PR, give it a title and description which are as clear and detailed as possible.
After submitting a pull request, maintainers will review it and may make suggestions to fix before merging. It will be easier for your pull request to receive reviews if you consider the criteria the reviewers follow while working. Remember to:
- Run tests (if any) locally and ensure that they pass.
- Ensure your contribution is in the proper format, if defined, e.g., documentation conventions.
- Break large changes into a logical series of smaller patches, which are easy to understand individually and combine to solve a broader issue.
- Follow the project's coding and documentation conventions.
For a list of the maintainers, see the MAINTAINERS.md page.
To submit a new bug report, raise an issue in the appropriate repository before creating a pull request. This ensures that the issue is properly tracked. To fix an existing bug, assign yourself a bug from the issues page of the desired repository. Then, submit a pull request for review.
Bugs are tracked as GitHub issues in the corresponding repo.
We have tried to make it as easy as possible to make contributions. This applies to how we handle the legal aspects of contribution.
We follow the Developer's Certificate of Origin 1.1 (DCO) to manage code contributions, which is the same approach that the Linux Kernel community uses.
We ask that all developers include a sign-off statement in the commit message. Here is an example Signed-off-by line, which indicates that the submitter accepts the DCO:
Signed-off-by: John Doe <john.doe@example.com>
This can be included automatically in a commit to a local Git repository using the following command:
git commit -sTip: If a commit is created that did not include the
-soption, the original commit message can be edited by using thegit commit -s --amendcommand. A "force push" must be done afterward to add the amended commit to a PR.
Consider creating a git alias that permanently adds the -s flag to all commits. For example, let's define a cs alias for this purpose:
git config --global alias.cs "commit -s"
...
git cs -m 'Some comment' changed_filesThe alias will be added to your ~/.gitconfig file.
If you don't want to make this a global alias, omit --global and run the command in each repo's root directory where you want to use it. The alias will be added to the .git/config file for your local repo clone.
Unless specifically stated, all Alliance projects are distributed under a suitable "open" license. Use the following guidelines:
| Purpose | License | Website | SPDX License Identifier |
|---|---|---|---|
| Code and Model Weights | Apache License, Version 2.0 | link | link |
| Documentation and other written materials | The Creative Commons License, Version 4.0 - CC BY 4.0 |
link | link |
| Data | CDLA Permissive 2.0 | link | link |
The AI Alliance leaves open the possibility of additional terms concerning safe and responsible use for certain elements in special core projects. For example, some model weights may be open for use, except for harmful purposes. Any decision to use any such additional terms for a core project must be made by the AI Alliance Steering Committee and will be clearly identified in the core project's repository.