Why librarians should care about Git?

[davanstrien]

As @drjwbaker has mentioned I think one of the things that could be 'bulked out' in this lesson is an explanation of why GitHub matters for librarians. I am happy to do a 'Why you should care about GitHub' section. I think the main things to focus on are:

• research data management - with all three considered broadly. Librarians are already and will increasingly contribute to this.
• collaboration - related to the above. Git can facilitate collaboration and open up new workflows in a bunch of ways.
• Publishing - also related to the above. GitHub offers a new way of 'publishing'. Librarians need to think about how to deal with this. Helping both the 'production' and 'consumption' side of things. citing code?
• a gateway to loads of tools, resources and support. A huge amount of open source software is on GitHub if librarians want to use this software it is helpful if they know how to interact with Git.

Are there other things that could be included?

[drjwbaker]

Also, Git is a thing that IT professionals/developers with whom lots of librarians collaboration use all the time. So there is some dewizardification underpinning the rationale for this lesson.

[davanstrien]

👍

[weaverbel]

@davanstrien @drjwbaker Another thing we could sell it as is a repository system for librarians who want to share work. Loads of librarians are developing data management advice, for example, or library guides - this could be a way of sharing basic text.

[weaverbel]

It would be good to give them a demo of a Jekyll blog so they can see how it looks - also @drjwbaker has written a quick guide to getting a Jekyll blog using Jekyll Now https://github.com/LibraryCarpentry/librarycarpentry.github.io - is that still current, James?
6/6 (I was wrong - this is just a fork from https://github.com/barryclark/jekyll-now - sorry to originator for attributing work to James by mistake.)

[njsimons]

Some good points have already been made. Maybe also relevant for librarians: Git creates a backup system and structured documentation; Git can be an archival tool (of sorts).

[jezcope]

+1 to @njsimons comment about version tracking — I use it even for solo projects so that I can go back and find out where I messed up...

Also useful for controlled syncronisation between more than one computer (e.g. desktop & laptop for working from home etc.).

[drjwbaker]

@weaverbel On #7 (comment) I didn't write the Jekyll Now guide, that is just forked from https://github.com/barryclark/jekyll-now as part of the process of standing up the libcarp pages

[weaverbel]

@drjwbaker Sorry- my bad. Have updated my comment. But it's still a good thing to use?

[drjwbaker]

@weaverbel Sure! (it helped me learn what to do!)

[davanstrien]

Sorry I've been so slow with this (I think I missed the sprint part). I have been busy but will make a pull request addressing this this evening.

[weaverbel]

@davanstrien @drjwbaker @ccronje I have added a tiny bit of info here https://github.com/data-lessons/library-git/blob/gh-pages/_episodes/06-git-in-libraries.md just to get the ball rolling. Please feel free to edit it by adding all the good ideas listed above.

[weaverbel]

I think it might be good to use GitHub Pages as a way of showing librarians the benefit of Git. Librarians often want to publish info but don't have outlets. A Jekyll blog would be one way but GitHub Pages is something they could show to others as well as use themselves.

[evanwill]

I think it's important to highlight why Git and why GitHub separately.

Git = distributed version control: powerful history (history is never overwritten or deleted, every change linked to person), branching / merging, working in parallel, fearlessly experimenting with things

GitHub = git repo hosting: collaboration, project management, simple web publishing, history visualization, handy web interface

[drjwbaker]

Good point. We shouldn't lose sight of that. Pinging @ndalyrose and @alexandermendes who'll be looking at the lesson more tomorrow (UK time).

[yasmina85]

Having a website for your projects is really important, so an example of GIT pages can be used to show librarians one thing that can interest them. Furthermore, it is not only about generating a page that can be published, it is how easy this can be done with learning Web development.

[evanwill]

Here are a few articles I refer people to for the Why questions:

• Kris Shaffer, "Push, Pull, Fork: GitHub for Academics", Digital Pedagogy Lab (2013).
• Alexey Zagalsky, "Why you should use GitHub: Lessons for the classroom and newsroom", Storybench (2015).
• Daniel van Strien, "An Introduction to Version Control Using GitHub Desktop", Programming Historian (2016).

[evanwill]

Another area of interest to librarians is developing and publishing OER / open text books. For example:

• Kris Shaffer, Open Music Theory (textbook developed / hosted on GitHub, repo)
• Shawn Graham, Crafting Digital History (course website, textbook, class collaboration on GitHub)

[gillianelliot]

Bit radical and probably way off beam (I'm a total novice), but would there be a stronger case for a unit on GitHub i.e. "git repo hosting: collaboration, project management, simple web publishing, history visualization, handy web interface" rather than Git which is so complicated and a much harder sell.

[drjwbaker]

So @mkuzak and I just had this conversation. I think starting with Github has value. But Git remains the underlying open source software tool, whilst Github is a for-profit company. So we need to do two things: 1) - per @evanwill - seperate out Git and Github, and 2) make sure the Git workflow is clear to learners. I don't think the Github interface is the best was of teaching 2).

