Closed hollasch closed 1 year ago
Add a blurb about the role of the development
versus master
branches.
On rethinking this, we should add additional notes in the repo directly. The entire project should be usable and complete in an entirely offline mode.
That means either an appendix covering platform-dependent issues, or standalone notes in a notes/ directory or something.
Anyway, needs more overall thought.
Removing the punt label. This should be resolved in the v3 release.
Consider a section on further reading, such as Ray Tracing Gems. Probably start out as a seed wiki page.
Do we want a Further Reading section as a ...
I personally quite like the idea of a further reading markdeep document that is referenced as is it's own section in index.html
It isn't unreasonable to see such a thing quickly becoming the de-facto source for extended Ray Tracing learning
I think a standalone Markdeep document in the books directory would be best, and we can also link to this from the web home page (index.html
). Initial form isn't important, but I imagine that it would evolve into bibliography, perhaps categorized by topic. In fact, it might even be called bibliography.html
. Sections should be addressable, as should individual entries.
Okay, I have a bit of a jumbled mess where you'd typically find a brain.
For the FurtherReading.html
(or Bibliography.html
, I prefer FurtherReading.html
in the first draft), how do we want to structure it?
From the wiki: https://github.com/RayTracing/raytracing.github.io/wiki/Aggregation-of-Possible-Next-Steps
We have a couple of dissimilar things jumbled together.
This is biting off more than we can chew, but, for my own sanity, at least, I would like the project to get to a place that,
FurtherReading.html
doc contains
This is explicitly not a text book, but at some point we might need to have a conversation about Exercises. The books already nod toward having them (in the Further Reading sections), but the explicit outlining of Exercises introduces a lot of friction for the reader.
Indeed, all of the structure outlined above is an increase in friction for the reader. So I don't strongly recommend any of it, but it's a topic I've been ruminating on for a few weeks, and have largely not had any success in congealing. The excessive structure is simply a coping mechanism.
Consider pushing to a 3.2
This issue is kind of 2 different things at this point
For the second part, #407 is maintaing that.
Is the first part completed? We might be able to close out this issue?
The issue is fuzzier than I'd like. I was thinking of OS/platform/IDE specific guidance and supplementary documentation like that. I suppose that's backwards, and we should wait until we have some actual content first and then figure out how to fit it in.
TheNextWeek:Overview
What I will do in this mini-book is go with the simplest approach
in each design decision I make. Check https://in1weekend.blogspot.com/
for readings and references to a more sophisticated approach.
This will eventually need to be changed to point to the documentation outlined here
I lied. This thing is 3 issues.
I'm going to unassign myself and have you (@hollasch) do numbers 1 and 3. We're definitely punting on 2.
I think we need to do 1 (overhaul of ...) for v4, the question is if you want to punt on 3.
Yes. OS/platform/IDE specific guidance has been added ad hoc
inline where necessary, and we don't really hit enough of these issues to warrant a more formalized solution.
So this is just scoping down to a light overhaul, and probably doesn't even really need further work outside of talking about the latest release status.
Done in master. Time for this spaghetti monster to go move along.
Review README.md, CONTRIBUTING.md and the wiki. For example, the README needs more project information, some of which is currently located in the wiki.