Stop using number indices for modules

[kianenigma]

We are shuffling modules around from cohort to cohort.

Having the module folder names be prefixed by a number that always changes is neededless work for everyone.

• Abolish the number prefix.

I don't have a strong opinion about images. Given that we often reuse images from mod to mod, I would be fine with having all images in one folder, as long as name collision is avoided, which should be pretty unlikely.

Image folders in each syllabus folder is also good, given that we fix the main point above.

[nuke-web3]

Have you bothered to ask why there is this system at all? ;)

Presently there is no way (without number prefixes) to get:

• any sense of sequence from the directory structure.
• any sense of sequence from the template-based listing/landing page of all sides.
• build & host specific modules selectively, in sequence. (not lessons within it specifically)
• ... perhaps more I am forgetting.

I am for no numbering in file names, IFF #839 is completed in full and thus we can reason about sequence irrespective of the directory structure and file names as part of the build process.

So until those are resolved, we require a module prefix at a minimum.

---

I would be for a global image and asset "dump" where there is no directory structure to maintain, perhaps at most per module within it, but @JoshOrndorff has a strong preference for the opposite IIRC. I was moving in this direction with the #708 series of PRs I just submitted. I will let Joshy chime in more why that makes most sense (img folder per module) before I revert this direction. Here are a few reasons to have dedicated per module folders for slide's assets:

• content creators do not need to reason about or even be "aware" of the tooling to build slides, thus the assets dir can be renames to tooling or something, and all content lives in syllabus or renamed to something more "clear" that is the primary focus for all faculty.
• migration of slides between modules is clean, if you migrate images as well.
• there is no duplicated hierarchy in a global img directory, just one for slides, and tightly coupled images and other assets to those slides.

In any refactoring of images we need #784 to work well and ideally something a yarn job and/or CI can help check us on.

---

In general, and I need to update the CONTRIBUTING doc for reference as part of #708 , the structure I am using is:

syllabus
├── X-Module
│  ├── img
│  │  ├── something.svg
│  │  ├── raster.png
│  │  └── ...
│  ├── Y-Lesson_Title-slides.md
│  ├── ...
 ...

If we change this via this issue resolving, we need to decide globally and fast as our deadline looms.

[kianenigma]

I have my fingers crossed for #839 then 🤞🏻

[nuke-web3]

I think we are unblocked by #839 - take a look

[JoshOrndorff]

I have a strong preference for keeping images local to the slides that they appear in; Nuke is correct about that. Here are some reasons (I'll edit in the others as I remember them):

• If a module gets deleted or renamed, that only has to happen and one place and there is no chance that the two will go out of sync.
• When working in an IDE with a file explorer in a left pane (like the major ones have) it is nearly impossible to see both the slide md files and the images at the same time.
• The links from slides to images are shorter and easier to read and don't interfere with the line length formatting as much.

I also support Kian's goal in this issue of removing the numbers from directory and file names. I think the proper way to show the ordering or dependencies between modules is in a md document. This actually does exist currently, but it is not easy to discover. Maybe the main readme makes more sense.

[nuke-web3]

Indeed I opted for a fully modular lesson structure: https://github.com/Polkadot-Blockchain-Academy/testing-only/tree/main/content/cryptography/addresses as an example (this test repo will be deleted once our public book repo is made FYI).

There is only one issue with this: it's hard to reuse assets between lessons and modules.

The sequencing is resolved by use of mdBook & the SUMMARY.md page also:

[JoshOrndorff]

Why is this closed? There are still number indices in the directory names.

[nuke-web3]

This repo is moving to an archive, and thus we will no longer need to try and fix things, a new monorepo book is imminent that has no indices. here is the WIP that will be destroyed when approved and the HEAD of that repo used to start the new public facing content repo with slides embedded: https://github.com/Polkadot-Blockchain-Academy/testing-only