search

swcarpentry / training-course

Blog/website for the instructor training course
http://swcarpentry.github.io/training-course
Other
13 stars 81 forks source link

Pre-requisites for instructor training #445

Closed gvwilson closed 8 years ago

gvwilson commented 9 years ago

What should people be required to know before starting instructor training? How will we ensure that they know it? How will we avoid discouraging people from taking part by putting a prerequisite list in place?

wking commented 9 years ago

This spun off of a thread on mentoring@ 1. I'll link in some previous discussion to avoid rehashing it here.

On Wed, Apr 01, 2015 at 02:35:30PM -0700, Greg Wilson wrote:

What should people be required to know before starting instructor training?

Previous positions:

How will we ensure that they know it?

  • Have them attend a novice workshop 2.
  • Have them self-assess 3.
  • Have them complete a pre-workshop activity 7.

How will we avoid discouraging people from taking part by putting a prerequisite list in place?

  • Sensitive phrasing 8.
  • Double-header workshop/instructor-training sessions [9,10].
  • A help@ list that we point prospective trainees to for pre-training brush-ups and mid-training assistance [11,12,13,14].
bkatiemills commented 9 years ago

What should people be required to know before starting instructor training?

Casual familiarity (not expert knowledge) of one unit of SWC material of their choice - whichever one they think they'd most like to teach at their first workshop.

How will we ensure that they know it?

Tell them that all their exercises in Instructor Training will be based off of (loose) knowledge of the unit.

How will we avoid discouraging people from taking part by putting a prerequisite list in place?

Keep them action-based prereqs ('read a unit before the class starts') instead of knowledge-based prereqs ('master a unit before the class starts').

This seemed to work well in Melbourne for a live Instructor Training; the only other hard skills people need are some git and markdown, which we / other learners can support each other with in a live session, and a help@ list and hangout-style Q&A can resolve in online sessions.

wking commented 9 years ago

On Wed, Apr 01, 2015 at 02:58:34PM -0700, Bill Mills wrote:

… the only other hard skills people need are some git and markdown, which we / other learners can support each other with in a live session, and a help@ list and hangout-style Q&A can resolve in online sessions.

I'll elaborate on my earlier pushback 1, and say that the shell + Git is a full day of novice SWC material. I'm not sure how much brainpower folks will have left over to absorb instructor-specific content if they're trying to learn those on the side during a training session. I think Markdown is a small enough lift that we can wedge that in as an explicit topic (we don't cover it in our novice workshops anyway), but I'd encourage potential instructors to attend a novice workshop, or help@, or … to at least wrap their heads around basic Git before showing up at a training session.

bkatiemills commented 9 years ago

@wking I agree that tacking the whole git session onto instructor training is totally impossible - but it's not necessary, either. In Melbourne, the only use of git was to satisfy the 'make a contribution' req for getting an instructor badge, and many people did this via the web interface with no git and no shell. Like markdown, this is simple enough to wedge in and help people out with, either live or on the forthcoming help@.

Git is a huge hurdle for learners; setting that up as the price of admission for instructor training will hose participation. Better to use Instructor Training as the thin end of the wedge to help git newcomers get their feet wet just a bit, and learn more at their own speed.

weaverbel commented 9 years ago

What should people be required to know before starting instructor training?

I didn't really know much of anything before I started instructor training so my learning curve has been vertical! However, it did inspire me to tackle things I've been meaning to learn -- Python and the Unix shell, for example. And I think I am still very much in the beginner mindset which may help me as an instructor, as I won't make assumptions about what people might know.

However, I was really motivated to take this training on, and that has helped me keep at it.

Therefore it would probably be good if people already had some familiarity with using the command line and had experience of some kind of programming, so they don't get too discouraged.

How will we ensure that they know it?

A quiz would be my suggestion, though quizzes can be gamed.

How will we avoid discouraging people from taking part by putting a prerequisite list in place?

Make the prerequisites desirable, not mandatory. Explain that people without the knowledge will probably find it harder -- as I did -- but that the payoff is worth it.

wking commented 9 years ago

On Wed, Apr 01, 2015 at 03:15:23PM -0700, Bill Mills wrote:

@wking I agree that tacking the whole git session onto instructor training is totally impossible - but it's not necessary, either. In Melbourne, the only use of git was to satisfy the 'make a contribution' req for getting an instructor badge, and many people did this via the web interface with no git and no shell. Like markdown, this is simple enough to wedge in and help people out with, either live or on the forthcoming help@.

Hmm. If that's all you need to get through instructor training (and it looks like the web UI is also sufficient for setting up a workshop page 1), then I'm fine trying to include GitHub's web interface in instructor training (and not as a prereq). I'd teach it explicitly though, and I'd caution against having Git novices attempt a local-repository approach on their own (which was one of the issues bothering our original poster 2).

Git is a huge hurdle for learners…

Novice Git is a six-hour hurdle for everyone coming into our novice workshops.

… setting that up as the price of admission for instructor training will hose participation.

Even if we provide many avenues to satisfy the prerequisite ahead of time? If folks aren't willing to put in an extra few hours of tutored study to figure out one tool, I'm concerned about their willingness to prepare for their own teaching.

Better to use Instructor Training as the thin end of the wedge to help git newcomers get their feet wet just a bit, and learn more at their own speed.

I'm ok dropping the Git prerequisite if we have a short session on using GitHub's web interface as part of the instructor training. But if you've never seen the Git data model before, I expect a quick run through the “edit this file” button is setting folks up for trouble down the road. And if we can get useful Git skills into a quick session, why aren't we using that in our novice lessons?

wking commented 9 years ago

On Wed, Apr 01, 2015 at 03:19:52PM -0700, Belinda Weaver wrote:

Make the prerequisites desirable, not mandatory. Explain that people without the knowledge will probably find it harder -- as I did -- but that the payoff is worth it.

And I am completely on board with this.

bkatiemills commented 9 years ago

I'm ok dropping the Git prerequisite if we have a short session on using GitHub's web interface as part of the instructor training.

There is definitely room for this, let's do it.

And if we can get useful Git skills into a quick session, why aren't we using that in our novice lessons?

It's coming :) A number of us in Vancouver have been interested in doing 'fork and merge for novices', and some of the other instructors have had a lot of success there; it starts with simple in-browser contributions. PR inbound :)

Make the prerequisites desirable, not mandatory.

This still falls into the imposter phenomenon trap (Carol, my blog, para. 6.) - we must avoid creating the expectation that people should already know this stuff, especially when they really don't need to - 'nice to haves' very quickly morph into 'I'm not good enoughs' in the minds of many.

wking commented 9 years ago

On Wed, Apr 01, 2015 at 03:40:27PM -0700, Bill Mills wrote:

