Skip to content

Latest commit

 

History

History
100 lines (73 loc) · 4.18 KB

CONTRIBUTING.md

File metadata and controls

100 lines (73 loc) · 4.18 KB
Raw

Contributing

Contents

Introduction

Hello, and welcome to the contributing guide for Codespan!

Codespan is mostly maintained in the spare time of contributors, so immediate reactions are not to be expected! By following this guide you'll make it easier for us to address your issues or incorporate your contributions.

We look forward to working with you!

Code of Conduct

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

Matrix Room

Joining the matrix room at #codespan:matrix.org is a good way to get in touch with the developers and community.

Reporting Bugs and Suggesting Improvements

Bugs (unwanted behaviour) and suggested improvements are tracked as GitHub issues. Before reporting an issue, please check the following points:

  1. The issue is caused by codespan-reporting itself and not by how it is used. Have a look at the documentation if you are not sure. If the documentation is not helpful, you can contact the developers at the above matrix chat address or make an issue.
  2. Your issue has not already been reported by someone else. Please look through the open issues in the issue tracker.

When reporting an issue, please add as much relevant information as possible. This will help developers and maintainers to resolve your issue. Some things you might consider:

  • Use a descriptive title.
  • Describe how a problem can be reproduced. Ideally give a minimal example.
  • Explain what exactly is the problem and what you expect instead. If it is related to rendering, add screenshots or other illustrations.

Contribution Workflow

Follow these steps to contribute to the project:

  1. Make a fork of the codespan repository.
  2. Within your fork, create a branch for your contribution. Use a meaningful name.
  3. Create your contribution, meeting all contribution quality standards.
  4. Ensure all the tests pass (cargo test).
  5. Create a pull request against the master branch of the repository.
  6. Once the pull request is reviewed and CI passes, it will be merged.

Quality Standards

Most quality and style standards are checked automatically by the CI build. Contributions should:

  • Separate each logical change into its own commit.
  • Include tests for any new functionality and fixed issues in your pull request.
  • Update the changelogs with any added, removed, changed, or fixed functionality.
  • Document public functions.
  • Format code with cargo fmt.
  • Avoid adding unsafe code. If it is necessary, provide an explanatory comment on any unsafe block explaining its rationale and why it's safe.
  • Add a descriptive message for each commit. Follow these commit message guidelines.
  • Document your pull requests. Include the reasoning behind each change, and the testing done.

Release Process

  1. Bump the version numbers of each crate appropriately.
  2. Update the changelogs with the new version ranges.
  3. Create a new PR for the release, and if it passes CI merge it.
  4. Create a new tag for the release, pointing to the merge commit.
  5. Run the following commands in order from the root of the repository. Note that doing this too quickly may result in an error, due to a server-side delay in crate publishing: 
    cd codespan-reporting && cargo publish; cd ..
cd codespan && cargo publish; cd ..
cd codespan-lsp && cargo publish; cd ..