ArchivesSpace isn't perfect software. It contains bugs, lacks features, and has room for improvement like any other piece of software. Like most software programs, the ArchivesSpace program makes use of an issue tracking tool to manage known outstanding issues with the software. But perhaps unlike most software programs, we try to keep our issue tracker relatively free of debris. It's not that we don't want to hear about ArchivesSpace's problems — after all, we can't fix what we don't know is broken. It's just that we've found a mismanaged issue tracker to be more of a hindrance than a help.
The following are the policies that we ask folks to abide by when reporting problems or requested enhancements to ArchivesSpace.

How to report a bug

The process is described in the ArchivesSpace wiki: {+}https://archivesspace.atlassian.net/wiki/display/ADC/How+to+Report+a+Bug+.

How to request a new feature

The process is described in the ArchivesSpace wiki: {+}https://archivesspace.atlassian.net/wiki/display/ADC/How+to+Request+a+New+Feature+.

Issue management

Using JIRA sprints to manage issues is an important aspect of how the ArchivesSpace Program Team and core committers organize their efforts and communicate with each other and with the ArchivesSpace community at large. ArchivesSpace's sprints tend to be named to reflect release version numbers and variations thereof. The statuses of the JIRA issues are used to designate specific steps in the issues management workflow, so it's important to understand their meanings.

Example Issue Workflow

A member of the ArchivesSpace community wants to request a new feature or report a bug so they open a JIRA ticket (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, "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" after the ASpace Version field in the ticket is updated with "No Version".
For code development tickets, the prioritization Subteam reviews the tickets for duplicates. A comment is added to the duplicate ticket with a reference to the ticket it duplicates, the status of duplicate tickets is changed to "Closed-Duplicate", and the ticket exits the workflow. For tickets that the prioritization Subteam determines we will not do, the status is changed to "Closed-Will Not Do" and the ticket exits the workflow. For tickets that the prioritization Subteam assign a priority, the status is changed to "Ready for Implementation". Next, the Program Team assigns the ticket to a particular sprint cycle, software version, or the backlog and the status is changed to "Not Yet Started". The ticket is then assigned to a developer who sets the status to "Started".
The ticket goes through another review by the developer who determines one of the following:
1. 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
2. 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.)
3. 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" and, if rejected because there is more work needed, the status is changed to "Rejected". When a developer is ready to start work on the ticket again, the developer changes the status back to "Started" and begins work on the ticket again. Once included in the release candidate, the status is changed to "Closed" once the ASpace Version field in the ticket is updated with the appropriate release version.