This page describes development processes that allow for developers to maintain consistent workflows and understanding of common practices.

---

The DAILP Software Development team is responsible for maintaining the software units that power DAILP-based sites. There is more information about our software organization and application model under our Technical Design page.

DAILP’s applications follow a three tier architecture:

In order to get started, setting up your environment and understanding our code practices are essential.

Our Developer Workspace Setup and Development Workflows pages have more information on how to get set up, resources on the technologies that we use across our stack, developer tool recommendations, and describes processes of how developers maintain the code driving the website. The Development Workflows page specifically has a contribution guide and onboarding documentation.

All of our developer’s designs and implementations are sustained through our community-based and community-led decision-making and review process with community members. DAILP approves developer designs in light of community members’ needs and community members are included in testing the designs as well as design approval.

Our Community-Based Design page provides an overview of our community-based design methods and links to more specific pages. The Collective Decision-Making Process page describes DAILP’s framework and structured environment for translation, research, and design. The UX Design page provides a description of DAILP’s user experience (UX) design process and accomplishments.

There are some recommended steps on how to create designs and get them ready for implementation:

1. Define the goals of the designs through brainstorming on a document or paper. Some questions to ask yourself are as you draft ideas are:
   • What is the purpose?
   • What is your solution?
   • Who is it designed for?
2. How does this improve or differ from existing solutions?
3. Expand your ideas as a functional specification through writing them down. This includes non-functional requirements, user stories, user personas, functional requirements, and any other details that clarify the problem and solution. You should be continuously thinking about these perspectives as you draft and solidify your design.
4. Create an initial prototype draft. Drafting on paper with erasable writing utensils is recommended. This draft should focus on the experience and layout of the design as opposed to aesthetic and graphic design.
5. Once you have your first prototype draft, continue to evaluate and draft your designs until you have one you feel is suitable.
6. Next, run usability tests with users to review the experience of the design. Have a discussion with the users about the positives of the design, issues, and aspects that could be improved upon. Don’t wait for your design to be ‘perfect’ as feedback is valuable when designs are in early stages. Take notes of the evaluations so you know what you need to change or edit.
7. After receiving feedback, continue to finetune and test your prototypes.
8. Track and document changes between each design iteration with justifications of the changes.
9. As design components are approved and solidified, you can move those design components to implementation as you continue to finalize the rest of the design.

Documentation is integral to DAILP’s mission to prioritize user-focused design and is an open source for tribal communities to establish their own archives for language persistence. Therefore, the DAILP Software Development team is responsible for writing both internal and external facing software and workflow documentation. Some of the documentations include public materials on the DAILP website, the Wiki, developer documentation, and internal documentations. More information about these documentation workflows can be found under the Documentation Workflows section on our Administrative Workflows page.

---

DAILP uses multiple forms of communication methods depending on the task. These include: Meetings, Slack, GitHub, and Google Drive.

All meetings are held in person or over Zoom. DAILP has weekly overall team meetings and the development teams have additional weekly meetings.

DAILP Team Meetings:

These weekly meetings are used to share updates, demo in-progress work, and set priorities across all DAILP teams. Developers are expected to represent their own work, like the design and implementation process, in the form of regular updates and demos. Updates should be presented at a level understandable to the non-technical audience as this meeting is for the entire DAILP Team. However, the information should be detailed enough to paint an accurate picture of the work completed.

Updates should follow this format:

1. What did you do this past week?
2. What will you be doing over the next week?
3. What is blocking you?

Development Team Meeting:

These weekly development team meetings are used to share updates, demo in-progress work, and set priorities within the development team. Developers will share updates then collaborate to select pre-scoped work to take on, define and refine scope for emergent tasks, and review each others’ work. Updates will occur each meeting; demos and scoping will happen as needed. The development team will also cover current and upcoming pull requests as well as work through code issues together. Developers are encouraged to pair program and/or whiteboard together to better complete their work.

The typical flow of these meetings is:

1. Updates - these should be quick summaries to get people ready for longer conversations.
   1. What did you do this past week?
   2. What will you be doing over the next week?
   3. What is blocking you?
