For example, we have instructors.html but no instructors.md since ee137cf (Merging from template core, 2015-01-05) pulled in 3eaab25 (Removing example files, 2014-12-11). I'd guess the problem was just that they hadn't been edited locally before the pull from core, so they were removed. Somehow this repository branched off lesson-template without picking up swcarpentry/DEPRECATED-lesson-template@e9ad988 (Merge branch 'core' into gh-pages, 2014-12-11), which landed in the gh-pages branch right after 3eaab25 landed in core and turned those removals into no-ops for the example files in the gh-pages branch. I'd suggest recovering by starting from scratch filling in the missing .md files.

Look for FIXME in the sections.

Replaces item 1 of #19.

That should either go to the contents of the actual training or in the trainer's notes. It's actually easy to get messy with "Our materials, how to contribute" and so on. Some of my suggestions (used at the Australia and NZ IT in January 2016):

1. Start off with talking about collaborative material development in more general terms (proliferation of materials, why it happens, everyone has their version of slides, improvements never contributed back, analogy with OSS).
2. Show where our materials are (using Lesson sections in DC/SWC websites). Show the website and how it connects with the source (GH).
3. Show briefly this paper.
4. Show a discussion thread on one of the PRs which contains a change in materials. This demonstrates well why GH is so useful (vs Wikipedia or comments in Google Doc etc). It also shows the openness of the community.

I always also say that we understand the problem of high-barrier entry with GH and ask if people know of any useful tools.

In SWC we present materials as I/we/you. I introduce, we do it together, you practice on your own. Add this info to the instructor notes.

Another way of talking about it is Guided Practice and Independent Practice.

1. Do the pipe-and-filter live coding demo.
2. Ask trainees to teach only the second half, i.e., only the pipes part, not the redirect part.

"The typos are the pedagogy." https://twitter.com/danabrunson/status/684764295196876800

1. Doesn't connect directly with exercises.
2. Research basis seems shaky.
3. Questionnaire isn't open access.

On today's debrief (Jan 14) we discussed helpful hints on teaching methods for new instructors.

I'm not sure where this should go, maybe in workshop.md, but we should add a note to suggest keeping the lesson "script" or instructor's notes on a separate screen, such as a tablet. This way, learners aren't distracted by seeing the instructor's notes, and the instructor doesn't have to switch between screens to see what comes next. I like to use an iPad or tablet for this purpose, and the projected screen that the learners can see only contains the live code or instructions for challenges.

Another comment was that if there is the capability for 2 projected screens, you can have one for the live code, and another that shows the example scripts (for reference) or instructions for challenges.

• https://pypi.python.org/pypi/update-copyright/ should be discussed
• The Windows installer should be discussed
• Our data sets should be discussed

Remind trainees that there's no point having an exercise that only works on Linux (or Windows, or Mac) - must run out of the box on all three.

People aren't crude oil - we should find some other metaphor for instructor progression.

Code of conduct needs to be discussed somewhere - best place?

1. Allow more time for trainers to review feedback after first exercise
2. Give more direction on what kinds of feedback to provide
3. Provide more direction on how to do the exercise (reiterate a couple of times then ask someone what they think they're supposed to do)

Exercises about bank balances or children's birthday parties aren't as appealing to our audience as ones dressed up as science.

When someone submits an exercise or other PR against a lesson at the end of training, any code they include should follow the style of the lesson they're submitting to.

Maybe this has already been discussed but collecting GH usernames from Trainees would help tracking their submissions of PRs as a part of the Checkout/finishing instructor training process. As we scale up, doing it manually is not feasible.

Discussion of accessibility in 07-motivation.md needs to be filled in.

Hard to participate in Etherpd or live coding exercises with a tablet.

notes/manchester.txt describes a recent successful workshop - fold that into a reorganization of this material (including a schedule).

http://quorumlanguage.com/evidence/Evidence.pdf

Make it clear in instructor training announcements and advertising that an addition 2-4 hours of work is required afterward to complete checkout.

In the "Things You Shouldn't Do in a Workshop" section, I think it would be good to add that instructors shouldn't tell participants to "just" do something (e.g., "just go to the command line and type..."). This was brought up in the instructor training I participated in, and I thought it was a really important point. If someone says "just do X" and you can't do it, that's pretty demoralizing.

Might not be a great example. According to my colleague, who is a professor in Speech and Hearing, and an expert on reading, there's a scientific consensus that whole-word reading was a bad idea and phonics is the way to go (references to follow...). Therefore, the sentence "Both approaches are consistent with what we know about how children learn" might not be accurate, and the inferences that follow might not hold.

The more I think about what we say and what our goals are, the more I think that situated learning describes our view of teaching much better than cognitivism. We should therefore talk in detail about communities of practice and the zone of proximal development, both with respect to learners in the classroom and with respect to trainee instructors learning better teaching methods.

Trainees should submit solutions to exercises (particularly advanced ones).

Instructor training needs to be much clearer about use of the 'instructors' mailing list, admin fees, etc.

Our policy with self-organized workshops is that you are not allowed to use central resources to find instructors unless you are paying our workshop administration fee for the workshop. If you would like to pay the workshop administration fee we will be happy to help you find instructors. This instructor matchmaking is exactly why we employ folks (at a cost to us) that develop software for workshop organizing and are able to match the most appropriate instructor to the workshop and its audience.

Discussion thread for this SoL.

Replace detailed schedule in instructors.md with a more accurate one.

I am terrible remembering them. Also probably don't read enough/the right stuff. Essentially, my training sessions are quite dry and at times probably boring.
Having seen Greg teach with all the stories he adds here and there I know that it makes a big difference. So, please share the anecdotes with killjoys like myself :-)

