forked/hyper
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(dev): start a set of "dev" docs

Browse Source 
Initially this creates a top-level "dev" directory to hold documents
pertaining to the development, as opposed to the usage, of hyper. For a
first doc, it splits out the commit guidelines to its own file.

cc #2586
This commit is contained in:
Sean McArthur
2021-09-16 12:10:36 -07:00
parent 6a876b8ed2
commit e6b2cbda03
3 changed files with 69 additions and 76 deletions
Download Patch File Download Diff File Expand all files Collapse all files

77
CONTRIBUTING.md
View File

@@ -7,79 +7,4 @@ You want to contribute? You're awesome! Don't know where to start? Check the [li
## Pull Requests ## Pull Requests
When submitting a Pull Request, please have your commits follow these guidelines: - [Commit Guidelines](./dev/COMMITS.md)
### Git Commit Guidelines
These guidelines have been copied from the [AngularJS](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#-git-commit-guidelines)
project.
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**:
```
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
```
Any line of the commit message cannot be longer 100 characters! This allows the message to be easier
to read on github as well as in various git tools.
#### Type
Must be one of the following:
* **feat**: A new feature
* **fix**: A bug fix
* **docs**: Documentation only changes
* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing
semi-colons, etc)
* **refactor**: A code change that neither fixes a bug or adds a feature
* **perf**: A code change that improves performance
* **test**: Adding missing tests
* **chore**: Changes to the build process or auxiliary tools and libraries such as documentation
generation
#### Scope
The scope should refer to a module in hyper that is being touched. Examples:
* headers
* client
* server
* http
* method
* net
* status
* version
#### Subject
The subject contains succinct description of the change:
* use the imperative, present tense: "change" not "changed" nor "changes"
* don't capitalize first letter
* no dot (.) at the end
#### Body
Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes"
The body should include the motivation for the change and contrast this with previous behavior.
#### Footer
The footer should contain any information about **Breaking Changes** and is also the place to
reference GitHub issues that this commit **Closes**.
The last line of commits introducing breaking changes should be in the form `BREAKING CHANGE: <desc>`
A detailed explanation can be found in this [document][commit-message-format].
[commit-message-format]: https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit#

65
dev/COMMITS.md Normal file
View File

@@ -0,0 +1,65 @@
# Git Commit Guidelines
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**:
```
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
```
Any line of the commit message cannot be longer 100 characters! This allows the message to be easier
to read on github as well as in various git tools.
## Type
Must be one of the following:
* **feat**: A new feature
* **fix**: A bug fix
* **docs**: Documentation only changes
* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing
semi-colons, etc)
* **refactor**: A code change that neither fixes a bug or adds a feature
* **perf**: A code change that improves performance
* **test**: Adding missing tests
* **chore**: Changes to the build process or auxiliary tools and libraries such as documentation
generation
## Scope
The scope should refer to a module in hyper that is being touched. Examples:
* client
* server
* http1
* http2
* ffi
* upgrade
* examples
## Subject
The subject contains succinct description of the change:
* use the imperative, present tense: "change" not "changed" nor "changes"
* don't capitalize first letter
* no dot (.) at the end
## Body
Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes"
The body should include the motivation for the change and contrast this with previous behavior.
## Footer
The footer should contain any information about **Breaking Changes** and is also the place to
reference GitHub issues that this commit **Closes**.
The last line of commits introducing breaking changes should be in the form `BREAKING CHANGE: <desc>`

3
dev/README.md Normal file
View File

@@ -0,0 +1,3 @@
# Developing hyper
This is a set of documents outline how hyper is developed, how to contribute or get involved, various processes we use, and internal design explanations.