Sorry to be dense - still getting to grips with GitHub - how do I download a pdf copy of the student notes for the children - I'd like to print the latest version for the club on Friday and can only get the .md files. Thanks

The use of external resources (such as those in the Fireworks lesson) are a problem for schools where the physical machines are locked down. If you don't have easy access to the HDD, and can't use USB sticks, then getting the files onto the students machines is hard.

If the lessons are limited to the resources that Scratch provides (or require the students to draw their own images) then this makes the life of the volunteer much better.

Lesson 01 has been fixed, 2-9 haven't

Possibly due to codepage issues with the file/folder naming of some files git will show untracked changes for a cleanly cloned repo.

Repro steps:

1. fork scratch-curriculum
2. clone to Mac (may also cause problems on Windows, but not checked)
3. git status will now show the following...

# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   "Tu\314\210rkc\314\247e/"
#   "es-ES/Trimestre 1/01 Fe\314\201lix y Herbert/"
#   "es-ES/Trimestre 1/04 Ma\314\201quina de frutas/"
#   "es-ES/Trimestre 1/07 Que\314\201 es eso/"
#   "es-ES/recursos para voluntarios/Gui\314\201aDeInicioScratch1.3.pdf"
#   "es-ES/recursos para voluntarios/Gui\314\201aDeReferenciaScratch1.4.pdf"
#   "es-ES/recursos para voluntarios/tarjetas de Scratch/XX_crono\314\201metro.EN.pdf"

extra space in before
p.4 Things to try

Ian Mc

• the children followed the instructions OK, and enjoyed it.
• when they reached the "Make the Witch disappear" part (P5), a significant number of them found that when the game ran, the script to handle the "hide/play Fairydust" for the sprite did not seem to run. On inspection, it was as if the mouse click on the sprite (to make it disappear) was being lost. After some experimentation, I discovered that if the sprite image (witch1) was relatively large, the click detection for the sprite seemed to fail near the edges of the image. A quick work-around was to reduce the size of the sprite on the stage, so that the clickable area of the sprite seemed to match the actual sprite size. This improved the "hit" (click detection) to the point where it became reliable. I am not sure if this is a Scratch bug, or something to do with the properties of that particular sprite resource as I have not yet had a chance to investigate further. However, as a suggestion: the original sprite looks very large on the stage when it is imported, so it might be worth adding an instruction to reduce the size of the sprite in this exercise anyway.
• almost all of them carried out the instructions on P2, then proceeded with the instructions at the top of P3 (where it clearly states "add a block...") by duplicating the script. I am not sure why they (to a man/woman) all did this: it's obvious that they didn't read it properly, but seeing the script for a second time on the page inside the task made them think they had to copy it. I am not sure what to suggest here, but as a leader I had to repeat myself several times at this point before I realised what they were doing.
• when I ran the supplied (solution) scratch project on the whiteboard while they were working, I noticed that in the "appear/disappear" script (see P4) had been duplicated in all 5 sprites in the project. This meant that when I tried to demonstrate the "Whack", I was struggling as the sprites were flickering quickly on and off rather than appearing and disappearing (a race between two identical scripts in each sprite). Deleting the duplicate script for each sprite corrected the problem.
• there seems to be a default sound "pop" associated with the default stage for each scratch project in the downloaded material, which does nothing since it is not invoked.

In order to use https://github.com/CodeClub/lesson_format for automagically generating pdfs from markdown, we need to make a few changes to the markdown.

For the intro, after introduction add { .intro}
To make a green "activity step headers" { .activty} is added to the step header
for each checklist { .check}
for things to try { .try}
for challenges { .challenge}
for save { .save}
for test { .flag} (because to run you code is to click a flag in Scratch I guess)

I have updated the first 3 lessons for enGB, would appreciate help for the rest <3

In this exercise, there are two Page 9s.

P9 Step 6: instructions 1 - 5

• turn page -

P9 S6: instruction 6, TYP, SYP.

P10: Challenge 1

sv_SE should be sv-SE

gr-GR should be el-GR

I would like to know how to proceed to make minor corrections after my fork is merged,
From the contributions.md:
"We’ll also give you commit access to this and the other repos, so from this point in you’ll be able to make changes directly without needing to submit a pull request."
Is it already the case?
Thanks
Everton

I am (or rather one of my clubbers is) working on a new project for the club. I've managed to turn the markdown into a web page using the lesson_format python script. But how do I create the PDF version?