1. Explain why it's hard.
2. Create exercise asking learners to come up with (and then critique) approaches.

Coming up with a faded example during the session is extremely difficult for the trainee instructors. I suggest a different exercises: give them 2 examples of "broken" faded examples to fix. That is, give them 2 examples with description what problem they are teaching student to solve and ask the trainee instructors to fix/improve these examples. The examples should be "broken" in a way that the faded/taken out bits will be completely random, the teaching would not be effective. This would also allow the trainee instructors to better grasp the idea of what intrinsic, germane and extraneous load. I need some time to think about this but will try to submit something soon.

Trainees shouldn't just supply an exercise: they should explain what it's teaching.

Sarah M. writes:

I did a train the trainer session a fortnight ago, with a group of mixed experienced and inexperienced trainers and we did get them to design both a course aim and learning objectives on a topic of their choice (that was a slight mistake, next time I'd go with a set topic) we gave them about 10 minutes to come up with these in small groups, then we moved them round the groups to get another group to critique. Similar to the approach you took with the online group, worked well face to face and doesn't have to take long. Could be done either side of a coffee break even.

Get both exercise descriptions and typical student responses from Piazza and fold into material (the latter will be good examples to show learners). This replaces point 2 of #19.

1. More time for video exercises. Also provide them guidance about how much time they should spend on each feedback. So for example: each video 2 minutes and each feedback about 3 min. I think they were also running out of time because we didn't tell them how long to give feedback on one video. Giving them just the grid for feedback is not enough to structure it.
2. Theming the exercises on Day 1 (so build MCQ, concept map and then Learning Objectives) was something that people really liked.
3. More time for the video on Day 2 when they record themselves live coding. Also give them better guidance for preparations that we want them to pick something from the middle of the materials so that they actually spend most time doing live coding than introducing the topic. This should actually be really well demonstrated during the demo (i.e. how to teach stuff taken out of context and make assumptions that for example people already opened their terminals).
4. During the live coding demo, Tracy purposely made some common mistakes - this worked well when collecting feedback (we did one up one down).
5. A very high level comment: when talking about the concepts/theory the trainer needs to make very clear and probably a good few references back to how it ties in with SWC/DC. Sure, yeah, this is supposed to be generic part of the training. However, people come in for SWC/DC and they want to know "Why are you teaching us about cognitive overload? Is this used in SWC/DC". This basically boils down to the trainer being very well read in the pedagogical topics we cover and also be an experiences instructor.
6. People would like to get some kind of a list of the main concepts. Personally I (Aleksandra) think that we could have in the repo a simple print out sheet which only has a list of these key concepts ("Summative assessment. Formative assessment. Mental model. Concept map. COngnitive overload. …….) with spaces left between them and print them and hand them out. People can take notes on them. Taking notes in Etherpad is not great - it becomes messy. People are taking notes in their notepads anyway but they need a highlight/signpost - we say many words during the training but they sometimes are not sure which were the key ones.
7. The part on "Materials and how to contribute" needs better structure. Open discussion is rubbish. EIther we decide we focus on the "meta" level - talk about what we need in terms of materials, the flow in the community (maintainers, contributors, small changes vs large overhauls etc). or we discuss the mechanics (PRs). Personally I think the latter, the risk is that people in the IT who know Git well get bored. We should rather think about having a support group for people who want to learn Git too be able to do PRs to materials and then explain trainees how they can get into contributing to materials.
   I would also cover more about how friendly the community is - showing examples of good discussions under PRs (possibly controversial PRs). I also showed how the thread on Discuss list about "Leaving novices behind" turned into blog post.

What we need to emphasise and cover better in our day2 of the IT is the community of practice that we have, how good it is, what it brings, (also explain what "community of practice is"), how we facilitate it. This is our amazing asset and people coming to IT need to know this because THIS is what will pull them in.

Having learners record themselves and critique those recordings is a big part of our live workshops, but isn't described in detail in these notes.

I'd like to develop a set of three checklists for instructor trainers to go through in the lead-up to execution of and post-event.

Scheduling Event

• - Set a date
• - Decide if it will be online or in person
• - If in-person book travel
• - meet with host to talk through expectations
• - make sure host has identified attendees and delivered their names
• - send email to attendees with background reading and homework assignments

Running event

• - test video conference link

Post event

• - Email attendees about final project requirements
• - Schedule certifications (3-min lesson online)
• - Make sure AMY records are filled in
• - Badge instructors in AMY
• - Follow up with attendees not badged one month after
• - Follow up with attendees not badged two months after

I'm sure there are more things I'm forgetting, so please add them!

• create some kind of guide/format for how to do the exercises depending on whether teaching online or in person. Could be notes like "SG" (for do in small groups) or "Ind" for individual, w/ equivalents for online posting structure.
• create a dump/linked version of the assignments as posted on Piazza (including how to get people into groups, etc.)? Could be part of guide above?

belongs in 07-motivation.md