|
| 1 | +# hyper Collaborator Guide |
| 2 | + |
| 3 | +This document describes how collaborators manage hyper. |
| 4 | + |
| 5 | +- First off, a collaborator doesn't need to do all of the following perfectly. |
| 6 | + - It takes time to learn. |
| 7 | + - Instead, focus on growth. |
| 8 | + - Get in the habit of checking this guide with some frequency, and improve rather than stagnate. |
| 9 | + |
| 10 | +## Exemplify the Code of Conduct |
| 11 | + |
| 12 | +- Our [code of conduct](./CODE_OF_CONDUCT.md) is not elaborate. It doesn't require much study, nor explication. |
| 13 | +- To be a good collaborator, it does require internalizing it. |
| 14 | +- The code of conduct is proactive, positive. |
| 15 | +- A collaborator must be a good example of being kind. |
| 16 | + - It should not be possible to find significant fault in a collaborator against the simple principles in the code of conduct. |
| 17 | + |
| 18 | +## Internalize the Vision |
| 19 | + |
| 20 | +- Understand and use the project's [vision](./VISION.md) when helping guide decisions. |
| 21 | + |
| 22 | +## Review Pull Requests |
| 23 | + |
| 24 | +- Review pull requests promptly and kindly. Approve CI for new contributors. |
| 25 | + - Consider telling a maintainer to add you to the automated review queue. |
| 26 | +- Collaborators should feel comfortable approving and merging straightforward changes. Such as documentation, chores, styling, simple refactors, and basic bug fixes. |
| 27 | +- When reviewing larger changes, keep in mind the points on [being API caretakers](#api-caretakers). |
| 28 | +- When approving a PR, allow time for other collaborators to look before merging. |
| 29 | + - Especially if the PR is newer, or has a more significant change. |
| 30 | +- When merging, prefer squashing (it adds in the PR number). Touch up the commit message to match our [COMMITS](./COMMITS.md) style. |
| 31 | + |
| 32 | +## Provide Feedback on Features and Designs |
| 33 | + |
| 34 | +Collaborators try to participate early and often when new features are proposed. They also actively consider and recommend new features that users may need. |
| 35 | + |
| 36 | +### API Caretakers |
| 37 | + |
| 38 | +Collaborators are caretakers of hyper's API. When proposing, discussing, or reviewing changes to hyper, keep the following in mind: |
| 39 | + |
| 40 | +- Conservative additions |
| 41 | + - Conservative APIs reduce breaking changes |
| 42 | +- Don't expose internal implementation details |
| 43 | + - [Accessors can reveal internal repr](https://seanmonstar.com/micro/20260721-accessors-reveal-internal-repr/) |
| 44 | +- hyper-util is a place to explore first |
| 45 | + - [Vision: Not quite stable, but utile](./VISION.md#not-quite-stable-but-utile-useful) |
| 46 | + - [Roadmap: hyper-util](./ROADMAP.md#hyper-util) |
| 47 | +- Unstable features |
| 48 | + - Unstable features are not bound by our stability promise. |
| 49 | + - We don't just name a crate feature with unstable. |
| 50 | + - 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. |
| 51 | + - All unstable features require a conditional config flag passed to the Rust compiler. |
| 52 | + - For example, `hyper_unstable_ffi`. |
| 53 | +- Breaking changes |
| 54 | + - These would usually be reserved for a new SemVer major release, such as v2.0, and thus would usually be very rare. |
| 55 | + - An exception is fixing a mistake quickly after release of a new feature. |
| 56 | + - All breaking changes require approval by a maintainer. |
| 57 | + |
| 58 | +## Welcome New Contributors |
| 59 | + |
| 60 | +- Help new contributors find their way around the project and its processes. Follow the guidance on [acknowledging people when triaging](./ISSUES.md#acknowledge). |
| 61 | + |
| 62 | +## Answer Questions |
| 63 | + |
| 64 | +- Answer questions in issues or chat when you can, or help find someone who can. See the project's [help channels](../CONTRIBUTING.md#help). |
| 65 | + |
| 66 | +## Mentor Contributors |
| 67 | + |
| 68 | +- 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. |
0 commit comments