Details and discussion at LibraryCarpentry/librarycarpentry.github.io#25

The website is at http://librarycarpentry.github.io — see mozsprint-tagged issues for more details

Ensure readme files consistent and do not contain extraneous information (for example, references to too much LC history!)

The web scraping lesson https://github.com/data-lessons/library-webscraping was initially developed by @timtomch

The contents of @timtomch's lesson has been copied to this repository to be reviewed and amended before it is ready for publication as part of the library carpentry materials.

Use https://github.com/data-lessons/library-webscraping/issues for issues to be worked on during the sprint

Plenty of issues, big and small, to get your teeth stuck into over at data-lessons/library-openrefine.

moved here because it makes more sense!

I like the idea of creating (say) an annual release of Library Carpentry, with a DOI, et cetera. And I've used the Zenodo-Github link to do this with projects in the past. Looking at my Zenodo account, I making a release for each lesson so this is possible, though I'd rather do a big bundle per Programming Historian https://zenodo.org/record/30935#.V8VN9I78_6h. Does anyone have any thoughts on this? What I guess I'm proposing is that we do a "version x" release of all the Github repos combined (in some way..) on a semi-regular basis. This will need to be managed to ensure: 1) it is done at the regular intervals 2) everyone involved in credited correctly 3) the metadata is put somewhere public for reference.

cc @jt14den

I have had a request for a workshop in Italy. It will be in English with Italian helpers. The organisers are requesting that we get detailed and stable handout materials together so they can translate them for workshop.

We've already had LC taught in Norwegian (hi @danmichaelo!) but I don't think translating everything into lots of languages will scale without massive investment in people, money, time, and workflows.

Nevertheless - as many of your know - I think supporting learners who don't work in English is a priority for LC. Language distinguishes us from the other Carpentries. This is because whilst the language of science/research is (mostly) English the language of librarianship is not English.

Getting our handouts right seems like a good way first step towards supporting learners who don't work in English with the resources we have. This is because handouts are quicker and easier for workshop hosts to translate than whole lessons, meaning that learners can have a handout in their own language to support their learning during even a modestly funded English language workshop (this does of course require that their English is pretty good, but I think there is more than a gesture).

We have a workflow for managing handouts at #30. What I propose is that as part of this we have a conversation about building workflows:

1. for workshop hosts who want to translate handouts to languages other than English.
2. for lesson maintainers so that they can timestamp and archive translated handouts.
3. for workshop hosts so they can find the archive of translated handouts and adapt them to reflect the latest updates to lesson.

To do this right we need to reach more librarians outside of our English language bubble (note that the places outside the Anglosphere in which we've made gains have been places where English is common in Higher Education: the Netherlands, Norway, Denmark).

Who is willing to help facilitate this?

Further details and discussion over at LibraryCarpentry/library-python#38

Let's see what exists as sql courses.

you may check sololearn course on SQL, I got my basics there.
@rissom talked about https://sqlzoo.net

(#mozsprint, please label it dear admin)

Forking from #48 we need a catchup.

Possible Agenda

• saying hi and stuff
• @richyvk's awesome website work #49
• update from @chodacki on LC related bid success
• pre-chat about our place in the SWC/LC merger #48 (comment)
• tentative hands up to be on steering committee for us to become a 'Lesson Organisation' under The Carpentries umbrella (to be in place by January)

Date
I propose sometime between 20 September and 29 September.

People
From: @weaverbel @richyvk @tracykteal @gvwilson @ndalyrose @jt14den @chodacki @tracykteal @mkuzak @pitviper6

Should we think about customising these to be more applicable to library & information professionals?

As we set out a pathway towards consolidating Library Carpentry whilst protecting the 'Carpentry' brand and not diverting time/funds from SWC/DC, we need to figure out how to manage library software skills training requests for workshops that either come via SWC/DC or from our contacts (so, via established Carpentry and from outside of Carpentry).

A starting point is to have regional contact points for this. I'll put my hand up for Europe for now. Who is willing and able to take other regions into which we have existing reach? cc @pitviper6 @weaverbel @anelda :)

EUROPE: @drjwbaker
NORTH AMERICA: @pitviper6
AUSTRALIA: @weaverbel
SOUTH AFRICA: @ivdwalt & @erikamias

Next we need an outline workflow for how we handle requests, with an eye on both not burdening SWC/LC and not getting too procedural too soon. Something light like:

• For Requests that come through SWC/DC: normal SWC/DC process; LC contact looped in; LC contact fields questions/queries from requester about LC modules; requester tells SWC/DC about what modules they want; workshop agreed with SWC/DC in normal way; if LC content used, LC contact seeks/suggests instructor from LC community who may be able to join the workshop (but there is nothing saying that they have to!).
• For Requests that came to LC: request forwarded to LC contact; LC contact finds out what they want/what funds they have and either a) seeks/suggests instructor from LC community who may be able to join the workshop (may be self!) or b) steers workshop towards standard SWC/DC request process above; if a) SWC/DC made aware of workshop, SWC/DC suggests instructor if/as appropriate, workshop logged.

