Skip to content

Latest commit

 

History

History
95 lines (62 loc) · 3.43 KB

CONTRIBUTING.md

File metadata and controls

95 lines (62 loc) · 3.43 KB
Raw

Contributing guidelines

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

Table of contents

Getting started

Check out the Getting started and njs examples guides to get NGINX with njs up and running.

Ask a question

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

Contributing

Report a bug

Please ensure the bug has not already been reported as issue.

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 a feature or enhancement

To suggest a feature or enhancement, please create an issue on GitHub with the label feature or enhancement using the available feature request issue template. Please ensure the feature or enhancement has not already been suggested.

Note

If you’d like to implement a new feature, please consider creating a feature request issue first to start a discussion about the feature before implementing it.

Open a pull request

Fork the repo, create a branch, implement your changes, add any relevant tests, submit a PR when your changes are tested and ready for review.

Before submitting a PR, please read the NGINX code guidelines to learn more about coding conventions and style.

  • Try to make it clear why the suggested change is needed, and provide a use case, if possible.

  • Changes should be formatted according to the code style used by njs. njs mostly follows the NGINX coding style, with some minor differences. Sometimes, there is no clear rule; in such cases examine how existing njs sources are formatted and mimic this style.

  • Submitting changes implies granting project a permission to use it under an BSD-2-Clause license.

Git style guide

  • Keep a clean, concise and meaningful git commit history on your branch, rebasing locally and squashing before submitting a PR

  • In the subject line, use the past tense ("Added feature", not "Add feature"); also, use past tense to describe past scenarios, and present tense for current behavior

  • Limit the subject line to 67 characters, and the rest of the commit message to 80 characters

  • Use subject line prefixes for commits that affect a specific portion of the code; examples include "Tests:", "HTTP:", or "Core:". See the commit history to get an idea of the prefixes used.

  • Reference issues and PRs liberally after the subject line; if the commit remedies a GitHub issue, name it accordingly