6. Findable, Impactful, Citable, Usable, Sustainable (FICUS): A Heuristic for Digital Publishing

Nicky Agate, Cheryl E. Ball, Allison Belan, Monica McCormick and Joshua Neds-Fox

Introduction

This chapter addresses some unanswered questions raised in this volume—primarily, how does one create a piece of digital scholarship that will be accessible and sustainable far into the future, if indeed that is a key component of the work (i.e., it is not event- or performance-based, or purposefully meant to be unarchivable). The authors of this chapter serve as digital scholarly experts—we are authors, editors, publishers, project managers, project directors and librarians for many digital journals, monographs and publishing programs; of individual, collaborative and cross-institutional digital humanities projects; and of digital publishing platforms being built to accommodate both large- and small-scale digital projects such as digital dissertations.

We came together in Spring 2018 at a two-day think tank hosted by Duke University Libraries and supported by The Andrew W. Mellon Foundation, with dozens of other librarians, publishers and scholarly communication stakeholders, to work on the question of sustainably publishing large digital projects. The outcome of that discussion turned into an extended project culminating in the heuristic presented at the end of this chapter. What leads up to that heuristic is how we created it and why it matters to your digital (dissertation) project.

Tending the Seeds of Sustainable Digital Projects

There is much research published in this book and elsewhere on the long (often unknown) history of digital scholarship, and the authors of this chapter have dedicated a good bit of their careers, in various work capacities mentioned earlier, to maintaining and creating sustainable workflows and platforms for archiving digital scholarly products—whether they are digital articles, monographs, journals and electronic theses and dissertations (ETDs); digital humanities projects that fall outside the scope of traditional peer-reviewed publications; or the platforms used to distribute and preserve these monographs, venues and projects. We know from our daily practice as digital librarians and digital publishers that the question of sustainability is not easily answered when it comes to working with scholars who desire to use the latest, greatest tools. There is often a tension between the use of innovative media and preservation of the scholarly projects it enables. It is disheartening when scholars spend hundreds of hours on a project, only to discover too late that the platform they have chosen doesn’t afford them the chance to ensure the long-term viability of their work. This can happen for a myriad of reasons, including technological ease, existing knowledge base, accessibility, availability, economy and institutional constraints. The project wasn’t built to be a performance piece, but it becomes one—a work slipping quickly into technological degradation and unplanned obsolescence—because no one thought to consider sustainability as it was developed. We’ve seen entire scholarly journals disappear into the internet ether, including those managed and published by esteemed scholarly organizations.¹ But most publishers, librarians, editors and authors don’t wish for that to happen.

That was the exigence for the two-day discussion at Duke, which raised questions about digital publishing workflows, from creation to preservation, for ‘expansive’ digital projects. These were defined as digital humanities projects that are monograph-ish in scope. Many of the workshop participants were university press-affiliated publishers who have created or who manage publishing platforms that authors use to build digital humanities projects, including digital dissertations. Some of the most well-known of these open-source platforms (some of whose developers were in attendance) included Editoria, Fulcrum, Manifold and Scalar, but the group also had knowledge of authors who used other platforms such as Omeka and WordPress. The goal of the two-day workshop was to gather ideas on how a library should support authors who want to publish expansive digital projects, with the underlying issue being that many university presses—as the assumed go-to for many digital humanities (DH) authors—don’t have the capability and/or interest to offer long-term solutions for authors and their projects, whereas libraries are often better suited to help authors at most any stage of the DH project timeline and are the place where digital dissertations will eventually be deposited. (To be clear, the discussion at the workshop was not centered on graduate students and digital dissertations, but this chapter assumes that the digital dissertation is often the first type of project an author will undertake before embarking on a longer career filled with expansive digital projects and, indeed, they are often one and the same project as ETD grows into an academic’s first expansive digital project post-graduation.)

