CONTRIBUTING.md (4671B)
1 # Contributing 2 3 We welcome contributions to this project! 4 5 Before you start, we ask that you understand the following guidelines. 6 7 ## Code of conduct 8 9 This project adheres to the Adobe [code of conduct](../CODE_OF_CONDUCT.md). By participating, 10 you are expected to uphold this code. Please report unacceptable behavior to 11 [Grp-opensourceoffice@adobe.com](mailto:Grp-opensourceoffice@adobe.com). 12 13 ## Have a question? 14 15 Start by filing an issue. The existing committers on this project work to reach 16 consensus around project direction and issue solutions within issue threads 17 (when appropriate). 18 19 ### Current areas of work 20 21 The Adobe CAI team has been using this crate as the foundation of Adobe's Content Authenticity Initiative-related products and services since late 2020. As we shift toward making this crate available for open usage, we're aware that there is quite a bit of work to do to create what we'd feel comfortable calling a 1.0 release. We've decided to err on the side of releasing earlier so that people can experiment with it and give us feedback. 22 23 We expect to do work on a number of areas in the next few months while we remain in prerelease (0.x) versions. Some broad categories of work (and thus things you might expect to change) are: 24 25 * We'll be reviewing and refining our APIs for ease of use and comprehension. We'd appreciate feedback on areas that you find confusing or unnecessarily difficult. 26 * We'll also be reviewing our APIs for compliance with Rust community best practices. There are some areas (for example, use of public fields and how we take ownership vs references) where we know some work is required. 27 * Our documentation is incomplete. We'll be working on refining the documentation. 28 * Our testing infrastructure is incomplete. We'll be working on improving test coverage, memory efficiency, and performance benchmarks. 29 30 ### Desired feedback 31 32 We welcome feedback on: 33 34 * API design 35 * Prioritization of upcoming development, especially: 36 * File format support 37 * Assertion support 38 * Optimizations and performance concerns 39 * Bugs or non-compliance with the C2PA spec 40 * Additional platform support 41 42 ## Contributor license agreement 43 44 All third-party contributions to this project must be accompanied by a signed contributor 45 license agreement. This gives Adobe permission to redistribute your contributions 46 as part of the project. [Sign our CLA](https://opensource.adobe.com/cla.html). You 47 only need to submit an Adobe CLA one time, so if you have submitted one previously, 48 you are good to go! 49 50 ## Code reviews 51 52 All submissions should come in the form of pull requests and need to be reviewed 53 by project committers. Read [GitHub's pull request documentation](https://help.github.com/articles/about-pull-requests/) 54 for more information on sending pull requests. 55 56 Code submissions will need to pass all automated tests in place at the time of submission. 57 These include such things as Rust code format, Clippy/lint checks, and unit test coverage. 58 59 We encourage you to raise an issue in GitHub before starting work on a major addition to the crate. 60 This will give us an opportunity to discuss API design and avoid duplicate efforts. 61 62 ### Pull request titles 63 64 The build process automatically adds a pull request (PR) to the [CHANGELOG](CHANGELOG.md) unless the title of the PR begins with `(IGNORE)`. Start PR titles with `(IGNORE)` for minor documentation updates and other trivial fixes that you want to specifically exclude from the CHANGELOG. 65 66 Additionally, the build process takes specific actions if the title of a PR begins with certain special strings: 67 - `(MINOR)`: Increments the minor version, per [semantic versioning](https://semver.org/) convention. **IMPORTANT:** This flag should be used for any API change that breaks compatibility with previous releases while this crate is in prerelease (version 0.x) status. 68 - `(MAJOR)`: Increments the major version number, per [semantic versioning](https://semver.org/) convention. 69 70 ## From contributor to committer 71 72 We love contributions from our community! If you'd like to go a step beyond contributor 73 and become a committer with full write access and a say in the project, you must 74 be invited to the project. The existing committers employ an internal nomination 75 process that must reach lazy consensus (silence is approval) before invitations 76 are issued. If you feel you are qualified and want to get more deeply involved, 77 feel free to reach out to existing committers to have a conversation about that. 78 79 ## Security issues 80 81 Security issues shouldn't be reported on this issue tracker. Instead, 82 [file an issue to our security experts](https://helpx.adobe.com/security/alertus.html).