[evanwill]

It starts to become a LOT to fit into the lesson (and retain). It looks like the outline currently gives 3 hours? Are we assuming they already have a basic shell lesson?

I usually teach Git and GH-pages in separate workshops of about 1.5 hours each (get-git and go-go-gh-pages). I taught the two together once in about 2.5 hour session. We covered the basic git workflow (clone, add, commit, push, skipping git history), and then reinforced it by creating a couple test GH-pages repositories (one with basic HTML, one with basic Jekyll). It is a lot of content, but I do think it's a good way to get people practicing command line and git, while learning the basics of Markdown and HTML, while creating some concrete outcome (a website).

[alexandermendes]

I was starting to think myself that it does indeed become a lot to squeeze in.

Sure, using GitHub Pages with Jekyll makes it pretty easy to get a basic page up, but it's not nothing. Then as soon as people want more than a single page of text we have to deal with the templating language, configuration files, styles and so on. Perhaps we can have an episode right at the end and if people get that far we can show the potential to setup a basic page.

I also think that it's important to separate git and GitHub. We can demonstrate how to set up a git repo, add, remove, branch, etc. before GitHub even comes into it (sharing the code, project management etc.). The web interface really seems a lot more confusing to me than just running a few shell commands (and probably more of a pain to guide people through in the lessons).

[evanwill]

Sorry, one more thought about Why:

I think people get the Why better with lots of examples.

I always highlight the Carpentries sites (collaboratively developing teaching materials and publishing on GitHub), open text books (easy to share, modify, publish), or Programming Historian (open peer review, project management via Issues, published on gh-pages) in addition to some relevant academic project with code.

The openness, the ability to share, modify, and preserve, should be important to librarians (and academics in general).

Then contrast Git with version control that people already do, goofy file names, Word's track changes--and realize how complicated and ineffective those options are. It brings up a lot of issues about the typical academic writing workflow using expensive proprietary tools. Word documents aren't a good tool, and are only said to be "simple" because people are so familiar with them.

[evanwill]

@alexandermendes actually I typically skip a git init type example, and start with GitHub > create a repository with README > git clone.

Realistically, a basic user will be using git clone or fetch/pull, and never do git init except in an intro lesson. Because episode 2 currently uses init, episode 3 introduces the use of git remote--which seems more complicated than necessary, since the basic user just clones and doesn't need to set remotes manually.

but this is getting off the issue topic of Why, so maybe we should start some other threads with lesson specifics?

[alexandermendes]

@evanwill Ok, all good points, thanks. I think we'll probably just entirely rewrite these today, so it would be good to see what everyone thinks in a few hours. And yes to the new issues, I'll add a few soon.

*Edit: Of course, when I say entirely rewrite we'll still use chunks of the work already done! I think there's just a lot of reorganising to do.

[ndalyrose]