I'm ok dropping the Git prerequisite if we have a short session on using GitHub's web interface as part of the instructor training.

There is definitely room for this, let's do it.

Ok. So assuming our mini-consensus here flies with everyone else ;), I think the plan is:

I think that's a solid step forward.

I'm still concerned about implicit prerequisites buried in there, and would be curious to figure out what they are. Can you succeed at instructor training if you've never opened a browser before (although this is hard to imagine ;)? If you grab a non-technical, non-scientist off the street and put them into the session, will they thrive? Is the only requirement a working knowledge of English (to read the central notes)? The session's language? But we can work out those sorts of details later on.

I'm also not sure what instructors who are intimidated by our novice shell and Git lessons are hoping to teach ;). I'd expect the existing lessons would be fairly approachable by someone who was fluent in the Python or SQL lessons. But if we have the capacity, I'm fine putting folks through the “how to teach” instructor training before they master the “what to teach” novice lessons. If we start hitting instructor training bottlenecks, I think funneling folks through the novice lessons first would help folks figure out whether or not they were really interested in teaching this material before we invest instructor-training time.

bkatiemills commented 9 years ago

training-course is the blog / website for the online version, while instructor-training is the actual lessons for instructor training, and more closely reflects the live course (and I get the two confused every single time).

I'm still concerned about implicit prerequisites buried in there, and would be curious to figure out what they are.

To answer this I'd examine what distinguishes someone who would be able to pick through a SWC lesson on their own - since that's one way to get ready to teach a new unit. Some sort of maddeningly vague technical affinity? I think a FORTRAN wizard would probably be able to pick up SWC to a teachable level really quick - but again, if you start saying things like 'must have some experience coding in any capacity', some people will assume the one hour webinar they watched makes them a master, while others figure they only got a masters in computational physics - and the gender split on who makes which of those decisions is not good.

I'm also not sure what instructors who are intimidated by our novice shell and Git lessons are hoping to teach ;).

R or Python. Or, more generally, it's really Git that a lot of people bounce off of; plenty of new instructors would hit the shell out of the park, but have never used Git before. Ultimately, I'm happy if a new instructor is prepared to teach one and only one unit at their first workshop (that was how it was for me, though my one unit was, perversely, Git :)

Anyway - cool, what @wking synthesized in those three bullets looks really good to me, enthusiastic +1 here. But also, @weaverbel hit on something important, and that was the impact of motivation on instructor trainees. We preach it super hard WRT to SWC students, but it matters just as much for our instructors. Making sure we protect and encourage that motivation is definitely something to keep in mind, and all this talk about prereqs folds into that.

wking commented 9 years ago

On Wed, Apr 01, 2015 at 05:13:32PM -0700, Bill Mills wrote:

training-course is the blog / website for the online version, while instructor-training is the actual lessons for instructor training, and more closely reflects the live course (and I get the two confused every single time).

Thanks for clearing me up. I've updated the repository descriptions in GitHub to match this (“Blog/website for the instructor training course” and “Software Carpentry instructor training course material”), which will hopefully decrease confusion going forward.

… what @wking synthesized in those three bullets looks really good to me, enthusiastic +1 here.

I've posted back to the original thread asking for folks to confirm/amend the proposal before we move forward to implementing it 1.

But also, @weaverbel hit on something important, and that was the impact of motivation on instructor trainees. We preach it super hard WRT to SWC students, but it matters just as much for our instructors. Making sure we protect and encourage that motivation is definitely something to keep in mind, and all this talk about prereqs folds into that.

Makes sense to me. I'd expect this should be a note in instructors.md, but it looks like we've lost that locally (swcarpentry/instructor-training#9). Once we resolve that issue, we can add a note to this effect there.

vsudilov commented 9 years ago

This is a question I've been struggling with since joining the teaching12 training course. I expected a much higher level of prior knowledge, and that expectation has been the cause of some frustration for me. FWIW, my frustration was echoed by another professional software developer independently of my experience. In principle, I think @wking expressed my thoughts well with:

I'm also not sure what instructors who are intimidated by our novice shell and Git lessons are hoping to teach

I took a minute to review the mission statement at http://software-carpentry.org/scf/index.html. I took away two key goals from that document:

If I keep those goals -- with which I agree -- in mind, then I can see how that attitude isn't necessary. Nevertheless, I think making the prerequisites for instructors concrete -- even if they are much lower than I what my initial assessment was -- would help to prevent that attitude from cropping up in the first place. My idea of concrete pre-reqs would be something like:

tl;dr: +1 for "concrete" instead of "desirable" prerequisites.

wking commented 9 years ago

On Thu, Apr 02, 2015 at 07:41:55AM -0700, Vladimir Sudilovsky wrote:

This is a question I've been struggling with since joining the teaching12 training course. I expected a much higher level of prior knowledge, and that expectation has been the cause of some frustration for me…

Thanks for sharing this :). Can you give more specifics on what you found frustrating? Did you feel underprepared? Overprepared? With which skills? If you felt overprepared, why was that frustrating?

My idea of concrete pre-reqs would be something like:

  • can write a hello world program in python, R, or bash.
  • can clone a self-owned git repo from github, add a new file, commit, and push
  • can make the following directory structure using the console: ~/foo/bar/baz

According to @BillMills, you don't need to use the shell or command-line Git to get through the instructor training 1. Does that match your experience? If so, why suggest these prerequisites? If not, where were those skills needed (so Bill has something concrete to push back on)?

vsudilov commented 9 years ago

Apologies for being unclear. I do software development for a living, and I didn't expect other instructors to have little to no experience on some topics. Having a concrete list of prerequisites would have helped me better estimate the technical skill level of instructors and gauge my expectations accordingly.

If I came in seeing "be able to write hello world", I would have had much different expectation than "be able to write and test a module that reads, analyses, and plots data from a file on disk". I came in with the latter expectation.

FWIW, I agree with you that relying only on the github gui to do git is a setup for failure.

bkatiemills commented 9 years ago

@vsudilov thanks for your comments! Thing is, there are heaps of people who would do an amazing job of teaching R, Python, or shell, who don't use git. We don't require our instructors to be able to teach the whole workshop solo.

Also, we commonly run into people who would be an amazing instructor and know more than enough about several of the topics, but grossly underestimate themselves; if we start setting technical prereqs, they will opt out not for lack of skill, but lack of confidence - and that would have cost us some of our best instructors.

wking commented 9 years ago

On Thu, Apr 02, 2015 at 09:34:41AM -0700, Vladimir Sudilovsky wrote:

I do software development for a living, and I didn't expect other instructors to have little to no experience on some topics.

