April, Thanks for your thoughtful reply. I'll restate for two cases. I'll try to be clearer and more succinct.
If I assume that all SWC shell lessons will cover loops when I start planning my lesson, I may end up in a bad place if not all Shell lessons will have covered it and I count on it. If I assume that everyone who takes an SWC Novice Python Inflammation will have seen try: except:, but it is not covered by all SWC instructors, then I might end up in a bad place. Where my question was sort of really leading was back to the notion of the really 'core' material that will be covered by everyone who teaches a lesson with that title, so that someone outside any particular workshop can be reasonably assured that some clearly definied _minimum_ set of topics would be covered. I understand there is always tension between presenting what seems 'right' somehow for the level of the participants and what's in the lesson plans, but if the lesson plans were shorter, they would be more accurate representations of what was _actually_ covered in all (or most all) lessons of a particular type, both for people who might want to build on them and for the people who might want to sign up for them. For that last mentioned thought, there are two cases in point that have come up in my experience, a) someone who signs up because they are maybe a little shaky on the morning's Python topics, but are really looking forward to Functions, Errors and Exceptions, Defensive Programming, and Debugging, and then comes away disappointed when those don't get covered; b) the *verse (inverse, obverse, converse, or reverse) of that, three of four people really are rank beginners, but most of the other participants are in case a), so the instructor shorts the early topics to be sure to have time for the more advanced ones, and the beginners are at sea after about 30 minutes. I believe I've seen both here. My intuition tells me that maybe restricting the material that's 'required' but providing ample material that's 'extra' might help. It would help make descriptions more accurate ahead of time (which might make learner self-placement easier), and it would help those who expect coverage of the listed topics later. I wanted to toss the idea out to the general population to see if anyone else was thinking about intermediate workshops and thus might care about having a reliable set of topics in precursors, or who might have experienced people who were disappointed in the workshops because they either lagged or sped and might think this could help reduce their numbers. Thanks, again, for your thoughtful reply. I hope I've manged to clarify rather than murk. -- bennet P.S. Which intermediate topics are you thinking about/working on? I've thought a couple of times about putting something together that does the equivalent of a full day of shell, and half days of make, and git, with some kind of pipeline/workflow that does something comprehensible as the product at the end. That wouldn't be SWC, but I think most of the core concepts would be covered, and I think it would be useful to quite a large scientific audience. I will have to take an extended vacation to get it done, though. On Mon, Oct 3, 2016 at 6:14 PM, April Wright <wright.apr...@gmail.com> wrote: > Hi Bennet- > > I've been thinking a lot about intermediate training lately, and I was > wondering, Bennet, if you could restate the problem as you see it? > > There's the problem of what topics are covered. However, like Raniere said, > SWC-branded workshops do all have to cover a set of material (shell, > programming in R/Python, git). But it seems to me that your question might > be how can you plan an intermediate workshop when you don't know if the > previous instructors got through command-line programs, or if they only made > it to defensive programming, to use the Python lessons as an example. > > That's a problem that I'm not sure how to fix. On a really fundamental > level, I think instructors need to have the discretion to slow down and > cover less material if they think that's warranted. One way that I have > tackled this in the past (in a non-SWC workshop) is to have the intermediate > workshop restricted to people who have taken the beginner workshop, or who > contacted me and explained their situation. That's obviously somewhat > unsatisfying, since it means that self-taught and other intermediates need > to recognize that they are intermediates, and contact me (and I scale > terribly). But that's the best solution as I see it - to plan materials that > assume usage of the prior materials as a starting point, and to try to > control the flow of people through whatever pipeline you set up. > > If you're in a situation where you can't control the flow of folks through > whatever pipeline, I think the next best thing is to be explicit. Explicit > about a) what skills you will assume (possibly with links to SWC materials > on them, if applicable) and b) about what will be covered (i.e., what skills > they will gain). You can also have people apply to a workshop, rather than > sign-up for it. I recently taught a week-long immersive research course in > my discipline, and we had people apply with a CV, and an explicit statement > of what they wanted to get out of the course. This, however, runs into the > same scaling issues - it took my co-instructor and I a really long time to > pick our participants. > > In short: intermediate learning is challenging, since the definition of > intermediate is relative. But there's a real drop-off in availability of > materials after beginner courses, and I'm glad you're thinking about it. > > -- april > > > On Mon, Oct 3, 2016 at 5:36 AM, Raniere Silva <rani...@rgaiacs.com> wrote: >> >> Hi, >> >> > I would agree that indeterminacy of workshops exists because SWC has >> > learned that not all lessons fit all disciplines or experience levels. A >> > quick >> > example is that version control is a tough concept unless learners have >> > done at least some coding and have either lost a lot of work or broken a >> > piece of code and want desperately to go back to a previous copy that >> > they can't find. So for a particular level of learner a workshop may >> > exclude >> > git or it may not. I think this analogy applies to most tools. >> >> I agree with Cameron when he say "not all lessons fit all disciplines or >> experience levels". >> I only want to add two cents: >> all Software Carpentry workshops need to cover Git (or Mercurial or >> another version control system). On a workshop with novice learners you >> probably will not cover branches but on a workshop with learners that >> have done at least some coding they will probably ask the instructors >> about branch. ;-) >> >> Cheers, >> Raniere >> _______________________________________________ >> Discuss mailing list >> Discuss@lists.software-carpentry.org >> http://lists.software-carpentry.org/listinfo/discuss > > > > _______________________________________________ > Discuss mailing list > Discuss@lists.software-carpentry.org > http://lists.software-carpentry.org/listinfo/discuss _______________________________________________ Discuss mailing list Discuss@lists.software-carpentry.org http://lists.software-carpentry.org/listinfo/discuss
