Skip to content

Commit 10a6b11

Browse files
crandmckcrandmck
authored
Add required open source files and PR template (#2)
1 parent 42dafb1 commit 10a6b11

File tree

4 files changed

+213
-0
lines changed

4 files changed

+213
-0
lines changed

‎.github/PULL_REQUEST_TEMPLATE.md‎

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,13 @@
1+
## Changes in this pull request
2+
<!-- Give a description of what has changed -->
3+
4+
## Types of changes
5+
<!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
6+
7+
- [ ] Bug fix (non-breaking change which fixes an issue)
8+
- [ ] New feature (non-breaking change which adds functionality)
9+
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
10+
11+
## Checklist
12+
- [ ] All applicable changes have been documented
13+
- [ ] Any `TO DO` items (or similar) have been entered as GitHub issues and the link to that issue has been included in a comment

‎CODE_OF_CONDUCT.md‎

Lines changed: 74 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,74 @@
1+
# Adobe code of conduct
2+
3+
## Our pledge
4+
5+
In the interest of fostering an open and welcoming environment, we as
6+
contributors and maintainers pledge to making participation in our project and
7+
our community a harassment-free experience for everyone, regardless of age, body
8+
size, disability, ethnicity, gender identity and expression, level of experience,
9+
nationality, personal appearance, race, religion, or sexual identity and
10+
orientation.
11+
12+
## Our standards
13+
14+
Examples of behavior that contributes to creating a positive environment
15+
include:
16+
17+
* Using welcoming and inclusive language.
18+
* Being respectful of differing viewpoints and experiences.
19+
* Gracefully accepting constructive criticism.
20+
* Focusing on what is best for the community.
21+
* Showing empathy towards other community members.
22+
23+
Examples of unacceptable behavior by participants include:
24+
25+
* The use of sexualized language or imagery and unwelcome sexual attention or
26+
advances.
27+
* Trolling, insulting/derogatory comments, and personal or political attacks.
28+
* Public or private harassment.
29+
* Publishing others' private information, such as a physical or electronic
30+
address, without explicit permission.
31+
* Other conduct which could reasonably be considered inappropriate in a
32+
professional setting.
33+
34+
## Our responsibilities
35+
36+
Project maintainers are responsible for clarifying the standards of acceptable
37+
behavior and are expected to take appropriate and fair corrective action in
38+
response to any instances of unacceptable behavior.
39+
40+
Project maintainers have the right and responsibility to remove, edit, or
41+
reject comments, commits, code, wiki edits, issues, and other contributions
42+
that are not aligned to this Code of Conduct, or to ban temporarily or
43+
permanently any contributor for other behaviors that they deem inappropriate,
44+
threatening, offensive, or harmful.
45+
46+
## Scope
47+
48+
This Code of Conduct applies both within project spaces and in public spaces
49+
when an individual is representing the project or its community. Examples of
50+
representing a project or community include using an official project e-mail
51+
address, posting via an official social media account, or acting as an appointed
52+
representative at an online or offline event. Representation of a project may be
53+
further defined and clarified by project maintainers.
54+
55+
## Enforcement
56+
57+
Instances of abusive, harassing, or otherwise unacceptable behavior may be
58+
reported by contacting the project team at [email protected]. All
59+
complaints will be reviewed and investigated and will result in a response that
60+
is deemed necessary and appropriate to the circumstances. The project team is
61+
obligated to maintain confidentiality with regard to the reporter of an incident.
62+
Further details of specific enforcement policies may be posted separately.
63+
64+
Project maintainers who do not follow or enforce the code of conduct in good
65+
faith may face temporary or permanent repercussions as determined by other
66+
members of the project's leadership.
67+
68+
## Attribution
69+
70+
This code of conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
71+
available at [https://contributor-covenant.org/version/1/4][version].
72+
73+
[homepage]: https://contributor-covenant.org
74+
[version]: https://contributor-covenant.org/version/1/4/

‎CONTRIBUTING.md‎

Lines changed: 104 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,104 @@
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+
[[email protected]](mailto:[email protected]).
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+
Some broad categories of work (and thus things you might expect to change) are:
22+
23+
* 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.
24+
* We'll also be reviewing our APIs for compliance with best practices.
25+
* Our documentation is incomplete. We'll be working on refining the documentation.
26+
* Our testing infrastructure is incomplete. We'll be working on improving test coverage, memory efficiency, and performance benchmarks.
27+
28+
### Desired feedback
29+
30+
We welcome feedback on:
31+
32+
* API design
33+
* Prioritization of upcoming development, especially:
34+
* File format support
35+
* Assertion support
36+
* Optimizations and performance concerns
37+
* Bugs or non-compliance with the C2PA spec
38+
* Additional platform support
39+
40+
## Contributor license agreement
41+
42+
All third-party contributions to this project must be accompanied by a signed contributor
43+
license agreement. This gives Adobe permission to redistribute your contributions
44+
as part of the project. [Sign our CLA](https://opensource.adobe.com/cla.html). You
45+
only need to submit an Adobe CLA one time, so if you have submitted one previously,
46+
you are good to go!
47+
48+
## Code reviews
49+
50+
All submissions should come in the form of pull requests and need to be reviewed
51+
by project committers. Read [GitHub's pull request documentation](https://help.github.com/articles/about-pull-requests/)
52+
for more information on sending pull requests.
53+
54+
Code submissions will need to pass all automated tests in place at the time of submission.
55+
These include such things as Rust code format, Clippy/lint checks, and unit test coverage.
56+
57+
We encourage you to raise an issue in GitHub before starting work on a major addition to the crate.
58+
This will give us an opportunity to discuss API design and avoid duplicate efforts.
59+
60+
### Pull request titles
61+
62+
Titles of pull requests that target a long-lived branch such as _main_ or a release-specific branch should follow [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/#specification). This means that the first word of the pull request title should be one of the following:
63+
64+
* `build`
65+
* `chore`
66+
* `ci`
67+
* `docs`
68+
* `feat`
69+
* `fix`
70+
* `perf`
71+
* `refactor`
72+
* `revert`
73+
* `style`
74+
* `test`
75+
76+
Optionally, but preferred, a scope can be added in parentheses after the type. The scope should be the name of the module or component that the commit affects. For example, `feat(api): Introduce a new API to validate 1.0 claims`.
77+
78+
If more detail is warranted, add a blank line and then continue with sentences (these sentences should be punctuated as such) and paragraphs as needed to provide that detail. There is no need to word-wrap this message.
79+
80+
For example:
81+
82+
```text
83+
feat(api): Introduce a new API to validate 1.0 claims
84+
85+
Repurpose existing v2 API for 0.8 compatibility (read: no validation) mode.
86+
```
87+
88+
The conventional commit message requirement does not apply to individual commits within a pull request, provided that those commits will be squashed when the PR is merged and the resulting squash commit does follow the conventional commit requirement. This may require the person merging the PR to verify the commit message syntax when performing the squash merge.
89+
90+
TIP: For single-commit PRs, ensure the commit message conforms to the conventional commit requirement, since by default that will also be the title of the PR.
91+
92+
## From contributor to committer
93+
94+
We love contributions from our community! If you'd like to go a step beyond contributor
95+
and become a committer with full write access and a say in the project, you must
96+
be invited to the project. The existing committers employ an internal nomination
97+
process that must reach lazy consensus (silence is approval) before invitations
98+
are issued. If you feel you are qualified and want to get more deeply involved,
99+
feel free to reach out to existing committers to have a conversation about that.
100+
101+
## Security issues
102+
103+
Do not create a public GitHub issue for any suspected security vulnerabilities. Instead, please file an issue through [Adobe's HackerOne page](https://hackerone.com/adobe?type=team).
104+
For more information on reporting security issues, see [SECURITY.md](SECURITY.md).

‎SECURITY.md‎

Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,22 @@
1+
# Security
2+
3+
This C2PA open-source library is maintained in partnership with Adobe. At this time, Adobe is taking point on accepting security reports through its HackerOne portal and public bug bounty program.
4+
5+
## Reporting a vulnerability
6+
7+
Please do not create a public GitHub issue for any suspected security vulnerabilities. Instead, please file an issue through [Adobe's HackerOne page](https://hackerone.com/adobe?type=team). If for some reason this is not possible, reach out to [email protected].
8+
9+
10+
## Vulnerability SLAs
11+
12+
Once we receive an actionable vulnerability (meaning there is an available patch, or a code fix is required), we will acknowledge the vulnerability within 24 hours. Our target SLAs for resolution are:
13+
14+
1. 72 hours for vulnerabilities with a CVSS score of 9.0-10.0
15+
2. 2 weeks for vulnerabilities with a CVSS score of 7.0-8.9
16+
17+
Any vulnerability with a score below 6.9 will be resolved when possible.
18+
19+
20+
## C2PA Vulnerabilities
21+
22+
This library is not meant to address any potential vulnerabilities within the C2PA specification itself. It is only an implementation of the spec as written. Instead, report any suspected vulnerabilities within the spec [here](https://github.com/c2pa-org/specifications/issues).

0 commit comments

Comments
 (0)