While we authors represent a small fraction of attendees at the Duke Libraries workshop, it became clear from the discussion that the five of us² shared similar insights and expertise in publishing and preserving digital scholarly projects. At the end of the workshop, we were prompted by Paolo Magnifico (from Duke Libraries and project director for the annual Triangle Scholarly Communications Institute) to propose a working group for that year’s TriangleSCI, where we would create a giant checklist/heuristic³ for digital scholarly publishing that brought together existing best practices for publishing and preserving digital projects. There were and are many best practices, and more published regularly.⁴ Our team was accepted for the week-long workshop in Durham, NC, to create what would become FICUS: a checklist for Findable, Impactful, Citable, Usable and Sustainable digital scholarship.

Fertilizing FICUS

A good DH project often starts with a catchy name, and the acronym FICUS came to us quickly. We appreciated that any checklist we made would be beholden to change—always in need of updating as new types of projects, technologies, genres and workflows were created around and in support of digital publishing. It made sense that our name reflect this precarity, and as sometime-gardeners, we recognized how precarious ficus plants are in the wild, easily dropping leaves and dying when environmental conditions shift. And yet they are beautiful, life-giving things. Our intention in naming the checklist after the ficus plant, then, is to indicate its usefulness while still understanding that the items within may change on a whim.

Our vision statement for the FICUS checklist highlights the necessity that ‘digital projects are fully integrated into the scholarly publishing ecosystem and are recognized and rewarded as first-class scholarly contributions’. The ‘first-class’ designation came in response to then-Senior Program Officer at the Mellon Foundation Don Waters’s use of the phrase to signal scholarly projects that are accorded the highest level of recognition and value in academia’s tenure systems. That is, we wanted to mirror the language of one of the primary funding agencies to support digital humanities scholars and their work and to show that we firmly believe DH projects are first-class scholarly contributions within academia.

Our mission with FICUS is to ‘reduce the risk for publishers by increasing the likelihood that digital projects will be findable, impactful, citable, usable and sustainable by building a scaffold of critical guiding questions’. The Duke workshop focused on library publishers, as evidenced by their 2019 outcomes publication,⁵ which covered planning, allocating resources, discoverability, evaluating and preserving ‘expansive’ digital projects from a library’s business-model perspective. At TriangleSCI, the FICUS team also decided to focus on educating publishers (including libraries) who wanted to help authors with digital projects. Our efforts later in this chapter turn this checklist towards authors—including those working on digital dissertations—and the information they need to plan and draft their projects, in consultation with their local librarians, potential publishers, and, of course, their advisors.

As we began to build FICUS, we drew from a number of existing resources that we and other participants at the TriangleSCI workshop knew about. It is likely there are even more resources that have become available since we first began work on FICUS. These resources are excellent sources of information on digital publishing in and of themselves, so we link to and explain them briefly here. It is basically the literature review section of this chapter. If you are ready for the checklist already, skip ahead to the next section.

An Ethical Framework for Library Publishing, Version 1.0: the ‘Ethical Framework’ (2018), authored by a working group of the Library Publishing Coalition that included Joshua Neds-Fox, a FICUS author, provides a heuristic for ethical considerations in digital publishing regarding accessibility; diversity, equity and inclusion; privacy; academic freedom; and related topics. The FICUS group focused primarily on the accessibility recommendations in this document to inform the usability and sustainability sections of our checklist, but approached the overall creation of the checklist in terms of its ethical role in helping publishers and authors to create projects that hit all possible marks for readership.

HuMetricsHSS Initiative: HuMetricsHSS began as a TriangleSCI project in 2016, where the project team created an humane values framework for ‘evaluating all aspects of a scholarly life well-lived’.⁶ These values include equity, openness, collegiality, quality and community. Nicky Agate, from the FICUS team, also serves on the HuMetricsHSS initiative and brought the concept of openness, in particular, to play throughout our work on FICUS, and this work was particularly useful as we crafted the Impact section of the checklist.

