I'm midway through a workshop. Brief thoughts: * Even if folks don't install, I'm partial to helping them through the process. Git for Windows is quick; Conda and git/OSX Developer tools takes a bit longer, but still worth it. Work with your neighbor as it's installing, or use online tools <http://try.jupyter.org>, or short <https://try.github.io/levels/1/challenges/1> lessons/ alternatives <https://try-python.appspot.com/> if possible. As teaching-instructor, I will often do a check before lunch (i.e. "before you go, run jupyter notebook - if it doesn't work, let's chat") to prepare for non-day1-morning installation issues. If student sits in the back and keeps up on an alternative tool (like python interpreter vs jupyter notebook), I try to help with installs during an exercise / breakout. * I know my limits, but I'm confident with quick debugging. I've seen quite a few common errors before (and sometimes the instructor makes a mistake and fixes, but the learner is 2 minutes behind...) I try to give at most 1 minute of help at a time, kneeling, at a low whisper. I think this may be a reasonable ask for instructors during "off" lessons (motor ability permitting). I also give advice to helpers re: touching keyboard, noise level, etc (it can be hard to notice how distracting you are to others!) In serious/blocking cases, I may ask the student to sit in the back to finish debugging in a less distracting environment. (Of course, this is only if most others are keeping up..) * After we solve the issue, I sometimes share lesson material links on Etherpad so they can read / catch up (usually folks can get back on track).
On Mon, Jan 8, 2018 at 12:21 PM, Tracy Teal <[email protected]> wrote: > Thanks Greg. These are a lot of great ideas. Belinda has a summary blog > post planned, and we're planning to add a section about this to the > 'helpers' section of the developing Carpentries Handbook. (More on that > soon!) > > Best, > -Tracy > > On Mon, Jan 8, 2018 at 6:18 AM, Greg Wilson <[email protected]> > wrote: > >> This is all great stuff - can someone please PR an addition to the >> instructor training summarizing it? >> >> Cheers, >> >> Greg >> >> >> On 2018-01-08 4:28 AM, JACKSON Michael wrote: >> >>> Hi, >>> >>> Other suggestions are to: >>> >>> * Ask the learner to watch the lesson as if it was a conventional >>> demo-style lecture. Though they lose the "doing" aspect, they won't lose >>> track of the lesson and their neighbours won't be disturbed by explanation. >>> * Ask them to buddy up with another student (which can be easier if >>> they're there with colleagues). >>> * Have a couple of back-up laptops with a pre-installed SWC/DC >>> environment (though this imposes additional requirements on hosts and >>> instructors). >>> >>> On a related note I'd make a distinction between students who fall >>> behind either because they have problems comprehending the material and >>> typing it in or who end up with a file/environment in a bugged state, and >>> those who have problems because they made no effort to install the >>> prerequisite software and run the related checks before they turned up >>> (despite myriad requests to do so!). As helpers are a limited resource I >>> think they should be used primarily for the former not the latter. To >>> handle the latter, at the start of each session, 5-10 minutes could be >>> spent checking people have their environments correctly set up. Any >>> unsolvable issues within this time period could be addressed be the >>> approaches suggested above. >>> >>> cheers, >>> mike >>> >>> ________________________________________ >>> From: Discuss <[email protected]> on behalf >>> of Paul Ivanov <[email protected]> >>> Sent: 06 January 2018 23:37:52 >>> Cc: Software Carpentry Discussion >>> Subject: Re: [Discuss] Taking over learner's keyboard >>> >>> Hi Peter! >>> >>> (I sent this directly to you, now replying to list...) >>> >>> On Fri, Jan 5, 2018 at 10:55 PM, Peter Hoyt <[email protected] >>> <mailto:[email protected]>> wrote: >>> I recently was helping in a SWC workshop, with a (beginner) learner who >>> got lost. >>> Instead of taking over the learners keyboard, I talked her through the >>> process. >>> >>> Not sure if you saw a thread Belinda started on this topic in November. >>> The subject line was "On not touching people's devices", there are some >>> thoughts, suggestions, and resources in it: >>> http://lists.software-carpentry.org/pipermail/discuss/2017-N >>> ovember/thread.html#5609 >>> >>> >>> Even though I tried to be quiet, this turned out to be VERY distracting >>> to nearby learners (and they let me know it), and it's understandable. Has >>> anyone come up with a strategy to deal with this? For example if you could >>> grab the laptop and move to an empty spot in the back of the room where >>> learners can be talked to, without disturbing others? This seems >>> distracting also, and would only make the learner fall farther behind. >>> >>> This scenarios resonates with me: I'm loud, my voice carries, and I end >>> up having less control over my volume the more caffeinated, excited, or >>> sleep deprived I am, so I've definitely run into this before (which >>> unfortunately also means it has likely happened even more when those around >>> were to polite to tell me to pipe down). >>> >>> It's tough and very situation dependent - if it doesn't block them from >>> continuing to participate, you can suggested putting the issue aside for >>> now and offer to help during the next break. Another way is to get on a >>> synchronous communication channel - (be it IRC, slack, or etherpad), and >>> try to solve it that way. The advantage of doing that in the channel used >>> by the workshop is that other helpers/instructors/learners might face the >>> same issue and will benefit form the instruction, or have a clue about how >>> to proceed. It also allows the person to context switch a little bit >>> gentler, and perhaps copy-paste commands as opposed to having to type them >>> out from your phonetic incantations like "arr em space minus eff arr space >>> dot slash data enter". I've also written out commands on a piece of paper >>> and handed it over. Now having said that, as you point out there is a >>> tension between wanting to provide full context (what's happening, why, and >>> enumerating the different paths towards resolution) and getting to a >>> resolution. >>> >>> But sometimes, you're just going to get an impossible situation - I >>> recall a hardware failure - computer freezing and refusing to boot >>> mid-workshop one time. The owner said that it was known to be a flaky >>> laptop, and we tried switching bios settings and had a bootable USB drive >>> with Debian on it that we tried to conjure new life into that machine, >>> which partially worked but in the end there was little we could do about it >>> - the machine kept freezing, we had to admit defeat and change our >>> expectations and our strategy for the remainder of the day. >>> >>> -- >>> _ >>> / \ >>> A* \^ - >>> ,./ _.`\\ / \ >>> / ,--.S \/ \ >>> / `"~,_ \ \ >>> __o ? >>> _ \<,_ /:\ >>> --(_)/-(_)----.../ | \ >>> --------------.......J >>> Paul Ivanov >>> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 >>> >>> >> >> _______________________________________________ >> Discuss mailing list >> [email protected] >> http://lists.software-carpentry.org/listinfo/discuss > > > > _______________________________________________ > Discuss mailing list > [email protected] > http://lists.software-carpentry.org/listinfo/discuss >
_______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/listinfo/discuss
