...
Idea | Comments | Next steps | Progress | ||||||
Convene a working group to develop a thesaurus or glossary and create examples of antiracist descriptive practice. | This was felt by many to be outside of ArchivesSpace’s purview. There are good examples to point to in the wider archives and cultural heritage community. | Add information about other efforts in this area to a resource page keeping track of our anti-racism and inclusion efforts. |
Resources available at Anti-racism and Inclusion in Archives Resource List If you would like to contribute or make a suggestion to this resource list, email ArchivesSpaceHome@lyrasis.org. | ||||||
Provide guidance on which fields to use for disclaimers on material containing racist, sexist, and offensive language or content. | Some of the feedback pointed out that this is primarily a descriptive standards issue, not really an ArchivesSpace issue. | Add information about other efforts in this area to a resource page keeping track of our anti-racism and inclusion efforts. We will also work with relevant community groups to incorporate guidance from DACS on this issue into our user manual, tool tips, and training materials. |
Resources available at Anti-racism and Inclusion in Archives Resource List If you would like to contribute or make a suggestion to this resource list, email ArchivesSpaceHome@lyrasis.org. | ||||||
Eliminate coding terminology that echoes racist language such as "master" and "blacklist/whitelist". | We are investigating tools that GitHub has made available to make this process easier from a technical standpoint, and will work on reeducation within our community. |
| |||||||
Explicitly acknowledge in the application that there is inherent bias in the application and make it clear which who can access records and fields in ArchivesSpace and how. | We will add a statement to our GitHub repository. |
| |||||||
Convene a working group to examine unconscious bias and barriers to entry in the ArchivesSpace application, particularly related to language and privacy. | A lot of this work is being done through the discussions themselves. Creating specifications for issues that had surfaced and beginning work toward development would better retain momentum and achieve progress. Creating specifications for issues that had surfaced and beginning work toward development would better retain momentum and achieve progress. These ideas vary greatly in complexity and amount of effort and skills required to build them into the application. | Program team is working on specifications for many of these ideas, calling in community members as needed. Program team will then work to estimate the staffing and cost associated with them. |
| ||||||
Ability to choose simplified templates for data entry, import, export, and display in the public user interface. | A common theme of the discussions was that ArchivesSpace can very complicated for an inexperienced user, especially a non-archivist. The ability to use simplified templates and views for some functions would significantly lower the barrier to entry. This type of functionality is often requested in other contexts as well. | ||||||||
Develop a scaffolding or infrastructure to make redescription work or antiracist description work easier within ArchivesSpace. | Specific items mentioned included: · bulk editing · full audit trail · additional fields for tracking work
Some of this work is perhaps too complex to undertake or the function can be achieved in the application in part already, but bulk editing is one of the most requested features in the application in general. | ||||||||
Allow for versioning of all record types in ArchivesSpace to document the changes made when doing redescription work and a way to provide the context for why the change was made. | This is probably the most difficult of the ideas technologically because it may require rearchitecting the application. | ||||||||
Create a mechanism to provide trigger or content warnings at both the resource and archival object level. | It is already possible to manually provide a trigger warning as text within a field or note, or a blanket statement within an ArchivesSpace deployment. Discussions suggested taking this farther by having a way a warning could appear more prominently on a record (particularly in the PUI) and being able to invoke it as needed throughout the application. | ||||||||
Provide a mechanism to allow users to submit a correction/edit to a finding aid or annotate finding aids. | Some commenters pointed to a recommendation on page 6 in the recommendations for Anti-Racist Description Resources from Archives for Black Lives in Philadelphia: https://archivesforblacklives.files.wordpress.com/2019/10/ardr_final.pdf | ||||||||
Provide support for description in multiple languages and more translations of the interface. | This has been raised in many contexts previously and would support ArchivesSpace’s growth as well as commitment to inclusion. | https://archivesspace.atlassian.net/browse/ANW-957 If you are interested in contributing a translation of the ArchivesSpace interface, please email ArchivesSpaceHome@lyrasis.org | |||||||
Provide a way to make agents repository-specific or viewable by only some users. | This is also probably quite complex to implement. This could be part of a larger set of changes related to multi-tenant support, which would require significant architecture changes. | ||||||||
Enable the use of Traditional Knowledge (TK) labels on indigenous cultural heritage materials. (https://localcontexts.org/tk-labels/) | TK labels are useful for institutions implementing the Protocols for Native American Archival Materials (http://www2.nau.edu/libnap-p/protocols.html), guidelines for sensitive and ethical management of indigenous materials which were endorsed by SAA in 2018.
| Program team will consult with some experts within and outside the current community about these needs and write specifications. For the purposes of funding, these ideas could be considered a subset of a larger development project, or a development project of its own. | |||||||
Explore ways to better support integration with Mukurtu (https://mukurtu.org/) for those organizations using both Mukurtu and ArchivesSpace or needing to exchange data with other organizations that use one or the other. | Mukurtu is an open source collection management system specifically aimed at sharing digital content in “culturally relevant and ethically-minded” ways. It is often used by institutions that work with indigenous cultural heritage materials. | ||||||||
Add a mechanism for authentication in the public interface. | Some archives want to be able to share some information about their collections with some users but not everyone, when those users don’t share a common IP address or domain or something else that otherwise might be used to restrict access to a website. This is a common issue for tribal archives who have little IT support. | ||||||||
Provide better support for right-to-left (RTL) scripts, ideally bi-directional text. | ArchivesSpace does already provide some support for right-to-left scripts already but comments indicated that it is insufficient for some needs. | We will convene a small working group to investigate this issue and provide a specification. | |||||||
Add fields for variant terms and a function that allows us to make the variant term the local display term when the LCSH term is deemed harmful. | Subjects have always been one of the simplest kinds of records in ArchivesSpace. Expanding the subjects module has come up in discussions for several years, for a range of reasons. | We will convene a working group on expanding the subjects module, with a particular focus on concerns related to inclusion. | |||||||
Provide mechanisms to better support non-LCSH authority term imports. | While not entirely related to expansion of the subjects module, it will be important that the subject record in ArchivesSpace be able to accommodate data points prevalent in the chosen controlled vocabularies. |
IN