Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/C2SP/C2SP
Community Cryptography Specification Project
https://github.com/C2SP/C2SP
Last synced: about 1 month ago
JSON representation
Community Cryptography Specification Project
- Host: GitHub
- URL: https://github.com/C2SP/C2SP
- Owner: C2SP
- License: other
- Created: 2020-12-27T00:21:17.000Z (over 3 years ago)
- Default Branch: main
- Last Pushed: 2024-07-16T09:38:52.000Z (2 months ago)
- Last Synced: 2024-07-16T22:53:26.032Z (2 months ago)
- Language: Python
- Homepage: https://c2sp.org
- Size: 206 KB
- Stars: 260
- Watchers: 29
- Forks: 18
- Open Issues: 21
-
Metadata Files:
- Readme: README.md
- License: LICENSE-BSD-1-CLAUSE
- Code of conduct: CODE_OF_CONDUCT.md
- Codeowners: CODEOWNERS
Awesome Lists containing this project
- awesome-starred - C2SP/C2SP - Community Cryptography Specification Project (others)
README
# Community Cryptography Specification Project
## Motivation
What if we wrote specifications like we write software? C2SP is an experiment to create
usable specifications by following common software methodologies, like semantic versioning.
## Structure
C2SP maintains a collection of specification documents. Each specification is small and
focused, with a limited scope.
Every specification has an assigned maintainer, who is responsible for reviewing and
accepting changes to that specification.
There is a team of stewards that maintains the general repository, assigns and removes
maintainers for specifications, and is the final decision level. Individual maintainers
manage development of specifications on a day-to-day basis.
## Versioning
All specifications use [Semantic Versioning](https://semver.org/). Since this is normally
intended for software, we adapt it to our specifications with the following semantics:
- 0.Y.Z indicates draft specifications.
- Bump the version as often as you need!
- Always bump the minor version on any material change.
- 1.Y.Z indicates "final" specifications, but these are not set in stone.
- At this point a specification's meaning should not change.
- Bump the patch version when making changes to the text of a specification (to improve
it, or fix errata).
- An extension could be defined in a separate specification, and the "main"
specification's minor version would be incremented to include the extension.
- 2.Y.Z and above will ideally never be needed! But if we make a mistake in a finalised
specification, this would be the pathway to recovery.
- Otherwise these are identical to 1.Y.Z.
## Contributing
Anyone is welcome to contribute new specifications or collaborate on existing documents,
in accordance with the [C2SP Code of Conduct](CODE_OF_CONDUCT.md) and the relevant
licenses.
### Adding a new specification
New specifications are approved by the stewards and assigned to a maintainer.
If you wish to maintain a new spec, open an issue with a `New spec:` prefix.
Pick a meaningful, short name for the specification. This will become part of its URL
(e.g. `https://c2sp.org/short-name`).
### Updating an existing specification
You can either clone this repository and make changes locally, or you can edit a
specification directly in the GitHub UI. In either case, once you are finished, open a
pull request with your proposed updates.
## License
All specifications in this repository are licensed under CC BY 4.0
(https://creativecommons.org/licenses/by/4.0/).
All code in this repository is licensed under the BSD 1-Clause License
([LICENSE-BSD-1-CLAUSE](LICENSE-BSD-1-CLAUSE)).