tokio_worker 0.2.0

Asynchronous, message-driven workers for Tokio applications
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111

# Contributing to `tokio_worker`

For basic information about the `tokio_worker` project, please read the
[README.md](README.md). The project is licensed under **MIT**, and by
contributing, your work will also be licensed under the same terms.

Before submitting changes, please read the [Developer Certificate of
Origin](DCO). All patches must include a `Signed-off-by: NAME <EMAIL>` line to
acknowledge your agreement with the DCO.

Ensure your Git name and email are correctly configured. While you don’t need to
use your real details, avoid leaving them as the default values. To verify your
current settings, run:

```bash
git config user.name
git config user.email
```

If they’re incorrect or unset, update them using:

```bash
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"
```

We welcome all contributions, whether it be bug reports, fixes, feature
submissions, feature requests, or improving documentation or testing. Enjoy
collaborating!

## Git Repository

The repository is hosted at <https://git.4rs.nl/awiteb/tokio_worker.git>, with
`master` as the active development branch.

## Nostr Repository Address

You can submit issues and patches via any
Nostr-compatible client using the address:
`naddr1qqx8gmmtd9h47am0wf4k2uszyqqqqqqp2p08ujyjwprwnwa2w2937w63zgn7ygqv27xku6ascaltjqcyqqq80xgpp4mhxue69uhkummn9ekx7mqpzfmhxue69uhkummnw3ezudrjwvhxumqppamhxue69uhkummnw3ezumt0d5vy5amd`

When using [`n34`](https://n34.dev), there's no need to specify the address, it
will automatically check the `nostr-address` file. Simply submit your issues and
patches without worrying about this detail.

## Contribution Workflow

Before submitting changes, open an issue to discuss your proposed contribution.
Clearly indicate that you intend to work on it and wait for a maintainer's
response. If the issue remains open, you may proceed with submitting your patch.

### Reporting Issues

When opening an issue, include:
- Detailed steps to reproduce the problem
- Relevant error messages or logs
- Expected vs. actual behavior

Please label your issue appropriately (e.g., `bug`, `feature`, `question`) to
help categorize it.

### Your Patch

Ensure your patch submission tool notifies the maintainers and sends the patch
to their read relays, most tools handle this automatically.

#### Patch Guidelines

- Keep patches small: Focused changes are easier to review and merge.
- Run `just ci` before submitting your patch.
- Update the change log with your patch. Run `git-cliff > CHANGELOG.md`
- Use [Conventional Commits]: Start the patch subject with one of these types:
  - `feat`: New feature
  - `fix`: Bug fix
  - `docs`: Documentation updates
  - `refactor`: Code restructuring without behavioral changes
  - `deprecate`: Marking code as deprecated
  - `remove`: Removing deprecated code
  - `security`: Security-related changes
  - `perf`: Performance improvements
  - `test`: Test additions or corrections
- For all other changes, use `chore`.
- Add `!` to the subject if your patch contains a breacking change, e.g.
`remove!: text` and `fix(worker)!: text`
- Use the `--cover-letter` flag to include a cover letter with your patch.
Describe the issue you’re addressing, whether it’s a one-line bug fix or a
5000-line new feature.
- Specify the base commit for your patch using the `--base` flag.
- First-time contributors: Review the [Submitting Patches guide](https://www.kernel.org/doc/html/latest/process/submitting-patches.html) before sending your patch.
- If you revise your patch, you should reference all previous revisions (or the
root patch if this is the first revision) and explain the changes made (i.e.,
the differences between this patch and the prior one).

#### Code Style

When writing code, make sure to folow this:
- Using Rust's official formatting tool, `rustfmt`, to format your code.
- Writing clear and concise code with meaningful variable and function names.
- Adding comments to explain complex logic or algorithms.

#### Cover Letter Description

Your patch description should provide a clear and concise summary of the
changes you have made. It should also include any relevant context or background
information that will help the project maintainers understand the purpose of the
changes. Make sure to reference the issue[^1] that your patch is addressing, and
note any breaking changes that your patch introduces.

[^1]: When referencing, avoid URLs or `nevent` formats with relays. Instead, use only the note ID in `note1` bech32 format.

[Conventional Commits]: https://www.conventionalcommits.org/en/v1.0.0/