hyper Collaborator Guide

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 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 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.
• 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 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
• hyper-util is a place to explore first
  • Vision: Not quite stable, but utile
  • Roadmap: 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.

Answer Questions

• Answer questions in issues or chat when you can, or help find someone who can. See the project’s help channels.

Mentor Contributors

• Help contributors grow toward becoming project members. Issue triaging often provides opportunities for mentoring, but the ideas can be applied to reviews, or when answering questions.