Ok. This will be a rehash of a previous post, but it's relevant nonetheless.
To know which categories are intuitive, we must trace a 'lifecycle of knowledge', the path whereby information is discovered, disseminated and applied by others. Once we know this 'path', we know which discussions are likely to merge into which others.
Broadly, knowledge on Qhimm takes the following path:
- Reverse engineering generates info about algorithms and file formats. Halfway through disassembly, someone will probably produce a file viewer. Further discussion ensues.
- Finally, once discussion has 'matured' (i.e. once we're fairly sure how this or that feature works), we copy info into the wiki and turn our viewers into editors
- Visitors take these editors and wiki knowledge, and use them to create a mod. These mods are rarely perfect first time, and it's likely that end users will raise bug reports. This feedback will further develop those mods.
[li]Elsewhere, a very different class of mods will become community patches for the official releases. These mods rarely involve the same tools as the others. They focus on a certain kind of bug report for the PC release. They don't involve the qualitative feedback other mods require.
[/li][/list]
From this, I suggest that:
- Tech related discussion should include tools as a child board. Tools are created as part of the reverse engineering process, not at the stage of modding projects
- Mod threads need to include bug / feedback discussion. Release posts and bug reports are part of the same 'dialog'.
[li]Community patches need to live separately to other mods. They should sit as a child board in a 'tech support' thread
[/li][/list]
