Move modules into new courses that don't need changes

[adamblanchard]

Some modules don't need any content changes to make them work in the new program structure.

A good first step would be to move these ones, which can also set an example for how we should do it for the other modules that need some breaking up/restructuring/additional changes.

e.g. html/css is staying the same and as a single module as it is today, so this one is easy to move over!

I'll write a plan for what "moving over" means, as part of this ticket.

• HTML-CSS
• Pre-course
• Team process (don't think this exists anywhere yet... need to ask around)
• ...

[rvedotrc]

What I intend to do is to copy over all the existing content (modules, whatever you want to call them) as-is, as a jumping off point for the new stuff. The way I'm thinking of this stuff is that the modules/courses/units-of-learning form a directed acyclic graph, with a directed path from A to B representing "once you already know A, taking this path teaches B [and everything else along that path]".

and if that's the case then it does no harm — and I would say that it's helpful — to add units in to this repo, i.e. the legacy/existing ones — because the mere existence of a unit doesn't make it automatically part of anything.

In this way of thinking, it would be helpful to be able to see that directed acyclic graph. I'm having a think about that.

[adamblanchard]

@rvedotrc I see where you're coming from, because the "importing" idea is how I approached the proposal doc, by just linking to the existing content.

The scope for this specific task is to add modules that are already "finalised", ie. have no major required changes in the new programme compared to the "legacy" version. These are (mostly) straight up copy and pastes of existing modules, but in the right places in our new courses. Then we can call those "done" for now.

I'm not sure I see the value in creating those "imports" into this repo on their own (like your examples in your recent PRs), since we already have a proposed plan, we can skip a step:

1. Go through each course/modules in the proposal doc
   a. If the module content has an agreed place in our new programme (e.g. git1/week1 into foundation course) copy the full content over already and call it done.
   b. If we don't know how to structure specific module(s) yet (e.g. javascript/node.js) make a proposal first (see Plan to split up existing javascript/node.js modules across the new courses #4), and try again.

The first tasks I've written out on the project board are supposed to reflect the first steps in that process.

I am at risk of sounding dismissive about thinking more deeply about this first pass of the new programme, because I'm trying hard to scope the first goal to "simply" reuse existing content and structure it into three courses. It's the (very) bare minimum before onboarding the next teams.

But we of course have lots of much needed improvements in the next iterations (as well, following on from our "ideal learning goals" workshop soon!). In the scope of that work, I'm super interested to hear more about how you see the content fitting together, especially if we can find a neat way of visualising the connections between stuff 🤔

[rvedotrc]

The value that I see, at least, is that by starting with an as-is import, all the subsequent work is smaller, e.g. refactoring.

Anyway, I await reviews on my PRs. :-)

[rvedotrc]

See #16 and #19 .

[adamblanchard]

I'll raise another ticket for "Team processes" module, because it's a new module that I can't just copy over from somewhere already.

So, at this point, this ticket only contains moving the Pre-Course material over. Details in #26