Skip to main content

How to contribute

info

Learn how to submit content to TON Documentation here.

Contribution guidelines​

Documentation maintainer community​

TON Documentation is entirely open source. Community enthusiasts and early TON contributors have played a key role in creating this open source TON documentation by turning their notes into detailed pages.

It was initially written by TON contributors and supported by TON Studio. We aim to educate users about TON through explicit, easily searchable content that appeals to technical experts and casual readers.

How to contribute​

  1. Clone the current version from the ton-docs GitHub repository.
  2. Choose an area to contribute according to the Style guide and open a related issue.
  3. Familiarize yourself with Content standardization and Typography.
  4. Before submitting your pull request, complete and verify each milestone in the description checklist.
  5. Open a pull request against the main branch with a clear description and concise updates according to the template.

Pull request template​


## Description

Brief description of the changes introduced in this pull request. Include any relevant issue numbers or links.

Closes [link to issue].

## Checklist

- [ ] I have created an issue.
- [ ] I am working on content that aligns with the [Style guide](https://docs.ton.org/v3/contribute/style-guide/).
- [ ] I have reviewed and formatted the content according to [Content standardization](https://docs.ton.org/v3/contribute/content-standardization/).
- [ ] I have reviewed and formatted the text in the article according to [Typography](https://docs.ton.org/v3/contribute/typography/).

info

To avoid excessive rework, read the contribution guidelines in the Style guide, Content standardization, and Typography before contributing. Don't worry about minor issues; maintainers will help you fix them during the review process.

Development​

Best practices for pull requests​

  1. Keep your pull request small. Minor pull requests (~300 lines of diff) are easier to review and more likely to get merged. Make sure the pull request does only one thing; otherwise, please split it.
  2. Use descriptive titles. It would be best to follow the commit message style.
  3. Build locally and ensure it succeeds without crashes.
  4. Use soft wrap: Don't wrap lines at 80 characters; configure your editor to soft wrap.

Communicate with other developers​

See also​