‘Access/ibility: Access and Usability for Digital Publishing’: this 2016 publication on access and accessibility, openness, preservation and sustainability of digital scholarship came out of a weeklong workshop hosted by Cheryl Ball, one of the FICUS authors, and attended by twenty-six scholars, librarians and digital scholarship advocates. During the workshop, they created a set of best practices for accessible scholarly multimedia, built in part on the decades of experience publishing Kairos, the longest continuously running scholarly multimedia journal in the world. This list targets authors and publishers, and focuses on layout and design, interactivity, images, audio and video. The items here were primarily used for the Citable, Usable and Sustainable sections of the FICUS checklist.

DH Project Questions: this heuristic was created by FICUS author Ball to help authors translate some of the more challenging rhetorical and technical obstacles authors face when creating digital humanities projects into simple action-based questions they could answer. The list came from years of practice with Kairos authors and KairosCamp institutes where Kairos editors helped individual and collaborative author groups scope, pare, and propose better, more sustainable and rhetorically sophisticated digital publishing projects.⁷ While this heuristic focused on authors and the FICUS team ended up focusing on publishers, some of the ‘Big Questions’ from this list, including ‘Where will [your project] live?’ and ‘Who will sustain it?’, guided how we created different categories of our FICUS checklist.

CRediT (Contributor Roles Taxonomy): CRediT provides a taxonomy of fourteen roles that represent the range of contributions often found in digital publishing projects, including Conceptualization, Data curation, Formal Analysis, Methodology, Project administration, Software, Visualization, Writing—original draft and Writing—review and editing, among others. The FICUS team used the concepts from CRediT to inform parts of the Impact section, particularly as it relates to tenure and promotion/evaluation issues (i.e., who gets credit for working on digital publishing projects and how are those folx’ work rewarded?).

NDSA Levels of Digital Preservation: the National Digital Stewardship Alliance (NDSA) has provided a matrix for digital preservation of all kinds of projects since 2013, and their updated 2018 version was in-progress at the time we were working on FICUS, but still provided a roadmap for parts of our Sustainability section, in particular. Their matrix provides different levels of focus on preservability for libraries and archives to follow that focus on knowing, protecting, monitoring and sustaining one’s digital content.

FAIR data principles: these principles are targeted towards making data-intensive science and data sets more Findable, Accessible, Interoperable and Reusable (FAIR). They were published in 2016, but they didn’t come to our attention until the 2018 TriangleSCI workshop, thanks to a group of our European colleagues (where the original principles were created). The FICUS group noted the cross-overs between both sets’ Findability and Accessibility principles, and that much of what the FAIR principles outline in terms of data can easily be applied to digital publishing projects writ large.

Socio-Technical Sustainability Roadmap (STSR): this project, hosted by the University of Pittsburgh’s Visual Media Workshop, was published while we were at TriangleSCI and covers a broad range of sustainability questions for digital projects. The FICUS team felt that the STSR was more comprehensive in covering some of the sustainability issues than we could cover in a week of brainstorming, so our Sustainability section remained in beta until writing this chapter. We still refer publishers and authors to that document, particularly as it highlights questions in regards to a whole project (the questions of which are similar to the DH Project Questions discussed above), staffing and technologies, and creating a digital sustainability plan for projects.

‘Developing a Business Plan for Library Publishing’, by Kate McCready and Emma Molls, was published in 2018, around the same time as our TriangleSCI meeting. Although we didn’t use it to inform our FICUS checklist, the concept of providing guiding questions to establish an effective and sustainable library or other publishing program will impact the sustainability of digital projects that any publisher undertakes, and that authors should be aware of. Ultimately (and, in our minds, unfortunately), the business models of a publisher will indicate and often limit the types of projects publishers are willing to move forward with.

Tending FICUS

