Merge branch 'main' into feature/nw6-html-css-sprint-1

.env.example

@@ -1,8 +1,8 @@
 # Allow accessing a GitHub bearer token to avoid rate limits when doing HTTP fetches to the GitHub API.
 # This can be generated at https://github.com/settings/tokens?type=beta and needs read-only access to all public CYF GitHub repos.
-CYF_CURRICULUM_GITHUB_BEARER_TOKEN=""
+HUGO_CURRICULUM_GITHUB_BEARER_TOKEN=""
 # Client ID and secret for the GitHub OAuth app used to authenticate users.
 GITHUB_CLIENT_ID="clientid"
 GITHUB_CLIENT_SECRET="clientsecret"
 # The domain of the site, used for generating redirect URLs.
-DOMAIN="http://localhost:8888"
+DOMAIN="http://localhost:8888"

.github/pull_request_template.md

@@ -1,3 +1,7 @@
+# WARNING MAJOR STRUCTURAL CHANGE IN PROGRESS 12 JAN 2024
+
+Hello contributor! In between you opening this PR and you merging it, you may find a large conflict appears. This is because this site will be broken down into Hugo modules in the same way CodeYourFuture/curriculum-labs is currently structured. The platform (features) will move into the common-theme module and the content (text) will move into the common-content module. The pages will move into the organisation directory. (org-cyf for CYF and org-mcb for MigraCode) You will need to find the new location of your content and move it there. If you are unsure, please ask in the comment thread of this ticket.
+
 ## What does this change?
 
 Module:
@@ -18,7 +22,3 @@ Week(s):
 ## Who needs to know about this?
 
 <!-- Tag anyone who might want to be notified about this PR -->
-
-## Rendered Pages
-
-<!-- Leave this area and below blank. A github bot will render your changed github files for you here. -->

.github/workflows/check-consistency.yml

@@ -0,0 +1,19 @@
+name: Check consistency
+
+on:
+  pull_request:
+  workflow_dispatch:
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Setup Go
+        uses: actions/setup-go@v4
+        with:
+          go-version: 1.21
+      - name: Build tooling
+        run: (cd tooling/go && go build ./cmd/local-overrides-enforcer)
+      - name: Check consistency
+        run: ./tooling/go/local-overrides-enforcer

.github/workflows/test-tooling.yml

@@ -0,0 +1,17 @@
+name: Test tooling
+
+on:
+  pull_request:
+  workflow_dispatch:
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Setup Go
+        uses: actions/setup-go@v4
+        with:
+          go-version: 1.21
+      - name: Run tooling tests
+        run: cd tooling/go && go test ./...

common-content/en/blocks/evaluate/index.md

@@ -0,0 +1,33 @@
++++
+title="Evaluate ✏️"
+headless="true"
+time= 60
+[objectives]
+    1="Evaluate your current progress against previous modules"
++++
+
+You must check in with yourself and evaluate your progress as you move through the course.
+
+Check your progress against your past self: go back to and tackle a problem from a previous part of the course.
+
+{{<note title="Pair up and check progress" type="activity">}}
+
+## Setup 🧰
+
+1. Trainees need to split up into pairs
+1. In your pairs, nominate a driver and a navigator. A driver will type out the code. A navigator will use the prep to steer you in your solution.
+
+## Activity
+
+1. Find a problem from 2 modules ago and familiarise yourself with it
+1. Test and implement a solution to the chosen problem
+
+### Pay attention ❗🔍
+
+- Write tests first and run your tests frequently to get feedback
+- Swap driver and navigator roles often - perhaps after every test
+- Use your unit tests to break down the problem - don't try implementing everything all at once
+- Discuss your strategy together before writing any code
+- Check the learning objectives in each block. Do they make sense? Discuss them together as a pair
+
+{{</note>}}

common-content/en/blocks/morning-orientation/index.md

