Skip to content
Daniel Côté edited this page May 20, 2020 · 28 revisions

Welcome to the RayTracing Tutorial Project

  • Before anything, read the project README to get started and understand what this Python module is all about and what ray tracing is.
  • The list of things to do (called Issues) are here. If they are not assigned to anyone, you can take them by assigning them to you.
  • The KanBan board tracking everything To Do/In Progress/Done is here. Things move along from left to right. Things to do can be issues or other things not on GitHub
  1. To get started on writing, read HOWTO modify the article file. The article is on Overleaf
    1. Start by discussing with Daniel a section you want to work on
    2. Propose a quick outline
    3. Keep your iterations short: it is frustrating for you if you must rewrite or delete large sections
    4. Sometimes, finding the right word for a sentence can take 30 minutes. That is normal.
  2. To get started on coding, read HOWTO-Code on GitHub.
    1. You can adopt any issue, as long as you own it properly: go through, fix it, call for help if needed.
    2. Always create a branch to work. Start from master or a sub-branch if you are working on a specific detail that has not been merged yet into master.
    3. Very now and then, Fetch in the GitHub application to get changes to get your branch up to date
    4. Every day, click Update from Master in the GitHub application to pull important changes that were accepted major changes
    5. Readability of the code is essential: docstring for each function, proper capitalization. Read HOWTO Coding Style Guide
    6. Any changes where you fix a given function that does not work properly will probably be accepted quickly.
    7. Any changes where you propose a new algorithm will be reviewed carefully. Remember, speed is not the key design goal: readability and usability are.
    8. Any changes to the API (i.e. if you change a function name or the number of arguments) without backward compatibility is not accepted unless you provide strong (and good) arguments. We do no program only for us: people have been using the code for some time now.
    9. Proper capitalization is important. Function and variable names are very important.
    10. Create a Pull request when done. Assign reviewers: D. Côté + others if you want feedback from others.
    11. Only D. Côté can merge the pull requests.
  3. To get started on writing tests, read HOWTO Write Unit Tests
    1. We aim for 90% coverage with the tests.
    2. You find a bug? Create a test that illustrates it, then create an Issue. Then go to 2.
Clone this wiki locally