I’d like to thank both Becky Yoose and Kim Phipps (Messiah College President) for fixing the term hospitality in my mind, Chris Bourg for the challenge she extended and the phrase “for the love of baby unicorns,” Linda Ballinger for asking questions, Julie Hardesty for a year of collaboration toward a useful metadata documentation plan, the Samvera Documentation Working Group for their work and for helping the metadataists formulate a plan, and the C4LJ Editorial Committee and Becky for providing feedback on this draft

I once owned a Star Trek uniform. It was Deep Space Nine[1] style, blue for science and for Jadzia Dax, and an awkward, terrible fit on me. The second website I ever built was a DS9 Geocities fan site. I was the kind of teenage girl who spent hours downloading miniscule 30-second trailers of episodes on StarTrek.com, just to get her fix, and I don’t regret that… for all that I still can be a walking Memory Alpha[2].

What I’m writing about today is hospitality in libtech, and my starting point is Chris Bourg’s 2018 Code4Lib Keynote (keynote video). I understand, appreciate, and support the message of the study Chris cited which mentioned Star Trek posters. I’m writing on the side of Trekkies for inclusion. I shouldn’t assume, for example, you know that Memory Alpha is the Trek wiki, named for the United Federation of Planets’ library/data archive.[3]

This is the last Trek reference, I promise.