@@ -0,0 +1,41 @@
++++
+title="🎡 Morning orientation"
+headless="true"
+time=15
+[objectives]
+    1="Introduce and welcome new volunteers"
+    2="Nominate a timekeeper"
+    3="Check the morning day plan and group structures"
++++
+
+{{<note title="Planning during the week" type="info">}}
+🧭 Step 1 and step 6 can be done earlier in the week. Create a post on Slack and get some people to take on the roles of **timekeeper** and **facilitator**. Nominate people who've not done it before.
+{{</note>}}
+
+# 👣 Steps
+
+0. Assemble the entire group (all volunteers & all trainees) in a circle
+1. Choose someone (volunteer or trainee) to be a **facilitator** for this morning orientation block
+2. The **facilitator** should briefly welcome everyone with an announcement. Here is an example announcement to read aloud:
+
+> 💬 "Morning everyone, Welcome to CYF {REGION}, this week we are working on {MODULE HERE} {SPRINT NUMBER HERE} and we're currently working on {SUMMARISE THE TOPICS OF THE WEEK}"
+
+3. Check if there are any new volunteers or if there are some attendees who haven't met before. Ask any newcomers to introduce themselves to the group/relevant people
+
+4. Check if it is the _start of a new module_. In other words, are you working on sprint 1? If so then ask someone to read out the success criteria for the new module you have started.
+
+5. Go through the _morning day plan only_ (typically on the curriculum website) - check the following things:
+
+- Check the number of Tech-Ed / PD volunteers you have for the morning
+- Double-check check someone is leading a given session
+- For any new activities ( like workshops or anything unfamiliar) - describe how this block works for the group. If there are any new volunteers, then briefly describe how that block works
+- Decide how best to allocate trainees and volunteers for a given block - some blocks will make this clear
+
+6. Nominate a timekeeper (volunteer or trainee) from the group - aim for someone who hasn't done it before.
+
+⏱️ Timekeepers will need to:
+
+- Announce the start of an activity and how long it will take (check everyone is listening)
+- Manage any whole class timers that are used in an activity
+- Give people a 10-minute wrap-up warning before the end of an activity
+- Announce the end of an activity and what happens next

common-content/en/blocks/requirements/index.md

@@ -0,0 +1,33 @@
++++
+title = 'Understanding Requirements'
+headless = true
+time = 20
+facilitation = false
+vocabulary=["Requirements", "User Stories"]
+emoji= '🧩'
+[objectives]
+1='Identify described requirements'
+    2='Identify extra requirements from your own experience'
+    3='Resolve trade-offs in conflicting requirements'
+    4='Translate requirements into high-level design outlines'
++++
+
+Communication is _hard_. Today, let’s explore some ways we communicate with each other in software development. It’s not enough to draw a picture of a website and assume the other person will build what you imagine. It’s never a good idea to assume shared context or shared interpretations.
+
+So how do we understand what to do? By understanding **requirements**.
+
+### Formalising Requirements
+
+Today we're going to think about requirements. We're going to ask these questions:
+
+- _why_ we're working on a project
+- _who_ we're making it for
+- _what_ they're going to use it for.
+
+Before starting to solve a problem (how), step back and ask yourself those **why**, **who**, and **what** questions.
+
+We're going to think about a few projects and discover some requirements. This is really important in order to do technical work, but you don't need to have any coding experience, or be thinking about coding, when doing this.
+
+{{<note type="tip" title="Remember" >}}
+To make great software, we need to think about people, not just code.
+{{</note>}}

content/fundamentals/blocks/user-stories/index.md → common-content/en/blocks/user-stories/index.md

@@ -1,43 +1,17 @@
 +++
 title = 'Understanding Requirements'
 headless = true
-time = 60
+time = 50
 facilitation = false
 vocabulary=["Requirements", "User Stories"]
 emoji= '🧩'
 [objectives]
-1='Identify described requirements'
+    1='Identify described requirements'
     2='Identify extra requirements from your own experience'
     3='Resolve trade-offs in conflicting requirements'
-    4='Translate requirements into high-level design outlines' 
+    4='Translate requirements into high-level design outlines'
 +++
 
-Communication is _hard_. Today, let’s explore some ways we communicate with each other in software development. It’s not enough to draw a picture of a website and assume the other person will build what you imagine. It’s never a good idea to assume shared context or shared interpretations.
-
-So how do we understand what to do? By understanding **requirements**.
-
-### Formalising Requirements
-
-Today we're going to think about requirements. We're going to ask these questions:
-
-- _why_ we're working on a project
-- _who_ we're making it for
-- _what_ they're going to use it for.
-
-Before starting to solve a problem (how), step back and ask yourself those **why**, **who**, and **what** questions.
-
-We're going to think about a few projects and discover some requirements. This is really important in order to do technical work, but you don't need to have any coding experience, or be thinking about coding, when doing this.
-
-{{<note type="tip" title="Remember" >}}
-To make great software, we need to think about people, not just code.
-{{</note>}}
-
-### User Stories
-
-We can discover requirements with something called 'User Stories'. The simplest user story looks like this:
-
-> As a [type of user], I can [achieve some goal].
-
 #### Imagine a coursework tracker
 
 As trainees, you have coursework to do. Imagine a website which tracks how coursework is going for you all. Thinking about that website, some user stories could be:

common-content/en/blocks/wordle/index.md

