This case study focuses on software development in collaboration with Indigenous communities in the U.S. and Australia, outlining the experience of Mukurtu system designers. Mukurtu is a digital content management system (CMS) originally developed in collaboration with Warumungu Aboriginal community members and built upon Warumungu knowledge systems.
By Kim Christen, Professor and Director of Digital Technology and Culture, Washington State University
Challenge in Context
In Australia, like other settler states, large amounts of Indigenous communities cultural heritage materials are held outside of the original communities in libraries, archives, and museums. Collected within initial colonial contexts and on-going research contexts (void of informed consent and ethical exchanges) cultural heritage material (including language materials, traditional knowledge and cultural materials/belongings) are often disconnected from their originating contexts. In addition to this distancing, the original materials often contain incorrect, misinformed, missing, and offensive metadata. Finally, with the move to digitize collections and put them online, Indigenous communities face a second set of removals and distancing from their heritage. In addition, they face increasing misattribution and the continued and more extensive circulation of incorrect metadata.
Context and Background
In Tennant Creek, NT Australia, Warumungu Aboriginal community members I worked with had in 2001-2002 received large amounts of digitized photographs from missionaries—photos the community had never seen. The community, however, could not find a “software solution” for how to manage these digital cultural materials and balance Warumungu protocols for the circulation, sharing and access to these materials. In the Warumungu social system people, places and ancestors all relate to one another and together maintain and sustain their cultural systems, practices and knowledge. In this system there is a continuum of access to places, knowledge and cultural materials. For example, women from one kin group may be the only ones who can sing a certain ritual song, or after a person has passed away the family decides how long images of them should be out of out of circulation. In all cases, factors such as gender, ritual status, kin relations, place-based relations all combine to highlight layers and types of access along a continuum. There was no easy way to adapt this to a standard content management system or digital archive system. We could not find a digital content management and access platform that respected these levels of protocols for access and circulation and also privileged Indigenous ways of defining, describing and relating to cultural materials, belongings and knowledge.
The question became, how do we allow for Indigenous systems of knowledge sharing, production and circulation that emphasize not looking as much as looking? How do we allow for diverse ways of knowing, naming, and understanding within technological platforms built with Western standards at their base? How do we respect Indigenous values and respond to colonial histories of collection within digital access platforms? The challenges we faced demanded technical and social solutions. We needed better ways to create and display metadata, we needed to account for diverse sets of access parameters, we needed to provide layered narrative options to highlight diverse community voices and we needed to facilitate ethical exchanges and knowledge sharing. We took our guidance from the name given to the archive in Tennant Creek. Mukurtu (MOOK-oo-too) means “dilly bag” in Warumungu. A dilly bag is “a safe keeping place,”—elders keep sacred items in the dilly bags to steward in appropriate way. Younger generations must approach elders to gain access and knowledge. This invites dialogue and the sharing of cultural knowledge between generations of community members as they teach and learn from one another. The dilly bag is a good metaphor for the way Mukurtu functions by responding to established and emerging sets of relations and cutting across social and cultural needs to extend relationships and empower knowledge sharing.
Solution(s) and Outcomes
Growing from the alpha version that was a stand-alone database, we moved to create open source software that would be flexible enough to account for diverse sets of protocols from Indigenous communities around the world and also non-Indigenous institutions who want to engage with and share content ethically. That is, there are no “baked-in” or predefined protocols for access, viewing, sharing, or curation within Mukurtu. Instead we built the platform to have flexible cultural and sharing protocols that are defined by users, including public. That is, there is no open or public by default, this too is a choice. Our mission at Mukurtu has always been focused around providing a secure, simple to use, collaborative, open source platform for Indigenous communities, organizations, and institutions to use and to engage with non-Indigenous collecting institutions.
Community Software Development
One way we have sought to achieve this is through what we call “community software development”—focusing on communities as developers. Mukurtu’s development and training merge so that in all of our workshops, training sessions, and online support with people who use Mukurtu, we seek out specific features and functions that meet their specific needs.
Adapting the Agile software development model, we focus on place-based and locally infused narratives that inform the design and architecture of Mukurtu as well as define the main features and functions. We develop Mukurtu’s core features and functions from the relationships, belongings (not objects), and cultural narratives of Indigenous communities who use Mukurtu.
We also needed to allow for many pathways for interaction and feedback from people who use Mukurtu; if we defaulted to GitHub as the only way to interact with our development team we would be leaving out many people for whom GitHub is intimidating or simply not a known and trusted entity.
Mukurtu’s user base has always been Indigenous communities, specifically the archives, libraries, museums and/or cultural centers within these communities. Prior to the 1.0 release in 2012, the Mukurtu team at WSU and its development partners did active testing and used case-driven needs assessments. For example, beginning in 2011, our team has presented yearly demos and provided hands on workshops at the Association of Tribal Archives, Libraries, and Museums (ATALM) annual conference.
Starting with this base of users, we have worked to grow not just the software, but also the community of participants around which it would flourish and develop. We knew that a “build it and they will come” model of open source software development would not work for the communities whose needs we were addressing by creating this new content management platform. Rather than an academic user base, who may have IT support and infrastructure, by and large the Indigenous communities who seek to use Mukurtu CMS have small staff and minimal IT support. Thus, we knew that support, training, and an easy to use platform were all necessary parts of a whole digital management ecosystem.
Long-term Relationships
The community software development model emphasizes an iterative approach to development driven by specific community needs.
We begin when possible with face to face meetings, and if not possible we use “virtual” screen sharing sessions. In either case we begin with community needs and goals rather than software needs. That is, a large part of our time is focused on listening to what community members want, what their goals are for content creation, sharing, and use. These listening sessions are crucial for on-going development in terms of the software, but also, and significantly for community building,
We are not just building and maintaining software. More fundamentally we are building a community—one that we want to be responsive to specific cultural needs and values. To build community we have to ensure that Mukurtu’s core functions reflect the values of our community members. First and foremost, then, this is about trust. Establishing trust has meant not just listening, but also coming back—over and over again. It is quite rare that we only have one meeting or one session with communities. Instead, we have had years, and in some cases, decades’ long relationships that have acted as the foundation for ongoing growth and support. Our Mukurtu support team is also part of our development team. In many ways, the support team is on the front lines of development because they hear first- hand from users about “bugs,” needs, desires, and goals.
Cognitive Walkthroughs
A core activity we use during community or one-on-one meetings is built from “cognitive walkthroughs” where individuals are asked to walk-through a series of tasks (adding content, vetting materials, etc.) with specific desired outcomes. These walk-throughs identify both areas for updates in functionality and theming (for example, is the interface intuitive?, are there steps in the process that could be made simpler?, etc.) as well as missing or incomplete features.
As one example, over the first two years after the 1.5 release of Mukurtu we continued to get feedback from those using Mukurtu that they wanted a “dictionary.” We did not want to replicate standard Western dictionaries nor did we want to mimic academic priorities for linguistic research and revival. Instead, we held face to face and virtual sessions with the existing content types and interfaces within Mukurtu CMS to determine the specific needs—as well as the seemingly conflicting needs. That is, some people wanted to NOT have the translation field viewable, they only wanted the term. This was largely for teaching purposes in an immersion setting, so that language learners would not have an English gloss, but only the Indigenous term. Others however wanted multiple terms and translations in one view. In the version of the dictionary that is now in Mukurtu 2.1 we allow BOTH of these options (and several others). In addition to these more individual sessions, over several years we queried all our workshop participants and culled together a list of the specific needs—multiple audio fields, the ability to assign authorship to individual words, choices for the order of term and translation (or no translation), etc.
User Stories and Distributed Development
In the last two years (2016-18) we have also added five Mukurtu hubs to our Mukurtu support and development model. These hubs are regional centers that aid in the development of Mukurtu CMS—as a platform and software—through community engagement and the creation of “user stories” for our development team. The Mukurtu Hubs managers meet with communities in their areas over the course of a year and during that time they listen to needs, do cognitive walk-throughs and then create user stories to submit to our WSU development team. User stories are short descriptions of a software feature or function from the end-user perspective. User stories at their core are framed as specific requests that have actionable outcomes for development. We paired these down to make the format easily digestible.
Ideally all user stories should follow this format:
- Key story elements: a user, an action and a benefit
As a <type of user>, I want to <action> so that <benefit>
- Acceptance criteria
Descriptions of what success looks like for the action or feature described in a user story
- Prioritization
How important is this item (using the MoSCoW Method: Must have, Should have, Could have, Would be nice)
Here is an example from our Mukurtu GitHub
- Key story: As a Mukurtu User, I want to delete any atom I created, so I can better manage the SCALD atoms in my media library.
- Priority: M
- Acceptance Criteria:
- The creator of an atom should be able to delete their own atom, provided it is not being referenced by other content (Digital Heritage Item, Dictionary Word, taxonomy term, etc)
- Mukurtu Admins and Drupal Administrators can delete any atoms, provided they are not being actively referenced by other content (Digital Heritage Item, Dictionary Word, taxonomy term, etc)
- If a user tries to delete an atom that is currently being referenced Mukurtu should provide a contextual warning
Conclusion
This process of community software development that includes support, training and maintenance, has allowed us to see the long-term arc of Mukurtu CMS as a platform from the vantage point of community members. In fundamental ways it has shaped our ongoing goals. That is, it has pushed us to see that statistics such as numbers of users, or numbers of commits on GitHub are not reliable benchmarks for success. Instead, how we measure success if from the feedback we get from the Mukurtu community—that is, are we responsive? Have we included enough time for testing and engagement before launching a new feature? Have we stayed in contact enough? Are we still building relationships? Are we connecting people, communities and repositories in meaningful ways that support ethical use and sharing?
In the end, we judge everything by our core philosophies: does this assist in creating a safe keeping place for cultural belongings, knowledge and languages?
We have framed our collaborative methodology using the guidelines recommended by the First Archivists Circle “Protocols for Native American Archival Materials.” Three of their suggestions are part of the foundation of our processes:
- Strive to develop institutional holdings that are comprehensive, inclusive, and reflect all key perspectives on Native American issues. Make an effort to collect resources created by, rather than just about, Native Americans.
- Respect and act on both Native American as well as “Western” approaches to caring for archival collections. Traditional knowledge systems possess equal integrity and validity. Actions and policies for preservation, access, and use based on Native American approaches will in some cases be priorities, as a result of consultations with a tribal community.
- Consult with culturally affiliated community representatives to identify those materials that are culturally sensitive and develop procedures for access to and use of those materials.
In the last twenty years collecting institutions have heeded the calls by Indigenous peoples to integrate Indigenous curatorial models and knowledge into mainstream museum and archive practices—from cataloging descriptions to display modes. From the Brian Deer classification system developed by First Nations librarians in Canada to the insertion of warnings for cultural sensitivities on Australian digital archives, these concerns are becoming a central part of the profession. 1 Mukurtu CMS builds these suggestions into its base functionality to provide tribal/community representatives, affiliated scholars, and collections owners a means to interact with and expand the information around individual pieces of content and whole collections. In this way, Mukurtu CMS and its workflows provide the framework for a new mode for the curation, display and classification of archival materials that recognizes the usefulness of integrating multiple sets of standards and information systems.
Print This Page