We want to turn our lessons into lovely HTML, and hopefully PDF too

Ideally, we'll convert the markdown into HTML and PDF directly, using templates, but there are some issues.

• Markdown doesn't support all the options we need: In particular, reusing glyphs, splitting up sections, inline scratch blocks for tutorials
• Scratchblocks are hard to render, except with a javascript library (no easy PDF option)
• Generating PDF involves battling XeTeX, or battling HTML's not so great print support.
• HTML print support varies in browsers. Some fail to handle SVGs. It's not pretty. wkhtml2pdf is out of date, PyQtWebkit may work well enough, but we still have issues with page numbering.

There has been some work with the lesson browser:

• There are four incomplete and different versions that use some rails-flavoured malarkey to generate HTML. It doesn't produce stand-alone html, and the CSS is entangled in preprocessors. The markdown has been edited to include ERB blocks to get special features.
• The python curriculum can survive without changes to markdown (yet), and so we're using Pandoc to convert it to HTML, and printing them manually. The CSS was very last minute, but it works and we're using it.
• Someone else has written a python script to parse the scratch files and translate them into markdown. The HTML and CSS seem to be spot on for the PDFs, but similar issues with HTML and print happen.

https://www.dropbox.com/sh/vrexgtvhg1he0hm/7hW5TRSGGC

Unfortunately, they've introduced two new markdown options, tutorial breaks (a line of ^^^'s), and a **foo**{.classname} syntax, which ties it to the html output. The latter syntax is supported by some less common markdown libraries http://johnmacfarlane.net/babelmark2/?text=**sup**%7B%3A+.quote%7D

The solutions as I see it:

Focus on HTML generation for now, and produce PDFs from it, and hopefully work on a XeTeX template that's styled and fancy in the far off future. We will have to rely on HTML->PDF until something replaces scratchblocks.

1. Make a new incompatible markdown variant, with options for image replacements, inline code highlighting, and automated collection of tears. Write our own markdown to HTML parser. Cry.

1.a Find a markdown variant that works for us and doesn't break on github.

1. Use a different markup format that supports the features we need. Use Pandoc or similar to produce HTML. We can also use Pandoc to migrate away from markdown. RestructuredText is similar, and may support everything we need.
2. Move directly to HTML fragments. Use something like XSLT, or something less clunky to translate into the HTML we have
3. Go hog wild and write our own markup format.

Go through all the projects on http://projects.codeclubworld.org/en-GB/scratch.1 and find all the red blocks (these are formatted wrong) and correct them so they get the proper colour block

Reference to Scratch Card Required - Timer

Not present via link Club Resources - Scratch Cards given on
http://projects.codeclub.org.uk/en-GB/index.html

According to linkchecker, the following scratch-related files are missing from one or both of the projects repos:

nb-NO/01_scratch/01/fane-drakter.png
nb-NO/01_scratch/01/fane-skript.png
nb-NO/01_scratch/01/kategori-data.png
nb-NO/01_scratch/01/screengrab.png
nb-NO/01_scratch/02/tre_spoekelser_screenshot.png
pl-PL/01_scratch/01/Feliks-i-Herbert.png
pl-PL/01_scratch/02/Pogromcy-duchow.png
pl-PL/01_scratch/02/scratch_1-02_Pogromcy_duchów_zasoby.zip
pl-PL/01_scratch/03/Fajerwerki.png
pl-PL/01_scratch/04/Jednoreki-bandyta.png
pl-PL/01_scratch/04/scratch_1-04_Jednoręki_bandyta_zasoby.zip
pl-PL/01_scratch/05/Glodna-ryba.png
pl-PL/01_scratch/06/06 Pustynny wyscig - Informacje.html
pl-PL/01_scratch/06/06 Pustynny wyscig.html
pl-PL/01_scratch/06/scratch_1-06_Pustynny_wyścig_zasoby.zip

After teaching code club for a few week, i've found a bunch of errors with the lesson plans:

• Forever IF
• IF instead of IF THAN

The images used that contain these are confusing the children, so i'm having to rewrite FOREVER IF for:

github recognises this filename, and does this:

Therefore, it would be better to have a more general CONTRIBUTING.md file, that either links to or includes these translation instructions, but also includes more general guidelines for contributing.

Most popular repos have really good CONTRIBUTING.md files that can be used for inspiration e.g. bootstrap.

We have custom images for paintbox, fireworks, xmas capers

The Scratch team has agreed to add these to the standard scratch library if we provide them with vector files.

