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

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.

HTML

Adhere to the Code Guide.

• Use tags and elements appropriate for an HTML5 doctype (e.g., self-closing tags).
• Use npm packages for third-party JS when possible.
• 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:

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.