[OSCTC-planning] Curriculum questions

Tue Mar 11 21:07:44 UTC 2014

Hi Naomi,

Thanks so much for the detailed feedback, and sorry for taking so long to
reply.  I have some comments and follow up questions. Please respond at
your leisure.  If anyone else wants to chime in, they're welcome!

>
> So to reveal my biases, my main concern with curriculum and pedagogy in
> community based programs is that it seems to be to be very traditional and
> (for want of a better word) linear. In the Chicago Python workshops I
> taught at we used pretty much the Boston workshops curriculum. The pattern
> was familiar - a morning of linear lecture on the Python, followed by the
> afternoon of project work. The thing is, I always found that was not a
> great way to teach. Rather than argue this myself I'll just reference Kathy
> Sierra's great post about "Just in case" vs. "Just in time" Learning -
> http://headrush.typepad.com/creating_passionate_users/2005/03/motivated_to_le.html
>
> Following on that, I'm a fan of constructivist learning, where the learner
> does experiments and figures out how a system works - research is pretty
> clear that learning derived that way is much more effective than lecture.
>

I actually lean towards "just in time" learning myself.  "Just in case"
learning seems to be easier to build a curriculum around, though.  Usually
when I'm doing "just in time" learning it's either alone or one-on-one with
a mentor.  I do believe that it's possible to design a "just in time"
curriculum, but I'm not sure where to start - do you know of any examples
of people/groups who've done this successfully?

Actually, this is such a broad topic of conversation that it might be best
moved to the events list.  Are you on @events?

>
> The other thing I learned while working with the Head First series was to
> beware of "cliffs"... that is, where you lead the learner down a path until
> suddenly you get to a point where they have know idea what's going on...
> and feel like they're being pushed off a cliff.
>
>
We've very much experienced this cliff, going from tutorials to projects
time.  We've been working on supporting attendees more during projects
time, but maybe there are additional things we can do.