@alexandermendes @evanwill Sounds good! My goal today is to revise http://data-lessons.github.io/library-git/01-what-is-git/ to reflect the Why and What For more clearly and upfront, awesome examples @evanwill super useful.

[evanwill]

Some more thoughts about Why librarians should care about git, hopefully to help think about what needs to be focused on in the lesson:

I am a librarian and use git and github every day:

• project management and version control for web development projects, for example developing digital collections, or getting code repositories for Primo customization from ExLibris or other libraries working on the same interface.
• organizing and sharing digital projects (e.g. poemBot) to document and publish so that others can use them
• creating open educational resources that are easy to share and adapt (e.g. an open text book, IBMT)
• new means of open publication and peer review, e.g. Programming Historian
• supporting open science workflows (transparently, authenticity, documentation, reproducibility)

Furthermore, it's a great skill for librarians to teach in library workshops since nearly all students encounter code, digital projects, or web pages during their career, but few receive training in basic computing skills and development tools. The library is an interdisciplinary space to teach these sorts of things that isn't constrained by the disciplinary curriculum--it's an extension of our traditional of literacy outreach to the digital realm. Teaching git is a great opportunity to expose students to a variety of concepts that improve digital literacy and support research: version control, command line basics, why we use plain text, free and open source, collaboration and project management. This use-case is much more SWC like--but I think SWC is focused on their complete 2 day workshop concept. I am imagining this aspect of library-git as more train-the-trainer, communicating to librarians about why github is such a powerful concept with a lot of potential and how they could present it to their patrons. I think librarians are more interested in the idealistic aspects (openness, transparency, access) than the average SWC crowd.

I regularly teach Git and gh-pages at library workshops and to grad student groups (e.g. Git for Collaboration Intro. I am always surprised at basic misconceptions, such as people doing very advanced modeling in R not realizing they are just writing plain text files, or people not realizing all websites are just plain text and can be easily modified by them. Git seems to help make these basic digital literacies more clear and concrete, despite the struggles actually understanding version control!

[evanwill]

@sharilaster brought up another good point for the Why discussion in PR #54:

So much of the usefulness of Git & GitHub for library work extends to any kind of role in the library. By decreasing the emphasis on the professional title "librarian" and increasing focus on the work that you can accomplish with these tools, this lesson is friendlier to any participants, not just those with an MLS degree or who have "professional" positions.

[drjwbaker]

Furthermore, it's a great skill for librarians to teach in library workshops since nearly all students encounter code, digital projects, or web pages during their career, but few receive training in basic computing skills and development tools. The library is an interdisciplinary space to teach these sorts of things that isn't constrained by the disciplinary curriculum--it's an extension of our traditional of literacy outreach to the digital realm.

@evanwill: small thing on this. Our lessons have - thus far - avoided being pitched at librarians who teach academics/students because this isn't the function of all university/academic (our main focus) libraries or librarians. We have tried to pitch LC as - first and foremost - offering skills librarians can use in their work, with supporting the work of others as a secondary consideration.

[evanwill]

@drjwbaker i certainly wasn't claiming completeness in my comments, just trying to provide diverse relevant examples that might get library folks excited.

There isn't any universal librarian duties. There are many librarians who do have teaching, digital literacy outreach, research support, emerging technology, open data, subject liaison, etc etc as part of their duties, it is their work. We bring the concept of version control and collaborative workflows to our patrons, or as you mentioned above, need to understand it to better communicate with researchers or developers.

[katrinleinweber]

@evanwill Thanks for the link list!

Because I saw several Carpentries discussions about the pros and cons of focussing on Git's CLI over GitHub Desktop already, I thought a little info graphic was in order: http://slides.com/katrinleinweber/deck. It shows which GUI portion of GHD maps to which Carpentry-taught command. Maybe it's useful for referring learners onwards, after a git lesson.

[VickyRampin]

Hi all -- was this issue ever resolved? If not I can gladly make a PR for the mozsprint today adding the rich info from the above discussion to the lesson.