generated from phundrak/rust-poem-openapi-template
315 lines
14 KiB
Markdown
315 lines
14 KiB
Markdown
<!-- omit in toc -->
|
||
# Contributing to gege-jdr-backend
|
||
|
||
First off, thanks for taking the time to contribute! ❤️
|
||
|
||
All types of contributions are encouraged and valued. See the [Table
|
||
of Contents](#table-of-contents) for different ways to help and
|
||
details about how this project handles them. Please make sure to read
|
||
the relevant section before making your contribution. It will make it
|
||
a lot easier for us maintainers and smooth out the experience for all
|
||
involved. The community looks forward to your contributions. 🎉
|
||
|
||
> And if you like the project, but just don't have time to contribute,
|
||
> that's fine. There are other easy ways to support the project and
|
||
> show your appreciation, which we would also be very happy about:
|
||
> - Star the project
|
||
> - Tweet about it
|
||
> - Refer this project in your project's readme
|
||
> - Mention the project at local meetups and tell your
|
||
> friends/colleagues
|
||
|
||
<!-- omit in toc -->
|
||
## Table of Contents
|
||
|
||
- [Code of Conduct](#code-of-conduct)
|
||
- [I Have a Question](#i-have-a-question)
|
||
- [I Want To Contribute](#i-want-to-contribute)
|
||
- [Reporting Bugs](#reporting-bugs)
|
||
- [Suggesting Enhancements](#suggesting-enhancements)
|
||
- [Your First Code Contribution](#your-first-code-contribution)
|
||
- [Improving The Documentation](#improving-the-documentation)
|
||
- [Styleguides](#styleguides)
|
||
- [Commit Messages](#commit-messages)
|
||
- [Join The Project Team](#join-the-project-team)
|
||
|
||
|
||
## Code of Conduct
|
||
|
||
This project and everyone participating in it is governed by the
|
||
[gege-jdr-backend Code of Conduct](CODE_OF_CONDUCT.md). By participating,
|
||
you are expected to uphold this code. Please report unacceptable
|
||
behavior to <phundrak>.
|
||
|
||
|
||
## I Have a Question
|
||
|
||
> If you want to ask a question, we assume that you have read the
|
||
> available [Documentation](/phundrak/gege-jdr-backend/wiki).
|
||
|
||
Before you ask a question, it is best to search for existing
|
||
[Issues](/phundrak/gege-jdr-backend/issues) that might help you. In case you have
|
||
found a suitable issue and still need clarification, you can write
|
||
your question in this issue. It is also advisable to search the
|
||
internet for answers first.
|
||
|
||
If you then still feel the need to ask a question and need
|
||
clarification, we recommend the following:
|
||
|
||
- Open an [Issue](/phundrak/gege-jdr-backend/issues/new).
|
||
- Provide as much context as you can about what you're running into.
|
||
- Provide project and platform versions (cargo, rustc, etc), depending
|
||
on what seems relevant.
|
||
|
||
We will then take care of the issue as soon as possible.
|
||
|
||
## I Want To Contribute
|
||
|
||
> ### Legal Notice <!-- omit in toc -->
|
||
> When contributing to this project, you must agree that you have
|
||
> authored 100% of the content, that you have the necessary rights to
|
||
> the content and that the content you contribute may be provided
|
||
> under the project license.
|
||
|
||
### Reporting Bugs
|
||
|
||
<!-- omit in toc -->
|
||
#### Before Submitting a Bug Report
|
||
|
||
A good bug report shouldn't leave others needing to chase you up for
|
||
more information. Therefore, we ask you to investigate carefully,
|
||
collect information and describe the issue in detail in your report.
|
||
Please complete the following steps in advance to help us fix any
|
||
potential bug as fast as possible.
|
||
|
||
- Make sure that you are using the latest version.
|
||
- Determine if your bug is really a bug and not an error on your side
|
||
e.g. using incompatible environment components/versions (Make sure
|
||
that you have read the [documentation](/phundrak/gege-jdr-backend/wiki). If you
|
||
are looking for support, you might want to check [this
|
||
section](#i-have-a-question)).
|
||
- To see if other users have experienced (and potentially already
|
||
solved) the same issue you are having, check if there is not already
|
||
a bug report existing for your bug or error in the [bug
|
||
tracker](/phundrak/gege-jdr-backendissues?q=label%3Abug).
|
||
- Also make sure to search the internet (including Stack Overflow) to
|
||
see if users outside of the PhundrakLabs community have discussed
|
||
the issue.
|
||
- Collect information about the bug:
|
||
- Stack trace (Traceback)
|
||
- OS, Platform and Version (Windows, Linux, macOS, x86, ARM)
|
||
- Version of the interpreter, compiler, SDK, runtime environment,
|
||
package manager, depending on what seems relevant.
|
||
- Possibly your input and the output
|
||
- Can you reliably reproduce the issue? And can you also reproduce
|
||
it with older versions?
|
||
|
||
<!-- omit in toc -->
|
||
#### How Do I Submit a Good Bug Report?
|
||
|
||
> You must never report security related issues, vulnerabilities or
|
||
> bugs including sensitive information to the issue tracker, or
|
||
> elsewhere in public. Instead sensitive bugs must be sent by email to
|
||
> <phundrak>.
|
||
<!-- You may add a PGP key to allow the messages to be sent encrypted as well. -->
|
||
|
||
We use PhundrakLabs issues to track bugs and errors. If you run into
|
||
an issue with the project:
|
||
|
||
- Open an [Issue](/phundrak/gege-jdr-backend/issues/new). (Since we can't be sure at
|
||
this point whether it is a bug or not, we ask you not to talk about
|
||
a bug yet and not to label the issue.)
|
||
- Explain the behavior you would expect and the actual behavior.
|
||
- Please provide as much context as possible and describe the
|
||
*reproduction steps* that someone else can follow to recreate the
|
||
issue on their own. This usually includes your code. For good bug
|
||
reports you should isolate the problem and create a reduced test
|
||
case.
|
||
- Provide the information you collected in the previous section.
|
||
|
||
Once it's filed:
|
||
|
||
- The project team will label the issue accordingly.
|
||
- A team member will try to reproduce the issue with your provided
|
||
steps. If there are no reproduction steps or no obvious way to
|
||
reproduce the issue, the team will ask you for those steps and mark
|
||
the issue as `Status/Need More Info`. Bugs with the `Status/Need
|
||
More Info` tag will not be addressed until they are reproduced.
|
||
- If the team is able to reproduce the issue, it will be marked
|
||
`Reviewed/Confirmed`, as well as possibly other tags (such as
|
||
`Priority/Medium`), and the issue will be left to be [implemented by
|
||
someone](#your-first-code-contribution).
|
||
|
||
<!-- You might want to create an issue template for bugs and errors that can be used as a guide and that defines the structure of the information to be included. If you do so, reference it here in the description. -->
|
||
|
||
|
||
### Suggesting Enhancements
|
||
|
||
This section guides you through submitting an enhancement suggestion for gege-jdr-backend, **including completely new features and minor improvements to existing functionality**. Following these guidelines will help maintainers and the community to understand your suggestion and find related suggestions.
|
||
|
||
<!-- omit in toc -->
|
||
#### Before Submitting an Enhancement
|
||
|
||
- Make sure that you are using the latest version.
|
||
- Read the [documentation](/phundrak/gege-jdr-backend/wiki) carefully and find out
|
||
if the functionality is already covered, maybe by an individual
|
||
configuration.
|
||
- Perform a [search](/phundrak/gege-jdr-backend/issues) to see if the enhancement
|
||
has already been suggested. If it has, add a comment to the existing
|
||
issue instead of opening a new one.
|
||
- Find out whether your idea fits with the scope and aims of the
|
||
project. It's up to you to make a strong case to convince the
|
||
project's developers of the merits of this feature. Keep in mind
|
||
that we want features that will be useful to the majority of our
|
||
users and not just a small subset. If you're just targeting a
|
||
minority of users, consider writing an add-on/plugin library.
|
||
|
||
<!-- omit in toc -->
|
||
#### How Do I Submit a Good Enhancement Suggestion?
|
||
|
||
Enhancement suggestions are tracked as [Gitea
|
||
issues](/phundrak/gege-jdr-backend/issues).
|
||
|
||
- Use a **clear and descriptive title** for the issue to identify the
|
||
suggestion.
|
||
- Provide a **step-by-step description of the suggested enhancement**
|
||
in as many details as possible.
|
||
- **Describe the current behavior** and **explain which behavior you
|
||
expected to see instead** and why. At this point you can also tell
|
||
which alternatives do not work for you.
|
||
- **Explain why this enhancement would be useful** to most
|
||
gege-jdr-backend users. You may also want to point out the other
|
||
projects that solved it better and which could serve as inspiration.
|
||
|
||
<!-- You might want to create an issue template for enhancement suggestions that can be used as a guide and that defines the structure of the information to be included. If you do so, reference it here in the description. -->
|
||
|
||
### Your First Code Contribution
|
||
#### Setting Up Your Development Environment
|
||
Code contributions are most welcome! To contribute to the project, you
|
||
will need to the README and install the
|
||
[prerequisites](/phundrak/gege-jdr-backend#prerequisites) and [setup your
|
||
development environment](/phundrak/gege-jdr-backend#installing).
|
||
|
||
You can use the IDE of your choice, popular options for Rust projects
|
||
are [VSCode](https://code.visualstudio.com/) or
|
||
[RustRover](https://www.jetbrains.com/rust/), but plenty of other code
|
||
editors are available such as:
|
||
- Emacs (we recommend [rustic](https://github.com/rustic-rs/rustic)
|
||
over [rust-mode](https://github.com/rust-lang/rust-mode)
|
||
- [Vim/NeoVim](https://github.com/rust-lang/rust.vim)
|
||
- [Sublime Text](https://github.com/rust-lang/rust-enhanced)
|
||
- [Helix](https://rust-analyzer.github.io/manual.html#helix)
|
||
- [Visual Studio](https://rust-analyzer.github.io/manual.html#visual-studio-2022)
|
||
- [Eclipse](https://projects.eclipse.org/projects/tools.corrosion)
|
||
- And plenty other text editors!
|
||
|
||
Depending on your choice, you may need to install an LSP server and an
|
||
LSP client on your text editor, such as with Emacs and Vim/NeoVim.
|
||
|
||
#### Where Should You Start?
|
||
If you want to participate to gege-jdr-backend, but you’re not sure what
|
||
to do, take a look at the [opened issues](/phundrak/gege-jdr-backend/issues). You
|
||
way find issues with the `help wanted` tag where you could weigh in
|
||
for the resolution of the issue or for decision-making. You may also
|
||
find issues tagged as `good first issue` which should be relatively
|
||
approachable for first time contributors.
|
||
|
||
#### Writing Your First Code Contribution
|
||
Take your time when reading the code. The existing documentation can
|
||
help you better understand how the project is built and how the code
|
||
behaves. If you still have some questions, don’t hesitate to reach out
|
||
to maintainers.
|
||
|
||
When you start writing your code, only modify what needs to be
|
||
modified. Each contribution should do one thing and one thing only. Do
|
||
not, for instance, refactor some code that is unrelated to the main
|
||
topic of your contribution.
|
||
|
||
Check often the output of clippy by running `just lint`, and check if
|
||
existing tests still pass with `just test`. Ideally, start by writing
|
||
new tests that describe the intended behaviour of your contribution
|
||
with functions that will purposefully fail these tests, then iterate
|
||
over these functions until they finally pass all tests.
|
||
|
||
Check also that your code is properly formatted with
|
||
`just format-check`. You can format it automatically with
|
||
`just format`.
|
||
|
||
Finally, check if the code coverage of gege-jdr-backend. Ideally, try to
|
||
stay within the initial percentage of code coverage of the project,
|
||
and try to stay above 75% of code coverage. If it drops below 60%,
|
||
your contribution will be rejected automatically until you add more
|
||
test covering more code.
|
||
|
||
For writing tests, don’t hesitate to take a look at existing tests.
|
||
You can also read on how to write tests with SQLx [in their
|
||
documentation](https://docs.rs/sqlx/latest/sqlx/attr.test.html), as
|
||
well as some examples of poem tests in the [documentation of its
|
||
`test` module](https://docs.rs/poem/latest/poem/test/index.html).
|
||
|
||
### Improving the Documentation
|
||
To improve the documentation of gege-jdr-backend, you have two choices:
|
||
- Improve the [wiki](/phundrak/gege-jdr-backend/wiki) of the project with
|
||
high-level, functional documentation
|
||
- Improve the code documentation by adding some
|
||
[rustdoc](https://doc.rust-lang.org/rustdoc/how-to-write-documentation.html)
|
||
within the code. You can also take the opportunity to add new tests
|
||
through code examples in the rustdock; who knows, maybe you will
|
||
discover a bug writing these tests, which will help improve the code
|
||
itself!
|
||
|
||
## New Pull Requests
|
||
### Commit Messages
|
||
When creating a new commit, try to follow as closely as possible the
|
||
[Conventional Commits 1.0.0](https://www.conventionalcommits.org/)
|
||
standard. Each line should not exceed 72 characters in length. Commits
|
||
shall also be written in the present tense. Use the imperative mood as
|
||
much as possible when explaining what this commit does.
|
||
|
||
> Instead of *Fixed #42* or *Fixes #42*, write *Fix #42*
|
||
|
||
**DO NOT** increase the project version yourself. This will be up for
|
||
the maintainers to do so.
|
||
|
||
### Creating the Pull Request
|
||
Submit your pull requests to the `develop` branch. Pull requests to
|
||
other branches will be refused, unless there is a very specific reason
|
||
to do so explained in the pull request.
|
||
|
||
Note: *PR* means *Pull Request*.
|
||
|
||
**All PRs** must:
|
||
- Branch from `develop`
|
||
- Target the `develop` branch, unless specific cases. Maintainers are
|
||
the only contributors that can create a PR targeting `main`
|
||
- Live on their own branch, prefixed by `feature/` or `fix/` (other
|
||
prefixes can be accepted in specific cases) with the name of the
|
||
feature or the issue fixed in `kebab-case`
|
||
- Be rebased on `develop` if the PR is no longer up to date
|
||
- Pass the CI pipeline (a failed CI pipeline will prevent any merge)
|
||
|
||
PRs coming from a `main`, `master`, `develop`, `release/`, `hotfix/`,
|
||
or `support/` branch will be rejected. PRs not up to date with
|
||
`develop` will not be merged.
|
||
|
||
**Simple PRs** shall:
|
||
- Have only one topic
|
||
- Have only one commit
|
||
- Have all their commits squashed into one if it contains several commits
|
||
|
||
If you open a PR whose scope are multiple topics, it will be rejected.
|
||
Open as many PRs as necessary, one for each topic.
|
||
|
||
**Complex PRs** shall:
|
||
- squash uninteresting commits (fixes to earlier commits, typos,
|
||
syntax, etc…) together
|
||
- keep the major steps into individual commits
|
||
|
||
<!-- omit in toc -->
|
||
## Attribution
|
||
This guide is based on
|
||
[**contributing-gen**](https://github.com/bttger/contributing-gen).
|
||
The Pull Request part is heavily based on the corresponding part of
|
||
Spacemacs’
|
||
[CONTRIBUTING.md](https://github.com/syl20bnr/spacemacs/blob/develop/CONTRIBUTING.org#pull-request).
|