Skip to content

Latest commit

 

History

History
102 lines (74 loc) · 4.01 KB

CONTRIBUTING.md

File metadata and controls

102 lines (74 loc) · 4.01 KB
Raw

Contributing to tower-lsp

tower-lsp is an open-source project that values community contribution. We could always use a helping hand! What would you like to do?

  1. I want to submit issues or request features.
  2. I want to contribute code.
  3. I want to write documentation.

Submitting issues

One way you can help tower-lsp is to report bugs or request features on our GitHub issue trackers. We can't fix problems we don't know about, so please report early and often!

When reporting a bug or asking for help, please include enough details so that the people helping you can reproduce the behavior you are seeing. For some tips on how to approach this, read about how to produce a Minimal, Complete, and Verifiable example.

When making a feature request, please make it clear what problem you intend to solve with the feature, any ideas for how tower-lsp could support solving that problem, any possible alternatives, and any disadvantages.

Contributing code

The general workflow for contributing code to the tower-lsp repository is as follows:

  1. Fork this repository to your own GitHub account.
  2. git clone the forked repository to your local machine.
  3. Check out the branch you wish to make changes against.
  4. Make your changes and push them up to the forked repository.
  5. Open a pull request against this repository.

Before submitting your pull request, please make sure the following conditions are satisfied:

  1. The pull request is based on an up-to-date version of your respective branch.
  2. If your pull request introduces new functionality, you have written test cases for them.
    • Unit tests are placed at the bottom of the same .rs file in a submodule called tests. See this example for reference.
    • Integration tests are placed in a separate .rs file in the tests subdirectory.
  3. The codebase has been processed with cargo fmt.
  4. All of the following commands completed without errors:
    • cargo build
    • cargo test --all
    • cargo run --example server

We encourage you to check that the test suite passes locally before submitting a pull request with your changes. If anything does not pass, typically it will be easier to iterate and fix it locally than waiting for the CI servers to run tests for you.

Thank you very much for your contribution! Now tower-lsp will be a little faster, more ergonomic, and more efficient.

Writing documentation

Documentation improvements are always welcome!

As with most Rust projects, API documentation is generated directly from doc comments, denoted by either /// or //!, using a tool called Rustdoc. See the official Rust book's chapter on Rustdoc for more information on how this works.

Documentation of any kind should adhere to the following standard:

  1. Lines must not extend beyond 80 characters in length.
  2. To enhance readability in text editors and terminals, use only reference style Markdown links, as shown in the example below. However, if the link points to an anchor that exists on the same page, the inline style should be used instead.
Here is some [example text] with a link in it. While we are at it, here is yet
yet [another link][al], but shorter. If we are linking to [an anchor](#anchor)
on the same page, we can do this inline.

[example text]: https://some.url/
[al]: https://another.url/

When submitting your pull requests, please follow the same workflow described in the Contributing Code section above.

Code of conduct

Please note that this project is released with a Contributor Code of Conduct. By participating in this project, you agree to abide by its terms.