My typical workflow - in private business repos, but for the same reasons specified in OP - is as follows:
1. Fork the PR branch.
2. Make the changes I want to see upstream.
3. Create a PR into the author's branch.
4. Ask the author to review my changes.
5. When my PR is complete, finally review and merge The original PR.
This gives me the opportunity to explain my changes in commit messages, and gives the author an opportunity to push back or argue actual functionality changes I made if it's not all coding style. Now the author has license in accepting my changes. It avoids the cumbersome comment/resolve feedback loop, shows the author that their contribution is important and I'm willing to put time into making it right, and ultimately gives them credit when their PR is merged.
So this tells us that the diameter of the moon is roughly one Australia, East to West.
Alternatively, if we simplify Australia to a circle, then the moon's radius is equal to Australia's radius.
Therefore, since the (surface) area of a circle is πr^2 and the surface area of a sphere is 4πr^2, the moon has roughly four times the surface area of Australia.
You know you really don't need to tear down his work because you don't like the way it reads.
Lots of the missing articles are around command line arguments, where the correct usage is ambiguous anyway.
I don't find it distracting. The content of these books is an excellent resource on an immeasurably useful topic.
As for "... but if you're asking for money...," this post is literally giving away his work. The consumer is given the option to pay nothing, or whatever is reasonable according to their own valuation.
If you as the consumer value the work less because it fails to conform to language rules, then you are actually invited to decrease the compensation given by you to the author.
Don't feel bad - it's something many many people confuse. Marketing jargon, changing production targets, and general lack of knowledge in a very technical field only exacerbate the problem.
I think it's important to note a few things about your second point:
This version of Magic Leap's display has nothing to do with light fields. It is a wave guide optic, just like Epson Moverio, Hololens (the term holographic also implies nothing special in terms of optics, it's a wave guide display combined with perspective rendering), and almost all other see-through HMDs. Magic Leap made headlines when they teased their oscillating fiber display, which had potential to render light fields, but that has not been pursued with this release. That's not to say they won't pursue it in the future, it's just not relevant to this product.
Next, eye tracking actually doesn't affect what is rendered to the display. The relationship of the headset display's field of view to the user is rigidly fixed even if your eyes move; different objects should not be rendered when moving only your eyes.
Rather, eye tracking is used for contextual information and user interaction. Gaze direction could be an input to foviated rendering, or you could use your eyes to select and manipulate digital objects.
Nothing I've said is meant to detract from ML's product; it's a very exciting development and a huge accomplishment for ML and the XR industry. I just think we should keep these points in context.
Anybody see the background picture behind the article? I'm on my phone, can someone with means extract it and post it somewhere so we can see what it is?