Contribute

Contribute to the open-source development of Hinode.

Hinode is fully open source and welcomes any contribution, either big or small. To streamline the contribution process, please take a moment to review the guidelines outlined in this article.

Using the issue tracker  

The issue tracker  on GitHub is the preferred channel for bug reports, feature requests and submitting pull requests.

Asking for support  

Use the GitHub Discussions  to ask for support from the Hinode community  . The discussion forum also includes other topics, such as ideas  and showcases  . We strive for a safe, welcoming, and productive community. The community guidelines  provide more context about the expectations, moderation policy, and terms of service.

Bug reports  

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:

• Validate your HTML and Markdown content to ensure your problem isn’t caused by a simple error in your own code.
• Use the GitHub issue search  — check if the issue has already been reported.
• Check if the issue has been fixed — try to reproduce it using the latest main in the repository  .
• Isolate the problem — ideally create a reduced test case.
• Use the provided template in the issue tracker  to capture the context, evidence and steps on how to reproduce the issue.

Feature requests  

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.

Pull requests  

  Important

By submitting a patch, you agree to allow the project owners to license your work under the terms of the MIT license  (if it includes code changes) and under the terms of the Creative Commons ( CC BY-NC 4.0)  license (if it includes documentation changes).

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:

1. 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

2. If you cloned a while ago, get the latest changes from upstream:

   git checkout main
   git pull upstream main

3. Create a new topic branch (off the main project development branch) to contain your feature, change, or fix:

   git checkout -b <topic-branch-name>

4. 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.

5. Locally merge (or rebase) the upstream development branch into your topic branch:

   git pull [--rebase] upstream main

6. Push your topic branch up to your fork:

   git push origin <topic-branch-name>

7. Open a Pull Request  with a clear title and description against the main branch.

Module contributions  

Hinode supports Hugo modules to to provide a flexible and extensible modular framework. Please consider the module development conventions to take full advantage of Hinode’s processing pipelines.

Coding guidelines  

In general, run npm run lint before committing to ensure your changes follow our coding standards.

Partials and shortcodes  

Follow the coding conventions for partial development.

HTML  

Adhere to the Code Guide  .

• Use tags and elements appropriate for an HTML5 doctype (e.g., self-closing tags).
• Use WAI-ARIA attributes in documentation examples to promote accessibility.

CSS  

Adhere to the Code Guide  .

• When feasible, default color palettes should comply with WCAG color contrast guidelines  .

Javascript  

Bundle related client-side javascript in a logically named file. Add the file to the 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.

• No semicolons (in client-side JS)
• 2 spaces (no tabs)
• strict mode
• “Attractive”

Markdown  

See markdown rules  for more details. The following rules are globally disabled:

#	Rule	Remarks
MD013	Line length
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

License  

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.