contributing guidelines review #457
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,6 +1,5 @@ | ||
| # JavaScript Contributing Guildelines | ||
|
|
||
| These guidelines reflect our shared consensus on protocol and etiquette from what we've built so far. Every single item that is presented here is the result of lots of experimentation. However, that doesn't mean that there isn't a better way to do things. What we have below is simply what we've found to work best for us. In this document you will find notes about: | ||
|
|
||
| - Project structure. | ||
|
|
@@ -25,16 +24,6 @@ Our toolkit for each of these is not set in stone, and we don't plan to halt our | |
| - [Releasing](#releasing) | ||
| - [Documentation](#documentation) | ||
| - [Commits](#commits) | ||
| - [Pull Requests](#pull-requests) | ||
| - [Aegir](#aegir) | ||
| - [...for maintainers](#for-maintainers) | ||
|
|
@@ -109,7 +98,6 @@ NotFoundError.code = 'ERR_NOT_FOUND' | |
| exports.NotFoundError = NotFoundError | ||
| ``` | ||
|
|
||
| This enables others to reuse those definitions and decreases the number of hardcoded values across our codebases. | ||
| For example: | ||
|
|
||
|
|
@@ -156,72 +144,27 @@ For releasing a js-ipfs, see [RELEASE_ISSUE_TEMPLATE](https://github.com/ipfs/js | |
|
|
||
| #### Documentation | ||
|
|
||
| `TBW` | ||
|
|
||
| ### Commits | ||
|
|
||
| We have guidelines for how our git commit messages should 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. | ||
|
|
||
| The commit message formatting can be added using a typical git workflow or through the use of a CLI wizard ([Commitizen](https://github.com/commitizen/cz-cli)). | ||
|
|
||
| - **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 nor 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 could be anything specifying the place of the commit change. For example `api`, `cli`, etc... | ||
| - **Breaking Changes** - Should be identified at the end of commit message. Start with the words `BREAKING CHANGE:` on a new line followed by a space or two new lines. The rest of the commit message is then used to describe in detail what was broken and the migration path (if there is one). | ||
|
|
||
| Examples: | ||
|
There was a problem hiding this comment. Could you add an example with a breaking change message please? There was a problem hiding this comment. @achingbrain there is already one below ;) There was a problem hiding this comment. There's an example, but it's just a regular feature commit? |
||
|
|
||
| ``` | ||
| feat(pencil): add 'graphiteWidth' option | ||
|
|
@@ -245,22 +188,13 @@ revert: feat(pencil): add 'graphiteWidth' option | |
| This reverts commit 667ecc1654a317a13331b17617d973392f415f02. | ||
| ``` | ||
|
|
||
| ### Pull Requests | ||
|
|
||
| There should be no dependencies that rely on commits. Instead, there should be WIP PR and each PR that depends on other WIP PR should list what it depends on. Yes, everyone will have to do the extra work of `npm link`ing everything, but this helps us have a cleaner workflow. | ||
|
|
||
| ## Aegir | ||
|
|
||
| We've created [a module](https://github.com/ipfs/aegir) to help us achieve all of the above with minimal effort. Feel free to also use it for your projects. Feedback is appreciated! | ||
|
|
||
| #### ...for maintainers | ||
|
|
||
|
|
||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this section want removing for the time being? What does
TBWmean?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be written. Right now, AFAIK we don't use nor rely on documentation.js for anything.