|
1 |
| -# How to Contribute |
| 1 | +# How to contribute |
2 | 2 |
|
3 |
| -## Identify area for contribution |
| 3 | +:::info |
| 4 | +Learn how to submit content to TON documentation here. |
| 5 | +::: |
4 | 6 |
|
5 |
| -There are several ways to identify the area where you can contribute to TON Docs: |
| 7 | +## Contribute rules |
6 | 8 |
|
7 |
| -- Join [TON Docs Club chat](https://t.me/+c-0fVO4XHQsyOWM8) in Telegram and get the latest tasks from maintainers. |
8 |
| -- If you have a specific contribution in mind but are unsure about it, confirm whether |
9 |
| - the contribution is appropriate by contacting one of the [Docs maintainers](/v3/contribute/maintainers) directly. |
10 |
| -- Get familiar with the most frequently asked questions in the [TON Developers](https://t.me/tondev_eng) chats. |
11 |
| -- Please read over the [issues](https://github.com/ton-community/ton-docs/issues) in the GitHub repository. |
12 |
| -- Learn available [footsteps](https://github.com/ton-society/ton-footsteps/issues?q=documentation) for the documentation. |
| 9 | +### Documentation maintain policy |
13 | 10 |
|
14 |
| -## TL;DR |
| 11 | +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. |
15 | 12 |
|
16 |
| -- If you need to add or edit something in TON Docs, create a pull request |
17 |
| - against the `main` branch. |
18 |
| -- The documentation team will review the pull request or reach out as needed. |
19 |
| -- Repository: https://github.com/ton-community/ton-docs |
| 13 | +It was initially written by TON [contributors](/v3/contribute/maintainers/) and supported by [TON Studio](https://tonstudio.io/). |
| 14 | +We aim to educate users about TON through explicit, easily searchable content that appeals to technical experts and casual readers. |
20 | 15 |
|
21 |
| -## Development |
22 | 16 |
|
23 |
| -### Online one-click contribution setup |
| 17 | +### How to contribute |
24 | 18 |
|
25 |
| -You can use Gitpod (a free, online, VS code-like IDE) for contributing. It will launch a workspace with a single click and will automatically: |
| 19 | +:::info |
| 20 | +This documentation is written in English. Please refer to [localization program](/v3/contribute/localization-program/how-to-contribute/) for other languages. |
| 21 | +::: |
26 | 22 |
|
27 |
| -[](https://gitpod.io/#https://github.com/ton-community/ton-docs) |
| 23 | +1. Clone a current version from the [ton-docs](https://github.com/ton-community/ton-docs) GitHub repository. |
| 24 | +1. Determinate an area for contribution according to [Style guide](/v3/contribute/style-guide/) and open a related [issue](https://github.com/ton-community/ton-docs/issues). |
| 25 | +2. Familiarize yourself with [Content standardization](/v3/contribute/content-standardization/) and [Typography](/v3/contribute/typography/). |
| 26 | +3. Open a pull request against the `main` branch with a clear description and concise updates according to the template. |
28 | 27 |
|
29 |
| -### Code Conventions |
| 28 | +#### Pool request template |
30 | 29 |
|
31 |
| -- **Most important**: look around. Match the overall style of the project. This includes formatting, naming files, naming objects in code, naming things in documentation, and so on. |
32 |
| -- **For documentation**: When editing documentation, do not wrap lines at 80 characters; instead, configure your editor to soft-wrap. |
33 |
| -- **Grammar**: `cpell` will check the spelling and suggest corrections in case of mistakes automatically before creating new commit. Feel free to add specific `words` to `cspell.json` config to include them in the verification dictionary. |
| 30 | +```md |
34 | 31 |
|
35 |
| -Don't worry too much about styles in general; the maintainers will help you fix them as they review your code. |
| 32 | +## Description |
36 | 33 |
|
37 |
| -### Pull Requests |
| 34 | +Please provide a brief description of the changes introduced in this pull request. Include any relevant issue numbers or links. |
38 | 35 |
|
39 |
| -So you have decided to contribute code back to upstream by opening a pull request. You've put in a lot of effort, and we appreciate it. We will do our best to work with you and get the pull request reviewed. |
| 36 | +## Checklist |
40 | 37 |
|
41 |
| -When submitting a pull request, please ensure the following: |
| 38 | +- [ ] I have created an issue. |
| 39 | +- [ ] I am working on content that aligns with the [Style guide](https://docs.ton.org/v3/contribute/style-guide/). |
| 40 | +- [ ] I have reviewed and formatted the content according to [Content standardization](https://docs.ton.org/v3/contribute/content-standardization/). |
| 41 | +- [ ] I have reviewed and formatted the text in the article according to [Typography](https://docs.ton.org/v3/contribute/typography/). |
42 | 42 |
|
43 |
| -1. **Keep your pull request small**. Smaller 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. |
44 |
| -2. **Use descriptive titles**. It is recommended to follow the commit message style. |
45 |
| -3. **Test your changes**. Describe your test plan in your pull request description. |
| 43 | +``` |
| 44 | +4. Before submitting your pull request, complete and verify each milestone in the description checklist. |
46 | 45 |
|
47 |
| -All pull requests should be opened against the `main` branch. |
| 46 | +:::info |
| 47 | +To avoid excessive rework, read the contribution guidelines in the [Style guide](/v3/contribute/style-guide/), [Content standardization](/v3/contribute/content-standardization/), and [Typography](/v3/contribute/typography/) before contributing. Don't worry about minor issues; maintainers will help you fix them during the review process. |
| 48 | +::: |
48 | 49 |
|
49 |
| -## What Happens Next? |
| 50 | +### Development |
50 | 51 |
|
51 |
| -The TON Docs team will be monitoring pull requests. Please help us by following the guidelines above to keep the pull requests consistent. |
| 52 | +- Learn the documentation development flow from a [ton-docs/README.md](https://github.com/ton-community/ton-docs?tab=readme-ov-file#set-up-your-environment-%EF%B8%8F) document. |
| 53 | + |
| 54 | +#### Best practice for pull request |
| 55 | + |
| 56 | +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. |
| 57 | +2. **Use descriptive titles**. It would be best to follow the commit message style. |
| 58 | +3. **Test your changes**. Run build locally, and make sure you have no crushes. |
| 59 | +4. **Use soft wrap**: Don't wrap lines at 80 characters; configure your editor to soft-wrap. |
| 60 | + |
| 61 | + |
| 62 | +## Communicate to other developers |
| 63 | + |
| 64 | +- [Ask questions related to TON documentation in the TON Docs Club chat in Telegram.](https://t.me/+c-0fVO4XHQsyOWM8) |
| 65 | +- [Get familiar with the most frequently asked questions in the TON Developers.](https://t.me/tondev_eng) |
| 66 | +- [Create an issue with your ideas on improvement.](https://github.com/ton-community/ton-docs/issues) |
| 67 | +- [Find and take available bounties for the documentation.](https://github.com/ton-society/ton-footsteps/issues?q=documentation) |
| 68 | +- [See docs-ton on GitHub.](https://github.com/ton-community/ton-docs) |
| 69 | + |
| 70 | +## See also |
| 71 | + |
| 72 | +- [Style guide](/v3/contribute/style-guide/) |
| 73 | +- [Typography](/v3/contribute/typography/) |
| 74 | +- [Localization program](/v3/contribute/localization-program/overview/) |
0 commit comments