## 1. Project Overview & Quickstart (hyperium/governance) # governance Open-source repository hyperium/governance ### Repository Details - **Repository:** [hyperium/governance](https://github.com/hyperium/governance) - **Primary Language:** Code *Note: High-volume repository documentation is actively indexed and synchronized by YakaAI.* ## 2. Official Technical Reference & Guides (hyperium/hyperium.github.io) ## File: _config.yml # Site settings title: hyper - fast and safe HTTP for the Rust language baseurl: "/" # the subpath of your site, e.g. /blog/ url: "https://hyper.rs" # the base hostname & protocol for your site defaults: - scope: path: "_legacy/" type: "guides" values: layout: "guide" - scope: path: "_stable/" type: "guides" values: layout: "guide" - scope: path: "_contrib/" type: "guides" values: layout: "guide" collections: legacy: permalink: /guides/0.14/:path/ output: true stable: permalink: /guides/1/:path/ output: true posts: permalink: /blog/:year/:month/:day/:title/ output: true contrib: permalink: /contrib/:path/ output: true # Build settings markdown: kramdown highlighter: rouge kramdown: input: GFM syntax_highlighter: rouge relative_links: enabled: true collections: true plugins: - jekyll-redirect-from hyper_docs_url: https://docs.rs/hyper/latest examples_url: https://github.com/hyperium/hyper/tree/master/examples http_body_util_url: https://docs.rs/http-body-util/latest hyper_tls_url: https://docs.rs/hyper-tls/latest hyper_util_url: https://docs.rs/hyper-util/latest http_docs_url: https://docs.rs/http/latest futures_url: https://docs.rs/futures/0.3.* legacy_docs_url: https://docs.rs/hyper/0.14.* legacy_examples_url: https://github.com/hyperium/hyper/tree/0.14.x/examples --- ## File: blog.md --- layout: default permalink: /blog --- {% for post in site.posts %}

  • {{ post.title }}

    • {% endfor %} --- ## File: index.md --- layout: home --- --- ## File: _contrib/code-of-conduct.md --- 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. --- ## File: _contrib/code-style.md --- 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"], > ``` --- ## File: _contrib/collaborators.md --- title: >- hyper Collaborator Guide layout: guide hyper_path: docs/COLLABORATORS.md --- This document describes how collaborators manage hyper. - First off, a collaborator doesn't need to do all of the following perfectly. - It takes time to learn. - Instead, focus on growth. - Get in the habit of checking this guide with some frequency, and improve rather than stagnate. ## Exemplify the Code of Conduct - Our [code of conduct](./code-of-conduct.md) is not elaborate. It doesn't require much study, nor explication. - To be a good collaborator, it does require internalizing it. - The code of conduct is proactive, positive. - A collaborator must be a good example of being kind. - It should not be possible to find significant fault in a collaborator against the simple principles in the code of conduct. ## Internalize the Vision - Understand and use the project's [vision](./vision.md) when helping guide decisions. ## Review Pull Requests - Review pull requests promptly and kindly. Approve CI for new contributors. - Consider telling a maintainer to add you to the automated review queue. - Collaborators should feel comfortable approving and merging straightforward changes. Such as documentation, chores, styling, simple refactors, and basic bug fixes. - When reviewing larger changes, keep in mind the points on [being API caretakers](#api-caretakers). - When approving a PR, allow time for other collaborators to look before merging. - Especially if the PR is newer, or has a more significant change. - When merging, prefer squashing (it adds in the PR number). Touch up the commit message to match our [commits](./commits.md) style. ## Provide Feedback on Features and Designs Collaborators try to participate early and often when new features are proposed. They also actively consider and recommend new features that users may need. ### API Caretakers Collaborators are caretakers of hyper's API. When proposing, discussing, or reviewing changes to hyper, keep the following in mind: - Conservative additions - Conservative APIs reduce breaking changes - Don't expose internal implementation details - [Accessors can reveal internal repr](https://seanmonstar.com/micro/20260721-accessors-reveal-internal-repr/) - hyper-util is a place to explore first - [Vision: Not quite stable, but utile](./vision.md#not-quite-stable-but-utile-useful) - [Roadmap: hyper-util](./roadmap.md#hyper-util) - Unstable features - Unstable features are not bound by our stability promise. - We don't just name a crate feature with unstable. - This has the problem of an intermediary crate enabling it, and someone depending on _that_ crate and not realizing they are accessing unstable hyper features. - All unstable features require a conditional config flag passed to the Rust compiler. - For example, `hyper_unstable_ffi`. - Breaking changes - These would usually be reserved for a new SemVer major release, such as v2.0, and thus would usually be very rare. - An exception is fixing a mistake quickly after release of a new feature. - All breaking changes require approval by a maintainer. ## Welcome New Contributors - Help new contributors find their way around the project and its processes. Follow the guidance on [acknowledging people when triaging](./issues.md#acknowledge). ## Answer Questions - Answer questions in issues or chat when you can, or help find someone who can. See the project's [help channels](./contributing.md#help). ## Mentor Contributors - Help contributors grow toward becoming project members. Issue triaging often provides opportunities for [mentoring](./issues.md#mentoring), but the ideas can be applied to reviews, or when answering questions. --- ## File: _contrib/commits.md --- 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**: ``` ():