The questions in the Findable, Impactful, Citable, Usable, and Sustainable sections provide a framework for authors. Initially geared towards publishers, we have transformed the FICUS checklist to accommodate how authors of digital projects might use these questions. This checklist doesn’t follow a linear order for composing a digital project, however. Authors might want to start with the Usable section, as it provides an entry point for applying your project’s purpose to an audience in a usable fashion. Next, authors may want to review questions in the Sustainability section, because it outlines how to find the best platform for your content and how to prepare your text for longevity from its earliest beginnings. From there, we recommend working backwards through Citable, Impactful and Findable, as many of the questions in Findable will require interaction with a librarian or publisher. While we don’t have space here to annotate each of the questions, and we recognize that some of the questions may more firmly rest in the domain of publishers and/or librarians, they are still good questions for authors to discuss with their librarians/publishers to learn more about the publisher’s approach to the longevity of their digital scholarly projects. The sections that have publisher-relevant questions are marked as such by the header to ‘Ask your Librarian and/or Publisher’.

In the case of ETDs, which are often published via an institutional repository, the key is to find the person(s) in your library or digital humanities center or research office who may be called a scholarly communications librarian, digital scholarship librarian, copyright officer, institutional repository manager or other titles (which may not include the word ‘librarian’). Look for the person who has some familiarity with digital publishing and can help you navigate these questions. Indeed, as you get deeper into the FICUS checklist, we hope it will become more obvious that partnering with a digital librarian means more than just relying on them to answer some basic questions for you, but that these folx can be embedded in your project team from the beginning and will often contribute a great deal of intellectual labor to your project. The CRediT taxonomy discussed earlier offers suggestions for how to credit them. TaDiRAH, the Taxonomy of Digital Research Activities in the Humanities, can also help in this regard. (But, y’all, for the love of all things easily citable, do we NEED these random capitalizations?!) We also recognize that not everyone will have a digital librarian at their university to ask these questions, and that shouldn’t stop you from proceeding! Start by asking your advisors or dissertation committee members, and if they don’t have any experience with digital dissertations and these types of questions, you might reach out to other scholars on your campus or other digital dissertators you know. In any case, coming to these allies having thought through possible answers is a great strategy for getting them up to speed on your project, so they will understand the scope of your needs and desires. Librarians and publishers in particular will do their best to help you fulfill both of those, though compromise is often required in digital projects due to usability, accessibility, sustainability, economy, and availability issues.

FICUS (the Checklist)

Findable

This section helps authors answer the question: how findable is your project, both by humans and by machines?

Ask Yourself and/or the Project Team

• Does the project fit (disciplinary, subject, methodological) into an existing publishing venue, index, list, or aggregation?
• Who is responsible for promoting and publicizing the project, and what methods will be used to do so?
• Where does your target audience discover new scholarship?
• If your project is about a certain ethnic, racial, geographic, socioeconomic group, how will you ensure that those audiences know about it?
• Can users in other languages/countries/environments discover the project?
• What partnerships can you form or use to create awareness of the project?
• What venues review projects like this?

