Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

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 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".

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, four 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 most tickets that the sub-team assigns a priority, the status is changed to Ready for Implementation and the ticket moves on. Occasionally tickets that a deemed a good idea but that have a very narrow use case or are considered good starter issues for community contribution may be changed to a status of Ready for 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 a developer begins working on the ticket, the status is changed to Development Started. The ticket goes through another review by the developer, who determines one of the following:

  • There is 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 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 again. When it is ready, 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.

  • No labels