Skip to content

Latest commit

 

History

History
69 lines (46 loc) · 3.11 KB

CONTRIBUTING.md

File metadata and controls

69 lines (46 loc) · 3.11 KB
Raw

Contributing To The Ray Tracing in One Weekend Series

The Ray Tracing in One Weekend series is intended to be lightweight and accessible for all who want to learn about ray tracing and related graphics topics. To that end, we welcome feedback, proposals, and improvements.

In particular, we are now a dedicated GitHub organization. The books are now available in HTML from https://raytracing.github.io/, so we can keep the content up-to-date with the latest corrections and improvements.

Development Branches

We use master as our release branch. Generally, changes should never go directly to the master branch. All ongoing development work (and all of the latest changes) will be in the dev-patch, dev-minor, or dev-major branches. The appropriate target branch for any pull requests you want to make will be determined in the associated issue first (all PRs should have an associated issue).

Issues

The easiest way to help out is to log any issues you find in the books. Unclear passages, errors of all kinds, even better ways to present something -- just go to the issues page.

Before creating a new issue, please review existing issues to see if someone has already submitted the same one. Odds are you're not the first to encounter something, so a little quick research can save everyone some hassle. It's also a good idea to verify that problems still exist in the development branch when creating new issues.

When entering a new issue, please include all relevant information. For content issues, include the book or books this applies to, and specific locations that should be reviewed. Similarly for code: please include the file, function/class, and line number(s) if that applies.

Pull Requests

To contribute a change to the project, please follow these steps:

  1. Create a GitHub issue.

  2. Let us know whether you're willing to make the fix yourself.

  3. Participate in the discussion as needed. We'll ensure that the work doesn't conflict with or duplicate other work planned or in progress, and decide which development branch is correct for the release type and release schedule.

  4. Create your changes in a feature branch (or fork) from the assigned development branch (dev-patch, dev-minor, dev-major).

  5. Follow the existing code style.

  6. Include a one-line summary change at the bottom of the current development section in the changelog. Include a reference to the associated GitHub issue.

  7. When ready, create your pull request and request a review from "rt-contributors".

If anything above sounds daunting, note that you'll get massive credit for actually reading the CONTRIBUTING.md and following the process above -- so we'd be delighted to answer any questions and guide you through the process.

Questions

If you have any questions, feel free to ping me at steve@hollasch.net.