I'm still having trouble figuring out why a fellow trainee's relative inexperience in a particular lesson topic would make instructor training frustrating. It seems fairly orthogonal. The material covered in instructor training seems like it's mostly about the act of teaching, and less about the material that will be taught.

FWIW, I agree with you that relying only on the github gui to do git is a setup for failure.

This is maybe too strong ;). My current opinion here is that it's ok to use the GitHub web interface if it's a lot easier to teach and is sufficiently powerful to accomplish the task at hand (and it sounds like it is 1). There's just not as much room for growth down that path. I'd strongly recommend folks use command-line Git for version control, since that avoids getting stuck when you need something that's only exposed via the command-line UI. I see a fair number of Git goofs that I think could have been avoided if folks had a better grasp of Git's data model, so I think folks who actually use Git would be well served by putting in a few hours to understand its data model. But if you're only using Git to create new workshop repositories, you can just follow the directions 2 and you'll be fine. And if folks feel more comfortable learning that after the instructor training class, that's ok with me 3. And if they decide that they'll put off learning command-line Git until they get stuck with something GitHub's web UI can't handle (which may be never), that's fine with me too. That doesn't mean I'd hire someone that couldn't use Git from the command line, but I'd certainly be happy to have them come teach R at a workshop I was leading (where I'd put in a few good words for command-line Git and offer to help get them started in that direction ;).

hgibling commented 9 years ago

You don’t need to be an expert programmer to take part: in fact, we prefer instructors who are only two steps ahead of their learners and can still remember what it’s like to find programming difficult and confusing.

This quote from the training-course blog is what pushed me to sign up for training, as it explained why my only 1.5 years of using R might actually be beneficial. I assumed it to mean that as long as you have a SWC workshop-level (or higher) understanding of at least one of the topics taught (be it git, shell, python, R, mercurial, MATLAB, or SQL), you're a good candidate for becoming an instructor. The workshop I attended had three instructors, each teaching one topic (and one teaching two), so I don't see a problem when someone isn't as strong with all topics, as long as they are willing to learn those other topics to take notes/help students with red stickies up. If someone isn't familiar with any of these topics, I think it might be wise to suggest they attend a SWC workshop first (though this may be difficult depending on where they are located, and could hinder expanding SWC to regions where there are currently no instructors).

I think being a SWC workshop alumnus is one kind of prerequisite that could be used (but obviously not the only one that should be used). Out of curiosity, have the numbers been crunched to determine what percentage of current instructors are workshop alumni?

weaverbel commented 9 years ago

I am with Heather on this - having attended a workshop as a participant would be a good prerequisite, even if you couldn't make it a mandatory one. I am going to attend our bootcamp in Brisbane in July as a participant as I hope to learn by observation what works and what doesn't - and hopefully that will make me a better instructor. I might even teach a bit of it too to put my instructor training into practice before jumping in and teaching a lot more at a later bootcamp.

I honestly think the most important attributes for Software Carpentry instructors are

(a) a strong desire/motivation to help researchers pick up important skills (b) the ability to see the problems learners have from the learners' own perspectives.

Having technical skills and knowledge is obviously important -- or the material could not be taught -- but loads of the demotivation stories people have posted show that teachers with technical knowledge alone (and not the two attributes above) performed really poorly as teachers -- they lacked empathy, and they had little enthusiasm for the actual job of teaching. The result is they drove people away, destroyed confidence, and so on.

So maybe a prerequisite would be that people answer honestly why they want to do instructor training. If the answer shows it's mostly about the benefit to them, and not to others, then maybe they would not make the best instructor material?

mtb-za commented 9 years ago

My take on this, having read most of the above quickly and not having followed any of the links. I am also looking more at the git/github issues than things in general, but am still thinking about those.

The confusion around git/github seems to be linked into the fact that at least some familiarity is required to complete the tasks we have. When Greg asks us "write a blog post about x", that requires a certain level of ability using the tools that the blog uses. Since the blog uses jekyll, and is hosted on github, (some) skill with git has become a hard pre-requisite.

The remaining skills are based on things that are not being directly tested in the instructor course. No one is checking if I can write any python/R/MATLAB or whatever else gets added. I could be doing this course only vaguely knowing what a loop is.

What I would suggest is that (some of) the outgoing class do a couple of sessions about the basic workflow required for actually posting to the blog with the new intake.

What needs to happen to post to the blog.

I am going to be fairly detailed about this, just to check if I am missing anything as well.

First-time setup:

  1. Fork the main repo
  2. Clone to a local machine
  3. Write a post (with an explanation of the YAML frontmatter)
  4. Add the file
    • to a new branch?
  5. Commit the file (with a reasonable commit message would be nice)
  6. Push to the forked version
  7. Create a pull request

We need to get the upstream changes

This means we need at least one remote, so:

  1. Set up an upstream repo (the original)
  2. Pull from that to update the local version.

When writing a new post after that:

  1. Pull from upstream
  2. Create new post
    • Including YAML frontmatter
  3. Add post file
    • To new branch
  4. Commit file
  5. Push to forked version
  6. Create pull request

This is not a huge amount of work, once you are comfortable with git. But if any of those steps is missing/done wrong, then things will not work, leading to confusion and frustration.

I feel that making a guide for novice users covering the above steps in fair detail, specifically for the instructors' course (not just a generic guide to git/github) would go a long way. If people are still unclear or want more help, it will obviously be available in some form, at least if Round 12 is a fair representation of the people who sign up for this in terms of helpfulness.

weaverbel commented 9 years ago

Hi Martin I agree this would be good. When I started, I was using Windows and the online (Web) interface to Git and Greg's instructions _Create a file titled "submissions ...." didn't make sense to me in that setting. And the header also tripped me up. So maybe some instructions that at least mention how things look and work in the Web interface would be good. I am now doing Git on the command line but I really had tears of frustration about how dumb I felt at not being able to follow things at the start. Belinda

wking commented 9 years ago

On Thu, Apr 02, 2015 at 05:26:28PM -0700, Martin Bentley wrote:

The confusion around git/github seems to be linked into the fact that at least some familiarity is required to complete the tasks we have. When Greg asks us "write a blog post about x", that requires a certain level of ability using the tools that the blog uses. Since the blog uses jekyll, and is hosted on github, (some) skill with git has become a hard pre-requisite.

But it wouldn't be a prerequisite if there was a section of the training course that explicitly taught the GitHub web interface from scratch, which is one of the proposed changes. In that case, “post to the blog” is:

  1. Log in to GitHub and navigate to the directory where the posts live.

  2. Click on the Create a new file here button:

    fork-and-create

    If you don't already have a fork, that will be a “Fork this project and create a new file” button.

  3. Follow the rest of the steps to create the commit and pull-request for that new file.