>
> Student section
>
>    1. I suppose this is covered by the instructor (although instructors
>    can be variable) but as a newcomer, I probably don't really understand why
>    git matters... even a few words on why I would want to worry about version
>    control and how it can help a distributed project would be useful, I think.
>
> One thing worth mentioning: the end of the open source tools lecture (which
can be found here <https://openhatch.org/wiki/OSCTC/Tools>) goes over what
version control is and why you'd want to use it, and explores Wikipedia as
a prominent example of version control.  So we do touch on that.

I created an activity that was slightly less of a toy project here (
https://openhatch.org/wiki/Open_Source_Comes_to_Campus/Curriculum/Directory)
but it would be wonderful if we could design an activity that's of inherent
usefulness.  I think that would also help with the "why this matters"
aspect.

>
>    1. What does "fork" mean? And why do I want to do that? Or will I have
>    already had that explained to me?
>    2. Again, what does "clone" mean/do?
>
> These are things a good instructor will explain automatically, but you're
right that they should be in the materials as well, regardless of how good
the instructor is.  Here's the language I used recently - how does it look?

*To "fork" a project means to make a copy of it. You can't edit the
original - somebody else owns it. But you can edit your "fork".*

*You have a personal copy, but it's on Github (what git calls "a remote"),
and not a local copy you can easily edit. We call the process of making a
local copy "cloning".*

>
>    1. Find a Task and Resolve a Task would be much better with example
>    screen shots... what is said is accurate, but someone is doing this for the
>    first time everyone one of those things is going to be an unknown, a center
>    of uncertainty... I'd try to make it clear what they can expect.
>
> Oh my goodness we should have so many more screenshots.  This is a flat
out lapse on our parts.  Thank you for pointing it out!

>
>    1. Same thing for commit and push... some sample out put would be very
>    good... otherwise how do I know if I've done it right? what if I enter
>    something in correctly, what do the errors look like?
>    2. Again, what is a "pull"? Why do I want to do that? What  happens
>    when it is or is not approved?
>
> Yeah, we should include information about that as well.  Thanks!

>
>    1. Setting mulitple remotes - again, some sample output to make sure
>    I'm doing it right would be helpful, but the big issue is making it clear
>    why I would want to do that, preferably with a couple of brief scenarios
>    that I could understand. My guess is that people who've never worked on a
>    project with git before are going to be fairly clueless as why they are
>    even learning this.
>
>
The main issue I have with "sample scenarios" is that I worry it might be
confusing for students to mentally juggle multiple sample scenarios with
the activity itself.  To that end, it seems ideal if we can build the need
for these tools into the activity.  For instance, at an event on Sunday
students seemed to understand the importance of multiple remotes well when
I explained them in the context of "getting the updated version of the main
repository".

> Teacher Section
>
> This is fine for someone who both is familiar with git and has teaching
> experience. However, inexperienced/unconfident teachers aren't given very
> much to go on.
>

Yeah, it needs work.  Thanks for the kick in the pants.  :)

>
> I also have a quibble with the approach. Encouraging questions through IRC
> does have the advantage that more students can see the question and the
> answer (or the instructor can pick questions to discuss orally). But it
> also adds another obstacle. If I'm struggling with the exercise and not
> familiar with IRC, I now have TWO problems to resolve before I'm going to
> get anywhere. And if IRC is the preferred way of asking questions and I
> don't feel comfortable with that, I'm going to feel extra stupid for having
> to raise my hand and ask the dumb way.
>

Maybe instead of asking questions on IRC, we can encourage people to, after
a mentor has helped them, report the answers they came up with.

I totally get what you're saying, but at the same time we want to get
people used to IRC.  Perhaps the answer is to do a better job of getting
people very comfy with it earlier in the day.

>
> For this reason I really encourage that some good instructors are
> "floaters", circulating amongst the students, checking screens for errors,
> smiling and making eye contact, even asking if there are any questions,
> rather than letting students just stew in their own juices.
>

Yes, we try to do this whenever our # of mentors allow.

>
> The final note I want to raise is evaluation. What ways do you have of
> evaluating how well the material and the teaching is working? I'm not
> suggesting a standardized test at the end, by any means, but are there any
> less formal measures recorded? Like how far each student gets? How
> successful they are? How many problems did the have and where? I used to
> make notes on my materials as I taught recording questions asked that I
> didn't expect, making notes on where most people struggled, etc. Just
> something to think about.
>

Two main ways.  We have an exit survey students fill out where they rate
the activity and also give freeform feedback.  The problem is there are
sometimes very low % of students filling out the survey.  (Although I
introduced a "why feedback is important" brief section on Sunday, and got
~65% of students to fill it out, which is promising.)  The other way we can
rate success is the number of students who make it through the activity,
because "making it through" is clearly visible by a submitted PR.  We're
aiming for 100% there.

>
> *Final notes:*
>
> Of course a skilled teacher with a small class would be fine with this as
> it is... but if you are using amateur instructors, the student/teacher
> ration is more that 6 to 1, etc. then my experience would be to look for
> trouble.
>

That's been our experience as well.

>
> Please take all of this with a large grain of salt - I only teach a few
> times a year now, and I was a bit of a quite rebel when I was teaching. I
> also know that engaged and enthusiastic teachers and students can do
> amazing things, even when not everything is perfectly aligned.
>
> And finally, since at this point in my life I don't have much time to
> contribute to actually work on these issues, I'm offering these suggestions
> very much with a sense of appreciation for the work you're doing, and a
> desire to help in the small way that I can.
>
>
Thank you for taking the time to give us feedback!  It's very much
appreciated, and quite helpful to us.  :)

~ Shauna

> Cheers,
> Naomi Ceder
>
>
> --
> Naomi Ceder
> https://plus.google.com/u/0/111396744045017339164/about
>
> _______________________________________________
> OSCTC-planning mailing list
> OSCTC-planning at lists.openhatch.org
> http://lists.openhatch.org/mailman/listinfo/osctc-planning
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhatch.org/pipermail/osctc-planning/attachments/20140311/432e10b8/attachment.html>