This site is an archive; learn more about 8 years of OpenHatch.

[OSCTC-planning] Curriculum questions

Naomi Ceder naomi.ceder at gmail.com
Tue Mar 11 22:49:01 UTC 2014 

On Tue, Mar 11, 2014 at 9:07 PM, Shauna Gordon-McKeon <shaunagm at gmail.com>wrote:

> 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?
>
> I think you're right that it's harder... and while the convenience of the
teacher shouldn't overrule the needs of the learner in an ideal world,
obviously we don't live in an ideal world. I'm not sure that I know of a
shining example in the classroom, although O'Reilly's Head First books are
consciously constructed on that model.


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

I'm not on @events at the moment, no... should I be?


>
>
>>
>> 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.
>
> No specific ideas from me, but I think being away of the issue is a huge
first step.

>
>
>>
>> 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". *
>
> My point exactly - a "good" instructor will do a lot of things
automatically that then are not explicit for less skilled instructors and
students who might be on their own. So yes, the language you use answers
the question.

>
>
>>
>>    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".
>
>
I agree with the concern - samples need to be set off in such a way that
they can be helpful, but not dominate over the rest of the material.


> 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.
>
> Sure - if you make saying something/asking something/interacting on IRC a
early part of getting set up, then the reliance on IRC is easier to take.

>
>
>>
>> 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.
>

Surveys are nice, but not all that reliable in terms of understanding
success, I think. Making it through is a useful metric, but it doesn't help
you find the rough spots and it really address mastery - some might be
making it through without really understanding everything. This is a hard
topic, so I'm not offering a criticism, more trying to articulate how hard
it is. Is there a target beyond this? If a student makes it through, what
should they expect to be able to do? And can they in general do that?

Again, just raising the questions, which I don't think get thought about
very much... how do we really know what works?


>> *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.  :)
>
> I'm glad it was of some use. I realize it was more questions than answers.
:)

Cheers,
Naomi


> ~ 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
>>
>>
>
> _______________________________________________
> OSCTC-planning mailing list
> OSCTC-planning at lists.openhatch.org
> http://lists.openhatch.org/mailman/listinfo/osctc-planning
>
>


-- 
Naomi Ceder
https://plus.google.com/u/0/111396744045017339164/about
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhatch.org/pipermail/osctc-planning/attachments/20140311/2e2d3ff7/attachment-0001.html>

More information about the OSCTC-planning mailing list