You can do the whole GitHub flow in a browser, so you don't need command-line Git for the training course. As I've said before, I'd recommend folks learn command-line Git, but I don't think it needs to be an instructor-training prerequisite. I agree with Belinda that phrasing assignments in a way that's clear to both command-line Git and GitHub web interface users would be good, but once we're explicitly teaching the GitHub web interface, I don't see a need for a Git prerequisite at all.

mtb-za commented 9 years ago

@wking That is a good point. I think that if using the web-interface becomes the default, rather than assuming command line, but with command line instructions in parallel, it would go a long way to addressing things on that front.

In terms of other requirements, it depends on what people are interested in or have background in. It also depends on how they will be doing the workshops. In my own situation, I will probably need to run the entire workshop, given that I will be the only instructor in quite a wide radius, so I will need to be reasonably comfortable teaching the lot. For someone who has other instructors nearby, they may only need to know the absolute basics of a given topic, plus knowledge of one in a bit more depth that they would teach.

So someone may be quite happy to teach R, but not be familiar with the shell or git, but know enough to help other people if someone else is teaching. I think that technical requirements would vary a little.

I second the comments above that a desire to teach other people these sorts of skills would seem to definitely be required, which is likely to be a case of self-selection in any case: the type of people who sign up are likely to be exactly these.

As an aside, it looks like we are largely agreeing on things here?

gvwilson commented 9 years ago

On 2015-04-02 11:12 PM, W. Trevor King wrote:

But it wouldn't be a prerequisite if there was a section of the

training course that explicitly taught the GitHub web interface from scratch, which is one of the proposed changes https://github.com/swcarpentry/training-course/issues/445#issuecomment-88658069. In that case, “post to the blog” is:

  1. Log in to GitHub and navigate to the directory where the posts live. 2.

    Click on the Create a new file here https://help.github.com/articles/creating-new-files/ button:

    If you don't already have a fork, that will be a “Fork this project and create a new file” button.

Follow the rest of the steps
<https://help.github.com/articles/creating-new-files/> to create
the commit and pull-request for that new file.

You can do the whole GitHub flow in a browser https://help.github.com/articles/github-flow-in-the-browser/,

Nope: you can do the whole GitHub flow in a browser, because you understand how it all works under the hood. If you look at blog posts in the current round of instructor training, you'll see that many of our trainees struggled to do this because they don't. Even people at GitHub admit (off the record) that their web interface isn't really usable by people who don't already know the plumbing.

snim2 commented 9 years ago

My 2p (sorry for the length):

What should people be required to know before starting instructor training?

Nothing; anything you add here will be a) difficult to test for, b) may put motivated instructors off and c) will add a complicated extra stage to signing up for Instructor Training which may be a time waster for all involved.

How will we ensure that they know it? How will we avoid discouraging people from taking part by putting a prerequisite list in place?

Exactly. So, why not avoid the problem altogether? There are several sorts of people who will sign-up for Instructor Training. Some will have a lot of teaching experience, some will have almost none. Some will have a lot of technical experience, some will have almost none. Interesting that those of us with teaching qualifications are not exempt from training, so I would say that if the purpose of the training is to ensure that everyone knows about the "SW Carpentry way of doing things" then the training should continue to be compulsory and open to all and there should be no exam at the start. Otherwise why not exempt people who already know the technical stuff and already have a teaching qualification?

A proposal for a solution

To fix the "what to do about people who don't already know about Markdown / GitHub, etc." I would take a different strategy.

Step 1: I would ask people coming onto Instructor Training to either post a link to a URL of a GitHub repository that contains a Jekyll blog that they have contributed to, or state that they do not have such a link. People who already have the necessary technical skills will either have a Jekyll repository or they will be able to put one together pretty quickly. People who don't think they can do this quickly will need help getting up to speed with Jekyll / Git / Markdown.

Step 2: I would make sure that each round of Instructor Training has a roughly equal balance of people who have a Jekyll repository and people who do not. In a pre-training phase I would pair these people up and get the people with Jekyll blogs to teach the people without blogs how to set one up, over Hangout or Skype. If there is already a long waiting list for Instructor Training then there should be plenty of time for the pre-training phase to happen.

This way you solve the initial problem and get an added bonus - people will come onto Instructor Training already knowing a couple of people and with a little bit of experience in online teaching and learning which they can reflect on. In my view this would help to speed up the pace of the training when it does start.

wking commented 9 years ago

On Fri, Apr 03, 2015 at 01:34:42AM -0700, Martin Bentley wrote:

As an aside, it looks like we are largely agreeing on things here?

That's the goal ;). If we can come up with a path forward that sounds good to everyone, it's probably a good bet. If we can't quite come to a consensus, the project maintainer has to weigh the arguments and make an executive decision. In either case, the more distinct perspectives and arguments we here, the better-informed our eventual decision will be.

wking commented 9 years ago

On Fri, Apr 03, 2015 at 03:24:54AM -0700, Greg Wilson wrote:

2015-04-02 11:12 PM, W. Trevor King:

You can do the whole GitHub flow in a browser…

Nope: you can do the whole GitHub flow in a browser, because you understand how it all works under the hood. If you look at blog posts in the current round of instructor training, you'll see that many of our trainees struggled to do this because they don't. Even people at GitHub admit (off the record) that their web interface isn't really usable by people who don't already know the plumbing.

I'll look over the blog posts (I haven't yet), but my understanding was that the GitHub web interface is currently being taught implicitly or in after-we're-lost tutoring sessions. The proposed plan 1 addresses that by adding explicit training in using GitHub's web interface. Building a mental model of the workflow will take time, but Bill thinks [2](and I agree) that you can probably teach enough familiarity to create blog posts more quickle using GitHub's web interface than if you went the command-line Git route. Do you disagree with the estimated teaching time for this route? I haven't seen a live GitHub-web-interface training session, but I imagine it's worst-case a half day, since that's what our command-line Git lesson takes. And the worst-case time savings would come from not needing the half-day novice shell lesson before wading into Git.

wking commented 9 years ago

On Fri, Apr 03, 2015 at 04:55:29AM -0700, Sarah Mount wrote:

Step 2: I would make sure that each round of Instructor Training has a roughly equal balance of people who have a Jekyll repository and people who do not. In a pre-training phase I would pair these people up and get the people with Jekyll blogs to teach the people without blogs how to set one up, over Hangout or Skype. If there is already a long waiting list for Instructor Training then there should be plenty of time for the pre-training phase to happen.

This way you solve the initial problem and get an added bonus - people will come onto Instructor Training already knowing a couple of people and with a little bit of experience in online teaching and learning which they can reflect on. In my view this would help to speed up the pace of the training when it does start.

