# 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.](#submitting-issues)
2. [I want to contribute code.](#contributing-code)
3. [I want to write documentation.](#writing-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][mcve].
[mcve]: https://stackoverflow.com/help/mcve
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.
[Open a pull request]: https://github.com/ebkalderon/tower-lsp/compare
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`
[this example]: ./src/codec.rs#L129-L157
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][rd] for more information on how
this works.
[rd]: https://doc.rust-lang.org/book/ch14-02-publishing-to-crates-io.html#making-useful-documentation-comments
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.
```markdown
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](#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.
[Contributor Code of Conduct]: ./CODE_OF_CONDUCT.md