I definitely like the idea of "choose the version that’s best for your audience” too. ??
Something Ashley and I had been discussing during our original lesson planning was “What if we flipped the script? How much of the initial learning could we do entirely on GitHub.com, to introduce how you coordinate and collaborate and get them to see the multi-user coordination benefits more clearly, and then introduce the command line later?” We went with Steve’s version in the order written in order to give it a test run for reporting back to the community, but that might also be an idea worth considering as another choice among the options. People who are used to web-based Google Docs and Word Online versions of version control would find the GitHub web interface more familiar to start with, and they could really take advantage of Git versioning and pull requests for multi-file productions like publications via the web interface with less “fear factor” than the command line can create. (I was surprised to get command line fear factor from a group of IT pros, but it was mentioned in the feedback!) It would also put collaboration in the foreground – when Git goes into a 2 hour time window, sometimes you don’t actually get to the multi-user part of it. If there was a “starts with GitHub” variant that begins with collaboration and pull requests, because the “add and commit and push” are by definition already handled by the web interface, I could see that being helpful to teams that need to figure out how to coordinate multiple files as pieces of a larger project, whether or not the files are text files. Two more cents. ?? Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 From: Christina Koch<mailto:[email protected]> Sent: Friday, January 12, 2018 9:40 AM To: Bond, Steve (NIH/NHGRI) [F]<mailto:[email protected]> Cc: Strong, Dena L<mailto:[email protected]>; Software Carpentry Discussion<mailto:[email protected]> Subject: Re: [Discuss] Git and Github lesson (follow-up) Hi all, Jumping in a bit late, but this development is great! I like the idea of offering two flavors of the git/github lesson -- a more command line based one and this more github flavored approach. I also like the idea of gathering a list of alternative things to edit -- either replacing Dracula with another option or having 2-3 ways to teach (how we handle that infrastructure can be part of a later discussion). Thanks all! Christina On Wed, Jan 10, 2018 at 8:38 AM, Bond, Steve (NIH/NHGRI) [F] <[email protected]<mailto:[email protected]>> wrote: Hi Dena, Thanks for all of the feedback! And I really like your visual aids. I’ll try to spend some time to modify the clone/conflict section and add a few new sections to go through reset and branches. Congrats on a successful workshop. -Steve From: "Strong, Dena L" <[email protected]<mailto:[email protected]>> Date: Tuesday, January 9, 2018 at 7:24 PM To: "Bond, Steve (NIH/NHGRI) [F]" <[email protected]<mailto:[email protected]>>, Software Carpentry Discussion <[email protected]<mailto:[email protected]>> Subject: RE: [Discuss] Git and Github lesson (follow-up) Reporting in: I just taught from Steve’s version today, and it went fantastically. I’ve never taught Git before. I really liked teaching with this structure – the Dracula thing never made sense to me, whereas both the audience and I didn’t have any problems following the “all right, we’re adding new features to software under development” description. I would enthusiastically endorse anyone who wants to teach from this version to give it a go! (I was particularly lucky since Maxim Belkin, my co-instructor, is brilliant, friendly, and enthusiastic! My original co-instructor had a house emergency and I’m really glad Max could step in. I would have been flailing a lot when the IT pros I was teaching asked things outside my knowledge and expertise level, but I would have been doing that with any lesson plan.) The TL;DR and a physical mechanism for conveying concepts below: This audience: 6 IT professionals ranging in experience from “I’ve never touched Git before” to “I’ve been using it on and off for a few years, but I still don’t get it.” The method: Steve’s non-Dracula version of git-novice, a slide deck for supplemental concept walk-throughs, and a bunch of file folders for physical representation of what was happening with each edit in each step. All my links are collected up at https://tinyurl.com/itpro-gitnotes<https://urldefense.proofpoint.com/v2/url?u=https-3A__tinyurl.com_itpro-2Dgitnotes&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=rD4OA1kkL0S4v1qYK9k-ja5g5j8GrEgKciJJhx3Vkj8&m=p7qQrGLTNvMswazA0VMvQ-rNOAKR4V7H6b7dkQlOCLg&s=ULyG963VMTCvsd7WiBcmOEPNcxrcL9SXHcxIsn9F5jk&e=>. On the potential confusion point Steve mentions below: Two of our pairs were OK with the fork vs clone thing and worked out how not to have name space collisions and knew where they were at. However, our third pair was struggling and Maxim helped them out a lot. As suggested below, I think revising it so people are forking from a different repository than you’ve just cloned from would help reduce the name space collision headaches. And people were also finding that they could just accept the pull request because they already had access after having traded authorizations for collaboration. (So maybe have them fork from the instructor’s version instead?) We also discovered that either there weren’t instructions explicitly telling you to go up a directory from your previous working directory before running a clone command, or it was well enough buried that 2 of our 6 ended up cloning their new stuff into the folder they were already working in. So more clearly spelling out “before you start a new project, go back to your ~ directory” could be helpful to add too? Because these were IT pros, they were more interested in complex workflows, resets, “hitting the undo button,” and continuous integration capabilities than in open science and R studio, so we went off the lesson plan at the end of step 9 and Max freestyled branching, merging, resets, and travis-ci. I think it would be worth considering adding “how do you roll back” to the course – they were really interested in branching and git reset and git checkout, which don’t get touched on in the major material. One poor individual had been manually undoing all his changes to get back to matching the master version whenever he wanted to retrace his path, and I think branches and git reset have changed his world. Food for thought? A teaching aid I found helpful: A “folders and notes” setup for physically demonstrating what goes where at what step. (Image attached – in actual class I put working-space on the left and repository on the right to match reading order; this photo was when I was setting up mirrored versions to test drive.) * Working directory: Papers in front of you * Edits: Sticky notes that get put on a thing in your working directory * Stage: A folded-over piece of paper labeled “stage” (because I only had manila or hanging folders, and the inner folders were commits) * Commit: “You take everything that’s in stage, and put it in this manila folder. Then the manila folder goes into your local repository hanging folder. You get more and more manila-folder commits as you add new versions to your local repository, and each of them has its own label – that’s this hash tag right here…” * Repositories: Two hanging folders of the same color, one in front of the person (local) and another in a box at the end of the room (remote/GitHub.com). It seemed to help people visualize the differences between add, commit, and push as I walked them through things, and the manila-folder layer gave some starter ground work for the difference between clone (“Blue wants to edit on Pink’s project, so Blue grabs a manila commit folder from Pink’s remote folder and puts it in Blue’s local folder in front of them”) and fork (“Blue doesn’t want to edit in Pink’s repository, Blue wants their own. So first we copy Pink’s manila folder commit into Blue’s remote directory, and then Blue has their own working space for this project, and here’s how Blue can give Pink some edits with a pull request.”) I hadn’t worked out how to simulate branching because I knew Maxim would handle that the way he preferred to, but everything up to that point seemed to work fine. I’d never thought I’d feel comfortable teaching Git, because I don’t use it in my working life. But we needed teachers, so I dove in, and I loved this lesson structure, and I want to give a huge thank you to both Steve (for providing the lesson structure) and Maxim (for being the safety net and expert guru all at the same time). :D From: Discuss [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Bond, Steve (NIH/NHGRI) [F] Sent: Tuesday, December 05, 2017 1:38 PM To: Software Carpentry Discussion <[email protected]<mailto:[email protected]>> Subject: Re: [Discuss] Git and Github lesson (follow-up) Hi All, For a bit more context, we decided to strip the Dracula backdrop out of the git lesson completely to give our workshop participants another opportunity to write little scripts. The example we settled on was unit conversions (dollars-to-cents, minutes-to-hours, etc.). We also wanted to change the focus to the GitHub UI, because that is how the other instructors and I generally manage repositories on a day-to-day basis. It seemed weird to spend time showing students how to initialize a local repository and then turn around and say they probably won’t often do it that way. In practice, the reworked lessons have gone reasonably well. Depending on the class, though, it has gotten a bit sketchy when we move into collaboration and conflict resolution. In the lesson as currently written, students are asked to pair up and then create repositories that they then reciprocally share. Unfortunately, people tend to get confused about which repository they are modifying, which one is their own, and which is their partner’s. It might make more sense to have the instructor create a central repository that everyone clones and edits. Then we could create a conflict that affects everyone the same way. It’s been a while since our last workshop, so the material hasn’t been getting much attention. If there is sufficient interest from the community though, I’m happy to facilitate further refinements on my own fork or work with the core team on the main SWC version. Best, -Steve From: Anelda van der Walt <[email protected]<mailto:[email protected]>> Date: Tuesday, December 5, 2017 at 10:39 AM To: Software Carpentry Discussion <[email protected]<mailto:[email protected]>> Subject: [Discuss] Git and Github lesson (follow-up) Dear all, Back in July 2017 I started a conversation on the discuss list about alternative Git/Github lessons that exist in the Carpentry community [1]. So many of you responded with suggestions about how you have dropped the Dracula example or augmented it with episodes on things like Git GUI or Github and more. Thanks very much to everyone who responded. One of the first lessons I was pointed to, was Steve Bond's (copied on this email) lesson [2] which was originally forked from the SWC git novice lesson, but introduces Github and constantly show how to do things both in git and github. Last week we ran a workshop at NWU where we trialled Steve's lesson. I chose this lesson as it was mature enough to use off the shelf (Steve had put a lot of effort in to make sure the lesson is refined). Feedback from the workshop: * It was great to introduce the power of local repositories and connect that with online repositories and collaboration. * The lesson makes version control much more accessible even for learners who are not yet comfortable on the commandline. * The switching adds cognitive load but we went very slow and got good feedback. * I veered off the script to spend some time introducing all the things that can be clicked on in the Github interface and people found that very valuable, but I don't know how to incorporate this as an episode in the lesson making it practical? * We didn't get to the collaboration part even though we had time to spare as people's brains were fried by late Friday afternoon. We ended the workshop on a high. The lesson includes screenshots for every step of the way so I recommended people referred back to the lesson when they get to collaboration and conflict resolution. Afterwards a colleague did a short demo of how she uses Git from RStudio and another colleague showed the same for his text editor (Visual Studio Code [3] - available for Mac, Windows, Linux). This was really helpful to show people how they can use even better tools to be more efficient and adopt version control easier. I'm wondering if the community would like to try out Steve's lesson as alternative to Dracula and provide some feedback? Maybe this is a low hanging fruit waiting to be picked and solve some of our git teaching/learning problems? Steve already did most of the work... What do you think? Thanks, Anelda [1] http://lists.software-carpentry.org/pipermail/discuss/2017-July/005319.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.software-2Dcarpentry.org_pipermail_discuss_2017-2DJuly_005319.html&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=rD4OA1kkL0S4v1qYK9k-ja5g5j8GrEgKciJJhx3Vkj8&m=p7qQrGLTNvMswazA0VMvQ-rNOAKR4V7H6b7dkQlOCLg&s=R-qwCx8hDJgxUEMYg5KHVM3Rv6s0UOgzY9MQuudYiS0&e=> [2] https://github.com/biologyguy/git-novice<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_biologyguy_git-2Dnovice&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=rD4OA1kkL0S4v1qYK9k-ja5g5j8GrEgKciJJhx3Vkj8&m=p7qQrGLTNvMswazA0VMvQ-rNOAKR4V7H6b7dkQlOCLg&s=B3LbliHbOKBp4k1-MWrBa26QViHAlgZme2YBjHjt4pQ&e=> [3] https://code.visualstudio.com/docs/supporting/faq<https://urldefense.proofpoint.com/v2/url?u=https-3A__code.visualstudio.com_docs_supporting_faq&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=rD4OA1kkL0S4v1qYK9k-ja5g5j8GrEgKciJJhx3Vkj8&m=p7qQrGLTNvMswazA0VMvQ-rNOAKR4V7H6b7dkQlOCLg&s=hNtoHJBFVDwgL_JxvrLsvea1LkfbxPAdha5VSobiek0&e=> _______________________________________________ Discuss mailing list [email protected]<mailto:[email protected]> http://lists.software-carpentry.org/listinfo/discuss<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.software-2Dcarpentry.org_listinfo_discuss&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=rD4OA1kkL0S4v1qYK9k-ja5g5j8GrEgKciJJhx3Vkj8&m=p7qQrGLTNvMswazA0VMvQ-rNOAKR4V7H6b7dkQlOCLg&s=IGgiKVMUs1b75D_mOa2G_wfh6kWuTNschdUTkmpY4gs&e=> -- Christina Koch - Research Computing Facilitator, University of Wisconsin - Madison<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.wisc.edu_&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=rD4OA1kkL0S4v1qYK9k-ja5g5j8GrEgKciJJhx3Vkj8&m=p7qQrGLTNvMswazA0VMvQ-rNOAKR4V7H6b7dkQlOCLg&s=bmdp6Yj_wn8mZ7iegqvyjFEXqIFLh2H9RJZxo44-yRE&e=>, Center for High Throughput Computing<https://urldefense.proofpoint.com/v2/url?u=http-3A__chtc.cs.wisc.edu_&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=rD4OA1kkL0S4v1qYK9k-ja5g5j8GrEgKciJJhx3Vkj8&m=p7qQrGLTNvMswazA0VMvQ-rNOAKR4V7H6b7dkQlOCLg&s=lkFTiUTel3PUZ5gCknGPn0psDtPnKd7L7m9seEjE6QE&e=> Wisconsin Institute for Discovery<https://urldefense.proofpoint.com/v2/url?u=http-3A__wid.wisc.edu_&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=rD4OA1kkL0S4v1qYK9k-ja5g5j8GrEgKciJJhx3Vkj8&m=p7qQrGLTNvMswazA0VMvQ-rNOAKR4V7H6b7dkQlOCLg&s=o6UVqpxuRZ8OTnCt6FVmL_nbGa6VAG5OhyooRNGB5pQ&e=>; Advanced Computing Initiative<https://urldefense.proofpoint.com/v2/url?u=http-3A__aci.wisc.edu_&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=rD4OA1kkL0S4v1qYK9k-ja5g5j8GrEgKciJJhx3Vkj8&m=p7qQrGLTNvMswazA0VMvQ-rNOAKR4V7H6b7dkQlOCLg&s=4DvYt9sftiAB2HiH5qV1zDRj3GGEjjFbCfFXhuI-yxU&e=>; ACI-REF<https://urldefense.proofpoint.com/v2/url?u=https-3A__aciref.org_&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=rD4OA1kkL0S4v1qYK9k-ja5g5j8GrEgKciJJhx3Vkj8&m=p7qQrGLTNvMswazA0VMvQ-rNOAKR4V7H6b7dkQlOCLg&s=tgz_4HjUfwiXNgPaj-jCObQrrADaA41ZdLBwCaqH6rY&e=> email: [email protected]<mailto:[email protected]> // phone: (608) 316 - 4041 // calendar: tinyurl.com/ChristinaCHTC<https://urldefense.proofpoint.com/v2/url?u=http-3A__tinyurl.com_ChristinaCHTC&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=rD4OA1kkL0S4v1qYK9k-ja5g5j8GrEgKciJJhx3Vkj8&m=p7qQrGLTNvMswazA0VMvQ-rNOAKR4V7H6b7dkQlOCLg&s=2Rg1-5toqMInKwYkYuwnlV-Me4ROlWKtioLPioQfi_s&e=>
_______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/listinfo/discuss
