Add project governance documentation

Explains how Maintainers are selected and their responsibilities.
Explains the Pull Request review workflow.
Adds config for Mergify to enforce this workflow.

Signed-off-by: Dave Tucker <[email protected]>

Author: dave-tucker

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,51 @@
+<!--
+    Thank you for your contribution to Aya! 🎉
+
+    For Work In Progress Pull Requests, please use the Draft PR feature.
+
+    Before submitting a Pull Request, please ensure you've done the following:
+     - 📖 Read the Aya Contributing Guide: https://github.com/aya-rs/aya/blob/main/CONTRIBUTING.md
+     - 📖 Read the Aya Code of Conduct: https://github.com/aya-rs/aya/blob/main/CODE_OF_CONDUCT.md
+     - 👷‍♀️ Create small PRs. In most cases this will be possible.
+     - ✅ Provide tests for your changes.
+     - 📝 Use descriptive commit messages: https://cbea.ms/git-commit/
+     - 📗 Update any related documentation.
+
+-->
+
+# Summary
+<!---
+      Summarize the changes you're making here.
+      Detailed information belongs in the Git Commit messages.
+      Feel free to flag anything you thing needs a reviewer's attention.
+-->
+
+# Related Issues
+<!--
+For example:
+
+- Closes: #1234
+- Relates To: #1234
+-->
+
+# Added/updated tests?
+
+_We strongly encourage you to add a test for your changes._
+
+- [ ] Yes
+- [ ] No, and this is why: _please replace this line with details on why tests
+      have not been included_
+- [ ] I need help with writing tests
+
+# Checklist
+
+- [ ] Rust code has been formatted with `cargo +nightly fmt`.
+- [ ] All clippy lints have been fixed.
+      You can find failing lints with `./clippy.sh`.
+- [ ] Unit tests are passing locally with `cargo test`.
+- [ ] The [Integration tests] are passing locally.
+- [ ] I have blessed any API changes with `cargo xtask public-api --bless`.
+
+[Integration tests]: https://github.com/aya-rs/aya/blob/main/test/README.md
+
+# (Optional) What GIF best describes this PR or how it makes you feel?

CODEOWNERS

@@ -0,0 +1 @@
+* @aya-rs/aya-maintainers

CONTRIBUTING.md

@@ -1,67 +1,111 @@
-# Contributing to Aya
+# Contributing Guide
 
