The goal of the Avalon Media System is to create something so valued that people insist on sustaining it.
Primary software development is occurring at Indiana University and Northwestern University, with potential contributions from several of our test and implementation sites. Test sites will provide input on requirements, design, and evaluation as they install and use the software. We plan to transition primary development and support to a self-sustaining open source community by the end of the grant period (September 2014). Broad community engagement and adoption are the most important means of ensuring the ongoing availability and maintenance of any open source system; to this end, rather than a monolithic code base with a “black box” architecture, the Avalon Media System will support more open connectivity between components. This will make it easier for future contributors and users to add or remove parts based on their needs.
We believe that the partners involved in this project will be critical to creating an open source community committed to improving and sustaining the Avalon Media System. These partnerships represent only the beginning of active discussions with the broader library and archives community about requirements and use cases. Feedback from testers and potential users is encouraged; it will be a crucial component of Avalon's development, as requirements will continuously be refined throughout the Agile development process. The project team will conduct regular online software demonstrations as components are completed, to be promoted via appropriate mailing lists and other online venues, and use these to gather feedback for development cycles. Recordings of demonstrations of the work on Avalon are posted every 2 weeks.
The Avalon team uses the Agile development process for the design, development, integration, test, and delivery of the system. Using the Agile development process allows for a highly flexible and interactive method of receiving timely feedback about Avalon requirements and design. In this process, the team generates and manages requirements through User Stories. Sprints refer to work committed to by the team to be complete and demonstrated at the end of two week cycles. Sprints can be altered to accommodate outside meetings with subject matter experts that may provide timely feedback for the project.
The Scrum/Agile process consists of two regularly occurring meetings: Daily Stand-Ups and Sprint Planning Sessions.
Daily Stand-Ups. The purpose of the daily stand-up meeting is to report what team members did the previous day, pull tasks (what they will be working on) for the day, discuss progress and briefly mention any impediments encountered the course of the sprint.
Sprint Planning Sessions. During the Sprint Planning Sessions, the meeting is divided into 3 major parts: demo, retrospective and sprint planning. In the demo portion, team members show the results of the sprint. Demos will be recorded and available to the public.
During the retrospective, team members evaluate how effective the team was at completing the stories during the sprint. During sprint planning, the entire team discussed the stories that will be included in the next sprint. Each story is described and prioritized. After the stories are described, team members (excluding the scrum master and project owners) simultaneously write tasks for the stories. The team comes back together to review tasks, add notes and pull tasks.