This pre-training study phase is closer to some of the earlier proposals for this issue (the novice-workshop/instructor-training double headers [1,2] or a more gradual tutoring with connections formed on help@ starting a month before the instructor-training course 7). You're tweaking the latter by substituting existing-instructor/trainee pairings with Git-savvy-trainee/non-Git-trainee pairings. Greg took a less formal pass at that approach this time 8, so I'd recommend we try the broader-pool help@ approach next time around. Git-savvy trainees can always join the help@ pool if they want to lend a hand with back-channel help.

wking commented 9 years ago

On Wed, Apr 01, 2015 at 03:40:27PM -0700, Bill Mills wrote:

And if we can get useful Git skills into a quick session, why aren't we using that in our novice lessons?

It's coming :) A number of us in Vancouver have been interested in doing 'fork and merge for novices', and some of the other instructors have had a lot of success there; it starts with simple in-browser contributions. PR inbound :)

Greg's pointed out the current round of trainee submissions as a good source of GitHub web interface usability issues 1. That's probably good fodder for planning your GitHub web interface lesson. It's also mostly independent of this issue (since the proposed changes 2 just assume that you can teach this stuff in a reasonable time period, and don't really care about how you teach it). @BillMills, if I start reading through the submissions to collect GitHub web interface pitfalls, where should I post the results so you can address them in your coming lesson? Is there already a GitHub repository with the lesson? Otherwise, can you setup that repository? It doesn't need content yet, just an issue tracker to collect the pitfalls.

wd15 commented 9 years ago

I am not sure if I missed this above, but maybe simply limiting the size of the group. That way Greg can give more one to one feedback to each trainee instructor about any aspect of the material that is proving difficult, not only the Git/GitHub/blog related issues.

I don't think it's so bad to limit numbers as long as it is based on a queuing system and not on a merit based system. Maybe also weighting candidates not based on a merit system would be acceptable as well. Instructors from countries that don't already have instructors could go to the head of the queue for example.

Maybe Greg could limit numbers in the short term and then train some alternative instructors to run the SWC instructor training in the long term and expand SWC in that way (clone some Gregs).

wking commented 9 years ago

On Sat, Apr 04, 2015 at 03:01:09PM -0700, Daniel Wheeler wrote:

I am not sure if I missed this above, but maybe simply limiting the size of the group. That way Greg can give more one to one feedback to each trainee instructor about any aspect of the material that is proving difficult, not only the Git/GitHub/blog related issues.

Greg's a busy guy ;). I think the proposed help@ list 1 will make it easier for trainees to find support without bottlenecking on Greg.

HKYang commented 9 years ago

I am surprised many discussions were surrounding on git issues. In my humble opinion, git does need to improve its usability. My experiences with four commercial version control tools were pretty pleasant. However, I encountered more hassles than expected in using git for this instructor training. So if we put git as a prerequisite then many motivated potential instructors would be killed. Git is just a man-made tool and has nothing to do with "assessment for teaching potential."

wking commented 9 years ago

On Sun, Apr 05, 2015 at 09:20:29AM -0700, HKYang wrote:

So if we put git as a prerequisite then many motivated potential instructors would be killed…

That's one of the reasons the current proposal doesn't list any prerequisites 1.

JohnRMoreau commented 9 years ago

Confíteor fratres, Mea non culpa

tl;dr - Feisty trainee is feisty, still doesn't get Git.

I will say that I personally have been one of the most vocal trainees struggling with Git, Github, and Markdown. If anyone would like to know how bad it has been this round, please read my demotivation blog post.

I'd like to add a huge +1 to @BillMills comment re:instructor motivation. Waiting until someone reaches the point of needing to ask for help or partcipate in an 'after-we're-lost tutoring session' ignores basic principles about teaching adult learners. Please note that I am not saying teaching college students, I'm talking about graduate students, junior professors, postdoc researchers, and industry professionals. One critical component of adult pedagogy is that the adult learner has far more on the line in terms of the self-confidence. Yes, it is ego at stake and it matters. Someone can say that people 'should' ask for help or 'should' accept their limitations. Nothing about those statements make them true. Someone can things 'should' be a certain way as much as they want; they might as well yell at the wind. If an adult learner faces a situation that could undermine their self-worth, they will avoid the situation.

...not sure what instructors who are intimidated by our novice shell and Git lessons are hoping to teach ;).

The statement reads as somewhat elitist. I will assume positive intent on behalf of the writer. Unfortunately, the context does not make the statement less inflammatory. When someone dismisses a person's worth as an instructor because of a program they don't use, that behavior has the effect of discouraging diversity within Software Carpentry.

First, it will deepen existing fault-lines around race, gender, class, and imposter syndrome. Many trainees in this round do not feel intimidated, they feel confused. For someone in a privileged position to come in assuming that the trainees need to be rescued will cause a great deal of resentment. When an expert assumes that they knows how a novice feels and they know what's best for the novice, that behavior strips the learner of their agency, of their right to self-determination.

Second, making Git and the Unix Shell into any sort of pre-req for instructor training will narrow the scope of academic diversity in Software Carpentry. In particular, the Social Sciences do not have the same issues of the Physical and Natural Sciences. For most social science researchers, there's not a sensor array spitting out data every hour or every day. With out that frequent data feed, command line scripting does not appear to have the same relevance. Journal papers in social sciences do not have quite as many co-authors and contributors. Papers with three or more authors are less common in fields like Economics compared to Genetics. With fewer people, it's easier to make do without version control (ie Git). That does not mean Git would not be a great benefit to economists, it means that you have far fewer potential instructors in fields like Economics that have a high skill level with Git.

What I hope to teach

Let me see if I would qualify under the requirement that instructor trainees must know a program that they do not intend to teach, according to a standard set by experts with decades of experience.

Based on those weaknesses, it sounds like I wouldn't make a very good instructor. Before anyone dismisses me entirely, please consider a few other points:

Please, someone tell me how my struggles with Git outweigh all of those points. Tell me that because I can't match an expert level of git, I have no place teaching the software I use to make a living. And if you do tell me that, you might as well tell learners struggling on day 1 of a workshop not to come back on the second day of a workshop.

PS: If I sound upset, that's because I will always fight for my students. Even before they are my students. I do not mean to attack any one person or belabor the point. After I calm down a bit, I'll come back with some constructive suggestions. Also, please feel free to offer your own suggestions on git, github, and markdown to our round 12 discussion page on Git, Github, and Markdown.

wking commented 9 years ago

On Sun, Apr 05, 2015 at 10:15:54AM -0700, JohnRMoreau wrote:

...not sure what instructors who are intimidated by our novice shell and Git lessons are hoping to teach ;).