Discuss..

see http://pad.software-carpentry.org/library-carpentry for more info.

At present, who names of Maintainers and Contributors are not listed with the lesson. I propose we put the former on the lesson front pages (eg http://data-lessons.github.io/library-data-intro/) and the latter on the lesson readmes (eg https://github.com/data-lessons/library-data-intro/blob/gh-pages/README.md)

I'm happy to take on this work. Do we have quora?

cc @mkuzak

I would like to see instructor guides developed for all Library Carpentry lessons. This could be a good sprint project. Librarians will probably like to have some guidance on how to teach what for many will be new material. Not sure what instructor guides should consist of? Then see some of the guides for Software Carpentry lessons, e.g. shell - http://swcarpentry.github.io/shell-novice/guide/, python - http://swcarpentry.github.io/python-novice-inflammation/guide/.

Guides like this help with context setting, things to remember to explain, and other useful info.

This issue follows on from discussion at data-lessons/library-openrefine-DEPRECATED#42. All LC lessons are affected. Can @cmacdonell or someone please advise on how best to resolve across lessons? We would like the Setup menu item to be rendered as shown here http://swcarpentry.github.io/lesson-example/.

Following comments at Portland Instructor Training, ensure that all LC lessons have learning outcomes that fit Bloom's Taxonomy http://swcarpentry.github.io/instructor-training/19-lessons/

1. Review
2. Edit
3. Create issues on lessons if edits not appropriate (for example, lessons under development)

Alan Danskin has contacted me with a list of use cases for XSLT that could form the basis for a lesson around transforming XML documents into other documents. The purpose of this issue is to share these use cases (with Alan's permission) and to open a discussion about whether this is something that we want to pursue, perhaps in partnership with Data Carpentry.

Please use Issues to raise questions, report problems and other things for discussion during the sprint. Be sure to label your issue mozsprint so we can find these easily.

@ndalyrose and @alexandermendes are going to work through, revise, and improve the Git lesson tomorrow (British Library, UK site). Refer to data-lessons/library-git-DEPRECATED#7 during the work.

We need to revert this repo back to our meta LC repo for lesson development et al. Thought on timescales and tasks? I'm feeling we need to align with #22 as the readme here should list lessons, their status, et cetera.

Suggestion for a #TODO:
Turn the material on
https://guides.github.com/activities/citable-code/
into a module for library carpentry.

There are currently two lessons in an "incubator" phase:

• library-webscraping
• library-spreadsheets

They both need further development as well as being taught some more so they can be refined. We also need to make sure they are flagged up better on the website as needing further development.

I want to be able to assign issues to people but I need to add them to the team here to do that and I can't unless I'm an 'organisation owner'. @weaverbel?

This is an issue for people who are interested in developing, contributing to, teaching or following the development of Library Carpentry workshop materials. We'll provide updates here on opportunities to be involved and progress.

So, if you are interested in Library Carpentry, please subscribe to this repository, or comment on this issue and you will get notifications of activity.

There will also be other issues on content development or specific events, but the idea is that communication will be coordinated in this repository, so we can keep track of everything that's going on and people globally can be involved in the conversation.

It would be good to have an easy way for the community to include more examples/use cases in each lesson without impacting on the lesson's core worked examples and length/time concerns. The discussion that sparked this issue: #31.

One solution might be creating a markdown file in each lesson where we can keep adding 'recipes', like this https://github.com/OpenRefine/OpenRefine/wiki/Recipes.

The 2016 workshop call closes 16 December http://librarycarpentry.github.io/workshop-call/ We need a group of people who can agree to read through these and together make a decision by the new year. Say ay below if you can help!

Following on from @tracykteal #6 (comment)

To consider:

• Software Carpentry has been coordinating Library focused Software Carpentry events, that I think have even been called Library Carpentry. Do you want this to continue?
• If and what support and relationship does LC want from SWC/DC in terms of instructors, templating and such?
• What rules do we want around workshops that use both LC and SWC/DC materials? (given that the latter require at least one SWC/DC qualified instructor)

cc @tracykteal @pitviper6 @weaverbel

Details and discussion at LibraryCarpentry/librarycarpentry.github.io#26

Referring to data-lessons/library-openrefine-DEPRECATED#60 (comment) ensure that:

1. There is a place for handouts in each lesson repo
2. There is a place for handouts on each lesson website
3. There is a suggested workflow for converting .md to presentations formats so that instructors can print handouts with ease. Recommend both programmatic workflow (eg Pandoc) and GUI/web-based (eg http://dillinger.io/)

We need to create some scenarios and use cases for the shell lesson, and this could be a good sprint task.

We have counting and mining data, we have grep to find info within files, and basic shell navigation. Should we do a FOR loop? And what else? At my workshop today, people wanted specific tasks the shell can do for librarians. It would be good to create a list.

The amazing @richyvk has done a fabulous job with the website redesign http://www.richyvk.me/library-carpentry-redesign/ so let's start to move on this. Issues should be raised here.

Repo view is here: https://github.com/richyvk/library-carpentry-redesign if people want to fork and do some pull requests.

I think it is pretty nice. We do have to think about reskinning the blog to match though.

In each individual lesson I have noticed issues with the setup instructions. It seems unclear if each lesson should explain the complete set up process, or just the specific tool being introduced. For example, should the Git lesson explain how to install Git, set up the terminal, and get a decent text editor, or will participants have that already?

SWC has a centralized initial set up as part of the main workshop page, then each lesson has a very basic set up page since everything is already installed.

The biggest barrier is making sure Windows machines are set up correctly to use the terminal. In the past this relied on Git Bash (part of Git-for-Windows), plus a SWC windows-installer that added Nano editor, Make, and SQLite to Git Bash. However, the installer is out-of-date and Nano no longer works on current versions of Git Bash. Thus we need some workaround if a lesson assumes the use of Nano.

So I guess my question will there be a central Lib Carpentry setup where we say get a text editor, get a terminal set up, etc? Or do we have to add all the necessities to each lesson so they can stand more independently?

http://jekyllrb.com/docs/continuous-integration/travis-ci/ I am happy to implement but will require lesson repo admins to have Travis accounts and enable etc

This week Github announced the ability to add topics to repositories so it's worth looking at what topics we ought to add to ours.

Software Carpentry are also discussing this so we should probably attempt some kind of consistency carpentries/styles#130

It would be helpful to pin this repository for the org so it is easy to find and use as a "metarepository" for on going discussion and development documents (i.e. like SWC org page).

We have a new logo! (vector file, pdf)

I'll start integrating these next week around the lessons and sites next week.

Credit to Tammy Nguyen for her AWESOME work (and to Alix Keener for bringing us and Tammy together!)

Two sprints in, and with a growing community worldwide, I think it is time to think about our future direction.

In order to grow, and to meet the needs of new people who want to get involved, we need some mechanisms in place to handle enquiries and deal with requests for workshops - and possibly - engage with funders. We also need some ground rules about what kind of community we are, how we skill up our people, what we teach, and how we conduct ourselves.

To some extent, we have piggybacked on the Carpentries up till now - adapting some of their material, getting a cohort of librarians trained as instructors through their training program, following their code of conduct, and using infrastructure like workshop templates to advertise workshops or their AMY system to record them.

But we cannot and should not do this indefinitely - we would be like twenty-somethings still living in our parents’ home - using the family car, hogging the wifi - but not necessarily contributing back.

So the time has come to take stock and think about whether we aim to become a full-fledged 'Carpentry' or whether we go off in some other direction.

In my opinion, the status quo cannot hold. It worked for us between the 2016 sprint and now, but the massive explosion of interest since 2016, the quintupling of involvement between the 2016 and 2017 sprints, and the growth of new communities eager to teach the skills means we need something more.

There is a lot to manage. Already I am overwhelmed by the workload of handling enquiries, requests to teach, and so on. It may not be quite so much work for other people but it has become completely untenable for me: demand in the southern hemisphere is seemingly bottomless. I have just posted eight more workshops and am juggling requests for another five or six – when I already have a very busy day job!

But equally there are library and archivist organisations out there who want to get on board so we need to have some kind of official structure they can engage with and possibly fund. Money - lots of money - to spread these skills could be potentially on the table in the US, Canada, the Netherlands - it is already being provided in Australia, New Zealand and South Africa. That kind of interest and demand needs to be managed.

What I do in managing and teaching workshops, time-consuming as it is, is probably inefficient - wrangling via email is a silly way to work - things can so easily fall through the cracks, and one person teaching doesn't scale.

The systems Software and Data Carpentry have in place - which some people have tagged as bureaucratic or unacceptable overhead - are actually enablers: there are clear pathways to request workshops, to request instructor training, to debrief after a workshop or get guidance before. These systems actually facilitate involvement, whereas our ad hoc structure does not.

Because we don't have structure, it doesn't mean we don't have 'overhead' – we do, but it is largely hidden. I know because I handle a huge swathe of it (as do others).

I for one cannot continue to do so in an ad hoc way.

So do we join with Software and Data Carpentry or strike out on our own? Software and Data Carpentry have already decided two systems are untenable and are planning to merge into one organisation. I don't think we should build our own instructor training system, our own workshop systems, when such proven systems already exist.

We need a structure and a system of governance that assigns responsibilities but that also opens up pathways for people to play a role. Ad hoc structures - what we have now - don't allow people to do that. They are actual barriers because no--one is sure who is authorised to do what or how they might take the initiative.

At the very least we need to decide:

• Who is a Library Carpentry instructor?
• What do we teach? Do we mandate a core, or let people pick and mix?
• What is a Library Carpentry workshop, and what is a local adaptation? And is that fine? Or not?
• How do we train new people in our teaching and workshop methods?
• How do we accurately record all the workshops we teach and provide a mechanism for people to do that themselves?
• How do we create local structures people can join, e.g. local chapters?

I would suggest we need at least some kind of interim Steering Committee to manage discussion about these areas. Having advisors from the library and archives world would also be great.

Who is on a committee, how it would work - these issues can all be discussed openly.

This document aims to open that discussion. This initiative arises out of a community call last Friday night, notes of which can be found here.

We did have a couple of discussion threads here and here about all this after the success of the 2016 sprint. People should go back to those and read through the issues raised, but I thought it was important to start a new thread in case new people prefer to come to these issues anew.

Please have your say! Building Library Carpentry has been a strong community effort. We would like its future direction to be decided by its community.

Over to you.

Library Carpentry - state of play October 2016

This document is an attempt to define/agree what we consider to the be the core principles of Library Carpentry. It is written in the context of the (very exciting) expansion in recent months of Library Carpentry in terms of what it is offering, where it is being offered, and who is being offered.

What is Library Carpentry?

Library Carpentry is software skills training aimed at the needs and requirements of library professionals. Training takes places in face-to-face workshops where one or more of the developed modules are taught. Modules are also made available online (CC BY, published via GitHub Pages) for self-directed study or for adaption and reuse by library professionals.

Library Carpentry is in the commons and for the commons. It is not tied to any institution or person.

What is a workshop

A Library Carpentry workshop comprises one or more half-day, face-to-face sessions where one or more of the currently developed modules are taught. Ideally, 4 modules (e.g, Data Intro, Shell, Git, OpenRefine) will be taught in a workshop across four half-day sessions, but this is not mandatory. Organisers may prefer to teach the workshop over two or more days. While the original material is key, organisers may choose to swap in the SQL module to replace one of the core lessons, or teach it in addition. Workshops are interactive. Ideally attendees will bring their own laptop to workshop so that skills learnt can be replicated outside of the workshop without the need for additional setup.

Workshops are run by a team. Ideally this will consist of:

• a Host (who is the principal local contact for the workshop)
• Instructors (who present the tutorials and lead the practical exercises)
• a Lead Instructor (who is in charge of deciding what will be taught by whom and ensuring the teaching aspects of the workshop go smoothly)
• Helpers (who provide assistance during practical sessions). Workshops can be any size.

To maintain the quality of Library Carpentry workshops, it is highly recommend that a Software/Data Carpentry certified instructor is present at each workshop. For more on Software/Date Carpentry instructors and instructor training, see http://software-carpentry.org/join/.

What is a module

A Library Carpentry module is a set of training materials that can be used either to run a half-day, face-to-face training session or as self-directed learning. Each module comprises 3-4 sections, is interactive, works across Windows, OS X, and Linux operating systems (with all setup instructions included) and has a combination of follow-my-leader sections and exercises (and additional exercises) that map to library practice. Modules introduce software and concepts relevant to librarians and have a preference for open source and widely used software. Data used in exercises is library-related, e.g. bibliographic data.

Who is an instructor

A Library Carpentry instructor is anyone willing to lead a Library Carpentry workshop. There are at present no prerequisites or training required to run a workshop. Going forward we will continue to evaluate this, mindful of the success of the Software Carpentry Instructor Training approach and with the ambition for the lead instructor of every Library Carpentry workshop to have undergone Software Carpentry Instructor Training

How Library Carpentry is managed

Library Carpentry was developed and is maintained by volunteers. There is no central organisation or command structure, and all activity is - at present - voluntary. Management and maintenance are distributed. Each module is 'owned' by one of more individuals responsible for coordinating maintenance of that module. Changes to lessons are managed using the GitHub Issue tracker. Announcements and initial discussion take place on Gitter. New members are welcome to join this community.

The @LibCarpentry twitter is now live - thanks to John Chodacki.

Please follow and also tweet the news.

John has emailed me the password for the account - please either email me or John to get the password or just ping me in the chatroom to send it. I am weaverbel AT gmail.com. I'll leave it up to John to put his email on here.

The links in the README link to old (deprecated) locations and should probably be updated to the repos of active development. e.g. replace

https://github.com/data-lessons/library-data-intro-DEPRECATED

with

https://github.com/LibraryCarpentry/lc-data-intro

During our call (see http://pad.software-carpentry.org/library-carpentry for more info) the idea of having a set of principles for LC instructors came up (thanks @Repositorian for the idea, seconded by @ostephens). Although the pathway for LC is for having an SWC/DC approved instructor at every workshop, this could be off-putting in the short term. So, in the meantime, a set of principles seem like a good idea. Comments on the words after the break please!

The Library Carpentry community have established a set of principles that we ask every instructor to agree to if they are running a workshop under the Library Carpentry moniker. These are:

• I agree that to use one or more of the Library Carpentry modules in my Library Carpentry workshops.
• I understand that the secondary learning outcomes of Library Carpentry workshops are as important as their stated goals. These include (but are not excluded to) learners a) being introduced to the value of non-proprietary file formats, good data management, peer-to-peer learning, not always using GUIs, computational approaches to working with library data; and b) feeling more confident to admit what they don't know, collaborate with developers, pursue further self-directed learning.
• I agree to support and encourage learners and I endeavour to ensure that attendees have an enjoyable and fulfilling experience.
• I agree to honour the Software Carpentry code of conduct.
• I am aware that as Library Carpentry grows, it has an ambition for the lead instructor of every Library Carpentry workshop to have undergone Software/Data Carpentry instructor training. I am aware that by becoming a Software/Data Carpentry approved instructor I can help grow and enrich the Library Carpentry community. Having therefore been a instructor at a Library Carpentry workshop, I agree to consider becoming a Software/Data Carpentry approved Instructor.

To indicate that you agree to these principles, please add you name and GitHub user-ID to DOCUMENT WE NEED TO MAKE by making a pull request.

Simple action (also review all readmes for consistency whilst there).

At a recent Australasia preserves workshop (blog post, meeting notes), the idea was floated for some kind of digital preservation carpentry lesson or teaching material. It is not much more than an idea at this stage, but I would like to see a discussion on whether this is feasible and where it would fit? Would it make sense to be part of the archive carpentry lesson, or is it more stand alone?

Topics that could be covered in a lesson would include a general introduction as well as hands-on activities with open source tools creating checksums and fixity checking, file format identification, working with disk images etc.