Systems Librarian Documentation
From July 2015 to July 2016 I worked as Data, Science, & Systems Librarian at Mount Allison University in Sackville, NB, Canada. The library consisted of 6 full-time tenured or tenure-track librarians including myself and about 15 full time or part time staff. The library is run by the University Librarian who sits in a Dean-level position. Due to the size of the library, everyone must work closely with everyone else and there are a lot of hybrid jobs. Mine consisted of three parts. Data: providing service to anyone looking for assistance finding or manipulating data, serving as contact for the Data Liberation Initiative (Statistics Canada's microdata & GIS repository), and managing the library's internal statistics such as reference desk stats and e-resource usage. Science: provide instruction and collections development to the faculty of science as well as keep faculty members apprised of library goings-on. Systems: maintaining and updating the library's self-hosted ILS, proxy, website, e-resources, and Worldcat, ensure interoperability thereof, be the first point of contact for patron or staff technical problems, and investigating a migration to a new ILS. I also did regular shifts at the reference desk and investigated Zotero as a tool for the library to support in lieu of Refworks.
When I arrived in this position my predecessor had retired a few months before. He had left me some electronic files and a Word document with some information on procedures in it as well as more than a few trees worth of paper files. There was a lot to learn and quickly. It took about three months to get most of the administrative accounts to various e-resources switched to my name and email address. I sorted most of the paper documents into keep, recycle, and shred piles. Many of the paper documents were fortunately duplicated digitally somewhere on the library's shared drive or were sufficiently out of date to toss safely.
The Data side of the job was new, with the Data Liberation Initiative (DLI) portion having been largely neglected and the reference statistics handled by the reference librarians as a group. Therefore there was no local documentation on handling either of these, although the DLI organization has an extensive website. I had just missed the local DLI workshop which is held annually and did not get to attend until the next May (at which point it was very helpful!). As the reference statistics had been kept by various people over the years they were not consistent and therefore were difficult to analyze in a systematic way.
Financial information about the science collections were available through the ILS going back to its inception (~10 years) but most procedures and policies were relayed to me verbally by the Head of Technical Services who also handled acquisitions. The Technical Services staff had their own internal documentation, but the librarians made purchasing decisions based in committee meetings. Meeting minutes existed going back a few years, but were sparse in terms of rationalization for decisions.
The Systems portion of the job was where most of the existing documentation applied. My predecessor had written out a MS Word document that contained a number of procedures that were run on the ILS at regular intervals (e.g. new patron upload) and some known problems. There was also some information about E-Resources, but much of it was out of date.
When it came to managing the ILS, which I had never seen on the back end before, I relied heavily on the vendor's support documentation and mailing lists. I worked with a 0.6 FTE systems administrator who dealt with many server issues as well as serving as point person for contact with the vendor's support team when they needed direct access to the server. As a result, he kept his own extensive documentation in a personal wiki he hosted on his own home server of his own initiative.
In order to ensure I remembered all these new procedures I wrote them out in text (.md) files and put them in a folder entitled various things at various times. When I was working on a problem I would go back to the text file and update it with the date to explain what I had done and what had worked or not worked. It was written in a narrative style with the intention that someone could read it later and follow my train of thought on a given project.
To keep track of support documents on the vendor's ILS support site I started saving them in Zotero, the citation management software. In addition to bookmarking the URL, this saves a "snapshot" (scraped webpage) of the site in case the URL breaks or changes. I would frequently end up consulting 3-4 pages to resolve a single ILS problem, so I was always referring back to these files.
For all the online administrative accounts I needed to have access to I started with a spreadsheet to find out what I had an didn't have and then moved to the KeePass password manager for daily use. While this required significant set-up time, it saved a lot of time day-to-day, improved overall security a small amount, and made it easier to hand over the keys to someone else.
During my day-to-day work I kept a paper notebook to write down to-dos, important information, people to contact, grocery lists, etc. I also kept a couple calendars in MS Outlook, one private and one shared. This was invaluable when writing up a final annual report and tracking what I spent the most time on. I also experimented with a time-tracking tool called Toggle, but didn't stick with it. I referred back to my notebook and calendar when making sure my documentation was complete and contained all of the significant problems I had worked on.
While I had been doing quite a bit of documentation as I worked for my own benefit, it needed to be cleaned up and made coherent to someone else. This took a considerable amount of time. I had already started on writing my required annual report by going through my calendar and notebooks to remind myself of what I had done, so this assisted with ensuring I had documented all the things I had done. I made sure that there was one text document with all the regular rote tasks required of the position, instructions for them, and how often they should be performed. Each other problem I had solved (e.g. changing the proxy's rate-limiting settings) had its own text document. I annotated my Zotero bookmarks using the Notes function to provide an explanation of what problem they provided a solution to and ensured they were titled properly. I also cross-referenced these support docs in Zotero with the text files that I had personally documented the problems in. I tested exporting those Zotero files to ensure they were all exported completely and included instructions for the new person on how to install Zotero, import the files, and then read and understand them.
To keep track of some valuable paper files I scanned them and put them in a shared folder. The useful files were collated and organized into folders, including those that had originally been in three-ring binders. Documents that were of a more general nature, such as purchase orders or database contracts were moved over to the filing cabinet of the administrative assistant for better future findability.
The admin accounts I had been collecting had to be all put in my coworker's names or moved to a generic library email address. For a lot of vendors, this requires emailing their support staff to have it done and was quite tedious and time-consuming. It had been a longer-term project of mine to move them all to a generic library account specifically for the purpose and this would have been unnecessary if I had actually done that from the beginning. The coworker who would be taking over the large part of my e-resources responsibilities was not interested in using KeePass so I exported the database as a CSV file once it was completely updated.
The final text document I produced was a guide to the documentation. All of these files were put onto the library's staff shared drive. It also contained the folder of documentation my predecessor had left for me. And so it goes.