Skip to content

Latest commit

 

History

History
94 lines (61 loc) · 3.23 KB

CONTRIBUTING.md

File metadata and controls

94 lines (61 loc) · 3.23 KB
Raw

Contributing Guidelines

The following is a set of guidelines for contributing to NGINX Unit. We do appreciate that you are considering contributing!

Table Of Contents

Getting Started

Check out the Quick Installation and Howto guides to get NGINX Unit up and running.

Ask a Question

Please open an issue on GitHub with the label question. You can also ask a question on GitHub Discussions or the NGINX Unit mailing list, [email protected] (subscribe here).

Contributing

Report a Bug

Ensure the bug was not already reported by searching on GitHub under Issues.

If the bug is a potential security vulnerability, please report using our security policy.

To report a non-security bug, open an issue on GitHub with the label bug. Be sure to include a title and clear description, as much relevant information as possible, and a code sample or an executable test case showing the expected behavior that doesn't occur.

Suggest an Enhancement

To suggest an enhancement, open an issue on GitHub with the label enhancement. Please do this before implementing a new feature to discuss the feature first.

Open a Pull Request

Before submitting a PR, please read the NGINX Unit code guidelines to know more about coding conventions and benchmarks. Fork the repo, create a branch, and submit a PR when your changes are tested and ready for review. Again, if you'd like to implement a new feature, please consider creating a feature request issue first to start a discussion about the feature.

Git Style Guide

  • Create atomic commits. A commit should do just one thing, i.e. you shouldn't mix refactoring with functional code changes. Do the refactoring in one or more commits first.

    Ideally you should rebase locally and force push new commits up.

  • In the subject line, use the imperative mood. I.e. write the subject like you're giving git a command, e.g. "Free memory before exiting". Do not terminate the subject with a .

  • Try to limit the subject line to around 50 characters, but try not to exceed 72.

  • Wrap the body of the commit message after 72 characters.

  • Use lowercase subject line prefixes for commits that affect a specific portion of the code; examples include "tests:", "ci:", or "http:", and also individual languages such as "python:" or "php:". If multiple areas are affected you can specify multiple prefixes, e.g. "auto, perl:"

  • If the commit fixes an open issue then you can use the "Closes:" tag/trailer to reference it and have GitHub automatically close it once it's been merged. E.g.:

    Closes: https://github.com/nginx/unit/issues/9999

    That should go at the end of the commit message, separated by a blank line, along with any other tags.