 |
 |
I've been at the same organization for a long time and also have a sprawling list of applications, scripts, workflows, etc. necessary for my work and supporting others at the library. I've also inherited the typical, terrible situations where there's no documentation nor inventory of systems in use. What I try to do is: - put all non-trival code (anything more than a few shell commands) under distributed version control - always have a readme - always have setup, usage, and license sections in the readme - high-level, less technical workflow documentation resides in a wiki and links to relevant code and admin interfaces, etc. - we only recently got a password manager where we can share credentials (hurrah!) We also have various spreadsheets of applications tied to different functional concerns, like maintenance, authentication/security, data protection. Many of these are collaborations outside the library. I have a wiki page on my scheduled tasks, too—workflows I perform every month, semester, year, etc.—which I find is often overlooked in documentation, or isn't centralized in one place. *A lot* (all?) of the documentation I write is talking to myself because I'm a solo systems librarian at a small institution. But, for one, I frequently find it useful because library processes are full of eccentricities and it hopefully reduces our bus factor. I know some larger library dev teams have great, version-controlled documents for onboarding or processes (thinking of Princeton <https://github.com/pulibrary/pul-it-handbook> and Stanford <https://github.com/sul-dlss/DeveloperPlaybook> specifically) which is what I aspire to. This response doesn't do a great job of addressing apps/tools used by other teams. In some situations, you kind of have to trust them to be documenting on their own, it seems like it would be challenging for one person/team to be fully responsible for another's documentation. Best, Eric Phetteplace Systems Librarian California College of the Arts libraries.cca.edu On Tue, Nov 28, 2023 at 9:15 AM Margaret Alexander <[log in to unmask]> wrote: > I completely agree. One of our developers took another job 4 years ago, > and we are still finding little apps and dependencies that we know nothing > about but are still in use. Not to mention the ones that are NOT still in > use, but are still squirreled away on servers, and we have to figure out > who might have been using them to decide if they need to be migrated when > the server is upgraded, etc. > Which is to say, I don't have a solution, but am determined to get our > knowledge documented, and I'd love to hear what others are doing, too. > Best, > Margaret Alexander > Core Systems Librarian > University of Oregon Libraries > > -----Original Message----- > From: Code for Libraries <[log in to unmask]> On Behalf Of Hammer, > Erich F > Sent: Tuesday, November 28, 2023 8:14 AM > To: [log in to unmask] > Subject: [CODE4LIB] How does your library manage internal utilities > metadata? > > Between administrative interfaces for internal and third-party Library > service applications, IT/networking services, support services, etc., I > have around 3 dozen bookmarks just to (barely) manage my responsibilities. > That doesn't include the various forms for requesting other people do other > things with their tools/utilities. The other departments like Access > Services, Reference, Archives, Purchasing, HR etc. have their own utilities > and services for their needs, and I've been wondering if anyone is actually > keeping track of all of these internal needs in case someone else suddenly > needs to take over any particular job. Because of reduced staffing, there > is almost no redundancy, thus, I know unquestionably that should I get hit > by the Lotto bus, there are lesser-used-but-still-vital systems/services > that nobody else knows how to access. They might know of them and are > probably smart enough to figure out at least some basics if plopped in > front of them, but how to get to them has limited/no documentation. > > I've been thinking that our fundamental function is keeping track of > information, so shouldn't the Library also *collectively* keep track of all > the tools/utilities necessary to keep the library functioning? I imagine > that just a giant list would be too overwhelming when an individual > employee might only need a small percentage of them, so some means of > indexing/searching is probably required. Does anyone here do have a > shared/collective solution, or does each department (or worse, individual) > just keep that information separately and internally? Do you use a > third-party product (what?), or have you constructed your own solution? Do > you keep track of shared credentials or the individual staff members who > hold credentials? > > Thanks, > Erich > > > -- > Erich Hammer Head of Library Systems > [log in to unmask] University Libraries > 518-442-3891 University @ Albany > > The perversity of the Universe tends towards a maximum. >