Skip to content

Latest commit

 

History

History
99 lines (63 loc) · 5.09 KB

CONTRIBUTING.md

File metadata and controls

99 lines (63 loc) · 5.09 KB
Raw

Contributing

Join our Discord Channel

See community.

Triaging Issues and Pull Requests

One great way you can contribute to the project without writing any code is to help triage issues and pull requests as they come in.

  • Ask for more information if you believe the issue does not provide all the details required to solve it.
  • Suggest labels that can help categorize issues.
  • Flag issues that are stale or that should be closed.
  • Ask for test plans and review code.

Our Development Process

TVM CN documentation uses GitHub as its source of truth. The core team will be working directly there. All changes will be public from the beginning.

All pull requests will be checked by the continuous integration system, GitHub actions. There are unit tests, end-to-end tests, performance tests, style tests, and much more.

Issues

When opening a new issue, always make sure to fill out the issue template. This step is very important! Not doing so may result in your issue not being managed in a timely fashion. Don't take this personally if this happens, and feel free to open a new issue once you've gathered all the information required by the template.

Development

yarn install
yarn start

Installation

  1. Ensure you have Yarn installed.
  2. After cloning the repository, run yarn install in the root of the repository. This will install all dependencies as well as build all local packages.
  3. To start a development server, run yarn start.

Pull Requests

So you have decided to contribute code back to upstream by opening a pull request. You've invested a good chunk of time, and we appreciate it. We will do our best to work with you and get the PR looked at.

Working on your first Pull Request? You can learn how from this free video series:

How to Contribute to an Open Source Project on GitHub

Please make sure the following is done when submitting a pull request:

  1. Keep your PR small. Small pull requests (~300 lines of diff) are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
  2. Use descriptive titles. It is recommended to follow this commit message style.
  3. Test your changes. Describe your test plan in your pull request description.

All pull requests should be opened against the master branch.

Semantic Commit Messages

See how a minor change to your commit message style can make you a better programmer.

Format: <type>(<scope>): <subject>

<scope> is optional. If your change is specific to one/two packages, consider adding the scope. Scopes should be brief but recognizable, e.g. content-docs, theme-classic, core

The various types of commits:

  • feat: a new API or behavior for the end user.
  • fix: a bug fix for the end user.
  • docs: a change to the website or other Markdown documents in our repo.
  • refactor: a change to production code that leads to no behavior difference, e.g. splitting files, renaming internal variables, improving code style...
  • test: adding missing tests, refactoring tests; no production code change.
  • chore: upgrading dependencies, releasing new versions... Chores that are regularly done for maintenance purposes.
  • misc: anything else that doesn't change production code, yet is not test or chore. e.g. updating GitHub actions workflow.

Do not get too stressed about PR titles, however. Your PR will be squash-merged and your commit to the main branch will get the title of your PR, so commits within a branch don't need to be semantically named. The maintainers will help you get the PR title right, and we also have a PR label system that doesn't equate with the commit message types. Your code is more important than conventions!

Example:

feat(core): allow overriding of webpack config
^--^^----^  ^------------^
|   |       |
|   |       +-> Summary in present tense. Use lower case not title case!
|   |
|   +-> The package(s) that this change affected.
|
+-------> Type: see below for the list we use.

Versioned Docs

If you only want to make doc changes, you just need to be aware of versioned docs.

Do not edit the auto-generated files within versioned_docs/ or versioned_sidebars/ unless you are sure it is necessary. For example, information about new features should not be documented in versioned docs. Edits made to older versions will not be propagated to newer versions of the docs.

What Happens Next?

The core team will be monitoring for pull requests. Do help us by keeping pull requests consistent by following the guidelines above.