This solves #36

After running through lesson four with my Code Club group, I found the following things to be causes for confusion:

Step two:
5) asks you to add in next costume, which causes the costumes to change very quickly.
6) solves this by adding the wait block
7) asks what would happen without the wait block... which we already saw at step 5!

Step three:
2) doesn't make sense at all in its current form. This currently says "Set stopped to 1 when someone clicks on the image using when sprite1clicked and set stopped to 0 making sure to change the value from 0 to 1".

The second part of this - the "set stopped to 0..." part, is actually covered in 4), so should be removed from 2)

Step four:
Should explain that duplicating a sprite also copies its scripts, costumes and sounds.

Challenge three:
The content of the image is really difficult to see in the printouts.

page 6 step 2

Given code shows a blue Sensing variable for Timer
Does not give correct behaviour (counts past 0 into negative numbers)
Should be an orange Data variable

The final section of markdown is
```blocks
when FLAG clicked
set [timer v] to (30)
set [score v] to (0)
repeat until <(timer) = [0]>
wait (1) secs
change [timer v] by (-1)

stop [all v]
```

Which renders the stop [all v] inside of the repeat loop, which causes the game to stop at the first iteration. It looks like there should be a "```" to close the loop before the "stop"

Very easy to confuse a variable called answer with the sensing block answer. In fact, these are muddled up in the image below, where answer should be orange:

It would be preferable to use a different word, e.g. solution / right answer?

Also, giving variables and events the same name (in this case, won) is potentially confusing. UPDATE: this is fine I guess.

In step 3, on page 4 of the PDF, variables for 'YES' and 'NO' are used for setting the variable 'stopped' when it should be just the text 'YES' and 'NO'.

My observations:

• this activity contains a lot of good material, but it has not been put
  together as well as the first two (Felix and Herbert, and
  Whack-a-Witch). Since I regard the Level 1 projects as pretty much
  guided activity, at this point (project 3) I am still not expecting them
  to think to much about what they are doing. Hence, continuity of
  presentation for the first three seems to me to be very important to
  maintain consistency for the children.
• there are a some incorrect instructions, omitted instructions, and
  some rather adult language that a few of the kids did not understand.
  This meant that the overall flow of the club was very broken, reducing
  the amount of time spent doing and learning.

Specifics:

• the leader's notes are OK, but I would suggest that "Coordinates" as a
  concept is added to the "Skills" list - a few could not understand x and
  y coordinates, which was scattered liberally through the scripts.
• page 2 (activity instructions) is fine, and sets the tone correctly,
  much the way this was done in proj. 1 and proj. 2.
• page 3: instruction 7 is indented from the "Test Your Project" header,
  with no visual separation from it (whitespace). In earlier projects, at
  this point a "Save Your Project" would be used. Could I suggest either a
  SYP or whitespace is used here to separate the instruction as a distinct
  follow on activity?
• page 4: TYP headers normally have tests and verification questions -
  in this case, a change has just been made to use the mouse button, but
  this is not verified here with any questions.
• page 4: in the "Things to Try" section, all the kids could do the
  speed control (they used ideas from club 2/speed control). However, the
  first challenge of the two was more difficult, and since it was
  presented first, they all tried it first and got stuck, resulting in a
  break in the flow of the class's activities as we rushed round trying to
  sort out. Could I suggest that the simpler challenge is presented first?
  Also - if a small icon to indicate "Challenge difficulty" could be
  placed next to a challenge, it would let the children make choice about
  whether they want to try it, etc. For example, a little
  skull-and-crossbones (easy challenge), two (medium difficulty) three
  (stinker!)
• page 5: there is no explanatory (bold) subheader here to introduce
  what they are going to do before presenting the instructions. As an
  adult, I read it and understood it. The children however, followed it
  without really understanding why (refer to Step 1, page 2)
• page 5: instruction 3 states "IMPORT a new sprite...". This implies
  you are importing a new costume for the exiting rocket sprite: however,
  if you turn the page, instruction 4 sets up a script for a distinct
  sprite used to explode at the end of the rocket's travel. This means
  step 3 is incorrect: it should be "CREATE new sprite from File" with the
  corresponding image of the IDE button from the sprite area.
• page 6: At the start of Step 3, the first instruction is a TYP. This
  is in the wrong place, as it should be before SYP following Step 2
  instruction 4 at the top of the page. This will also need a dotted
  yellow separator bar after the instruction.