The statement reads as somewhat elitist. I will assume positive intent on behalf of the writer.

I certainly should have phrased that more sensitively, thanks for calling me out on it. I had intended the following:

I'd expect the existing lessons would be fairly approachable by someone who was fluent in the Python or SQL lessons.

sentence to clarify my position as “If you are already comfortable with Python or SQL, working through the shell and Git lessons shouldn't be that bad” and then the following:

But if we have the capacity, I'm fine putting folks through the “how to teach” instructor training before they master the “what to teach” novice lessons.

to clarify my position as “If you aren't comfortable with any of our lessons, that's ok too, so long as we have enough instructor-training bandwidth to spare”.

However, none of that excuses my original wording.

When someone dismisses a person's worth as an instructor because of a program they don't use, that behavior has the effect of discouraging diversity within Software Carpentry.

The goal was to express my confidence that instructors are likely at least as capable of consuming our novice shell and Git material as the usual learners who successfully navigate this material in our novice workshops. But again, I could have worded that more clearly.

Many trainees in this round do not feel intimidated, they feel confused. For someone in a privileged position to come in assuming that the trainees need to be rescued will cause a great deal of resentment. When an expert assumes that they knows how a novice feels and they know what's best for the novice, that behavior strips the learner of their agency, of their right to self-determination.

Sure. And having a help@ channel will let trainees reach out for assistance whenever they feel motivated to do so.

Second, making Git and the Unix Shell into any sort of pre-req for instructor training will narrow the scope of academic diversity in Software Carpentry.

Which is why the current proposal does not do this 1.

What I hope to teach

Let me see if I would qualify under the requirement that instructor trainees must know a program that they do not intend to teach, …

The idea was “I expect you are capable of learning …” not “you must already know …”. The current proposal does not call for any pre-requisites at all 1.

Please, someone tell me how my struggles with Git outweigh all of those points.

It certainly does not. But I think your struggles with Git do highlight a shortcoming in our current training course, which explicitly teaches neither Git nor Markdown. That's what we're trying to address with the proposed changes 1. This stuff is not trivial, and we take a full day to cover it with novice students. @BillMills feels like there's room to cover the GitHub web interface in less time, and skip the shell entirely 2. I'm not sure how long that would take, but I'm guessing something around half a day of in-person training for your average class 3. And regardless of how well you plan for the “average learner”, actual students will always take a range of time before the ideas gel in their minds. That's fine too.

I hear that you're frustrated, but I think the plan (the three bullets in 1) gives us a good chance of helping the next round of trainees avoid the sink-or-swim situation that caused so much trouble this round. It's always good to get more perspectives on a plan though. Is there anything else you'd change in addition to the three bullets? Anything in those bullets that you wouldn't do?

wking commented 9 years ago

On Sun, Apr 05, 2015 at 10:15:54AM -0700, JohnRMoreau wrote:

  • I struggle with git and github …
  • Every piece of markdown in this post has been hard won through hours of struggle.

And if any of these continue to bother you, I'm happy to discuss any problems you're having. Until we get a help@ list, you can either email me directly (wking@tremily.us) or message me on IRC (I'm ‘wking’ on both chat.freenode.net and irc.mozilla.org). If you want to take the IRC route but don't have a favorite IRC client, this web-client should work 1. This offer for help is open to everyone else too. I love talking about these tools because I get a lot of mileage out of them now, but struggled to figure them out on my own when I started my Ph.D. I'm happy to help others avoid the same difficulties I had.

bkatiemills commented 9 years ago

@weaverbel:

(a) a strong desire/motivation to help researchers pick up important skills (b) the ability to see the problems learners have from the learners' own perspectives.

I love it, this is exactly correct - any ideas on how to measure this well? That's a tough but very valuable problem.

@gvwilson:

you can do the whole GitHub flow in a browser, because you understand how it all works under the hood.

True for people trying to do it without guidance; but I'm sure the git help sessions can walk people through it at the procedural level - happy to be the one to actually do that.

@wking:

@BillMills, if I start reading through the submissions to collect GitHub web interface pitfalls, where should I post the results so you can address them in your coming lesson?

Thanks, that would be a huge help! Let's do that here (and happy to kick this repo over to SWC if/when people want me to).

@JohnRMoreau: I'm beginning to think that git proficiency is overemphasized in Instructor Training. It's there because we want you to be comfortable contributing your ideas to the lessons after the fact, because that's how our lessons get better - but it really has nothing to do with getting up in front of a class and teaching. It might make sense to take git usage out of Instructor Training entirely, and offer training seminars to those people who would like them, if and when they'd like to contribute back to the lessons - but that is a foundational change that will spawn its whole own massive thread :)

mjcollin commented 9 years ago

If git proficiency isn't expected in instructor training, at what point do we expect instructors to become comfortable with it? As members of Software Carpentry are we not ambassadors for using the tools and work flows we say we train people in? I think the fact that git is so painful during instructor training indicates that we (SwC) also need help developing those skills among ourselves and what better time than when we have the attention of dozens of talented people. The help@ list is a great idea.

I feel that instructors should be able to at least assist during all our core lessons and that means dedicating the time to become familiar with each lesson's skills. I completely agree with BillMills that existing expertise should not be a pre-requisite for instructor training; the order that people learn their skills is less important than their inclination to learn them.

Jekyll isn't on our core lesson list so maybe having a work-around for having to figure out the Ubuntu dependencies for Jekyll would be good >:)

wking commented 9 years ago

On Mon, Apr 06, 2015 at 10:53:56AM -0700, Bill Mills wrote:

I'm beginning to think that git proficiency is overemphasized in Instructor Training. … It might make sense to take git usage out of Instructor Training entirely, and offer training seminars to those people who would like them, if and when they'd like to contribute back to the lessons…

Spun off into #453. Until that lands, I think all three proposed changes still make sense 1. If it does land, we could obviously drop the explicit GitHub web interface training (and maybe Markdown, or maybe we'd keep that), but I think the other two changes (adding a help@ list and asking the trainees to read over at least one novice lesson) would still make sense.

wking commented 9 years ago

On Mon, Apr 06, 2015 at 11:45:15AM -0700, Matthew J Collins wrote:

Jekyll isn't on our core lesson list so maybe having a work-around for having to figure out the Ubuntu dependencies for Jekyll would be good >:)

I think the easiest workaround there is “push your proposed changes to the gh-pages branch of your personal public fork and let the GitHub folks render it for you” ;).

morgantaschuk commented 9 years ago

I actively despise everything about Vim. - JohnRMoreau

You're not the only one! My favorite vi joke:

vi has two modes: one where it beeps whenever you hit a key, and one where it deletes all the work you've done.

