The physics system in Panda was originally developed by a summer intern at the Disney VR Studio, for the purpose of controlling particle effects. It worked quite well for what it did, but as an intern project it was never terribly well documented. It was later extended and enhanced by various full-time engineers over the years to add a bit more functionality, but as it happens, no one had the time to go back and add more documentation.
This is one of the sad realities of life: engineers are paid to develop code, not documentation. Although well-documented code almost always pays for itself in the long run, businesses (including the VR Studio) tend to be more focused on the immediate needs of the short run. So sometimes code gets written in a hurry with minimal documentation; and it’s difficult to take time away from the demands of our current projects to go back and add documentation to something that already works.
We do the best we can. In fact, I think that Panda does pretty well for itself, compared to many other professional projects of similar magnitude. There are still large areas of the code that aren’t documented well, or at all; but on the other hand there are vast areas that are really quite well documented internally. And we have this splendid online manual, which grows more and more detailed every month.
(I say Panda does well compared to other professional projects. I’m not claiming that it’s as well documented as other volunteer projects. Projects that were designed from the ground up as volunteer open-source projects tend to be better documented from the beginning, because they don’t have the same market pressures on them to meet deadlines, and because good documentation is much more important when your developers are distributed around the world, rather than all collected in one room together. Since Panda started life as a closed-source project to meet the needs of Disney, and indeed still is developed primarily by Disney, it tends to be less well documented than some other open-source projects.)
Any user contributions to the documentation are, of course, welcomed and encouraged. Contributions of this nature will make the project better for everyone.
For figuring out systems that are not as well documented, it may be helpful to download the C++ source code and read that directly. The comments in the C++ code are the source of the generated API docs, but I find that the C++ code is a bit easier to follow than the generated API documentation, because it tends to be organized a bit more by functionality (rather than strictly alphabetically, for instance), and because occasionally comments that have been placed in unusual places in the code are inadvertently omitted from the generated docs.
And, of course, you can always read the code itself. Sometimes that’s the best description of what a particular function is supposed to do. 
David