• page 6: The word "unique" is a very adult word - could I suggest
  "different" in it's place? This also the word used in the TYP below,
  which they understand easily.
• page 7: instruction 2 asks the children to import 2 extra costumes for
  the explosion sprite. It then states "...and switch between them for
  each rocket..." There is no script graphic to accompany this, nor is
  there the usual explanation of why they are doing this. The net result
  of this was that they imported the costumes, did not carry out the
  implied programming step and continued on with the following TYP. At
  this point, sixteen little arms went up (almost in unison) to state the
  same thing - their explosions were all the same. The "next costume"
  block is clearly visible in the next graphic, but even I had missed it
  when I rehearsed beforehand. Can I suggest the addition of a script
  graphic here to explicitly insert this block, with a dotted yellow
  separator before the TYP?
• page 7: there is no visual separation of instruction 3 from the TYP,
  and no SYP after the previous script changes (costume changes).
• page 7: Step 3 instruction 3 makes a subtle algorithm change to cause
  the explosion to grow following a "bang" (to increase realism). The
  language here is again very adult: "...make the explosion grow over time
  as opposed to simply appearing." Might I suggest "Let's make the
  explosion get bigger after the rocket explodes!" This should also be a
  bold subheader for consistency.
• still with instruction 3: again, a subtle change in algorithm is
  implied rather than explicitly explained. The children (almost all
  of them), looked at the diagram, saw it was "much bigger" (I quote) and
  created a SECOND script as shown, attached to the sprite, rather than
  changing the existing script. This resulted in a delightful little
  bug (both scripts executing in a race condition), as I'm sure you can
  imagine: since all of them did the same thing, this really is a
  documentation problem. When explained, they all "got it", deleted the
  second script, and we were back on track (I confess, I am surprised that
  as an experienced adult programmer I missed this too).
