How to Contribute
The Bittorrent-Chain Docs is an open-source project, if you need to add or change anything in Bittorrent-Chain Docs, please raise a PR against the master branch,the documentation team will review the PR or reach out accordingly.
If you are adding a new document, it is recommended to just have a link to your github or documentation for more details.
If you want to contribute docs to us, please follow the following git workflow:
- Fork a new repository from
bttcprotocol/bttc-docsto your personal code repository
- Before writing docs, please synchronize your fork repository with the upstream repository
- Pull a new branch from the master branch of your repository for local development
- Edit the doc in your fork repository
- Write and commit the docs when it is completed
- Submit a pull request (PR) from your repository to
Doc Review Guidelines
The only way to get docs into
bttcprotocol/bttc-docs is to send a pull request. Those pull requests need to be reviewed by someone. there a guide that explains our expectations around PRs for both authors and reviewers.
authorof a pull request is the entity who wrote the diff and submitted it to GitHub.
teamconsists of people with commit rights on the
revieweris the person assigned to review the diff. The
reviewermust be a
The first decision to make for any PR is whether it’s worth including at all. This decision lies primarily with the PR owner, but may be negotiated with
To make the decision we must understand what the PR is about. If there isn’t enough description content or the diff is too large, request an explanation. Anyone can do this part.
We expect that
reviewer check the style and functionality of the PR, providing comments to the
author using the GitHub review system.
reviewer should follow up with the PR until it is in good shape, then approve the PR. Approved PRs can be merged by any PR owner.
When communicating with authors, be polite and respectful.
Commit messages should follow the rule below, we provide a template corresponding instructions.
<commit type>(<scope>): <subject>
The message header is a single line that contains succinct description of the change containing a
commit type, an optional
scope and a
commit type describes the kind of change that this commit is providing:
- feat (new feature,such as adding a new chapter)
- fix (bug fix,such as correcting documentation errors)
scope can be anything specifying place of the commit change. For example:BTTC-basics、Architecture、Governance、Delegator.
subject contains a succinct description of the change:
- Limit the subject line, which briefly describes the purpose of the commit, to 50 characters.
- Start with a verb and use first-person present-tense (e.g., use "change" instead of "changed" or "changes").
- Do not capitalize the first letter.
- Do not end the subject line with a period.
- Avoid meaningless commits. It is recommended to use the git rebase command.
Message body use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.
Here is an example:
feat(Delegator): update delegator chapter
1. add delegator's delegation process
2. improve transaction entry speed
If the purpose of this submission is to modify one issue, you need to refer to the issue in the footer, starting with the keyword Closes, such as Closes
#123,if multiple bugs have been modified, separate them with commas,such as Closes
Pull Request Guidelines
Create one PR for one issue.
- Avoid massive PRs.
- Write an overview of the purpose of the PR in its title.
- Write a description of the PR for future reviewers.
- Elaborate on the feedback you need (if any).
- Do not capitalize the first letter.
- Do not put a period (.) in the end.