On the more serious note, I agree that git, Markdown and Jekyll are real barriers to entry. Besides the learning curve, I don't believe that people fighting with git and the YAML header teaches us how to be better instructors. It's difficult to check what your post is going to look like before it hits the github pages, even for people with experience with all three technologies, since Github has its own special flavour of Markdown. It took me several tries before I could get an image to render on one of my first blog posts, even though I've worked with all three before. Let alone the amount of work for Greg with all the pull requests. I can't count how many times he went back and forth with someone to help them format their header properly.

Why we can't do all the assignments as comments on an issue like this, or in Disqus on the training site? Everyone could leave comments on the meeting notes. The current method of writing a blog post per assignment results in a page that is ridiculously long, making it hard to find anything you're looking for, like the meeting notes for example.

One suggestion I had as a prerequisite, or maybe a first assignment for the course would be to have someone record a five minute lesson on one of the SWC topics. After all, you have to know something reasonably well in order to teach it. Then they would also have the benefit of a "before and after" snapshot of their teaching abilities. It's not really a 'technical' requirement since it doesn't matter what you teach, and I think everyone teaching should be familiar enough with one of the SWC topics to teach at least the beginning of the lesson.

richford commented 9 years ago

It's difficult to check what your post is going to look like before it hits the github pages, even for people with experience with all three technologies, since Github has its own special flavour of Markdown. @morgantaschuk

I've had similar frustrations. There is a neat command line tool called octodown that will help you preview what your markdown will look like on Github.

richford commented 9 years ago

tl;dr - I like the three suggestions for improvement. I don't think that knowledge of any specific lesson should be a barrier to entry in the instructor training. But I am wary of a system in which instructors become so specialized that they cannot help students make connections to other SWC material.

I agree with @wking about the three suggestions for improvement 1. But I also agree with @mjcollin about the desire to have instructors who are able to assist with most of the core lessons. Here's why:

I'm in the current (i.e. round 12) training course so I'm not a veteran instructor by any means. But I've helped out at a few SWC workshops and I have noticed that the lessons can serve to reinforce each other. For example, explaining the difference between HEAD~1 and the 40-character hex string in the git lesson can also serve to reinforce the distinction between absolute and relative paths in the shell lesson. Similarly, there are some themes that are common to all lessons (e.g. documentation, descriptive variable names, minimizing duplication, etc.). An instructor who knows something about the material in each lesson can help students build a richer conceptual map. In How Learning Works, Ambrose talks about the value that instructors add by being able to make connections to previous content or by establishing hooks for upcoming content. So I'm concerned that if instructors become too specialized, then they won't be able to help students make these connections.

At the same time, I agree with @JohnRMoreau that lack of expertise in git (or any one topic) should not be a barrier to entry and could deny SWC of great instructors. So I'm not advocating that instructor trainees should be experts in all of the material. But I do think that there should be an explicit expectation that instructors familiarize themselves with the material as part of their continuing involvement in SWC (i.e. after training). As an analogy, many industries have continuing education requirements for their practitioners, which can be satisfied by taking classes, going to conferences, etc. SWC might not need something so formal, but it could be helpful for newly minted instructors to have some explicitly stated expectations to guide their development.

msarahan commented 9 years ago

@morgantaschuk @JohnRMoreau vi/vim is git's (unfortunate?) fallback editor. You can change this in your environment variables or in git's configuration

I see that this is the very first part of SW carpentry's git lessons: http://swcarpentry.github.io/git-novice/01-setup.html

@morgantaschuk @JohnRMoreau were/are you aware of this?

For me personally, my first instinct would not be to go to SW Carpentry lessons to patch up holes in my knowlege. I would turn to Google first, and hope that I turned up a good tutorial. At least in this case, the SWC tutorial would have been better at avoiding the "I want to use git, but first I have to learn vim" problem. Would a more explicit pointer to the SWC content help incoming trainees? I.e. "We'll use git in this course to collaboratively edit group contributions and help you prepare for contributing to course materials. Please glance over the SW Carpentry lesson here to make sure you're on the same page. If you have questions or need help, please head over to Help@"

Starter content, like the outline above by @mtb-za would be hugely helpful, I think.

Back to topic: prerequisites should simply be motivation and willingness to learn (thanks @weaverbel). I think an important, subtle part of "willingness to learn" is "willingness to interact with computers through commands (as opposed to buttons)." This is how I interpreted @wking statement: "...not sure what instructors who are intimidated by our novice shell and Git lessons are hoping to teach."

Beyond motivation and willingness to learn, it is up to us to provide careful learning paths that bring people up to whatever familiarity we ask of them.

wking commented 9 years ago

On Sat, Apr 11, 2015 at 02:37:10PM -0700, Mike Sarahan wrote:

Back to topic: prerequisites should simply be motivation and willingness to learn (thanks @weaverbel). I think an important, subtle part of "willingness to learn" is "willingness to interact with computers through commands (as opposed to buttons)." This is how I interpreted @wking statement: "...not sure what instructors who are intimidated by our novice shell and Git lessons are hoping to teach." … Beyond motivation and willingness to learn, it is up to us to provide careful learning paths that bring people up to whatever familiarity we ask of them.

The whole point of SWC is to give folks a path toward developing reasonable software development skills without leaving them to grope about on their own. I know I spent few years stumbling about myself before finding out about Git and embracing Python, and it would have saved me a lot of time if I'd had SWC there to point the way. SWC is good at teaching folks (our learners), and all the material is there for reading. The idea behind my poorly-phrased comment was just that if most novice leaners can pick up the fundamentals of a shell and Git in a day, I'd expect most (trainee) instructors could pick up similar skills in a similar timeframe 1. That doesn't mean you need all those skills to be a good instructor. It just means that acquiring those skills is unlikely to be an unachievably high bar for instructors.

But it doesn't really matter how much of a bar they are or whether we give folks a self-study path to learn them, since the current consensus seems to be that we should explicitly teach any required skills during instructor training itself 2.

daivanielsen commented 9 years ago

I think incoming trainees should at least have some familiarity with Git and GitHub. I think it's great that we're using GitHub to facilitate this training course and I've gotten a lot of extra practice with it over the last few weeks that's been really helpful.

As for markdown, I think it's pretty straightforward if someone has a md file they can use as a template. After I cloned/pulled material from the instructor training GitHub page, I used someone else's md blog post file to make my own. It was pretty simple and after that first try I acquired decent working knowledge of how things should be formatted in md.

