From a5eded4abde26afdd4e1b32115b58671d6cf740b Mon Sep 17 00:00:00 2001
From: Titus Wormer <tituswormer@gmail.com>
Date: Fri, 19 Aug 2022 16:51:02 +0200
Subject: Add contributing, support guide

---
 .github/contribute.md | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 76 insertions(+)
 create mode 100644 .github/contribute.md

(limited to '.github/contribute.md')

diff --git a/.github/contribute.md b/.github/contribute.md
new file mode 100644
index 0000000..0972827
--- /dev/null
+++ b/.github/contribute.md
@@ -0,0 +1,76 @@
+# Contribute
+
+This article explains how to contribute.
+Please read through the following guidelines.
+
+## Contributions
+
+There are several ways to contribute, not just by writing code.
+See [Support][] if you have questions.
+
+### Financial support
+
+You can help financially.
+See [Sponsor][] for more info.
+
+### Improve docs
+
+As a user you’re perfect to help improve the docs.
+Typo corrections, error fixes, better explanations, new examples, etcetera.
+
+### Improve issues
+
+Some issues lack information, aren’t reproducible, or are just incorrect.
+You can help by trying to make them easier to resolve.
+Existing issues might benefit from your unique experience or opinions.
+
+### Write code
+
+Code contributions are very welcome too.
+It’s probably a good idea to first post a question or open an issue to report a
+bug or suggest a new feature before creating a pull request.
+
+## Submitting an issue
+
+- the issue tracker is for issues, discussions are for for questions
+- search the issue tracker (including closed issues) before opening a new
+  issue
+- ensure you’re using the latest versions of packages and other tools
+- use a clear and descriptive title
+- include as much information as possible: steps to reproduce the issue,
+  error message, version, operating system, etcetera
+- the more time you put into an issue, the better help you can get
+- the best issue report is a [failing test][unit-test] proving it
+
+## Submitting a pull request
+
+- run `cargo fmt` and `cargo test` locally to format and test your changes
+- non-trivial changes are often best discussed in an issue first, to prevent
+  you from doing unnecessary work
+- for ambitious tasks, you should try to get your work in front of the
+  community for feedback as soon as possible
+- new features should be accompanied by tests and documentation
+- don’t include unrelated changes
+- write a convincing description of why your pull request should land:
+  it’s your job to be convincing
+
+## Resources
+
+- [how to contribute to open source](https://opensource.guide/how-to-contribute/)
+- [making your first contribution](https://medium.com/@vadimdemedes/making-your-first-contribution-de6576ddb190)
+- [using pull requests](https://help.github.com/articles/about-pull-requests/)
+- [GitHub help](https://help.github.com)
+
+## License
+
+[CC-BY-4.0][license] © [Titus Wormer][author]
+
+<!-- Definitions -->
+
+[license]: https://creativecommons.org/licenses/by/4.0/
+[author]: https://wooorm.com
+[coc]: https://github.com/remarkjs/.github/blob/main/code-of-conduct.md
+[unit-test]: https://twitter.com/sindresorhus/status/579306280495357953
+[support]: support.md
+[collective]: https://opencollective.com/unified
+[sponsor]: https://github.com/wooorm/micromark-rs/#sponsor
-- 
cgit