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 Support for support tickets, 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 In Review Closed-Complete, Closed-Duplicate, or Closed-Will Not Do for tickets that have been looked at by the Program Team but the next step has not been determined yet.For support tickets, the Program Team will follow-up with the reporter and determine how to satisfy the need. Once the support is finished, the status is changed to Closed-Complete after the ASpace Version field in the ticket is updated with "No Version"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 any ticket 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. The status is changed to Developer Assigned. Once 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:
- There is If more information needed so the developer changes the status to Waiting for Questions to be Answered after documenting questions in the ticket using comments. Once the questions have been answered, the status returns to Development Started.
- It doesn't need code implemented so the developer changes the status to Awaiting Support (NOTE: this won't happen often but an example could be that the Program Team thinks the ticket needs an indexing code change but it is determined that a re-index is required instead.)
- It is ready for implementation so the developer completes the implementation and changes the status 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 changed to Rejected. For Rejected tickets, when a developer is ready to start work on the ticket again, the developer changes the status back to Development Started and begins work on the ticket againreturned 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.
...