How to make sure people know a bit of Git/GitHub. For starters, they can indicate if they have their own GitHub page (which they should if they've done a SWC Bootcamp). And then maybe have new trainees clone the instructor training repo on their own (with some instructions available for those who need it). The next step would be to have them make a PR, but I myself struggled with this at the beginning of this training session, so it may be an issue for others.

I don't think these prereqs would discourage most people from doing the training course. Hopefully those who want to do this have done a SWC bootcamp, or have been exposed to Git in some other way. Maybe we could create an online training module about Git and GitHub for those who have very little/no experience with these. The contingency would be that the module needs to be completed (with some kind of evaluative assessment at the end) before enrolling in instructor training. Just some thoughts!

smcclatchy commented 9 years ago

Subject matter knowledge is extremely important but teaching ability must not be overlooked, as it often is in higher learning. We all know through experience that subject matter knowledge doth not a good teacher make, because we've all had bad experiences with people who were experts in their field but who couldn't teach. It's not simply a matter of having good people skills. Teaching really is an art that must be developed through thoughtful practice. K-12 teachers go through a year-long training program before their first year of classroom teaching. This year typically includes coursework, classroom observation, and practice teaching under the guidance of an expert teacher. New teachers observe experts, and are observed by experts who coach them through delivering their first lessons. There's some of this already in SWC instructor training. Rather than enforce prerequisites (which do serve to keep people away), could we develop a supportive coaching community of experts to guide newbies through their initial attempts at teaching?

jiffyclub commented 9 years ago

It would be helpful here to make the goal of instructor training explicit. Is it the only goal to teach people about pedagogy, or is it to more broadly prepare people to teach SWC workshops? If the latter then I think Git/GitHub experience is definitely necessary and should be part of the curriculum.

chungkky commented 9 years ago

I didn't join in this thread earlier because much of what I wanted to say I said in my contribution to the Round-12 training session MoPad here https://etherpad.mozilla.org/swc-teaching-2015-04-02 starting at about line 349. But, grudgingly assuming people on this thread will not have seen the MoPad comments, here are some revisions and additions:

Prerequisite Skills for Teaching Training (TT) I'm torn: I agree with @weaverbel 's comments, esp. if you are serious about wanting novices to teach SWC. At the same time, you need enough familiarity with the content to teach and answer questions adequately and to be flexible in your teaching. Whether you need to have that familiarity, on all lessons, before TT is another question.

Instead of prerequisites, maybe it's more useful to assess students' skill level so you know who you are teaching (Ambrose Ch.1). Possible questions: how often have you used Python (or R, SQL, version control, unix shell, etc) in the last X weeks or X months or year? What do you use it for? (context) Why do you want to take SWC-TT (intent, motivation)? And, so that students know what to expect, make explicit TT's assumptions, apparatus, and learning goals, and have a syllabus available.

Re. GitHub skills (note: I'm in Round-12 of TT right now, first group to use GitHub for TT) I agree with @morgantaschuk 's comments re. steep learning curve of git/GitHub, the blog posts scrolling off into the void (I've never been able to get the Search box on the blog page to work), and that git/GH wrestling is unrelated to being a good instructor. To me, GitHub is mainly the apparatus for the TT course (and a clunky one at that) and hence an extraneous cognitive load. Let's admit/announce it as such and provide scaffolding.

Sacrilegious (and moot?) Question Is GitHub the best tool/apparatus for Teaching Training? I understand the whole of SWC (the lessons archive, the website, etc) moving to GitHub, but in TT we seldom modify our own submissions and we have not modified other people's submissions, so why do we need version control and the clunky GitHub interface/workflow for teaching training? I'm told a future assignment will involve modifying someone else's submission . . still, I'm wonder if GitHub is the best tool for TT.

Scaffolding and Practise Yes, online tutorials, but I don't think they are enough. We also need real-time exchanges where learners can ask questions arising from or not anticipated by the online tutorials. I propose the first lesson of TT be an optional one on the use of GitHub for the TT course. You can have mentors and help-lists later but there should be at least one across-the-board lesson where everyone gets the same baseline info together. Even so, expect difficulties because one or two lessons do not equal practise (Ambrose Ch4&5). I took the 2-day workshop which included git/GH (that lesson went too fast), I've done online tutorials on git/GH, I've read the Pro-Git book (last chapters are significantly more confusing), in Round-12 I have a git-buddy (thank you Luke) and a git tutorial (thank you max), and I still feel 5/10 with git/GH because I don't use it regularly in my work (nor do my colleagues; I'm in the arts/humanities, where most of us are slaves to MSWord and collaborative writing is still rare). No good short term solution to lack of practise.

luispedro commented 9 years ago

I vote for requiring enough knowledge of git to at least do a PR on a github repository. We don't need an instructor to know the different options to git rebase, but clone, edit, commit, push should be a requirement. Same for programming: an instructor need not be an expert, but they should be able take data from a text file and do a line plot in at least one programming language.

I'm a bit baffled by the argument that this would drive people away. Hopefully, it will drive them away to learn git and come back to instructor training later; but even accepting that some prospective instructors are so turned away by it they never reconsider it, it seems a very weak argument. From what I gather, instructor training sells out quickly, so it would likely not even make too much of a dent in the number of instructors, if at all.

Most importantly, SWC has a really good reputation right now (rightfully so, too) and it should be protected even at the cost of short term growth. If the certification is to mean anything, then there should be a minimal bar. Otherwise, I would not feel comfortable talking an institution into spending money from their oft-tight budget so they can fly in someone who may or may not know the core topics.

PBarmby commented 9 years ago

I got my first exposure to git during instructor training, and having more familiarity with it ahead of time would have made that process smoother. If a pre-requisite for instructor training had been to (eg) submit a PR, I probably would have dived in and tried. Being thrown into the deep end with git worked for me, but I can see how it might not work for everyone. Should it be a requirement?

There are several different ways Git/GitHub are used in SWC:

  1. Teaching it to learners.
  2. Facilitiating the community workflow: improving lessons, adding new ones, etc.
  3. To contribute to the blog (and the lessons?) as part of instructor training.

To me, item (1) is the most important reason for instructors to (eventually) know something about Git. You may not be planning on teaching it yourself, but if your co-instructor gets sick, or their transport is delayed, you should be able to jump in. To help out at workshops, you need some understanding beyond 'chant this magic incantation' which is how git seemed to me at first.

For item (2): this is more of a community decision. Do we want all instructors to be contributing to the lessons, or are we happy having many folks who just teach the material as it is? If the latter, then a detailed knowledge of Git/GitHub isn't necessary.

Item (3) is obviously a sore spot for people, and I'd agree that blogging via Jekyll/GitHub is not the easiest thing. One could argue that it is good for prospective instructors to experience the frustration of being unable to make something work (since our learners do), but maybe that's not the best use of everyone's time.

In conclusion, I'd echo what people have said above: prospective instructors need to be comfortable with at least one of the SWC core topics, and have the intention to become familar with all of the others.