2. Demos - showcasing current state of designs and implementations.
   1. What is the expected behavior (as informed by GH Projects specs)?
   2. [For implementation work] Share some examples representative of specified behavior
   3. Walk through the feature from the perspective of a user
   4. Questions and Feedback
3. Scoping - planning and selecting upcoming work.
   1. Discuss current work
      1. Are there any emergent needs or issues that need to be added to GH Projects?
      2. Are items in the “Ready” pool clear and of reasonable scope to developers?
      3. Are any items in current scope (“Ready” through “Community review”) blocked?
   2. Select and assign work from “Ready” pool
   3. Select work to move from “Backlog” to “Ready”

During onboarding, new DAILP team members are added to DAILP’s Slack channel. This is used for quick questions, shorter ongoing updates, and more casual communications. DAILP has specific channels that can be used to communicate with specific teams such as #team-development, a general channel, and the ability to direct message. Slack is also integrating with Github, which means if a software issue is determined in a Slack conversation, you can create an Issue there that feeds over to our repository.

Github operates as a repository, project management system, and communication method. DAILP code is open source and as a result, GitHub is an important place for our outward communication. It holds public-facing communications such as technical documentation, user workflows, and instructional content. All these communications are meant to help others mirror our software in order to stand up their own sites or help users understand more about DALP software. This content is written by student content developers for that audience in mind, but also contains further resources for software dev setup.

From there, the Issues, Pull Requests, and Projects tabs are all places where the development team can see ongoing work in a transparent manner, check for code updates in varying branches, and leave public comments. Software developers can create Issues when an update has been identified, which adds it to the feed and updates the status via the Issues field and comments. The Issues can also be pulled into DAILP’s Projects board and associated with other ongoing work there. (The ‘Project Management and Github Projects’ section below provides more information about DAILP’s Project board) Issues can lastly be associated with pull requests, which is where code is reviewed before being added to the main branch.

All shared documents and drafts for DAILP are created and stored in Google Drive. All DAILP team members use Google Drive to directly edit each other's work or leave feedback on a specific document as well.

The DAILP software development team uses GitHub Projects for our project management, particularly to track our work.

GitHub Projects is a fully integrated project management tool that we use at DAILP. It’s a dynamic collection of items pulled from other parts of GitHub collocated into a table, kanban board, or roadmap view. It enables our team to see tasks in a way that allows them to stay up to date, follow others’ progress, communicate across tasks, and understand how each item being worked on is related to others within the prescribed timeline/long-term objectives. For more information, see Learn about Projects through GitHub.

These are elements that get added to a project:

• Issues: are the backbone of the Projects space and are user-added elements that track bugs, new features, and anything else that requires planning. Issues hold information around the name of the task, its status, its type, other work it relates to, who is involved in it, and places for additional information and comments. Once created, an Issue can be added to the Projects board and situated in relation to other Issues. You can learn more about Issues through Github.
  • Adding Issues: New issues should be created whenever a new feature or task is identified and when planning has been completed. For DAILP, new issues are typically added by our project management team. DAILP operates on an agile schedule with flexible dates. As a result, we assign dates to high priority items that would result in the delay of other work if late.
  • Sub-issues: Using sub-issues helps to break work down into manageable tasks and better showcase the relationship between small steps to larger goals.
• Comments: When clicking into the details on an Issue, there is a space on the bottom to leave comments. This should be used to note any updates as things are in progress, tag another engineer with questions, and flag any delays or hurdles encountered.
• Pull Requests: are engineer-submitted proposals to merge changes from a branch of the code repository into another branch (usually the main branch). They are the main place for the Project Manager to review code, communicate about errors, and track commits or checks for that specific code. Pull requests can and should be linked to a corresponding Issue, which enables users to see the actionable code for a task within a board. Linking Pull requests can be done with Existing PRs and New PRs. You can learn more about Pull Requests through GitHub.

The DAILP Projects space consists of two boards separated by project: software development tasks and documentation. The goal in both boards is to create tasks that are small enough to be manageable and understable, but large enough to accomplish a goal.

Our Board consists of several viewing options:

• Prioritize Backlog
• Planning Board
• Active Work
• Roadmap
• Bugs
• My Items

---

To learn more about our code reviewing process, our page on Code Reviews describes some resources and information that includes how to authorize a pull request and practices for how to review pull requests.