Do you have an ORCID (http://orcid.org) and other persistent social media handles that will link you to the project once it is published?

Are commercial search engine optimization techniques employed for the project?

Does the project need to incorporate linked open data to enhance discovery and use, and how will you or your publisher provide for that?

Ask Your Librarian and/or Publisher

• What metadata needs to be created/maintained in order to register this project with the appropriate discovery systems?
• Does your metadata schema enable web-scale discovery? Specialty system discovery (e.g., library OPAC, DPLA, etc.)?
• What other persistent identifiers (work, object, media, personal) are relevant and/or useful to the project? (DOI, ORCID, ISSN, …. more?) Do those identifiers support the kinds of objects, media, work, persons involved in your project?
• Which of the following will the identifiers and registries provide (note that not all are required, but you should consider which your project requires):
  • Unique ID
  • Persistent link
  • Associated metadata repository/registry
  • API access to the repository/registry to services (such as reference linking, reference lookup, interaction with other services—funder repositories, for example)
  • Identity disambiguation
  • Credit
• Is there a plan for maintaining the project’s metadata in the identifier registries?

Impactful

This section answers the questions: will your project have impact and how will it be assessed?

Ask Yourself and/or Your Project Team

• Does this project fit with the broader goals of your academic research or teaching trajectory (e.g., scholarly/disciplinary focus, technology use, institutional mission/vision/goals)
• Will the project or its participants need or benefit from a scholarly assessment and validation process? (for validation, for tenure and promotion)
  • What form of scholarly assessment and validation is most appropriate for the project? (pre-publication review, post-publication review, open review, anonymous review)
  • Who is responsible for conducting the scholarly assessment and validation process? (e.g., the authors, the project team, the publisher)
  • Will the project document its scholarly assessment and validation method?
  • What do stakeholders need to know about the scholarly assessment and validation process for this project?
  • At what stages of the project will it be subject to scholarly assessment and validation?
• Who is recognized as a contributor to the project and how is that recognition expressed (human readable, machine readable)?
• How will you design the project to ensure that all project partners’ valued metrics are captured?
• How will you measure the success and impact of the project?
  • How will use be measured (course adoption, inclusion in LibGuides, downloads, web traffic, time on page)?
  • How will engagement be measured? (i.e., citations, blog posts, annotation, reviews, discussion in news media, assignments, community interest)
  • How will impact be measured? (i.e., international reach, awards, inclusion in public policy documents, references in grant proposals, citations, inclusion in syllabi)
• Is the project designed such that the desired measurable outputs can be tracked?
• Is the project designed such that its various uses can be tracked and followed?

Ask Your Librarian and/or Publisher

• Does this project fit your technological profile, either existing or aspirational?
• How will this project enable you as a publisher to broaden or deepen the scope of what you can offer?
• Does this project illustrate or demonstrate your values?
• Will you conduct scholarly assessment and valuation of the project, and if so, how will that be documented?
• How might you help us measure the project’s use and impact?

Citable

This section answers the question: how, and in what forms, will your work be cited by other scholars? All of these questions might best be answered in consultation with a digital librarian.

• Given the nature of the project and its content, what is the unit of scholarly value that users will want to cite? (e.g., the entire project, pages/sections/units within the project, individual media assets within the project, etc.)
• Does the project have the markers of permanence (including persistent identifiers) that make scholars secure in citing it?
  • If there is more than one citable unit, does each have a persistent identifier?
• Is integration with automatic citation generators desired or possible?
• How does project type/media/genre affect what’s citable, the citation format that may be used, and the metadata required?
• If the project in its public form changes over time, what is the plan for maintaining citability?
• If the content is later edited or modified, how will you ensure that ‘version control’ is reflected in the citation?

Usable

Usability is a more encompassing issue than the previous sets of questions, so we’ve broken it down into sections that each address different aspects of making your project usable. You will likely want to consult with a digital librarian on most of these sub-sections.

Audience

Answers the questions: is your project internally coherent in regard to its intended audience? How does your intended audience drive your choices for technology, language, design, etc.? This section is not meant to address the entire rhetorical scope of how audience affects your digital project, but to address how audience and usability intersect in terms of creating sustainable projects.

• Who is/are the audience(s) for your project? Is the project’s audience well-defined?
• How does the platform choice impact the potential audience’s use of the project? (See also Sustainable)
• Is there interaction with the project? Will that interaction be public, in the form of community translations, annotations, comments, or contributions? Will they be instantly visible, or after moderation? If so, how will that mediation or moderation take place and who will do it? (See also Sustainable)
• Are you attempting to crowdsource any part of the project content? How? (See also Sustainable)
• Will the intended audience have the necessary technical expertise and affordances (e.g, infrastructural access)?
• Does the project discovery plan serve the intended audiences? (see also Findable)
• Does your project’s development plan allow for the discovery and accommodation of unexpected audiences? (see also Findable)
• How will you determine that your project is reaching its intended audience, or recognize other audiences it is reaching?

Accessibility

Answers the question of who has access to your project, focusing on people with physical, geographic, and economic barriers to access.

• What is the accessibility testing plan? (timing, frequency, stakeholders, target compliance levels)
• Will the project be accessible on different devices?
• Who is included in usability testing and is that group inclusive of people of differing abilities and backgrounds?
• What statutory or institutional guidelines or requirements is the project subject to?
• How will the project’s device and browser support impact the expected and unexpected audiences’ access?
• How will the project’s content, context, and structure allow or limit access outside of its geo-political and cultural context? (bandwidth, reliability, expense, language, software, graceful degradation, social accessibility/censorship)
• Does the project allow for effective, authentic access to critical stakeholder communities? (e.g., those whose work or communities are featured in the project)

Usability

This section answers the question of how usable your project will be to potential audiences. You may develop a usability testing plan in concert with your library or other publisher.

• What is your usability testing plan?
• Is access limited by IP/username & password/non-accessible platform/language? (See also Sustainable)
• Have you developed testers that mirror the project’s audience?
• Will the project’s content be understandable in either human or machine-readable ways when encountered outside of the designed application?
• Have the design and layout elements of the project been assessed for loss of meaning if they are removed, absent, or do not gracefully degrade? (see also Accessibility). For example:
  • Will the text still function if a user views the project with their own style sheet?
  • Is navigation available through multiple modal points (e.g., mouse, trackpad, keyboard, eye-tracker, etc.)?
  • Do user interactivity features include feedback mechanisms, such as confirmation of response, indication of progress toward completion, time left to complete or timeout, etc.?
  • Do all media assets (image, audio, video, etc.) have attached descriptors and proper structured text (e.g., transcripts, captions, descriptions, alt attributes, etc.)?
  • Do users have control over how media assets are to be interacted with? (e.g., turning off auto-play on videos, etc.)? Do animated/moving assets avoid rapid refresh rates, blinking, pulsing or quick movement of dots and narrow stripes?
  • If color were removed, would the project’s use be inhibited?

Intellectual Property and Use Rights

This section answers the questions: How does copyright and licensing work in and for your project and team members? Some answers may be dependent on your publishers’ requirements as outlined in their author agreements, so you may need to address these questions in consultation with them.

• Will individuals keep copyright of their individual contributions? Will teams collectively share copyright to the outputs?
• What license will be applied to the project (all rights reserved; open license such as CC BY, CC0, GNU, WTFPL, EUPL)?
• Will different licenses be applied to different parts of the project (metadata, software, data)?
• Are there institutional policies that may guide or constrain your licensing options?
• Will the license choice impact the project’s eligibility for inclusion in relevant aggregations, indexes or other third-party discovery systems?
• Does the licensing structure support the intended uses and appropriately restrict other uses?
• Is the license both machine and human readable?
• Does the project include works/assets that are under copyright or require a license to use?
• Are there licensing limitations (use, cost, format quality) that would negatively affect the usability, accessibility, sustainability or impact of the project, either now or in the future?
• What materials fall under fair use? Public domain?
• How will copyright and credit be acknowledged or attributed in the project?
• What parts of your project are intended for reuse (content, data, platform, etc.)?
• What modes of technical re-use are intended? (replicable, consumable, portable)?
• How does the design and structure of the project allow for intended re-uses (e.g., package, zip file, Docker, Vagrant, GitHub, API, etc.)?
  • If the content layer (separate from the structure) is meant to be re-usable, how does the project accommodate that (e.g., APIs, OAI-PMH, data portability through structured content using json, XML, etc.)?
  • Are underlying systems essential to the project’s re-use? (programming environments/languages, dependencies, software, hardware, operating systems, etc.)
• Does the project make use of descriptive standards that promote its re-use? (e.g., metadata schema, rational URLs, Persistent ID systems, etc.)?
• Will the programming or content language be a barrier to re-use for your intended audiences?
• How will the project prevent unauthorized reuse of restricted materials?
• How does the project’s copyright status or license impact its reuse?

Sustainable

The Sustainability section relies heavily on the work of the Socio-Technical Sustainability Roadmap and the NDSA Levels of Digital Preservation. This section answers the questions: what content do you have and what platform will you need? How will you work with these materials to make the project sustainable? What is the end-life of your project?

Platforms

This section provides questions to help you determine a platform given your content, audience and tool availability, and how that platform will be maintained. A list of digital tools that have been used for DH projects is given here, although the maintenance of the list is in question, as new platforms, technologies and the like change rapidly: https://digitalhumanities.berkeley.edu/resources/digital-research-tools-dirt-directory

• What is the project for? (Is it a house? A power tool? A community? An attic?)
• Is it meant for people (to use, view, act on, work with) or not (does it operate on things by itself)?
• Is the project static or dynamic?
• How will the project interact with people or other systems? Do either of these need to add to/alter the project? Does it need to maintain states?
• Do you need user management/proxy identities?
• Is there some skill/knowledge/ability required before one could engage this project? (programming language, disciplinary knowledge, technical affordance) Does the platform need to mediate that Knowledge, Skill, Ability (KSA)?
• What content types live in the platform? (data, images, text, software, video, audio, complex digital objects, metadata, a stream of content from somewhere else, something else)
• Does the system need to manage persistent identifiers for content? (See also Findable)
• Is it meant to be open source or proprietary?
• What computing power is needed for the project? Is it resource intensive? (grid power, CPUs, memory use)
• How much digital space will this take? Will the project grow/shrink?
• Does the project need a human/s to manage data, software/hardware, development, workflows, users?
• How much institutional/ideological support and enthusiasm does the project have? Will the project die without you?

Preservation

This section answers the question of how long your project needs to last and how it will be preserved.

• How long does the project need to last to serve its purpose?
• Does it need to remain usable/reusable?
  • Is an analog, abstract, report, record or snapshot of the project sufficient for the long term?
• Are the systems/formats used in the project integral to the nature of the project, or could it be migrated to a new system/format if current systems become obsolete?
  • Are the modalities migratable? Is the user interface integral to the project, or could it be reconceived?
  • Will the formats of the project degrade physically? Is there a storage/migration solution for these formats if so?
  • What systems also need to be preserved in order to ensure long-term viability of the project?
  • Do you have access to the infrastructures necessary to preserve those systems?
• Is there sustainable funding earmarked specifically for preservation?
  • How much?
  • Will/can the project generate income? If so, is this income enough to solely sustain the project for its entire lifespan?
• Does the project have or need policies to describe the preservation intent (to protect it against commercial capture, commercialization, and/or disintegration)?
• How much digital space (GB/TB/PB?) does the project occupy?
  • Is there a second, geographically separated digital place where that much space can be apportioned for a copy of the project?
  • Has this space been budgeted for in a sustainability/funding plan?
• Can the storage/preservation versions of the project or its content be reliably reconstructed? How do you determine whether the data has degraded over time (checksums, etc.)
• How stable is the institution the project is connected to? Is it likely to last? Are there political considerations to the longevity of the project?
• Do natural, geophysical or geopolitical realities threaten the long-term viability of the project?

Retirement

Answers the questions of how to plan for your project’s digital afterlife.

• Once it goes live, is it finished/final/complete/closed to ongoing work or
• Is it intended to be developed/augmented/expanded continuously?
  • How will you ensure that work continues? On what cycle?
  • By what metric will you measure ‘fruitful’ expansion?
  • Will your publisher allow for ongoing work?
  • How will you know when the project has realized all the value it can?
  • Will there be periodic review of project value/viability? How often? By whom?
• How will you communicate the status of the project to users?
• What metrics will indicate that the project has reached the end of its lifespan?
• Is there a community that should be consulted with or communicated with about lifecycle events?
• When the project is at the end of its life, what constitutes adequate digital hospice? How do you help this project degrade gracefully into that good night?

FICUS in the Wild

It won’t be surprising if authors read the FICUS heuristic with bewilderment at the depth of thinking, pre-planning and execution of minutiae that seems required of digital projects. Librarians get that, which is why it is literally our job (at some institutions) to help scholars think through these types of projects. It also wouldn’t be surprising if authors only followed a small portion of these recommendations. It has been true for the decades since digital dissertations became objects of the scholarly record that authors have not attended to many of the items on this list, because these items felt outside your purview, beyond your knowledge or, in some cases, not even a thing yet (e.g., early ETDs that were published during a time when DOIs and rich metadata didn’t yet exist). We get it, and we sympathize. Your intellectual contributions towards the growing content knowledge in your academic disciplines are still the primary consideration in your dissertation projects and the primary expectation of your committees; the technological considerations, out of which much of this checklist is built, have most often been used in service of the content, which means they are considered after-the-fact and with whatever technology was available at hand. Our goal with the FICUS list is not to provide a mandate of to-dos for every digital dissertator but a set of considerations that will make your intellectual and technological labor last far into the future, for many more researchers to engage with.

We have published an archived version of the heuristic for you to download and use as an actual checklist at https://digitalcommons.wayne.edu/libsp/152/. We will end here, then, with the possibilities that present themselves to you as you proceed in your research, and the hope that you might let us know how it is going if you use the FICUS list.

Bibliography

Agate, Nicky, et al., ‘Findable, Impactful, Citable, Usable, Sustainable (FICUS): A Heuristic for Authors of Digital Publishing Projects’, Digital Commons, https://doi.org/10.22237/waynestaterepo/libsp/1606953600

Ball, Cheryl E., ‘DH Project Questions’, https://docs.google.com/document/d/194VWvDG9PZbDA6GmIV-QsT3wZ9-UE0CQ5CLtXYGoWls/edit?usp=sharing

Boczar, Jason, et al., ‘An Ethical Framework for Library Publishing’, LPC Publications (2018), Paper 1, http://dx.doi.org/10.5703/1288284316777

CASRAI, ‘CRediT—Contributor Roles Taxonomy’, https://casrai.org/credit/

Digital Humanities at Berkeley, ‘Digital Research Tools (DIRT) Directory’ (2015), https://digitalhumanities.berkeley.edu/resources/digital-research-tools-dirt-directory

Eyman, Douglas, and Cheryl E. Ball, ‘Everything is Rhetoric: Design, Editing, and Multimodal Scholarship’, in Editors in Writing: Behind the Curtain of Scholarly Publishing in Writing Studies, ed. by Greg Giberson (Logan, UT: Utah State University Press, forthcoming).

Eyman, Douglas, and Cheryl E. Ball, ‘History of a Broken Thing: The Multi-Journal Special Issue on Electronic Publication’, in Microhistories of Composition, ed. by Bruce McComisky (Logan, UT: Utah State University Press, 2015), pp. 117–36.

Eyman, Douglas, et al., ‘Access/ibility: Access and Usability for Digital Publishing’, Kairos, 20 (2016), http://kairos.technorhetoric.net/20.2/topoi/eyman-et-al/index.html

FORCE11, ‘The Fair Data Principles’, https://www.force11.org/group/fairgroup/fairprinciples

Hansen, D., et al., Expansive Digital Publishing (2019), https://expansive.pubpub.org/

HuMetricsHSS, https://humetricshss.org/

McCready, Kate, and Emma Molls, ‘Developing a Business Plan for a Library Publishing Program’, Publications, 6.4 (2018), 42, https://doi.org/10.3390/publications6040042

NSDA, ‘Levels of Digital Preservation, Version 2.0’ (2019), https://ndsa.org//publications/levels-of-digital-preservation/

Shirazi, Roxanne, and Stephen Zweibel, ‘Documenting Digital Projects: Instituting Guidelines for Digital Dissertations and Theses in the Humanities’, College and Research Libraries, 81.7 (2020), https://doi.org/10.5860/crl.81.7.1123

TaDiRAH—Taxonomy of Digital Research Activities in the Humanities, http://tadirah.dariah.eu/vocab/index.php

Visual Media Workshop at the University of Pittsburgh, The Socio-Technical Sustainability Roadmap, https://sites.haa.pitt.edu/sustainabilityroadmap/