I’m going to walk through some of my own reflections on hospitality in library technology, building from Chris’s talk to encounters with the idea I’ve had over the last year in particular. My undergraduate institution pushed “hospitality” hard (I was given a foot-washing towel at graduation) and it’s taken a long time for me to move beyond feelings about its pitfalls and a buzzword feel to appreciate its real worth as a concept. Listening to Becky Yoose describe documentation as hospitality in an interview on the ( Open paren podcast began the word’s rehabilitation for me. Chris challenged me again to think intentionally about spaces I occupy and not just how I speak to but about (vouching for) others.

In this editorial, I will be using the word hospitality to mean the intentional welcome of others into a space which one currently occupies, possibly as a member of a dominant group. I do not wish to encourage the idea that one should cultivate or maintain a role of benevolent host in a way that forces others to remain forever guest or outsider, although there will always be newcomers. Hospitality may be a first step to ceding one’s position as host in a space. It may be expanding that space to become a place with many potential hosts, each respected for their varied contributions and skillsets. It may also be supporting those in a different space or a different role, such as those who use the technologies we build and support (both colleagues and patrons), and respecting them in that space.

Intentionality as Hospitality

When it comes to behavior in the physical and virtual spaces we create for our community, a thoughtful and enforceable Code of Conduct is only the bare minimum for hospitality. Actually following up and enforcing such codes takes time and labor, but that work, followed by reports back to the whole community are the only way to build a deserved trust.

Beyond the language, behavior, and imagery covered by codes of conduct, however, we should intentionally consider the less overt ways in which we may exclude. Do we consider whether everyone in a group knows what we mean by ILS, git branching, 245$a, or other terms which arise in our daily work? At the 2017 Samvera Connect, my colleague Linda Ballinger encouraged her fellow metadataists on proactive responses to feeling overwhelmed by a barrage of new-to-you terms. Such terms are much like Trek posters, inoffensive in themselves, but exclusionary in certain contexts. The onus is on all of us to create environments where it’s ok not to know a thing and safe to ask.

The Recurse Center social rules, which are becoming more common at libtech events, provide guidance for creating such an environment. They read as follows:

• No feigning surprise
• No well-actually’s
• No back-seat driving
• No subtle -isms

These are an excellent starting point. If we’re trying to extend boundaries of the spaces we occupy, I would challenge us all to try the following as well:

• Recognize that you can learn from those just starting out.
• Embrace familiar questions as an opportunity to reflect on why they recur.
• Consider your usage of acronyms and jargon.
• Value both technical (code, QA, testing, UX, and accessibility) and interpersonal contributions to projects.

Regarding acronyms and jargon, this challenge is not to stop using them entirely but to proactively ensure everyone involved has sufficient context to understand what they mean.

Documentation as Hospitality

Beyond physical spaces and gatherings for sharing and learning, we need to be intentional about the kinds of materials we build for those learning on the job through self-teaching. I would venture that anyone, no matter their area of expertise, has encountered some kind of documentation which fell two or three steps short of where they needed it to be. Perhaps it was a primer with assumptions. Perhaps they could find beginner and advanced materials but nothing to guide folks who’ve got the basics down but want to move to an intermediate level. And, of course, sometimes there’s no documentation at all.

As mentioned in the introduction, Becky Yoose spoke on the ( Open paren podcast[4] of the concept of Documentation as Hospitality. She then expands on her definition of hospitality as:

“making sure that folks can enter in a particular community with the lowest bar possibly that I can do personally or I can build into the community systematically (or persuade others or bribe others) to make a more inclusive community” (emphasis added)

This one-on-one work is a critical aspect of building community, but relying solely on it will leave out those uncertain who or where to ask questions and burn out those offering such assistance. As communities, we would do well to determine systematic approaches to easing community entry, both through concerted efforts at building regular, inclusive learning spaces and through our documentation.[5]

A project which I’ve been watching and admiring is the Samvera Documentation Working Group’s A Guide for the Perplexed Samvera Developer. While still under development, it is an excellent example of documentation which tries to avoid presumption. Early on in the “New? Start here” section, the page “How to Ask for Help” includes directions for joining the Samvera Slack. Most real-time conversation happens on the Slack, particularly on its dev channel. The page then points readers to Slack’s own documentation on getting started as a Slack user. Will many readers already know what Slack is and how to use it? Sure. Will all? Nope, and the Documentation Working Group made the welcoming choice.

Meanwhile, while Terry Reese wrote his previous editorial on learning to be a selfish librarian, he puts a great deal of work into supporting MarcEdit. While many may be familiar with his tutorial videos, I only recently encountered the in-progress Learning MarcEdit, which includes full chapters to spell out things like what every choice in preferences means, with context. As with Samvera, this documentation does not require one to start out at some intermediate stage while still describing how to do complex tasks.

From my own experience, I’m aware how difficult it is to block out time to write up documentation, even if you consider it a critical component of a project. Besides time, however, I see a couple other impediments which documenters face. One is skill—knowing a lot about a thing and knowing how to write do not necessarily mean you’ll be good at writing its documentation. The other is that one may feel uncertain or even presumptuous in attempting documentation alone. Does one know everything which should be documented? Can one assess where others will need to start?

This is one case where what I’m grateful for overlaps with the Write the Docs community, which provides principles and hosts events where one may practice them. Working on the practice in a group, as above, also means that one person need not feel the full weight of creating welcoming documentation. One has partners, gets feedback, and benefits from multiple perspectives and backgrounds. The Samvera Metadata Interest Group has had false starts in figuring out how such a group should work, although we are now trying to align our work more with the developer-focused Documentation WG, an effort which I hope will be productive.[6]

Design as Hospitality

As we work to create more welcoming environments and the means for everyone in them to participate in the work we’re doing, we may also turn our attention to what we build (or implement) together. A fundamental level of how we design hospitality in our systems is accessibility. Rather than give a meager overview in this short space, I’ll refer readers to Ng and Schofield’s article in issue 37 of this journal. Beyond their accessibility and usability, however, there are other aspects of our systems which I would like to frame through the lens of hospitality.

Specifically, I want to address system design, record-keeping, and hospitality. In my January 2017 editorial, I dedicated a section to “The Records We Keep. Here I am concerned with a false hospitality which alleges we can become more hospitable through aggressive data collection.

Jones and Salo have written an overview of learning analytics systems in academia and how these intersect with libraries and library ethics. Besides the continual pressure libraries feel to justify themselves through learning outcome assessment, these programs are pitched as helping students do better in college. If such programs actually improve student success (according to some definitions of success) should we change our principles around privacy?

Beyond the challenges to this assertion outlined by Jones & Salo, I think we must also ask ourselves what kind of a world it is we want to be creating for our students. Is it one in which every institution surveils on them and reports back to others, ostensibly with their own good in mind? Is it one in which yet another dataset about them could be given or sold to researchers, demanded by governments, or compromised by hackers? Hardly a hospitable choice.

Nor is the problem limited to academic libraries. Public libraries already collect and share certain portions of patron data with a variety of content and service providers, including Amazon. Through its new product, “Wise,” OCLC now proposes to partner with libraries to collect all that data in one place, managed in the cloud by OCLC.

Some of the marketing around this product struck me as connected the editorial I was already drafting. In particular, their blog post includes the following testimonial, that Wise “removes subjectivity—instead of an interpretation of customer wants or what customers say they want, the system uses data to determine need.” I read this statement (from a customer, but promoted by OCLC) as a fundamentally false, hollow hospitality. Algorithms developed by human beings will reflect their assumptions and biases and impart their own oppressions.

Since the product is only just being marketed, I contacted OCLC with some of my questions and concerns.[7] The responses I received from their new Data Protection Officer were primarily marketing language, uncertainty about most technical specifics (it appears they still need to learn what’s in the Wise system, which they purchased from its developer, and build from there), and assurances that they take privacy seriously without any firm commitments to minimum standards. I believe the following excerpt may be an accurate assessment of what Wise attends to accomplish: “…it takes the very best of disparate systems and combines them into a unified, powerful solution; the collection and use of data, however, is not materially different from today’s practices.”[8]

I was reminded of Facebook’s recent statement to Reuters, that “data collection is fundamental to how the internet works.” Data collection certainly is the way things are right now. But rather than designing systems to collect, aggregate, and analyze that data more smoothly, perhaps we should assess where we are and reconsider. Humans will remain subjective, frustrating, and beautiful, no matter what kind of technology we throw at them. I hope we’ll remain aware enough about that to meet them as fellow humans whose inquiry, escapism, and entertainment we facilitate and whose privacy and safety in doing so we respect.

The Labor of Hospitality

If any of the above were easy, we wouldn’t have to talk about it. Intentionality about our space and words takes work. For most of us, it’s a practice that requires mindful attention. I certainly have a way to go when it comes to jargon. Writing the documentation may take as much time as creating the code did, with far less administrative support or reward in our careers. And trying to understand or negotiate data in external systems or advocate for better choices in what we’re making may require a good deal of time and emotional labor. Pushing back may even be dangerous to one’s employment. I’m aware of and grateful for the time another colleague recently put into phone calls and emails with a vendor after an internal group expressed concerns regarding privacy. Neither getting the answers nor documenting them in a way that the whole group could understand were easy.

If Code4Lib is good for one thing, though, it’s community. As we continue to recognize where we fall short, personally and collectively, in welcoming others, let us support each other in lowering barriers to entry and in building systems which extend that same hospitality and respect to the communities we serve.

End Notes

[1] Deep Space Nine was the third live-action Star Trek series, running in the mid-to-late 1990s. Over its 7 years, two styles of Starfleet uniform were used. Mine was, regrettably, the former.

[2] Memory Alpha is a wiki-based project reference for the Star Trek universe.

[3] I’m now overcome by the desire to write a comparison of the Star Trek United Federation of Planets’ library/archive setup and that of the Galactic Empire as shown in Star Wars: Rogue One.

[4] ( Open Paren. [ for the writer’s piece of mind…let’s close these ) ) ) ]

