Selecting prioritized tickets for development work

Once tickets have been reviewed and approved by the Development Prioritization sub-team, they become available to be worked on by developers and are added to the prioritized backlog. The Program Team regularly reviews prioritized tickets to match them with available development resources. Just like many of the archives we serve, we have a substantial backlog due to the size of the community and the relative level of demand for ArchivesSpace compared to the finite resources of a relatively small non-profit organization. When a compelling case can be made that there will be funds available to do more without harming ArchivesSpace’s long-term sustainability, the Program Team works with the ArchivesSpace Governance Board to get additional resources, such as with the recent addition of a full-time Front End Developer to the team.

Sources of development include staff developers, developers from Registered Service Providers, contractors (individuals or firms), and community developers. While many people contribute to the development process, and in some cases volunteers contribute code, in most releases of ArchivesSpace over 95% of the code comes from staff developers or those contracted by the team. Funds for development come almost entirely from membership fees.

Tickets vary greatly in complexity. They may be something as simple as changing the wording of a label or as complex as reconceptualizing a whole area of the application. It is important to note that even if a request sounds simple it may not be when it comes to writing the code to fulfill it. In selecting approved tickets to be worked on the team needs to match them to the capacity of our available developers. Because of the complexity and specialized domain of ArchivesSpace, there are many tickets that require sustained effort and expertise, as well as flexibility and ready access to community members so that they can be fulfilled using a collaborative, iterative implementation process. Staff developers are often the best choice for such work.

You may notice that there are times that lower priority tickets get worked on sooner than higher priority ones, and that an ArchivesSpace release may contain a larger number of tickets you consider lower priority compared to a feature you’ve been anxiously awaiting. This is because there are more possibilities for development solutions addressing these kinds of tickets. (If it helps, think of this as similar to making decisions about who can work on what in your archives successfully, and why certain piles get worked down more quickly than others.)

The roadmap, which is informed by taking a long view of overall priorities through past surveys and formal and informal community discussions and distributed to the community, serves as the guidepost for determining larger projects to work on. It is usually the basis for creating sprints of issues from the prioritized backlog. The program team aims to update the roadmap after each release and when there are major changes due to unexpected changes in staffing or outside conditions.

It is important to remember that much of the development effort that goes into ArchivesSpace relates to things that a user can’t necessarily see but are important to ongoing maintenance, like updating dependencies and creating automated tests. (If it helps, think of this as the relative amount of effort that goes into keeping the lights on, doors open, the desk staffed, and other routine activities in your archives going, compared to taking on new projects.) We also look for opportunities to pay down technical debt where we can. This kind of work does not usually go up for review by the Development Prioritization sub-team because of its specialized nature.

Also, while the Program Team tries to minimize such occurrences, not all user-facing tickets go through the Development Prioritization process. Sometimes issues are found during testing or the course of other work that require attention earlier than tickets already in the queue (sometimes addressing them is necessary to address the original issue). In such cases we try to minimize the impact on larger roadmap projects when possible.

As with everything we do, selecting tickets and larger areas of development focus is an iterative process, and is informed by shifting community needs over time. We welcome feedback and participation along the way.