teaching-plan: new page, also misc improvements from discussion

Author: rkdarst

README.md

@@ -49,6 +49,7 @@ instructor-screenshare
 instructor-audio
 instructor-stream
 team-teaching
+teaching-plan
 presenting
 presenting-inperson
 ```

lesson-review.md

@@ -52,6 +52,14 @@ Try to avoid:
 - Remember to add your own issues about how it went after you teach!
 
 
+## Your teaching plan
+
+This doesn't actually belong on your page, but somehow this
+preparation is related to making your own co-teaching plan for this
+one instance.  This is covered in {doc}`teaching-plan` (see the
+examples).
+
+
 ## Lesson guides
 
 Lessons should have some guides for instructors/maintainers.  They may
@@ -109,11 +117,28 @@ Most of your review time should be focused here.
   removed, perhaps mark it as advanced or optional.
 - Exercises vs demos
   - Things should be marked "demo" if it would be hard for a learner to
-    do it themselves.
+    do it themselves, based on what is written.
   - Things should be marked "exercise" if it should have everything
     necessary for a learner to do themselves.
   - Exercises can always be done as demo if the teacher decides
     (regardless of what the lesson says).
+- Verify for demos
+  - Clearly labeled as a demo
+  - Explains the purpose clearly (why you would do it)
+  - Explains the outcome clearly
+  - Has enough text/pictures so that a learner can see what you probably typed.
+  - Usually has the "solution" inline with the text of the demo.
+- Verify for exercises
+  - Clearly labeled as an exercise
+  - Labeled with expected duration
+  - Explains the purpose clearly (why you would do it)
+  - Explains the outcome clearly
+  - Shows every single command and thing that needs typing
+  - Common problems are anticipated and explained
+  - Where appropriate, recovery mechanisms: if someone got lost on the
+    previous exercise, what should they do?  Is there any solution?
+  - Has a detailed solution after the exercise steps (enough that it
+    can be followed as a demo if someone wants to)
 
 
 

presenting.md

@@ -11,7 +11,6 @@ This is assorted hints about actually presenting.
 - Why will this be useful?
 
 
-
 ## During the lessons
 
 - Take advantage of the mistakes/typos you make when teaching!
@@ -21,6 +20,7 @@ This is assorted hints about actually presenting.
   "how do you do Y?".  The first question implies something you are
   doing wrong, the second is open-ended.
 
+
 ## Exercise sessions
 
 - What to do during exercise sessions

teaching-plan.md

@@ -0,0 +1,34 @@
+# Teaching plan
+
+Try to make a written teaching plan that goes over what you'll cover.
+This helps to keep on topic (not going off on tangents and running
+over time) and making sure you cover everything.  The plan is very
+related to {doc}`team-teaching`, since the plan is the implementation
+of the team-teaching (saying who does what at each time and all).
+
+## Example plan
+
+https://hackmd.io/@AaltoSciComp/2025kickstart-tritondemos
+
+This plan format has worked well in the past.  It worked very well,
+because:
+
+- It has outline and timing - agreed with instrutors.
+- Has everything that need to be said and typed - no surprises,
+  nothing left out.
+- Allows us to avoid saying too much - we try very hard not say
+  anything we haven't prepared (other than audience questions of
+  course).
+  - We don't read/follow the lesson paragraph-by-paragraph.  Learners
+    can do that on their own time if they want (for example during the
+    exercise time or after the course).
+- It is very closely aligned to the lesson: ideally, each
+  heading/chunk in the plan corresponds to one section.  When we get
+  to that section, we scroll to it, and instead of reading from the
+  lesson page, we talk according to the plan.
+- It isn't *that* much work to prepare.
+- It forces us to test every command in advance.
+- We can still easily adapt the exact words we say to the need.
+- We don't read the lesson word-for-word very often.
+	
+TODO: more advice added here.

team-teaching.rst

@@ -88,6 +88,11 @@ different sections.
      "interviewer" and secondary to "expert", and the primary
      "interviews" the expert to explain what's going on.
 
+   This is implemented in the following teaching plan (see
+   :doc:`teaching-plan`).
+		
+   https://hackmd.io/@AaltoSciComp/2025kickstart-tritondemos
+
 
 
 Model 1: Guide and demo-giver (talker and typer)
@@ -105,6 +110,13 @@ Hands-on demos and exercises work especially well like this.  Here,
 the guide would follow the outline and serve as the director (see
 below).
 
+.. admonition:: Example of "guide and demo-giver"
+
+   In our HPC course, we use this for the main tutorials.  One of us
+   explains the material and says what to type, the other one types
+   the demos.  The instructors swap roles depending on interest.
+
+
 .. csv-table::
    :delim: |
    :header-rows: 1
@@ -131,6 +143,12 @@ interviewer "has the conn".
 
 Either person could type and do the demos.
 
+.. admonition:: Example of "interviewer and expert"
+
+   In our HPC course, we would use this for our intro to Slurm.  There
+   are no demos at that point, so one person prompts the other with
+   questions about Slurm.
+
 
 .. csv-table::
    :delim: |
@@ -163,6 +181,16 @@ but is much better than solo teaching.  The "Guide and demo-giver" is
 usually better when there are demos and "Interviewer and expert" when
 there aren't.  The teacher "has the conn".
 
+.. admonition:: Example of "teacher and student"
+
+   In our HPC course, this isn't used so much.  I might use it if I
+   was co-teaching something like GPUs or MPI, which I don't know that
+   well.  I'm not confident in what to type, so I really am much more
+   like a student than a demo-giver and I don't expect to contribute
+   much to the content.  Of course it's close to "guide and
+   demo-giver" anyway.
+
+
 .. csv-table::
    :delim: |
    :header-rows: 1