[5] Speaking of systematic approaches, tools which serve as programmatic intermediaries, such as MarcEdit, the C# MARC Editor, and OpenRefine and the accompanying documentation and tutorials are invaluable in lowering bars to entry and expanding communities. Their support of multiple skill levels also provides an opportunity for users to gradually build advanced skills (and confidence in their tooling expertise) which they may bring to other contexts.

[6] In my own experience of trying to lower barriers for entry, I’ve also realized some of the pitfalls when documentation may become the primary way one learns about a thing. In creating the EADiva project, my goal was simple—rewrite the EAD tag library in a way my classmates, who weren’t familiar with the language of Document Type Declarations, could use it. And interlink it for usability. However, simply learning what elements exist in EAD and how to encode data in them is not a good way to learn the practice of archival description. Beyond linking out to the HTML form of Describing Archives: a Content Standard and pointing out on the about page that it is primarily a technical reference, I sometimes struggle with how I can shape the site to make it that the site really is about the technical aspects of encoded archival description and not about its practices.

[7] In the interest of disclosure on my end, I asked the following questions:

• Is the entire Wise program opt-in for the patrons themselves? (e.g. if my public library adopts it, will it opt me in to some aspects and allow me to opt into others or does it give me a full opt-in option on my account page/elsewhere? does the library decide this?)
• Can a patron continue to use a public library which has adopted it without their data being gathered in some way by Wise? (This question includes shadow profiles, similar to those Facebook created for people without accounts.)
• Is the data stored entirely within an ILS system or centrally on OCLC’s servers/in the cloud? Answer: cloud, like OCLC’s ILSes.
• Will the data from multiple libraries be aggregated for overall analysis by OCLC?
• While OCLC has made clear it won’t sell patron data, will it be sharing that data with researchers or other library partners? Which other OCLC products might be informed by that data? Answer: Reiteration that they won’t sell patron data.
• If patrons opt in, are they told explicitly how their data is being aggregated and used? (I’d appreciate a copy of whatever disclosure is given, but also how it’s being conveyed in a non wall-of-text format since it’s a known issue that end-users don’t often read such agreements in detail)
• If data is stored centrally, would this be the largest dataset of library patrons’ borrowing and taste information ever compiled? What plans does OCLC have to keep an unprecedented and tempting dataset safe from hackers?
• Does OCLC have a plan for what will happen if Wise data (centralized or in one library) gets compromised? This question includes everything from possible punitive fines to the damage to libraries’ reputations as a whole.

[8] Ranjan, Brandy. (2018). Re: Questions re: OCLC Wise (context for Code4Lib Journal Editorial). [email].