@@ -0,0 +1,7 @@
++++
+title="Play Wordle"
+headless="true"
+time= 5
++++
+
+<iframe src="https://www.nytimes.com/games/wordle/index.html" width="100%" height="640px"></iframe>

content/fundamentals/blocks/code-dot-org/index.md → common-content/en/module/fundamentals/code-dot-org/index.md

@@ -11,14 +11,12 @@ emoji= '🧩'
  4="Control flow with while statements"
 +++
 
-Code.org is a block based programming tool. We will use something similar to build our course project. Let's look at Code.org together now and work through the first two exercises. One person will share their screen.
+Code.org is a block based programming tool. We will use something similar to build our course project. Go to the Code.org website and work through the first two exercises
 
 {{<note type="activity" title=" Exercise">}}
 Go to [Course Three, Lesson 2: The Maze](https://studio.code.org/s/course3/lessons/2/levels/1)
 
-1. Look at the interface together
-2. Everybody open the interface on their own computer as well
-3. Complete the first exercise
-4. Complete the second exercise
+1. Inspect the interface
+2. Complete exercise one and two
 
 {{</note>}}

content/fundamentals/blocks/cyf-blocks-requirements/index.md → common-content/en/module/fundamentals/cyf-blocks-requirements/index.md

@@ -1,7 +1,7 @@
 +++
 title = 'CYF Blocks'
 headless = true
-time = 20
+time = 30
 facilitation = false
 emoji= '🧩'
 [objectives]
@@ -14,11 +14,10 @@ emoji= '🧩'
 
 For the majority of this course, we will use a custom CYF application called [CYF Blocks](https://blocks.codeyourfuture.io/#introduction). It uses the same visual programming editor, Block.ly, as Code.org, but you will use it to create JavaScript for real websites you can show others.
 
-Let's all look through the interface together now, and do one exercise as a group.
+{{<note title="CYF Blocks" type="activity">}}
 
-{{<note title="CYF Blocks (20 minutes)" type="activity">}}
+- Inspect the interface
+- Read the introduction
+- Complete all steps in the first exercise
 
-- Look at the interface together
-- Everybody open the interface on their own computer as well
-- Complete all steps of the first exercise
-  {{</note>}}
+{{</note>}}

content/fundamentals/blocks/overcoming-blockers/index.md → common-content/en/module/fundamentals/overcoming-blockers/index.md

@@ -6,8 +6,9 @@ facilitation=false
 
 {{<note type="narrative" title="Reading">}}
 
-> [Overcoming Coding Blockers](https://www.linkedin.com/pulse/how-overcome-coding-blockers-kingsley-ibe/)
-> {{</note>}}
+[Overcoming Coding Blockers](https://www.linkedin.com/pulse/how-overcome-coding-blockers-kingsley-ibe/)
+
+{{</note>}}
 
 ## Why are we doing this?
 

common-content/en/module/fundamentals/using-the-curriculum/index.md

@@ -0,0 +1,33 @@
++++
+title = '🗺️ Using the curriculum'
+headless = true
+time="50"
+facilitation = true
+emoji= '🧩'
+[objectives]
+   1="Describe CYF's mission"
+   2="Identify the key elements of CYF's educational philosophy"
+   3='Describe how a flipped classroom works'
+   4='Identify the key pages of the curriculum interface'
+   5='Explain the sequencing of work in a typical week at CYF'
++++
+
+At Code Your Future, the curriculum maps out what you will learn together over the course. It defines your weekly work, the preparation you must do before class and what you will do together on Saturdays. Use this time to go through the activities and learn how to navigate the curriculum interface.
+
+### Resources
+
+The facilitator will make a copy of this template presentation 👉
+
+<iframe title="using-the-curriculum" width="768" height="432" src="https://miro.com/app/live-embed/uXjVMh2y3Ds=/?moveToViewport=-7348,-6186,14736,7636&embedId=173973063452" frameborder="0" scrolling="no" allow="fullscreen; clipboard-read; clipboard-write" allowfullscreen></iframe>
+
+### Preparation
+
+- [ ] Facilitator: Review the [How to use the curriculum](https://miro.com/app/board/uXjVMh2y3Ds=/?share_link_id=217111259406) presentation before class.
+- [ ] Facilitator: Ensure everyone can access the Miro board presentation.
+- [ ] Facilitator: Split the class into groups of no more than 4.
+- [ ] Facilitator: Make sure every group has access to a laptop.
+- [ ] Facilitator: Make sure every group has access to a piece of paper and pen
+
+### Introduction
+
+The facilitator will use the Miro board presentation to guide trainees and volunteers through a discussion about how we use the curriculum.