• page 8: Step 4 discusses a "Bug". I know what this is, and before
  presenting I had to think about how I would explain this. In Step 2, the
  problem to be fixed is first mentioned ("...we'll fix this problem
  later on"). In Step 4, the explanation dives in at the deep end
  ("Remember earlier we had a bug?"). Can you imagine what happened?
  "What's a bug?" - valid question, but they could not relate this to the
  earlier problem due to the new word. If the text in Step 4 read:
  "Remember earlier we had a problem with....?" they can first recall
  there was a problem. We then name the beast: "This is what we call a
  'Bug' in a script - something that makes the script work incorrectly"
  followed by the explanation "This is because....". We can now start the
  activity "Let's fix the bug!" - and so forth. Note this time that there
  is an explicit instruction to "replace" an instruction: this is
  different to Step 3, instruction 3 where an implicit instruction led to
  them duplicating the entire script.
• page 8: At the end of each previous lesson, there has been an Ending
  Script: "Well done, you've finished,.... Don't forget to Share...". This
  is omitted from this lesson: I thought on first noticing this that I had
  not printed the last page of the lesson and had a minor panic -
  referring to the original PDF it was also missing. This is the only
  lesson without this (except the DIY Game at the end).

Although this issue has been referenced in Closed issue #29 , the correction made in the revised documentation has not corrected the fault.

Original:

Step 1, instruction 2: "Import the Indoors/chalkboard background."

Corrected:

Step 1, instruction 2: "Click Stage and then the Backgrounds tab. Upload the the frame.bmp background."

This implies frame.bmp is a standard Scratch background. Frame is supplied in the extra "Resources" folder for the exercise, along with green-pencil, red-pencil, etc.

Suggested:

Click Stage and then the Backgrounds tab. Import the resources/frame background.

The worksheets refer to a 'chomp' sound effect supplied in the lesson's resources. However, the downloads from Code Club nor this Github repository contain the sound.

Here's an annoying bug in IE 8 running Flash Player 11.3.300. I've not managed to reproduce it on any other browser. The line

       set [color v] effect to (pick random (1) to (200))

from Step 3, making each explosion unique, causes whole canvas to go black (or white) whenever it is in a script. Removing the line completely seems to be the only way to resolve the problem.

I'm unable to reproduce the bug in Google Chrome's Flash Player but unfortunately Westminster City Council's WinXP build won't let me use that or install Adobe Air + Scratch2Download.

for some reason figcaptions are being added

I cannot find the jingle bells MP3 file that is referenced in the Christmas Capers project. Should it be in the downloadable materials? If so, it's not there.

I have noticed that the 'touching herbert' block in both versions of the script on p4 of the Felix and Herbert worksheet (PDF from the website) have round edges rather than points. I do not entirely understand the markdown format in this repository but I think that the the '<touching [herbert v]?>' is probably correct but the screenshots in CodeClub/CodeClubUK-Projects need changing.

Regarding the production process, has anyone set up "github change detection" and automatic generation of new documents?

Volunteers have been asking if we can include a note for parents in the volunteer resources, that they can give to parents when they pick up their kids from the first code club or something.

We have some info here: https://www.codeclub.org.uk/start-a-club/parents but a note that could be printed out would be handier for less tech savvy parents (and they're probably the ones that would benefit the most from it).

I got this email from Natalie Rusk (part of the Scratch team at MIT):

"Our moderators are censoring projects that beat up Dora and other children's characters or are focused on violence towards women (in addition to general graphic violence towards anyone). I realize the humor and alliteration with the "Whack a Witch" project, but would like to suggest when publishing to consider whacking something other than a human character (a donut? a worm? Knock a noodle?). Well, something to consider."

We have also gotten complaints from Wiccans for being anti-relgion.

Should we keep the lesson as is and tell people they can change it if they don't like it, or change the wording/graphics in use to be more PC. (for instance @tef made a nice ghostbuster version with ghosts instead of flying witches).

A lot of term 2 is still pdfs, and should be converted to markdown and scratch blocks

And a related issue: a few folders of translations don’t have a manifest at all. So for instance, de-DE scratch appears to have full translations, but no manifest, so projects don’t appear on any projects pages.

• update all scratch code examples to follow blocks syntax, ala http://wiki.scratch.mit.edu/wiki/Block_Plugin/Syntax so they work with the auto-pdf tool (I have attempted this for the first 3 lessons in enGB)
• update all scratch code examples to use scratch 2.0 only (some blocks depricated, some things are easier to do in Scratch 2.0 and should be rewritten)

There's an inconsistency of image file names in the Fish Chomp lesson.

Do you want to change the filenames of the image resources (fish1-a.png) to match the names mentioned in the markdown (resources/hungry-fish) or the other way round?

Quick question: What in heck is going on in this directory https://github.com/CodeClub/scratch-curriculum/tree/master/nb-NO/Termin-1

Also, the manifest can be updated

•        "filename": "02 spokelsesjakten/spokelsesjakten.md",
  

•        "filename": "02 spokelsesjakten/spokelsejakten.md",
  

As lesson 02 has a typo in the filename.

• Every script finishes with "stop script". This seems superfluous to me. What's the reason?
• Monster-Movement.pdf:
  • the first two pictures of scripts have "change y by ..." everywhere. This should be "change x by ..."
  • middle picture of script: the "if on edge bounce" block should come after the "if", not before. With the given script, when the monster comes to the edge, the body will bounce first, then the if-condition will be fulfilled (as the body is not touching after bouncing), the broadcasts will be sent, and the body parts will continue moving into the edge.
  • last picture of script: is "when I receive 'moved right' ", should be "when I receive 'moved' "
• Monster-Tentacles.pdf:
  • It would be good to write that the children should use a suitable "hat" block.
• Monster-Legs.pdf:
  • It should be pointed out that the leg costume has to be draw "lying down", with the "foot" to the right, as otherwise the angles in the script code (180 degrees for "down" etc.) will not work.
  • In the first paragraph, it would help to avoid confusion if it were explicitly stated that this code should not go into the legs, but rather into the body or stage (i.e. something that only exists once).
  • In the second picture of a script, the effect of the two 'ifs' are identical (as both the condition as well as the 'then' and 'else' clauses are opposite). This is superfluous and confusing. (Possibly the author was confused by the "we'll reverse these states for the other leg" phrase above?)
  • Note: The code duplication in both pictures could be avoided by using "when I receive 'moved' ".
• Monster-JointedArm.pdf:
  • The script for the upper arm seems wrong. It starts with "if space key pressed", which was already used for talking, so could better use another key. More importantly, it ends with "change x by 'move speed' ", which should be triggered by "when I receive 'move right' ".
  • Note: The extra variable "left arm" could be saved by using "sin of 'direction of Sprite ...' " in the formula for the lower arm.
• PS: To ensure the body parts move along with the body, an alternative would be to use something similar to how the lower arm moves according to the upper arm (but without the trigonometry): script for body part: "when green flag clicked" "set 'xdiff' to 'x position' - 'x position of body' " and "when I receive 'moved' " "go to x: 'x position of body' + 'xdiff' y: ..." and same for y. This solution prevents the problem with "if on edge bounce" above and generalizes to movement in any direction.

The current lesson plans target Scratch 1.0. For those using Scratch 2.0 there are subtle differences and, in some cases, things that don't work.

A set of instructions (and instructor notes) are required for Scratch 2.0.

[FYI To help with this I've forked the repository and will adding Scratch 2.0 specific instructions based upon my experience. https://github.com/martinpeck/scratch-curriculum]

During a lesson, we hit a problem with the What's That worksheet. At the bottom of page 5 is a script that contains "if answer = 1" but the trouble is that answer used isn't the variable called "answer", it's the answer from user input. It appears that someone has already noticed this & fixed the MarkDown source appropriately. The md file now refers to a variable called "right answer" but the PDF still contains the old, incorrect version.

Does anyone know how to regenerate the PDF's? I tried following the language pack build instructions to see if that would do it but that failed due to unicode issues (I'm blaming Windows!). If someone can point me in the right direction, I'd gladly get a new PDF version commited to the repo & probably will add some extra information into the contributing file as well.

All lessons are missing screenshots that are in the original pdfs. There should be at least one for each lesson (right after the intro) that shows what the finished game looks like.

• term 1
• term 2

I have a suggested correction to one of the Scratch projects...

On page 8 of the Fireworks project it says:

"Remember earlier we had a bug involving holding down the mouse button?
This occurs because when the rocket broadcasts its explosion, it will immediately repeat the if loop and send out another explosion message, before the last one has finished displaying."

In fact the bug isn't caused by the sending of a second explosion message (which doesn't happen for another second, due to the 'glide' block), it's caused because the position of the rocket is immediately reset at the beginning of the 'forever if' loop, and the explosion reads that position from the rocket sprite.

