hyperium · github-actions · Dec 11, 2024
diff --git a/_contrib/CODE_OF_CONDUCT.md b/_contrib/CODE_OF_CONDUCT.md
@@ -0,0 +1,25 @@
+---
+title: Code of Conduct
+layout: guide
+hyper_path: docs/CODE_OF_CONDUCT.md
+---
+
+## Be Kind
+
+- Don't be mean.
+- Insulting anyone is prohibited.
+- Harassment of any kind is prohibited.
+- If another person feels uncomfortable with your remarks, stop it.
+- If a moderator deems your comment or conduct as inappropriate, stop it.
+- Disagreeing is fine, but keep it to technical arguments. Never attack the person.
+- Give the benefit of the doubt. Assume good intentions.
+- Show empathy. There are 3 interpretations to any message: what we thought, what we said, and what they understand.
+- This does mean we exclude people who are not kind. We are happy to make that sacrifice.
+
+## Or Else
+
+- Violations of the Code of Conduct will result in 1 warning.
+- If the violation is major, a moderator may just ban immediately.
+- If a warning has already been given, a moderator will ban the offender.
+- There is no process for appealing a ban.
+- Any violations can be reported to sean@seanmonstar.com.
diff --git a/_contrib/CODE_STYLE.md b/_contrib/CODE_STYLE.md
@@ -0,0 +1,26 @@
+---
+title: Code Style
+layout: guide
+hyper_path: docs/CODE_STYLE.md
+---
+
+hyper uses the default configuration of `rustfmt`.
+
+## cargo fmt
+
+`cargo fmt --all` does not work in hyper. Please use the following commands:
+
+```txt
+# Mac or Linux
+rustfmt --check --edition 2021 $(git ls-files '*.rs')
+
+# Powershell
+Get-ChildItem . -Filter "*.rs" -Recurse | foreach { rustfmt --check --edition 2021 $_.FullName }
+```
+
+> **NOTE**: If you are using `rust-analyzer`, you can add the following two lines in your `settings.json` to make sure the features get taken into account when checking the project:
+>
+>    ```json
+>     "rust-analyzer.cargo.features": ["full"],
+>     "rust-analyzer.check.features": ["full"],
+>    ```
diff --git a/_contrib/COMMITS.md b/_contrib/COMMITS.md
@@ -0,0 +1,69 @@
+---
+title: Git Commit Guidelines
+layout: guide
+hyper_path: docs/COMMITS.md
+---
+
+We have very precise rules over how our git commit messages can be formatted.  This leads to **more
+readable messages** that are easy to follow when looking through the **project history**.  But also,
+we use the git commit messages to **generate the change log**.
+
+## Commit Message Format
+Each commit message consists of a **header**, a **body** and a **footer**.  The header has a special
+format that includes a **type**, a **scope** and a **subject**:
+
+```
+<type>(<scope>): <subject>
+<BLANK LINE>
+<body>
+<BLANK LINE>
+<footer>
+```
+
+Any line of the commit message cannot be longer 100 characters! This allows the message to be easier
+to read on github as well as in various git tools.
+
+## Type
+Must be one of the following:
+
+* **feat**: A new feature
+* **fix**: A bug fix
+* **docs**: Documentation only changes
+* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing
+  semi-colons, etc)
+* **refactor**: A code change that neither fixes a bug or adds a feature
+* **perf**: A code change that improves performance
+* **test**: Adding missing tests
+* **chore**: Changes to the build process or auxiliary tools and libraries such as documentation
+    generation
+
+## Scope
+The scope should refer to a module in hyper that is being touched. Examples:
+
+* client
+* server
+* http1
+* http2
+* ffi
+* upgrade
+* examples
+
+## Subject
+
+The subject contains succinct description of the change:
+
+* use the imperative, present tense: "change" not "changed" nor "changes"
+* don't capitalize first letter
+* no dot (.) at the end
+
+## Body
+
+Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes"
+The body should include the motivation for the change and contrast this with previous behavior.
+
+## Footer
+
+The footer should contain any information about **Breaking Changes** and is also the place to
+reference GitHub issues that this commit **Closes**.
+
+The last line of commits introducing breaking changes should be in the form `BREAKING CHANGE: <desc>`
diff --git a/_contrib/CONTRIBUTING.md b/_contrib/CONTRIBUTING.md
@@ -0,0 +1,45 @@
+---
+title: Contributing to Hyper
+layout: guide
+hyper_path: CONTRIBUTING.md
+---
+
+You want to contribute? You're awesome!
+
+Contributions come in all shapes and sizes. Let's take a tour of some of the different wants you could contribute.
+
+## [Code of Conduct](code-of-conduct.md)
+
+Firstly, all interactions with the project need to abide by the code of conduct. This is to make sure everyone is treated kindly.
+
+## [Issues](issues.md)
+
+- **Filing an issue** is a contribution. We appreciate you letting us know about bugs you've found, and any information that you can provide that we can use to make hyper better. Without your filing it, we may not be aware of the bug.
+- [Triaging issues](issues.md#triaging) is a huge help. By your helping make issues better, the reporters can get answers sooner, and others can fix them with less effort. You can also volunteer as a frequent [triager](maintainers.md#triagers).
+- Discuss [feature requests][feat] (especially those marked [request-for-comment][b-rfc]).
+
+[feat]: https://github.com/hyperium/hyper/issues?q=is%3Aissue+is%3Aopen+label%3AC-feature
+[b-rfc]: https://github.com/hyperium/hyper/issues?q=is%3Aissue+is%3Aopen+label%3AB-rfc
+
+
+## [Pull Requests](pull-requests.md)
+
+By the way, consider checking the [list of easy issues](https://github.com/hyperium/hyper/issues?q=is%3Aopen+is%3Aissue+label%3AE-easy) if you want to submit something.
+
+- [Submitting a Pull Request](pull-requests.md#submitting-a-pull-request)
+- [Commit Guidelines](commits.md)
+
+## Documentation
+
+Improving hyper's documentation is a huge help for everyone who is trying to _use_ hyper.
+
+- The API documentation (rendered at https://docs.rs/hyper) is stored as rustdoc comments directly in the source.
+- The main website has [tutorial-style guides](https://hyper.rs/guides). As of v1, they are currently in a [revamp](https://github.com/hyperium/hyper/issues/3411), and would greatly benefit from being filled out.
+
+## Help
+
+Helping others use hyper in their specific workflows is a very valuable way to contribute.
+
+- Answer questions asked directly in hyper's [Discussions](https://github.com/hyperium/hyper/discussions).
+- Join our [Discord](https://discord.gg/kkwpueZ) and help those who show up with questions.
+- **Blog about hyper.** You writing a blog post about how you use hyper to do something specific, or how you contributed a new feature, or debugged something in it, is a great idea. Not all examples can fit in the hyper repo. Search engines will help people find their use cases on your blog. And you can describe processes in more depth or from a different perspective.
diff --git a/_contrib/GOVERNANCE.md b/_contrib/GOVERNANCE.md
@@ -0,0 +1,115 @@
+---
+title: Governance
+layout: guide
+hyper_path: docs/GOVERNANCE.md
+---
+
+## Making decisions
+
+There's two main pieces to the way decisions are made in hyper:
+
+1. A decision-making framework
+2. The people who apply it
+
+The people are described [lower down in this document](#roles).
+
+### Decision-making framework
+
+We start with the users. The project wouldn't exist without them, and it exists
+in order to enable users to do amazing things with HTTP. We listen to our
+users. Some actively contribute their thoughts, but many others we must seek
+out to learn about their usage, joys, and headaches. Those insights allow our
+experts to determine the best solutions for the users.
+
+We then define a set of [tenets](./tenets.md), which are guiding principles
+that can be used to measure aspects of individual decisions. It should be
+possible to identify one or more tenets that apply to why a decision is made.
+And the set helps us balance which priorities are more important for our users.
+
+We combine the usecases with the tenets to come up with a [vision](./vision.md)
+that provides a longer-term plan of what hyper _should_ look like.
+
+Finally, we define a [roadmap](./roadmap.md) that describes what the
+short-term, tactical changes to bring hyper closer in line with the vision.
+
+## Roles
+
+These are the roles people can fill when participating in the project. A list
+of the people in each role is available in [maintainers](./maintainers.md).
+
+### Contributor
+
+A contributor is anyone who contributes their time to provide value for the
+project. This could be in the form of code, documentation, filing issues,
+discussing designs, or helping others on the issue tracker or in chat.
+
+All contributors MUST follow the [Code of Conduct][coc].
+
+👋  **New here?** [This could be you!][contrib]
+
+
+### Triager
+
+Triagers assess issues on the issue tracker. They help make sure the work is
+well organized, and are critical for making new issue reporters feeling
+welcome.
+
+Responsibilities:
+
+- Adhere to the [Code of Conduct][coc]
+- Follow the [triager's guide][triage-guide]
+
+Privileges:
+
+- Can edit, label, and close issues
+- Member of the organization
+- Can be assigned issues and pull requests
+
+How to become:
+
+- Make a few [contributions][contrib] to the project, to show you can follow
+  the [Code of Conduct][coc].
+- Self-nominate by making a pull request adding yourself to the
+  [list](./maintainers.md#triagers).
+
+
+### Collaborator
+
+Collaborators are contributors who have been helping out in a consistent basis.
+
+Responsibilities:
+
+- Be exemplars of the [Code of Conduct][coc]
+- Internalize the [vision](./vision.md)
+- Reviewing pull requests from other contributors
+- Provide feedback on proposed features and design documents
+- [Welcome new contributors][triage-guide]
+- Answer questions in issues and/or chat
+- Mentor contributors to become members
+
+Privileges:
+
+- Can review and merge pull requests
+- Can trigger re-runs of CI, and approve CI for first-time contributors
+- Can assign issues and pull requests to other organization members
+
+How to become:
+
+- Work at fulfilling the above responsibilities.
+- Any collaborator may nominate a contributor who has been around for some time
+  and is already filling the responsibilities.
+- Another collaborator must second the nomination.
+- If there are no objections, a maintainer will welcome the new collaborator.
+
+Don't be afraid to ask a collaborator for what you could work on to reach this
+goal!
+
+### Maintainer
+
+Maintainers are the project admins. Besides being a collaborator, they take care
+of house-keeping duties, help lead the direction, and have the final authority when
+required.
+
+[coc]: ./code-of-conduct.md
+[contrib]: ./contributing.md
+[triage-guide]: ./issues.md#triaging