-
Notifications
You must be signed in to change notification settings - Fork 5
Administrative Workflows
This page describes what DAILP, as a project, does to organize and support tribal translation teams (e.g., Eastern Band of Cherokee Indians, Anishinaabemowin, and United Keetoowah Band of Cherokee Indians). The translation teams develop and administer processes to create their own digital edited collections. Translation teams develop content and technical documentation for their workflows and the digital edited collections they create.
The DAILP project creates, refines, and sustains the reading and writing environment software and technical documents to hand off to the tribal translation teams.
DAILP’s Project Team Structure consists of:
- Project Leader: Leads community engagement as well as supports language practice and translation
- Project Co-Lead/Technical Lead: Plans and executes technical tasks as well as trains co-ops and work studies
- 1-2 Community Admins: Guides collaborations with DAILP team leaders to create new collections
- 2-3 Community-based Early Career Linguists: Native speakers (especially Cherokee or Anishinaabe)
- 2 Hourly Community Software Developers: Especially Cherokee or Anishinaabe
- Translators: Number to be determined based on project needs
For more specific information on DAILP’s Project Operations, check out our Language-Model page.
Community members lead the process of selecting documents, stories, and information for DAILP’s collection and the process is approached with indigenous data sovereignty in mind.
Community members approve the documents and stories DAILP publishes as well.
Our Collective Decision-Making Process page gives more details about DAILP as a community-based and community-led archive along with information about DAILP’s framework and structured environment.
Our Culturally Sensitive Information page provides additional information on DAILP’s process and approach for selecting and publishing documents.
DAILP's Reading Interface allows users to read edited collections, documents, document metadata, and word details. Our User Workflows page provides how users can use different features of DAILP’s Reading Environment. Cherokees Writing the Keetoowah Way (CWKW), is currently the only collection in the Reading Interface and is a digital collection of edited translations designed to assist scholars, language learners, translators, and teachers through its aims to provide support for Indigenous peoples’ reading and writing practices, language learning, and understanding of words, phrases and translations.
Language learners and translators work together to create translations of the documents and texts in the collection.
Feedback from members of the Cherokee tribal communities and people interested in the Cherokee language such as learners, teachers, and scholars influence the Reading Interface’s design principles.
DAILP’s development team establishes the metadata. Users with a role of Editor or Administrator can approve and edit certain metadata features.
DAILP’s Translation Environments are collaborative through communities of users, have attempted to establish reliable infrastructures for the digital archive, and centered workflows around the input of tribal community members to support and preserve the Cherokee language and practices.
Cherokee community members and English first-language speakers, translators, and learners are collaborators that work closely with the design of the digital translation environment.
Administrators run the user groups of the translation environments and oversee all aspects of the translation team’s workflows.
DAILP’s Reading and Translation Interfaces function as two sides of the same coin, complementing one another to support DAILP's aim for collaborative translation, language learning, preservation, and perseverance of indigenous languages. Our UX Design page has more details of the RI and TI structures and workflows.
The CARE Principles page under Community-Based Design provides information about DAILP’s community-based CARE Principles. This page explains how these principles affect teams and workflows.
There are different sets of documentation workflows within DAILP which include:
-
Public Materials: Are included on the DAILP website.
- About: Include standard information about DAILP’s goals, team, former contributors, project history, references, support, and why DAILP’s work is important. The About section is reviewed and edited when new updates occur.
- Stories: Provide news, events, and highlights of DAILP’s work and of significance to DAILP and its team members. The stories are typically drafted, reviewed by the DAILP team, and then published to the website.
- Spotlights: Include articles that highlight team members and their contributions. Spotlights focus on the experience of community members and student workers. They are typically drafted with any relevant images incorporated, reviewed by the team, and then published to CMS.
-
Technical Standards and Requirements:
-
DAILP is currently testing their site against the Web Content Accessibility Guidelines (WCAG) 2.1 and aim to have technical standards for our website. It’s important to make sure that our content and website is accessible to our audience and that DAILP is accommodating for people who have disabilities. Establishing technical standards and requirements allows our users to have a more user-friendly experience.
-
The technical standards we are currently in compliance with are:
-
1.2.1 Audio-only and Video-only (Prerecorded), Level A: DAILP has text descriptions of all audio files as a byproduct of the type of content we have.
-
2.4.2 Page Titled, Level A: DAILP has web pages and slugs that are appropriately and descriptively titled.
-
2.4.6 Headings and Labels, Level AA: DAILP has headings and labels that describe topic or purpose.
-
2.4.7 Focus Visible, Level AA: DAILP has a keyboard focus indicator that is visible and users are able to find the focus outline.
-
3.1.1 Language of Page, Level A: Screen users can detect English as web page default on DAILP website.
-
3.2.1 On Focus, Level A: User interface component does not initiate a change of context when it receives focus on DAILP’s website.
-
3.2.2 On Input, Level A: DAILP has submit buttons in place so any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.
-
3.2.3 Consistent Navigation, Level AA: DAILP’s Navigation menu order does not change across web pages.
-
3.2.4 Consistent Identification, Level AA: Labels on DAILP’s web pages are consistently applied and have the same functionality.
-
-
-
Wiki:
- The Wiki discusses the overall motivation and design of DAILP and its outputs.
- The process of designing a Wiki page starts with mapping DAILP concepts to specific workflows and outputs. Then a page is outlined and a team writer fills out the details. Once the page is ready, it’s reviewed by the DAILP team, and then published on DAILP’s Github.
- New pages drilling in on large concepts are created as needed.
-
Developer Documentation:
- GQL playground: Allows DAILP’s developers to test GQL queries and view GQL schema and functions. Written by devs using rustdoc on types that are exposed to GQL.
-
DAILP Rustdoc: Describes rust datatypes that fuel our backend. Written by devs using rustdoc comments.
- Comments provide additional context to developers.
-
Internal Documentation:
- GitHub projects: Provide definitions of work for developers and are usually written by DAILP developers or the DAILP admin team.
- PR Discussions: Describe what work has been done on a task, provide context about implementation, and facilitate feedback on code changes.
For all members being on-boarded to the DAILP team, we provide the following team-training materials:
-
Documentation of DAILP’s Brief Project History which provides overviews of DAILP’s project progression within 3 phases.
-
DAILP’s Table of Contents which provides important links for each of our workflows.
-
DAILP’s Comprehensive Job Aid which includes a project overview, our philosophical principles, an organizational chart, an overview of different student roles within DAILP, content and workflow overview, and helpful linked resources.
-
Documentation of a Glossary of Terms that is frequently used by DAILP teams.
The team-training materials for the Development team is provided on the Development Workflows page and Developer Workspace Setup page.
Upcoming for Spring of 2026, DAILP will also provide documentation of our Development and Linguistic teams, training materials on software, and materials for onboarding co-ops.
*If you would like to see these Team-Training Materials, please reach out to @chullings
As DAILP grows, grants are an important aspect of how we support the DAILP project, workflows, and teams.
DAILP plans grants with community-based teams and supports them in the application process.
Please see grant white papers here:
NEH DHAG Level II: Cushman, E. (2024, June 30). Translating Cherokee Manuscripts: Creating a Writing Environment for DAILP. National Endowment for the Humanities. https://apps.neh.gov/publicquery/AwardDetail.aspx?gn=HAA-284836-22
The NEH DHAG Level III grant was award in December 2024 and terminated in March 2025. https://apps.neh.gov/publicquery/AwardDetail.aspx?gn=HAA-303987-25
- CARE Principles
- Collective Decision-Making Process
- Data Resilience
- Culturally-Sensitive Information
- UX Design
- Metadata
- User Contributed Audio
- Audio Data Process
- Manuscript Annotation and Analysis
- Language Specific Limitations
- Annotation and Analysis (Before 2024)
- Code Standards
- AWS Diagnostics and Triage Guide
- Cloud Architecture
- Development Environments
- Data Representation
- Data Migration
- User Groups and Roles
- Wordpress Content
- Web Design & Accessibility