My suggestion is to re-word the explanation something like this:

"Remember earlier we had a bug involving holding down the mouse button?
This occurs because when the rocket broadcasts its explosion, it will immediately repeat the if loop and move the rocket back to the bottom of the stage. This happens before the explosion has moved to the position of the rocket."

The suggested fix is still correct.

A bit of (hopefully constructive) feedback.

We have been working our way through the term 1 scratch projects and
they have all been pretty good so far. But "paint box" was a bit of a
disaster.

We couldn't get the 'pencil' to draw a line consistently. It just kept
leaving dots and then occasionally (and unpredictably) drawing a line.
Everyone experienced the same problem. The only person who got it to
work was out brightest student, who got to the very end. This had 2
professional programmers rather flumoxed and the kids got rather
demoralized. I suspect that it doesn't work properly until the complex
'if' statement is added right at the end.

I'm not sure if it was a bug in scratch, a shortcoming in the project or
a combination of the 2. But I definitely think it needs re-thinking. An
example that doesn't 'work' until you reach the end isn't great for
teaching.

We were using Scratch v1.4.

NB/ The name of the background to import is also wrong - it should be
'frame' (IIRC).

Red-selector.gif doesn't load on scratch version 2. It says format not accepted, needs to be converted into png format

We're about to launch projects.codeclubworld.org, to allow people outside of the UK to browse and download projects. We're working on launching the UK version shortly afterwards.

Before we tell everyone about it, we're going to have to update some of the projects to make things better.

Related #71, #68

Each note/lesson/markdown file needs a yaml header, correct classes, and all terms need a manifest file

https://github.com/CodeClub/lesson_format/blob/master/FORMATTING.md

Dear,

There is an Issue with point 6. in DesertRace.md

1. Now set racing to be 0 when the project is first started. Change your when flag clicked script
   from before to look like this:

Chage your ?variable? when flag clicked…

In the same file: Click sounds and then record the sound of the a parrot winning the race!

Remove the "a"

https://github.com/CodeClub/scratch-curriculum/blob/master/en-GB/Term%201/06%20Desert%20Race/DesertRace.md

Cheers from the Luxembourg translation team.

Flappy Parrot contains clone blocks that are only available in Scratch 2. A club leader note to this effect would be very useful.

The download site provides the mouse sprite in the 'resources' file as shown in the screenshot at the start of the worksheet. However, the instructions indicate that the 'animals/mouse1' sprite should be used from the library. This should be consistent and for simplicity, as it is the very first project, it would be better to use the library sprite rather than requiring one to be uploaded. The screenshot should be updated to match.