Contributing to Scalding
This page lists recommendations and requirements for how to best contribute to Scalding. We strive to obey these as best as possible. As always, thanks for contributing–we hope these guidelines make it easier and shed some light on our approach and processes.
masteris the latest, deployed version.
developis where development happens and all pull requests should be submitted.
Submit pull requests against the
develop branch. Try not to pollute your pull request with unintended changes. Keep it simple and small.
The documentation for Scalding’s website is stored in the
docs/src/main/tut directory of the docs subproject.
We would love your help making our documentation better. If you see a page that’s empty or needs work, please send us a pull request making it better.
Make sure to add some code examples! Any code block of this form in any documentation markdown file will get compiled using
tut will evaluate your code as if you’d pasted it into a REPL and insert each line’s results in the output. State persists across
tut code blocks, so feel free to alternate code blocks with text discussion. See the tut README for more information on the various options you can use to customize your code blocks.
- Add your page to the appropriate section in the menu
Generating the Site
sbt docs/makeMicrosite to generate a local copy of the microsite.
Previewing the site
- Install jekyll locally, depending on your platform, you might do this with any of the following commands:
yum install jekyll apt-get install jekyll gem install jekyll
- In a shell, navigate to the generated site directory in
- Start jekyll with
jekyll serve --incremental
- Navigate to http://127.0.0.1:4000/scalding/ in your browser
- Make changes to your site, and run
sbt docs/makeMicrositeto regenerate the site. The changes should be reflected as soon as
After the release occurs, you will need to update the documentation. Here is a list of the places that will definitely need to be updated:
README.md: update version numbers
CHANGES.md: summarize changes since last release
(Other changes may be necessary, especially for large releases.)
You can get a list of changes between release tags
git log v0.1.2..v0.2.0. Scanning this list of commit messages is a good way to get a summary of what happened, although it does not account for conversations that occured on Github.
Once the relevant documentation changes have been committed, new release notes should be added. You can add a release by clicking the “Draft a new release” button on that page, or if the relevant release already exists, you can click “Edit release”.
The website should then be updated via
By contributing your code, you agree to license your contribution under the terms of the APLv2.