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, run bundle exec rake.
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'
After making your modifications, make sure that the source code documentation is up-to-date. Nanoc uses YARD for its source code docs. The YARD getting started guide is a helpful resource when writing YARD documentation.
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, make sure that you’ve got the approval of at least one other release manager (and preferably also the approval of Denis).
Before you start, ensure that you have access to the following:
- GitHub push access
- RubyGems push access
- Web site push 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
Once the preparation is complete, the new version can be released. To release a new version of Nanoc, follow these steps:
- Build the gem (gem build nanoc.gemspec).
- Tag the release using git tag --sign --annotate 1.2.3 --message 'Version 1.2.3', replacing 1.2.3 with the new version number. Signing Git tags is optional, but highly recommended.
- Push the gem using gem push nanoc-*.gem.
- Push the changes to GitHub (git push). Don’t forget to also push the tags (git push --tags).
- Close the GitHub milestone for this version, and ensure milestones for the next patch and minor versions exist. For example, when releasing 4.2.3, close the milestone for 4.2.3, and ensure milestones for both 4.2.4 and 4.3 exist.
Spread the word
To announce the new release, follow these steps:
- Update the release notes on the site. This only involves recompiling the site with the new version of Nanoc (the release notes on the site are extracted from the NEWS.md file in the Nanoc gem) and pushing the site (bundle exec nanoc deploy).
- Update the release notes on GitHub. Create a new release for the tag, set the release title to the new version number, and copy-paste the release notes into the description field.
- Send an announcement e-mail to the Nanoc mailing list. Include the version number, link to the release notes, instructions for how to update (using plain RubyGems and using Bundler), and instructions on how to report issues. The e-mail template that I often use is based on the following:
- Update the version mentioned on the Nanoc Wikipedia page.
Hi, Nanoc version is out. This major/minor/patch release fixes a bug related to X/adds enhancements X and Y/adds feature X. You can find the full release notes at the bottom of this e-mail or at http://nanoc.ws/release-notes/. You can update your gems using `gem update`. If you use Bundler (which I recommend), run `bundle update` to get the latest version of Nanoc. Do report any bugs you find on the GitHub issue tracker at https://github.com/nanoc/nanoc/issues/new. Cheers, Denis RELEASE NOTES
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 email@example.com. 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.
These people have contributed to Nanoc already:
Ale Muñoz, Alexander Groß, Alexander Mankuta, Andy Drop, Arnau Siches, Ben Armston, Bil Bas, Brian Candler, Bruno Dufour, Cédric Boutillier, Chris Burkhardt, Chris Chapman, Chris Eppstein, Christian Plessl, Colin Barrett, Colin Seymour, Croath Liu, Damien Pollet, Dan Callahan, Daniel Hofstetter, Daniel Mendler, Daniel Wollschlaeger, David Alexander, David Everitt, Denis Defreyne, Dennis Sutch, Devon Luke Buchanan, Dmitry Bilunov, Eric Sunshine, Erik Hollensbe, Fabian Buch, Felix Hanley, Garen Torikian, Go Maeda, Grégory Karékinian, Gregory Pakosz, Guilherme Garnier, Hugo Peixoto, Jack Chu, Jake Benilov, Jan M. Faber, Jasper Van der Jeugt, Jeff Forcier, Jim Mendenhall, John Nishinaga, Justin Clift, Justin Hileman, Kevin Lynagh, Lorin Werthen, Louis T., Lucas Vuotto, Mathias Bynens, Matt Keveney, Matthew Frazier, Matthias Beyer, Matthias Reitinger, Matthias Vallentin, Micha Rosenbaum, Michal Cichra, Michal Papis, Mike Pennisi, Nelson Chen, Nicky Peeters, Nikhil Marathe, Oliver Byford, Paul Boone, Peter Aronoff, Raphael von der Grün, Rémi Barraquand, Remko Tronçon, Riley Goodside, Ruben Verborgh, Scott Vokes, Šime Ramov, Simon South, Spencer Whitt, Stanley Rost, Starr Horne, Stefan Bühler, Stuart Montgomery, Takashi Uchibe, Toon Willems, Tuomas Kareinen, Ursula Kallio, Vincent Driessen, Vlatko Kosturjak, whitequark, Xavier Shay, Yannick Ihmels, Zaiste de Grengolada