I would also be -1 to building a blog at a Software Carpentry workshop. There's too much extraneous cognitive load involved.
I do however, agree that the planets lesson has little relevance to learners. I would be in favor of teaching Git *after* a programming session (Python/R), and having Wolfman and Dracula do something a little more useful and exciting than build plans to colonize Mars. (This immediately raises the question about which language to use: Python or R? Or should there be a version of this Git lesson for each language?) Git/GitHub in the context of scientific computing is *exciting*, because it solves real problems like data loss, reproducibility, and maintaining correctness. Maybe some learners go on to discover these things by themselves after our Git session, but I do feel it's a bit irresponsible of us not to lead them to it. On a related note: is there a Software Carpentry styled lesson on Git-for-scientific-software lurking somewhere? I found the materials for the excellent "Version Control and Unit Testing for Scientific Software" talk: http://conference.scipy.org/scipy2013/tutorial_detail.php?id=106 https://github.com/dklaes/SciPy2013/tree/master/Version%20Control%20and%20Unit%20Testing%20for%20Scientific%20Software/git But the Git materials here are more a summary of Git commands than a full lesson. Thanks, Ashwin On Fri, May 20, 2016 at 6:24 AM, Jan Kim <[email protected]> wrote: > Dear All, > > On Fri, May 20, 2016 at 09:00:29AM +0200, Lex Nederbragt wrote: > > Hi, > > > > Bruno Grande just published a blog post on this approach to teaching > > git by having learners set up their online presence using GitHub Pages, > > and contrasts it to the current SWC git-novice ???Planets??? lesson. I > > do not agree with all he is saying about effectively teaching git, > > but he does have a few interesting points: > > > > http://bgran.de/teaching-git-using-github-pages/ < > http://bgran.de/teaching-git-using-github-pages/> > > having just taught git using the planets lesson, I understand the concern > that the scenario is contrived. However, I do not believe that creating a > blog is a good alternative for these reasons: > > (1) Not everyone is comfortable with writing something at perhaps just a > few minutes notice and then putting it into the web-wide public. > Personally, > I'd do it reluctantly, make a very strong mental note to myself to take > down the thing after the lesson, and dislike the lesson for having to > remember that. And if I managed to forget, I'd not only blame myself, but > apportion some blame on the lesson as well. > > (2) A central purpose of SWC is to enable people to collaboratively develop > software for scientific computing. In this context, writing blogs is not > the > main use case. Two specific issues that I consider important are: > a) blogs are typically personal, so it's difficult to motivate a > scenario where contributions from team members result in a conflict > b) blog posts are typically written with a time stamp and then not > revised, so it's difficult to set up a plausible scenario for > showing diffs and checking out earlier versions. > > (3) Starting with setting up a local repo and pushing that to github later > makes much sense to me, both didactically and real-world wise. Starting > with github seems a rather backward way to go -- as far as I recall, all > my github repos that have any content of substance have existed outside > of github for a substantial amount of time before I put / pushed them > there. > > (4) In the workshop I just ran, we swapped github for bitbucket, because > the host wanted a cloud option for the participants that they could use > for collaborating but without the www-wide public potentially watching. > With the planets lesson, that was no problem but any lesson that uses > github-specific features would not allow such changes that easily. > > It seems to me that the current git lesson is, to some extent, the result > of squaring the circle of teaching revision control to learners who > possibly > have just barely written the first few revisions of their first shell > script. > This perspective could suggest to develop alternative git lessons that > extend > the scenarios used in the shell, Python, R etc. lessons. > > Best regards, Jan > > > > Best, > > > > Lex > > > _______________________________________________ > > Discuss mailing list > > [email protected] > > http://lists.software-carpentry.org/listinfo/discuss > > > -- > +- Jan T. Kim -------------------------------------------------------+ > | email: [email protected] | > | WWW: http://www.jtkim.dreamhosters.com/ | > *-----=< hierarchical systems are for files, not for humans >=-----* > _______________________________________________ > Discuss mailing list > [email protected] > http://lists.software-carpentry.org/listinfo/discuss >
_______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/listinfo/discuss
