New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What constitutes a Library Carpentry workshop? #1

weaverbel opened this Issue May 17, 2018 · 10 comments


None yet
9 participants

weaverbel commented May 17, 2018

I would argue that to be badged Library Carpentry, a workshop must teach at least the following core lessons:

  • Data intro
  • OpenRefine
  • Shell

Workshop hosts could then pick and choose other modules from the Stable, Beta and Alpha lessons, e.g. SQL, Git, Webscraping, etc., to suit their audience.

What do other people think?

@weaverbel weaverbel added the question label May 17, 2018


This comment has been minimized.


libcce commented May 17, 2018

One other question to add is, how long should a workshop be? 1 or 2 days? I believe it should be 2 days based on my answers below.

Outside of the core lessons that Belinda has proposed, there is a tendency for instructors to add git to their workshops. With the recent Mozsprint, the community identified that the lesson should be restructured, to begin with, GitHub and then move to git on the command line. Also, there was a discussion of reworking the intro to data lesson. The regex episodes seem to be popular in that lesson. Also, tidy data and SQL seem to have strong showings, though I think SQL should remain optional.

Based on my experience so far, my vote would definitely be for shell and OpenRefine. We might want to look at reworking data intro but that should be included as well. Finally, I think git belongs in the core, but as a reworked lesson which begins with GitHub and then moves to git on the command line. I believe there are some key aspects of git (e.g. versioning, open research), that librarians need to learn to understand and participate in communities (for instance, LC even).


This comment has been minimized.


weaverbel commented May 17, 2018

I would say "at least one day, but preferably two" and also leave it open for hosts to work out whether they want to do single days, run training over half days, or whatever, given that it is often hard for librarians to get large, dedicated blocks of time off for training. But maybe anything shorter than two days could be more "based on Library Carpentry" than official Library Carpentry. Most of my workshops are single day but I do Data intro, including regex, OpenRefine, and Shell in that time.


This comment has been minimized.

jezcope commented May 17, 2018

I might be inclined to say e.g. "One of Shell or Python". But then I'm biased because if Shell is a required lesson then the workshop we did in Sheffield last year wouldn't have counted! 🙂

Maybe it would be "One of Shell, Python, SQL" or similar?


This comment has been minimized.

Kakaalikins commented May 17, 2018

I agree that it should be at least 1 full day, but preferably 2, if possible (and organisers decide whether it's two days in a row, or two days across a period of time).

My initial thought on syllabus was Data Intro, OpenRefine, Shell and Git (or at least an intro to Github). But from reading everybody's feedback, I definitely think it'll be useful to make Data Intro and OpenRefine compulsory, with a choice of the 3rd lesson being either Shell, Git, Python or SQL ?


This comment has been minimized.

pitviper6 commented May 17, 2018

I agree with the 'at least one, preferably two days' for workshops. Also, I think a reworked data intro (I'd add some tidy data into it), OR and then git or shell is a good core curriculum. I like the idea of Git/Github because that encourages contributions to lesson development!


This comment has been minimized.

vai2fc commented May 18, 2018

I'd like to underscore the importance of @weaverbel's point re: breaking up a Library Carpentry workshop over multiple days. Being explicit that official LC workshops can be offered as, say, a series of afternoon sessions may make it more feasible for (academic) librarians to participate, especially during academic terms. That said, it means having enough locally-certified instructors, so that's something to consider...

Re: curriculum, data intro/shell/OpenRefine seem like a solid core to me, but I wonder if different Library Carpentry levels/tracks can be defined? For example, we just taught a 2-day Library Carpentry at Vanderbilt, so in thinking about how to continue integrating Library Carpentry lessons into professional development, I wouldn't want to have to repeat three of the four lessons in order to then touch on webscraping.


This comment has been minimized.

gvwilson commented May 19, 2018

  1. I believe SWC and DC workshops are still required to be a total of two days; if so, I think we should require the same for LC.
  2. I will defer to librarians, but would SQL be more useful to most than the Unix shell?
  3. Would Git be taught from the command line (in which case, learners would need shell) or via a GUI (in which case, maybe they wouldn't)?

This comment has been minimized.

drjwbaker commented May 19, 2018

Whilst I believe in consistency between Carpentries, the challenge with 1. in this context is that many librarians (certainly in the UK) have line managers whom they have to ask permission to attend LC events. This means that for many librarians I speak to at LC events, they have found it hard to justify taking two consecutive days away from normal daily responsibilities (and have colleagues who couldn't attend because they couldn't get permission for that block of time), especially as Carpentries encourages cohorts from institutions to attend together. Carpentries has developed around researchers and researchers rarely - in my experience - work to a permissions based line management model. So, in this regard LC either needs to be flexible to meet the needs of the library community (which ranges from people who consider themselves researchers to those who would not) or needs to make a really strong pedagogical case for why two consecutive days is a Good Thing.


This comment has been minimized.

ldko commented May 22, 2018

I think it makes sense to have Data Intro and maybe Shell as core lessons for a LC workshop because they teach general skills and concepts that can be applied in many aspects of library work. They teach concepts that will facilitate teaching the other lessons in the LC suite as well. I don't see OpenRefine as broadly applicable, it teaches one program that does one thing really well, so I personally don't think it should be core. If core needs to be three specific things (does it?) I would probably see more general applicability in teaching GitHub (with optional Git portion if command line usage seems likely for the audience).

Additionally if someone was going to do a workshop that featured web scraping, it would make sense to do a python intro lesson first. In this case it would make sense to start with Data Intro and [maybe] shell, but certainly it would be extraneous to teach OpenRefine in this scenario, but in order to be an official LC lesson, you would have to teach it.

I think the greater flexibility in Library Carpentry workshops the better. I work with a lot of people in my library who have done one of our Software Carpentry workshops and are disappointed to learn that our next workshop will basically teach the same thing. Since the target audience for Library Carpentry is presumably smaller than that of Software Carpentry or Data Carpentry, allowing more flexibility in choosing lessons from the LC set would facilitate more repeat LC attendees from our library employees.

Overall, I like the idea of saying Data Intro [and maybe shell or another lesson] are required plus two more lessons from the list--or something like that.


This comment has been minimized.


libcce commented Jun 26, 2018

Thank you, everyone, for your feedback which was used to develop

@libcce libcce closed this Jun 26, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment