I have reached the point where its time to move things into modules for the wiki.
I would like to name these modules based off the engine architecture so when something is moved I will know exactly where it should live.
Not sure exactly how to word this so I will just put it as best I can.
How would you categorize the components of jMonkeyEngine and what would you pick as topics for that component?
Ok heres a list of the new moduless.
As you can see they are indeed right and match the structure of the engine.
I will use these sub topics in those modules,
Lets try this another way,
These are engine components I believe, whats missing, if anything.
What engine component do these belong to,
indeed hard question.
yes, most problematic is Rendering vs Graphics.
IMO Rendering should go as sub-category of Grahics and contain āPre/Main/Post render / off-rendering / alpha / depth / aspect ratio / frustrum / etcā
Mainly what is in JME Tests ā renderer
Is terrain really an engine component ? That seems really game specific - just curious if this is a relic or an up-to-date decision 
What function do modules serve? If itās so difficult to categorize documentation topics and pages into modules, perhaps have fewer modules or even just one?
For what itās worth, hereās how I think about the topics youāve mentioned:
Of course, thatās not how the software is structured. Perhaps the software and the documentation should have different structures.
All topics are a leaf of some component. What I found when searching is the basic components that make up a game engine are specific to the engine itself. No two engines refer back to the same basic components.
There is some overlap that was obvious like,
@asser_fahrenholz I am not sure so thats why I ask, what component would it fall under if its not a component itself?
As @oxplay2 says, Rendering vs Graphics. So Graphics should be a component as listed and remove rendering.
A module can be looked at as a Book. The topics are chapters in that book. No two modules/books contain the same topics.
It is extremely subjective as your post helps to illustrate. Try searching on 3d game architecture and see what you get. Everything is specific to the engine itself.
Having one module is what we have now. Everything is lumped into this one module. If all we were going to do is use this one module then what was the use in converting to a modular system in the first place?
So to summarize your thoughts, these are the core components of the jme engine.
I really like the detail given in your post but I am surprised you list physics as a topic/chapter rather than a component/book given you have a complete site built around this one subject. That is one thing all engines had listed as a component, physics.
As I mentioned before, I was not sure how to word this properly so maybe this will help clear things up. I know it may seem like a trivial matter, but it is very important to get this right.
Thatās a nice analogy, but it doesnāt help us decide how to divide the wiki into modules. Paper publications are split into books for reasons that are irrelevant to a website. Once we understand what modules are for, I suspect the answer to your question will be clear.
Youād know better than I would! Your post indicated a desire to have offsite modules maintained by independent owners. If thatās what modules are for, then perhaps modularization should be based on repositories and/or owners.
Thatās an interesting point. Actually my website consists of 2 modules. Thereās a āminie-library-tutorialā module that walks you through using the Minie physics library in a JMonkeyEngine game, and then thereās a āROOTā module for all other aspects of the Minie Project. My thought was that all the āminie-library-tutorialā topics would eventually be shared between my site and the JMonkeyEngine wiki, while the āROOTā topics would not be shared.
Modules are an organizational method that are intended to hold topics that only apply to the module they live in. When done right, it should be intuitive for a contributor to know where a topic should live. If we match the engine design, this will occur naturally. The wiki will have a certain flow that just feels right. Maybe this will lead to more contributors. This will also help expose where we have holes in content that need to be filled.
For a physics module example, physics related topics and the module itself match a specific design element of the engine. The goal is simplification when adding, removing or editing content. We want the relationship to be obvious.
Take sound. We know this module represents something specific to the engine architecture, thats an easy one.
As was pointed out though, we have rendering and graphics. Is terrain one or the other or should Graphics be all encompassing, including filters, shadow and light? When looking at the engine source, there are terrain, lwgl and gui modules. Do all these have a common element that they spring from? If not then they should be components themselves.
In your use of I/O you lump networking in yet other engines consider that a module all in and of itself. This is the reason I brought this up. Those who are arms deep in the engine guts know best about the core design, not me.
I want to narrow each module down to what makes the most sense, the lowest common denominator so to speak.
Edit:
Unity
That sentence looks like a circular definition.
In the case of physics, thereās a very clear division between whatās physics and what isnāt. So clear that the physics code could be moved to a separate repo and released on its own schedule, as Iām doing with Minie. The independent release numbering implies to me that Minie physics, at least, has to be a separate module.
With sound, I donāt think itās so clear. Sound-related code is found in at least 5 Engine libraries: jme3-core, jme3-jogg, jme3-android, jme3-android-native, and jme3-nifty. If you modularized the documentation based on the Engine architecture, you might wind up with audio documentation in 5 different modules, which wouldnāt make things easy for contributors.
This is a reasonable enough break down, I guess. Even sgoldās comments related to audio aside, there is implementation code spread around but the āuserā facing classes are at least all in core.
But I might call āgraphicsā just ācore engineā in our case. Else we need to figure out where to talk about app states, controls, etcā¦ which are not graphics.