-
Notifications
You must be signed in to change notification settings - Fork 45
Home
Daniel Côté edited this page May 20, 2020
·
28 revisions
- 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
- To get started on writing, read HOWTO modify the article file. The article is on Overleaf
- Start by discussing with Daniel a section you want to work on
- Propose a quick outline
- Keep your iterations short: it is frustrating for you if you must rewrite or delete large sections
- Sometimes, finding the right word for a sentence can take 30 minutes. That is normal.
- To get started on coding, read HOWTO-Code on GitHub.
- You can adopt any issue, as long as you own it properly: go through, fix it, call for help if needed.
- 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.
- Very now and then,
Fetch
in the GitHub application to get changes to get your branch up to date - Every day, click
Update from Master
in the GitHub application to pull important changes that were accepted major changes - Readability of the code is essential: docstring for each function, proper capitalization. Read HOWTO Coding Style Guide
- Any changes where you fix a given function that does not work properly will probably be accepted quickly.
- Any changes where you propose a new algorithm will be reviewed carefully. Remember, speed is not the key design goal: readability and usability are.
- 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.
- Proper capitalization is important. Function and variable names are very important.
- Create a Pull request when done. Assign reviewers: D. Côté + others if you want feedback from others.
- Only D. Côté can merge the pull requests.
- To get started on writing tests, read HOWTO Write Unit Tests
- We aim for 90% coverage with the tests.
- You find a bug? Create a test that illustrates it, then create an Issue. Then go to 2.