Workflow Diagram and Narrative

NOTE: This workflow and narrative applies to JIRA issues with numbers beginning with ANW. Issues with numbers beginning with AR used a different workflow, with Accepted as the final status for most.

Workflow Narrative

A member of the ArchivesSpace community wants to request a new feature or report a bug so they open a JIRA ticket with the default status Newly Added. The Program Team reviews the Newly Added tickets for completeness and changes the status to Awaiting Prioritization for code development tickets to be considered by the Development Prioritization sub-team, Awaiting More Information for tickets that need more description and examples, or Closed-Complete, Closed-Duplicate, or Closed-Will Not Do for tickets that have already been filed or are actually requests for technical or user support.

For code development tickets, the Development Prioritization sub-team reviews the tickets and determines whether there is enough information to determine whether they should move forward. For those for which there is not enough information to determine whether to move forward, the ticket is assigned a status of Awaiting More Information and a comment is added explaining what is needed. Often a specific person or group will be tasked with researching or providing the necessary information. Once the necessary information has been provided, the status will be changed back to Awaiting Prioritization and the ticket will be reconsidered as below.

For tickets for which there is enough information, three outcomes are possible. For any ticket that duplicates another already in JIRA, a comment is added with a reference to the ticket it duplicates, the status is changed to Closed-Duplicate, and the ticket exits the workflow. For any ticket that the sub-team determines we will not do, the status is changed to Closed-Will Not Do and the ticket exits the workflow. For tickets that the sub-team assigns a priority, the status is changed to Ready for Implementation and the ticket moves on. Occasionally tickets are deemed a good idea but that have a very narrow use case or are considered good starter issues for community contribution - these get a label of "community_developer".

Next, as resources permit, the Program Team assigns the ticket to a particular sprint cycle, software version, or developer. Once a developer begins working on the ticket, the status is changed to Development Started.

The developer reviews the ticket. In most cases they proceed to working on it until it is complete. ticket goes through another review by the developer, who determines one of the following:

• If more information is needed or the ticket cannot be worked on by the assigned developer, the ticket may return to Ready for Implementation or Awaiting More Information.

Once the developer has completed their work, they submit a pull request to the ArchivesSpace GitHub repository and change the status to Pull Request Submitted. Once their pull request has been reviewed and deemed complete and acceptable, it will be merged in the ArchivesSpace code and the ticket status is changed to Ready for Testing.

Once the code for the ticket has been tested, if accepted, the status is changed to Ready for Inclusion in Release Candidate. If testing determines it is not ready and there is more work needed, the status is returned to Development Started and the developer will address the issues. When it is ready for retesting, the status is changed back to Ready for Testing.

Once included in the release candidate, the status is changed to Closed-Complete, with the ASpace Version field in the ticket updated with the appropriate release version. Closed-Complete is the final point in the workflow for most tickets.