Skip to content

funky repo structure with duplicated conflicting files #55

@pawrequest

Description

@pawrequest

hi guys, im new here, but i kinda wanna make some pretty big changes, and i'm willing to put the time in to get it done if there's agreement...

i feel like when i came to cp modding (only late last year so bear with me) i struggled to find the available resources, and now i've poked about in the ecosystem a bit, i know there are actually great docs, i just couldnt find them.

i think there are some changes we can make to the docs on a structural level that will cascade down into a better user experience of the wiki, and better connection between creators and tools/knowledge, as well as making it easier for maintainers to grok the docs repo.

i made a couple of simple suggestions in other issues just now, but there are some bigger changes that i wouldnt just throw out as a random pr.

eg, why do we have

├── for-mod-creators
├── for-mod-creators-theory
├── for-mod-users
├── glossary.md
├── modding
├── modding-guides
├── modding-know-how
└── the-wiki

when most of the toplevel categories are subcategories of 'for-creators'?

and then what's the semantic difference between 'guides', 'knowhow' and 'theory'?

so now there's
for-mod-creators/files-and-what-they-do/components/comprehensive-components-list.md
and also
for-mod-creators/theory/files-and-what-they-do/components/comprehensive-components-list.md
and they conflict.

we should, i think, make a plan to :

  1. do away with lots of the top level categories like 'modding', 'modding-guides'
  2. integrate most of the midlevel folders under for-creators
  3. consider combining some midlevel folders (eg frameworks and core-mods as one?)
  4. resolve any conflicts in the files and check internal references resolve
  5. edit extend and replicate the various readmes scattered about to serve as indexes and nav pages

it seems pretty dramatic, and probably needs some discussion, but i think it's worth it.
btw im not married to one particular vision of a restructure, but the general idea of integrating these nebulous categorisations like 'modding' and 'modding know-how' and 'theory' seems sound to me

if people are agreeable im happy to start a long-running branch and get contributions and feedback until merging is possible

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions