Pre-requisites for instructor training #445
Comments
|
This spun off of a thread on mentoring@ 1. I'll link in some On Wed, Apr 01, 2015 at 02:35:30PM -0700, Greg Wilson wrote:
Previous positions:
|
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.
Tell them that all their exercises in Instructor Training will be based off of (loose) knowledge of the unit.
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. |
|
On Wed, Apr 01, 2015 at 02:58:34PM -0700, Bill Mills wrote:
I'll elaborate on my earlier pushback 1, and say that the shell + |
|
@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. |
|
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. |
|
On Wed, Apr 01, 2015 at 03:15:23PM -0700, Bill Mills wrote:
Hmm. If that's all you need to get through instructor training (and
Novice Git is a six-hour hurdle for everyone coming into our novice
Even if we provide many avenues to satisfy the prerequisite ahead of
I'm ok dropping the Git prerequisite if we have a short session on |
|
On Wed, Apr 01, 2015 at 03:19:52PM -0700, Belinda Weaver wrote:
And I am completely on board with this. |
There is definitely room for this, let's do it.
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 :)
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. |
|
On Wed, Apr 01, 2015 at 03:40:27PM -0700, Bill Mills wrote:
Ok. So assuming our mini-consensus here flies with everyone else ;),
I think that's a solid step forward. I'm still concerned about implicit prerequisites buried in there, and I'm also not sure what instructors who are intimidated by our novice |
|
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.
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. |
|
On Wed, Apr 01, 2015 at 05:13:32PM -0700, Bill Mills wrote:
Thanks for clearing me up. I've updated the repository descriptions
I've posted back to the original thread asking for folks to
Makes sense to me. I'd expect this should be a note in |
|
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 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. |
|
On Thu, Apr 02, 2015 at 07:41:55AM -0700, Vladimir Sudilovsky wrote:
Thanks for sharing this :). Can you give more specifics on what you
According to @BillMills, you don't need to use the shell or |
|
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. |
|
@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. |
|
On Thu, Apr 02, 2015 at 09:34:41AM -0700, Vladimir Sudilovsky wrote:
I'm still having trouble figuring out why a fellow trainee's relative
This is maybe too strong ;). My current opinion here is that it's ok |
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? |
|
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 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? |
|
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:
We need to get the upstream changesThis means we need at least one remote, so:
When writing a new post after that:
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. |
|
Hi Martin |
|
On Thu, Apr 02, 2015 at 05:26:28PM -0700, Martin Bentley wrote:
But it wouldn't be a prerequisite if there was a section of the
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. |
|
@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? |
Also added a section on just using the github interface to create new files, based on [this comment](swcarpentry#445 (comment)) This might be too much detail or too large, but I figured it was useful, so I threw it in.
|
On 2015-04-02 11:12 PM, W. Trevor King wrote:
Nope: you can do the whole GitHub flow in a browser, because you |
|
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 solutionTo 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. |
|
On Fri, Apr 03, 2015 at 01:34:42AM -0700, Martin Bentley wrote:
That's the goal ;). If we can come up with a path forward that sounds |
|
On Sat, Apr 11, 2015 at 02:37:10PM -0700, Mike Sarahan wrote:
The whole point of SWC is to give folks a path toward developing But it doesn't really matter how much of a bar they are or whether we |
|
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! |
|
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. |
|
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. |
|
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) 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) Sacrilegious (and moot?) Question Is GitHub the best tool/apparatus for Teaching Training? 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. |
|
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 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. |
|
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:
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. |
|
Hi, I do not think people will be "afraid" if you set some prerequisites for this course. I think it is realistic. You can split the courses in several levels if needed. If you do not set any prerequisite you will end up with an heterogeneous group of people, which means that some people are going to be master programmers/computer geeks and some other people are going to be R users (that just use R for doing stats, and inside here you can have veeery different levels). So, if you try to teach GIT, Github, R programming, Python programming, Markdown, software development workflow, unit tests... half of the people will be bored (if you just explain the basics) and half of the people will have a brain explosion If the objective of this course is to teach basics, the prerequisite should be basic programming in R or Python, and you can explain the reasons for using version control, GIT, how to share your code and work in teams with github, Markdown, etc. If you want to go further, I would suggest GIT as a prerequisite (basic commands in the command line/shell). best, Sara |
|
On Fri, Apr 17, 2015 at 09:44:55AM -0700, Sara Varela wrote:
See folks commenting on “imposter syndrome” earlier in this issue and
But I think we do want a heterogeneous group of instructors, Opt-outs may make it harder to assess trainee knowledge during/after |
|
I am quite late to this discussion, but just wanted to contribute my experience. I knew nothing of git when I started instructor training several years ago. I learned git and GitHub via the instructor training and through collaborative repo work to set up for the first workshop I helped teach (where I taught shell and R). I now feel quite comfortable with git, but it is all due to the 'on-the-job' experience I have gotten as a SWC instructor, and then taking the skills I learned there back into my own research (currently a postdoc). So I would be in favor of not having a hard or even a soft requirement for instructors to know everything in the novice lessons before they start, as long as they feel quite confident in at least 1 or 2. All workshops have at least 2 instructors, so as long as the other one has a complementary skill yet, it should be ok. |
|
I would guess (I am happy to be corrected) that it is not a fruitful experience being taught a subject by someone who does not know that subject reasonably well. One large part of SWC is demystifying these tools. It is fairly easy for students to detect when the instructors are themselves still mystified, and this in turns leads to students getting the impression that it is not necessary to understand the material, in order to use it - which is surely the opposite of the impression SWC wants to convey. Forgive me for not reading the whole thread, but presumably there is no-one who thinks that every instructor has to know all the topics? I feel strongly that the person teaching git, needs to understand it well, but it's surely not necessary for all the instructors to understand git well. |
|
From reading part of the thread, there is a dilemma where prerequisites may discourage some people from registering to the instructors training, I think that someone who is motivated enough to become an instructor, will not get easily intimidated by such prerequisites. In my opinion, a person aspiring to become a SWC instructor, should take the time to at least go over the SWC Lessons page prior to the instructors training course, and be capable of completing these intro-level lessons to a large extent. Including Unix shell, version control, databases, and a programming language of choice. |
|
What about running two levels of instructor training (or will this cause unnecessary divide again?)
Here is more information to support my suggestion for those who have time to read on ;) Thinking of our situation in South Africa where we have 1 qualified SWC trainer, 1 currently enrolled in online training, and 3 enrolled for training commencing in June, I would love to be able to encourage many more people to get trained as instructors. I am not an instructor but hope to be one – in the meantime I will be organising workshops and assist where I can. I believe that as SWC grows in our country (and elsewhere) we will have a rich collection of trainers varying in technical skill level, teaching experience, and subject expertise and this will allow us to really make a difference to the way research is done and ultimately to the world – diseases/health, food scarcity, engineering questions, arts, and everything else we care about. My personal passion is to help people who traditionally have not been exposed to computers besides Word and Excel and who inherently believes they will never be able to code or talk to “geeks” (the imposter syndrome mentioned before). I believe this is the first place where SWC can make a huge difference in South Africa. I love this statement:
BUT... SWC can also make a huge difference in the world of people who taught themselves to code or are not currently using some of the best practices for scientific coding or even ones who are using best practices. I think SWC is successful based on so many factors
Attending a workshop or participating in instructor training don’t only provide one with skills to teach or to code, but it provides you with an opportunity to be submerged in this community where you can explore new things – safely without the fear of rejection or ridicule. That is what I’d like our South African researchers to be exposed to, to learn from, and to embrace. Maybe we don’t have to decide what instructors should look like, maybe we can create two tiers of instructor courses – beginners and advanced. The beginner instructors could look like the quote above. Advanced trainers can be more technically experienced to really take research coding to the next level. Of course advanced trainers may teach at either level as they wish. At the moment I am teaching people to do “ls” and “less” (okay slightly exaggerated) and work through the R novice material and they’re loving it and we’re all learning and it’s safe. But I can’t teach them magic R stuff applied to their specific research questions. I can’t teach them crazy git/GitHub tricks but I can help them learn about why one should be aware of version control and help them set up their Git account. And I can empathise because I’m struggling too, but I can encourage them because I have learnt so much in the last 3 months. I can basically prep them to attend a workshop offered by someone more experienced. I can help them write bad code (going from not coding at all) so that they learn and appreciate it when someone teaches them to write good code.
The main problem I foresee is having the capacity to provide training for all the trainees who might be interested in becoming SWC instructors… (Stating the obvious here). So, I guess we need to formalise the instructor training in a way that we can get more people trained up do run instructor training if we want to expand even more. [1] http://teaching.software-carpentry.org/page/2/ |
|
On Sat, Apr 18, 2015 at 01:35:23AM -0700, Anelda van der Walt wrote:
I have two concerns with this approach:
Since “Markdown and PRs via the GitHub web UI” is maybe a half-day of |
|
Wow, there is really a lot going on here. I'll be brief. I think that we should put some prerequisites, the prerequisites don't have to be hard-lined, and being an instructor is not for everyone. I elaborate now. I think that to teach something you should have a relevant experience in the field. The more, the better. SWC assumes that there basic computational skills that scientists should have, such as automating tasks using the UNIX shell, version control, and basic concepts of programming. Note that these are not tool related, but mostly conceptual frameworks (i.e. why writing functions, and not which is the R syntax to write a function). I think the requirement should be have a intermediate knowledge of such concepts. This is specifically vague to accommodate all the different background we see in our current instructors and hard to assess and test, so I think it should be up to the future instructor to think if they have such knowledge. To me the point is not dropping git or vi or markdown, it's whether the instructor is experienced enough in using the skills whose use we're advocating. Note that tools may change. A couple of years ago, SWC used SVN instead of Git, there was no sign of R or MATLAB, Markdown wasn't a thing, and we had lessons on spreadsheets. I particularly struggle with git sometimes, because I use mostly SVN for work. But I started using version control almost 10 years ago, so I understand why and how to use it and can make a case on a workshop on why scientists should do it. Same goes for programming. I don't use R, but I can explain the R materials on loops or functions at a novice level if I have some notes on the R syntax, because I have experience programming on other languages. I think instructor training was designed to instruct scientists with relevant experience on computing [1] how teach to others, and that's why there's almost no emphasis on actual materials we teach. Our prospective instructors are changing now and we're getting people without this experience we took for granted. My solution would be ask the prospective instructors to go thru our novice lessons and assess if they would feel comfortable teaching them, even if they don't know the particular tool. I don't care if someone has trouble doing pull requests for a few times, but if they never used the command line or a text editor before, I don't think they would be prepared to teach SWC after the instructor training nor that we should change the training curriculum to fit them. [1] And I think this sentence is important: scientists who understand the issues other scientists are facing, who probably don't have a proper CS training, but learnt in the trenches, and whose computing skills may not be consider such in a broader CS or software development context. |
|
On Mon, Apr 20, 2015 at 09:09:08AM -0700, Ivan Gonzalez wrote:
I think this is a reasonble position, but:
So far, I haven't heard about any issues with our training capacity, |
This is another reason why words like "novice" or "expert" are so useless (even "two steps ahead of the learners" is useless). However, "can you do a PR on a github repo?" is a very useful question. If there is no input filter, do you propose an output one, like an exam before people can be certified? Otherwise, how can you ensure that the certification represents something?
http://swcarpentry.github.io/training-course/ says Our online courses are full for the remainder of 2015. I have heard of courses filling out very very fast. |
|
On Mon, Apr 20, 2015 at 10:11:54AM -0700, Luis Pedro Coelho wrote:
We currently have neither filter as far as I know, other than “you
Thanks for the links :). Maybe we want to revisit the “no prereqs” |
|
Am I right in thinking that the current emphasis on teaching 'how to teach' is partly based on the assumption that people already know the material for 'what to teach'? For example, if you were teaching calculus, and your teachers didn't know calculus, you would have to teach that - first - or as well. There must be some danger in expanding software carpentry to the degree where the instructors do not themselves know the material. It's possible that will just improve the coverage of SWC, but it's also possible it will affect the reputation of SWC enough to slow the current progress. |
|
On Mon, Apr 20, 2015 at 10:27:45AM -0700, Matthew Brett wrote:
One of the problems is that “what to teach” is pretty flexible ;). |
|
On Mon, Apr 20, 2015 at 10:39:53AM -0700, W. Trevor King wrote:
If we have more students than we can teach, pre-testing would be a
Then potential trainees can decide how to balance the cost of a longer I think this would work well for online courses, but you'd need a bit |
|
It seems to me that git is a particularly good example of a topic that can be badly taught by someone who does not understand the underlying model. That can have a bad effect on the students, because they can't help but come away thinking that git is used by an obscure set of magical incantations, setting them on entirely the wrong path for their future learning. |
|
On Mon, Apr 20, 2015 at 11:03:05AM -0700, Matthew Brett wrote:
But you can be a perfectly competent SWC instructor, leading workshops And really, I think all of our tools (and probably most subjects) are |
|
To me, the PR on Github is anecdotal and should not be a requirement. I can do a significant PR fixing typos or rewording text using mostly (maybe only?) the Github web interface. This doesn't test my knowledge of the skills we aim to teach (automation, structure programming, and version control). Furthermore, Git is pretty young (at least its widespread use) and same goes for Markdown. A better test to me is using the shell and other command line tools. If someone is confident writing programs in whatever language using only command line tools, he/she could learn the specific tools we teach. |
|
@wking - sure - I am certainly not arguing that you should understand the git model before you teach some other topic, such as shell, markdown or structured programming. But I am arguing that, if you haven't read about and understood the git underlying model, you will be very likely to lead the students down the wrong path - when teaching git. It's one obvious case where understanding some basic ideas does have a large impact on how you teach. |
|
In my original response to this issue, I wrote I honestly think the most important attributes for Software Carpentry instructors are (a) a strong desire/motivation to help researchers pick up important skills Having now almost completed instructor training, and being about to run a bootcamp, I would now add a third, namely (c) the willingness to learn the lesson content well enough to be able to teach it. That means learning to use Git, the shell, Python, and so on even if they seem hard or incomprehensible at first. When I started instructor training, I could not have taught the lessons. But I got a Linux laptop, worked through the lessons, did the homework tasks, and now I feel I could teach some of the lessons, which is a huge step forward. Obviously I still have a way to go but I was more than willing to engage with a whole raft of new material. If we are to keep training instructors without strong technical backgrounds, they need to demonstrate that same willingness to learn. |
|
Well, I think knowing the materials well enough to be able to teach them is pretty much is the least one could ask for an instructor, in any case, not only for SWC. But the point is not that, the point is what we should ask from someone before becoming an instructor. I cannot understand the motivation of someone deciding to become an instructor in something far from his/her background or current skills. I'd recommend this person to take our regular bootcamp, learn the basics, get some practice, and take the instructor training later. I think it's common sense. In our mission statement [1], I see we are dedicated "to improve basic computing skills of researchers" and that "we want a significant fraction of our learners to become instructors". To me this means that future instructors must have at least the equivalent technical knowledge of learners at the end of our bootcamp. |
|
Prerequisite: having attended a workshop as a helper. No particular pedagogic skills need besides some guidelines those offered by whomever runs the workshop. Some technical skills obviously needed to be useful, also decided by the local team. |
@huguesfontenelle, this works if you leave in the Bay area or NYC, where we have a bunch of workshops and opportunities to help abound. Helpers are not reimbursed for travel, so how a person from Brazil, Spain, or Namibia is gonna find opportunities to attend as a helper and become an instructor? |
and others
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?
The text was updated successfully, but these errors were encountered: