Contributing to TDEX Specifications
This file define the guidelines and workflow to follow for correctly contributing on this project.
Writing specs#
The specification is supposed to be readable both in Markdown format and plain text.
Some requirements are obvious, some are subtle. They're designed to walk an implementer through the code they have to write, so write them as YOU develop YOUR implementation. Stick with MUST/SHOULD/MAY and NOT: see RFC 2119
Extend messages#
All message payloads are serialized with Protcol Buffers, in order to add new fields or deprecate older ones you MUST increment the number to maintain backward compatibility.
Creating Test Vectors#
For new low-level protocol constructions, test vectors are necessary. These have traditionally been lines within the spec itself, but the modern trend is to use JSON and separate files. The intent is that they be machine-readable by implementations.
Workflow#
To contribute a patch, the workflow is as follows:
- Fork repository
- Create topic branch
- Commit patches
- Push changes to your fork
- Submit a pull request
Guidelines:
- Commits should be atomic and easy to read, messages should be describe in detail to helpful the readers
- If the commit references another issue, add the reference into message
- Write (if as a possible) unit tests and/or functional tests to verify patches
- Existing tests must be work
Squashing#
Committer should squash or rebase commits before it will be merged, following Git doc.