Nanoc is the effort of dozens of people. Contributions are welcomed, no matter how small. This page shows the different ways you can make a difference to Nanoc.
Making a donation
Nanoc is, and always will be, provided free of charge. Development is voluntary and happens entirely in free time. If you use Nanoc and like it, please consider showing your token of support by making a donation.
If you find a bug in Nanoc, you should report it! But before you do, make sure you have the latest version of Nanoc (and dependencies) installed, and see if you can still reproduce the bug there. If you can, report it!
When reporting a bug, please make sure you include as many details as you can about the bug. Some information that you should include:
- The Nanoc version (nanoc --version), including the Ruby version
- The crash.log file, if the bug you’re reporting is a crash
- Steps to reproduce the bug
Submitting feature requests
If you have an idea for a new feature, start a discussion on the Nanoc Google group.
To contribute code, you need a basic knowledge of git. The Try Git interactive tutorial is quite good for getting up to speed.
Before you start coding, make sure that the idea you have fits with Nanoc’s philosophy. Start a thread on the discussion group or find us on the Gitter channel. Generally speaking, all bug fixes are accepted, while feature changes need more discussion.
To fetch the latest Nanoc source code, clone the Git repository:
~% git clone git://github.com/nanoc/nanoc.git
Create a new branch. Pick a good name; the convention is to prefix the branch name with
bug/ when it is a bug and with
feature/ if it is a feature. Once you’ve picked a branch name, create the branch:
nanoc% git checkout -b bug/fix-colors-on-windows
Nanoc uses Bundler to manage its development dependencies. Run bundle install to install all dependencies necessary for development and testing.
Now you can make modifications to the source code. You can find the source code in lib and the tests in test. Make sure that your changes have test cases that cover the bug fix or the new/changed functionality. To run the tests, do one of the following:
- To run all tests, run bundle exec rake.
- To run style checks, run bundle exec rake rubocop.
- To run a specific test file, run bundle exec m path_to_test_file from a subdirectory.
- To run a specific spec file, run bundle exec rspec path_to_spec_file from a subdirectory.
To test your locally modified version of Nanoc on a local Nanoc site, edit your site’s Gemfile and let the Nanoc gem point to the locally modified version:
gem 'nanoc', path: '/home/denis/projects/nanoc'
Finally, create a pull request. Once submitted, your work here is done. We’ll review the code, have a discussion and merge it once we’re satisfied.
If you’re a release manager, you can follow these steps to release a new version of Nanoc.
Before you start, ensure that you have access to the following:
- GitHub push access
- RubyGems push access
- Twitter access
If you are missing any of these, let me (Denis) know and I’ll set you up.
Preparing for a release
Preparing a release means ensuring that the version that is about to be released meets the requirements. To prepare for a release, follow these steps:
- Ensure the
Nanoc::VERSIONconstant is set to the right version. Keep in mind that Nanoc follows the Semantic Versioning standard.
- Ensure the release notes in the NEWS.md file are up-to-date, and that the release date is correct.
- Run the tests using bundle exec rake.
- As a final check, compile the Nanoc site with the Nanoc gem in the Gemfile pointing to your local Nanoc working copy, and verify locally that the release notes page is as expected.
Releasing the new version
Run scripts/release. It should just work!
Spread the word
To announce the new release, follow these steps:
- In the nanoc.ws repository, upgrade Nanoc. The web site will be built and published automatically.
- Send a tweet from the @nanoc_ssg Twitter account.
- Update the version mentioned on the Nanoc Wikipedia page.
Contributor code of conduct
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
Examples of behavior that contributes to creating a positive environment include:
- Using welcoming and inclusive language
- Being respectful of differing viewpoints and experiences
- Gracefully accepting constructive criticism
- Focusing on what is best for the community
- Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
- The use of sexualized language or imagery and unwelcome sexual attention or advances
- Trolling, insulting/derogatory comments, and personal or political attacks
- Public or private harassment
- Publishing others’ private information, such as a physical or electronic address, without explicit permission
- Other conduct which could reasonably be considered inappropriate in a professional setting
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at firstname.lastname@example.org. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.