I agree with Azalee. There needs to be some standard challenges included within the lessons because (a) that will help instructors who just want to pick up the notes and run with them, and (b) some of concepts in the lessons are taught via challenge as opposed to lecture / live coding. Those challenges have to appear at the correct place within the lesson or else the whole thing doesn't work. If we adopt the approach of putting all the lessons at the end then we are taking away challenges as a tool for teaching new concepts and restricting ourselves to only using challenges as a tool for practice and consolidation.
Perhaps standard challenges can appear in red boxes and optional extras in blue, or something like that? ----- Damien Irving PhD Candidate School of Earth Sciences The University of Melbourne Secretary, Australian Meteorological and Oceanographic Society (AMOS) Research Community Coordinator (Physical Sciences), Research Bazaar project http://resbaz.tumblr.com/about Ph: +61 3 8344 6911 Twitter: @DrClimate Blog: http://drclimate.wordpress.com/ CV: https://github.com/DamienIrving/CV/blob/master/CV.md On Wed, Apr 1, 2015 at 4:07 AM, Azalee Bostroem <[email protected]> wrote: > I agree with Ivan. As a seasoned instructor I like having a bunch of > challenges to pick from, but we have so many new instructors that having a > lesson that they can teach out of the box is valuable. I would propose > having a standard set of manageable exercises and an auxiliary file the > rest for more experienced instructors to choose from. > > -Azalee > > > ------------------------------------------------------- > K. Azalee Bostroem > Graduate Student > UC Davis > http://azaleebostroem.wordpress.com > ------------------------------------------------------- > > > > > On Mar 31, 2015, at 10:04 AM, Ivan Gonzalez <[email protected]> wrote: > > Sure, but then I think that some challenges should be labelled as extras, > or move to a "homework" file. Also, a novice instructor may have not know > this or which are the best to pick. In my experience what happens is that > as the lesson advances and the accumulated delay with respect to the time > estimate grows, instructors tend to drop challenges at all, and simply go > through the materials. > > We could have notes in the instructor guides stating that. For example, > "for topic 1, you should cover challenges 1 and 2 because they are > important, and pick up another from the list of challenges. The estimated > time to complete these three challenges is 10 minutes." > > Ivan > > El 31/03/2015, a las 12:46, Bill Mills <[email protected]> > escribió: > > One crucial thing to note: you don't have to actually *do* all the > challenges - I certainly don't. > > I think it's valuable to have a large selection of challenges for > instructors to pick from, to reflect exactly what they want to emphasize; > as we encouraged new instructors to add new challenges, the intention was > never for everyone to do every challenge every time. But, that could be > much better communicated. > > On Tue, Mar 31, 2015 at 9:27 AM, Ivan Gonzalez <[email protected]> wrote: > >> I can't attend the meeting tomorrow, but I agree with the plan. >> >> We could also set some guidelines for maintainers on how long a lesson >> would be. For example, limits in the number of challenges, lines of code, >> or even words per topic. I don't pretend to put a hard limit, but just as a >> function with 100 lines and 20 nested loops "smells of bad code", a topic >> with more than 5 learning objectives or more than 5 challenges is probably >> bloated. >> >> Best, >> >> Ivan >> >> El 31/03/2015, a las 12:01, Greg Wilson <[email protected]> >> escribió: >> >> I agree - how's this for a plan? >> >> 1. Maintainers for each lesson file an issue suggesting material that can >> be moved into discussion.md (a storage depot for extra stuff). >> >> 2. We ask trainees to submit exercises (particularly MCQs) rather than >> new content. >> >> Ivan/Gabriel, would you be willing to lead discussion of this at >> tomorrow's lab meeting? >> >> Thanks, >> Greg >> >> On 2015-03-31 11:38 AM, Gabriel A. Devenyi wrote: >> >> I've had a recent similar concern regarding the shell lessons. >> >> I think the root cause of this may be the final assignment for >> instructor training, it's probably easiest for people to just add material. >> We may need to re-spin that assignment a bit so we don't encourage bloat. >> >> -- >> Gabriel A. Devenyi B.Eng. Ph.D. >> Research Computing Associate >> Computational Brain Anatomy Laboratory >> Cerebral Imaging Center >> Douglas Mental Health University Institute >> McGill University >> t: 514.761.6131x4781 >> e: [email protected] >> >> On Tue, Mar 31, 2015 at 11:32 AM, Ivan Gonzalez <[email protected]> wrote: >> >>> Hi, >>> >>> I'm going through the Python novice lesson for a workshop I'm teaching >>> this week. It's been a few months since the last time I taught it and I've >>> noticed that the lesson has increased substantially. I feel the same with >>> the git novice lesson: in the last couple of months I'm the maintainer, >>> we've added a good 15 minutes in a lesson that most instructors and >>> learners have trouble finishing. Also, I think these additions are not >>> reflected properly in the estimated times. >>> >>> For example, the first topic of the python lesson [1] has now 10 >>> challenges, plus variables, memory model, operators, importing a module, >>> numpy arrays, slicing and indexing, methods for objects, plotting with >>> matplotlib, and some strings. The estimated time is 30 minutes, which >>> leaves me with ~2 mins per concept and 1 minute per challenge, where I'm >>> supposed to correctly type and run more than 50 lines of code. I also have >>> to show how iPython notebook works. I think this is not doable for the >>> average novice learner and instructor. >>> >>> As I said, this is not specific to the Python lesson. In a workshop I >>> taught last week, a similar situation with other lessons created a lot of >>> frustration among the students and, specially, among the instructors and >>> helpers (all first-timers but me). >>> >>> I understand that we all want to contribute to the lessons and add the >>> last best thing, but we are risking that our lessons become more a >>> self-study material, instead of something instructors can use in a workshop. >>> >>> Best, >>> >>> Ivan >>> >>> [1] >>> http://swcarpentry.github.io/python-novice-inflammation/01-numpy.html >>> >>> _______________________________________________ >>> Discuss mailing list >>> [email protected] >>> >>> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org >>> >> >> >> >> _______________________________________________ >> Discuss mailing >> [email protected]http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org >> >> >> -- >> Dr. Greg Wilson | [email protected] >> Software Carpentry | http://software-carpentry.org >> >> _______________________________________________ >> Discuss mailing list >> [email protected] >> >> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org >> >> >> >> _______________________________________________ >> Discuss mailing list >> [email protected] >> >> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org >> > > > > -- > Best Regards, > Bill Mills > Community Manager > Mozilla Science Lab > > > _______________________________________________ > Discuss mailing list > [email protected] > > http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org > > > > _______________________________________________ > Discuss mailing list > [email protected] > > http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org >
_______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
