Contribute to the open-source development of Hinode.
Hinode is fully open source and welcomes any contributions, either big or small. To streamline the contribution process, please take a moment to review the guidelines outlined in this article.
The issue tracker on GitHub is the preferred channel for bug reports, feature requests and submitting pull requests.
A bug is a demonstrable problem that is caused by the code in the repository. This may also include issues with the documentation or configuration files. Before filing a bug report, please consider the following guidelines:
Feature requests are welcome. But take a moment to find out whether your idea fits with the scope and aims of the project. Please use the provided template in the issue tracker to capture the idea and context.
Good pull requests—patches, improvements, new features—are a fantastic help. They should remain focused in scope and avoid containing unrelated commits.
Please ask first before embarking on any significant pull request (e.g. implementing features, refactoring code, porting to a different language), otherwise you risk spending a lot of time working on something that the project’s developers might not want to merge into the project. For trivial things, or things that don’t require a lot of your time, you can go ahead and make a PR.
Please adhere to the coding guidelines used throughout the project (indentation, accurate comments, etc.) and any other requirements (such as test coverage).
Adhering to the following process is the best way to get your work included in the project:
Fork the project, clone your fork, and configure the remotes:
git clone https://github.com/<your-username>/hinode.git cd hinode git remote add upstream https://github.com/gethinode/hinode
If you cloned a while ago, get the latest changes from upstream:
git checkout main git pull upstream main
Create a new topic branch (off the main project development branch) to contain your feature, change, or fix:
git checkout -b <topic-branch-name>
Commit your changes in logical chunks. Please adhere to these git commit message guidelines. Use Git’s interactive rebase feature to tidy up your commits before making them public.
Locally merge (or rebase) the upstream development branch into your topic branch:
git pull [--rebase] upstream main
Push your topic branch up to your fork:
git push origin <topic-branch-name>
Open a Pull Request with a clear title and description against the main branch.
In general, run
npm run lint before committing to ensure your changes follow our coding standards.
assets/js when using Hugo templating. Adjust the eslint configuration as needed to handle necessary exceptions. When adapting someone else’s code, please add a link to the original source to give them credit.
See markdown rules for more details. The following rules are globally disabled:
|MD024||Multiple headings with the same content|
|MD026||Trailing punctuation in heading|
|MD034||Bare URL used|
|MD051||Link fragments should be valid|
|MD053||Link and image reference definitions should be needed||Disabled due to false positives|
By contributing your code, you agree to license your contribution under the MIT license. By contributing to the documentation, you agree to license your contribution under the Creative Commons (CC BY-NC 4.0) license.