Skip to content

Latest commit

 

History

History
40 lines (27 loc) · 2.87 KB

DOCS_CONTRIBUTING.md

File metadata and controls

40 lines (27 loc) · 2.87 KB
Raw

The following information provides a set of guidelines for contributing to the Terra Docs repo. Use your best judgment, and, if you see room for improvement, please propose changes to this document.

Contributions come in the form of writing documentation, raising issues, and any other actions that help develop the Terra protocol documentation.

Just want to ask a question?

Please don't submit a pull request to ask a question. Instead, join us in the following communities, and ask all your questions.

First steps

The first step is to find an issue you want to fix. To identify issues we think are good for first-time contributors, we add the good first issue label.

If you find an existing issue that you want to work on or if you have a new issue to create, understand the workflow expected by maintainers of the Terra Docs repository.

Propose documentation changes

Terra Docs requires everyone, without exception, to submit doc-change proposals by using a pull request (PR). PRs enable contributions from the community, easy testing, and straightforward peer review.

To contribute a doc-change proposal, use the following workflow:

  1. Fork the repository.

  2. Add an upstream so that you can update your fork.

  3. Clone your fork to your computer.

  4. Create a branch and name it appropriately.

  5. Work on only one change in one pull request.

  6. Follow these conventions:

    1. Make your changes adhering to the Terra Docs Style Guide and the coding conventions described below. Generally, a commit serves a single purpose and differences should be easy to understand. Do not mix formatting fixes or code moves with actual code changes.
    2. Commit your changes. Write a simple, straightforward commit message. To learn more, see How to Write a Git Commit Message.
    3. Push your changes to your remote fork.
    4. Create a PR on the Terra Docs repository.
    5. Identify the type of PR by adding labels to it. For example, if you're still working on the changes, add the work-in-progress label. If you are proposing an enhancement, add the enhancement label.
    6. Wait for your changes to be reviewed. If you are a maintainer, you can assign your PR to one or more reviewers. If you aren't a maintainer, one of the maintainers will assign a reviewer.
    7. After you receive feedback from a reviewer, make the requested changes, commit them to your branch, and push them to your remote fork again.

After your PR is approved and validated, and no conflicts exist, it will be merged by a maintainer.