-Thanks for your help improving the project!
+* [New Contributor Guide](#contributing-guide)
+  * [Ways to Contribute](#ways-to-contribute)
+  * [Find an Issue](#find-an-issue)
+  * [Ask for Help](#ask-for-help)
+  * [Pull Request Lifecycle](#pull-request-lifecycle)
+  * [Pull Request Checklist](#pull-request-checklist)
+  * [Documentation Style](#documentation-style)
 
-## Reporting issues
+Welcome! We are glad that you want to contribute to our project! 💖
 
-If you believe you've discovered a bug in aya, please check if the bug is
-already known or [create an issue](https://github.com/aya-rs/aya/issues) on
-github. Please also report an issue if you find documentation that you think is
-confusing or could be improved.
+As you get started, you are in the best position to give us feedback on areas of
+our project that we need help with including:
 
-When creating a new issue, make sure to include as many details as possible to
-help us understand the problem. When reporting a bug, always specify which
-version of aya you're using and which version of the linux kernel.
+* Problems found during setting up a new developer environment
+* Gaps in our Quickstart Guide or documentation
+* Bugs in our automation scripts
 
-## Documentation
+If anything doesn't make sense, or doesn't work when you run it, please open a
+bug report and let us know!
 
-If you find an API that is not documented, unclear or missing examples, please
-file an issue. If you make changes to the documentation, please read
-[How To Write Documentation] and make sure your changes conform to the
-format outlined in [Documenting Components].
+## Ways to Contribute
 
-[How To Write Documentation]: https://doc.rust-lang.org/rustdoc/how-to-write-documentation.html
-[Documenting Components]: https://doc.rust-lang.org/rustdoc/how-to-write-documentation.html#documenting-components
+We welcome many different types of contributions including:
 
-If you want to make changes to the Aya Book, see the readme in the
-[book repository].
+* New features
+* Builds, CI/CD
+* Bug fixes
+* Documentation
+* Issue Triage
+* Answering questions on [Discord]
+* Web design
+* Communications / Social Media / Blog Posts
+* Release management
 
-[book repository]: https://github.com/aya-rs/book
+Not everything happens through a GitHub pull request. Please come to our
+[Discord] and let's discuss how we can work together.
 
-## Fixing bugs and implementing new features
+## Find an Issue
 
-Make sure that your work is tracked by an issue or a (draft) pull request, this
-helps us avoid duplicating work. If your work includes publicly visible changes,
-make sure those are properly documented as explained in the section above.
+Issues labelled as ["good first issue"] are suitable for new
+contributors. They provide extra information to help you make your first
+contribution.
 
-### Running tests
+Issues labelled as ["help wanted"] are usually more difficult. We
+recommend them for people who aren't core maintainers, but have either made some
+contributions already or feel comfortable with starting from more demanding
+tasks.
 
-Run the unit tests with `cargo test`. See [Aya Integration Tests] regarding
-running the integration tests.
+Sometimes there won’t be any issues with these labels. That’s ok! There is
+likely still something for you to work on. If you want to contribute but you
+don’t know where to start or can't find a suitable issue, you can reach out to
+us on [Discord] and we will be happy to help.
 
-[Aya Integration Tests]: https://github.com/aya-rs/aya/blob/main/test/README.md
+Once you see an issue that you'd like to work on, please post a comment saying
+that you want to work on it. Something like "I want to work on this" is fine.
+
+## Ask for Help
+
+The best way to reach us with a question when contributing is to ask on:
+
+* The original GitHub issue
+* Our [Discord]
+
+## Pull Request Lifecycle
+
+Pull requests are managed by Mergify.
+
+Our process is currently as follows:
+
+1. When you open a PR a maintainer will automatically be assigned for review
+1. Make sure that your PR is passing CI - if you need help with failing checks
+   please feel free to ask!
+1. Once it is passing all CI checks, a maintainer will review your PR and you
+   may be asked to make changes.
+1. When you have received an approval from at least one maintainer, your PR will
+   be merged.
+
+In some cases, other changes may conflict with your PR. If this happens, you
+will get notified by a comment in the issue that your PR requires a rebase, and
+the `needs-rebase` label will be applied. Once a rebase has been performed, this
+label will be automatically removed.
 
-### Commits
+## Logical Grouping of Commits
 
 It is a recommended best practice to keep your changes as logically grouped as
 possible within individual commits. If while you're developing you prefer doing
 a number of commits that are "checkpoints" and don't represent a single logical
 change, please squash those together before asking for a review.
+When addressing review comments, please perform an interactive rebase and edit
+commits directly rather than adding new commits with messages like
+"Fix review comments".
 
-#### Commit message guidelines
+## Commit message guidelines
 
 A good commit message should describe what changed and why.
 
 1. The first line should:
-    - Contain a short description of the change (preferably 50 characters or less,
+    * Contain a short description of the change (preferably 50 characters or less,
       and no more than 72 characters)
-    - Be entirely in lowercase with the exception of proper nouns, acronyms, and
+    * Be entirely in lowercase with the exception of proper nouns, acronyms, and
       the words that refer to code, like function/variable names
-    - Be prefixed with the name of the sub crate being changed
+    * Be prefixed with the name of the sub crate being changed
 
     Examples:
-    - `aya: handle reordered functions`
-    - `aya-bpf: SkSkbContext: add ::l3_csum_replace`
+    * `aya: handle reordered functions`
+    * `aya-bpf: SkSkbContext: add ::l3_csum_replace`
 
 1. Keep the second line blank.
 1. Wrap all other lines at 72 columns (except for long URLs).
@@ -72,8 +116,8 @@ A good commit message should describe what changed and why.
 
    Examples:
 
-   - `Fixes: #1337`
-   - `Refs: #1234`
+   * `Fixes: #1337`
+   * `Refs: #1234`
 
 Sample complete commit message:
 
@@ -92,3 +136,32 @@ nicely even when it is indented.
 Fixes: #1337
 Refs: #453, #154
 ```
+
+## Pull Request Checklist
+
+When you submit your pull request, or you push new commits to it, our automated
+systems will run some checks on your new code. We require that your pull request
+passes these checks, but we also have more criteria than just that before we can
+accept and merge it. Theses requirements are described in the
+[Pull Request Template].
+
+It is recommended that you run the integration tests locally before submitting
+your Pull Request. Please see [Aya Integration Tests] for more information.
+
+## Documentation Style
+
+If you find an API that is not documented, unclear or missing examples, please
+file an issue. If you make changes to the documentation, please read
+[How To Write Documentation] and make sure your changes conform to the
+format outlined in [Documenting Components].
+
+If you want to make changes to the Aya Book, see the README in the
+[book repository].
+
+["good first issue"]: https://github.com/aya-rs/aya/labels/good%20first%20issue
+["help wanted"]: https://github.com/aya-rs/aya/labels/help%20wanted
+[Aya Integration Tests]: https://github.com/aya-rs/aya/blob/main/test/README.md
+[How To Write Documentation]: https://doc.rust-lang.org/rustdoc/how-to-write-documentation.html
+[Documenting Components]: https://doc.rust-lang.org/rustdoc/how-to-write-documentation.html#documenting-components
+[book repository]: https://github.com/aya-rs/book
+[Discord]: https://discord.gg/xHW2cb2N6G