The following is included verbatim from [README.md](README.md).
---
Contributions are **highly encouraged**; if you'd like to assist, consider checking out the [`good first issue` label](https://github.com/kivikakk/comrak/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22)! I'm happy to help provide direction and guidance throughout, even if (especially if!) you're new to Rust or open source.
Where possible I practice [Optimistic Merging](http://hintjens.com/blog:106) as described by Peter Hintjens. Please keep the [code of conduct](CODE_OF_CONDUCT.md) in mind too.
Thank you to Comrak's many contributors for PRs and issues opened!
### Vulnerabilities
Please report security issues to the author at <<ashe@kivikakk.ee>>. If you
have a GitHub account, you are welcome to use its interface to [privately report
security issues](https://github.com/kivikakk/comrak/security/advisories/new).
### Policy on LLM contributions
Please do not submit the output of LLMs to Comrak, in any form. For example, do
not use them to:
- Write code.
- Write tests.
- Write comments.
- Write issue or pull request descriptions.
- Write documentation.
This list isn't exhaustive, and skirting the rules is not tolerated.
If an LLM has played a part in your discovery of a bug, or performance or
security issue, that's OK — I simply ask that you write the issue, fix, or pull
request description yourself, by hand. If you do not personally understand what
you have submitted, you are assisting neither Comrak's maintainers nor yourself
with your submission.
I make an exception for vulnerability reports. If you've found a legitimate
security issue in Comrak, you may privately submit an LLM-written report. If,
however, your reports are consistently trash tier, I will block you from the
project. There's no reason they have to be. This hasn't happened, yet, and (a)
I am grateful, and (b) don't be the first. I will update this canary should this
fact ever change.