When I taught newcomers to use git at Open Source Comes to Campus workshops, we did something similar to what Bruno Grande does, and had a lot of success with it. Some of these concerns occurred to us, this is how we dealt with them:
On Fri, May 20, 2016 at 7:44 AM, Ashwin Trikuta Srinath < [email protected]> wrote: > I would also be -1 to building a blog at a Software Carpentry workshop. > There's too much extraneous cognitive load involved. > We did not use a Jekyll blog, but rather a very simple HTML template to minimize cognitive load. We helped students create something more complicated later, during the freeform section at the end of the day, if they were interested. If you have students create this in a github repository matching their name, they don't even have to use a gh-pages branch, so it really is minimal additional load. > > 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. > > This seems like the strongest objection to me, but perhaps the two things could be combined - sharing data via github pages. > > (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. > > We addressed this by giving students a template to work off of and suggesting they customize it with their name but making sure they knew it was okay to do something silly and pseudonymous. A blog lesson doesn't need to include real, serious blog posts. Alternatively, if it's a public data-sharing site, you can use clearly labelled example data so that students don't feel like the exercise is reflecting on them. > 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. > > These are good reasons for a hybrid lesson. We induced conflicts by having students make changes to the templates and push them back to master, but we were trying to demonstrate a typical open source fork-clone-change-pull-request work process, which is a bit different from what you're trying to do. (Although I will say, as someone who has kept a blog for years, that there are plenty of plausible scenarios in which I'd want to update a blog post!) Anyway, I'm not necessarily arguing for changing the SWC lesson - it sounds like there are some pretty good reasons not to. Just wanted to share how a blog-style into to git lesson worked for us. - Shauna > > 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 >
_______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/listinfo/discuss
