The current process is:
- A bug or feature request is submittedsubmitted by an ArchivesSpace user(s) or by the Program Team on a users’ behalf.These requests can be entered at any time. To speed up the process, requests should be thoroughly described.
- Initial evaluation of newly submitted requests is performed by the ArchivesSpace Program Team on a regular basis. The Program Team will ask the requester to provide further information to the issue if needed. For sufficiently described features, the Program Team checks if the feature and/or bug:
- has already been reported
- has already been addressed or is a feature already in the application
- is institution-specific
- Move of requests to “icebox” in ArchivesSpace development queue. If a request is not a duplicate, describes new functionality and is generic rather than specific, the Program Team moves the issue to the the “icebox” in the ArchivesSpace development JIRA and assigns it a Epic label so it can be viewed alongside similar issues – e.g. ‘EAD export’, ‘container management’.
- Development prioritization. On at least a monthly basis, the Development Prioritization Team reviews and prioritizes according to established criteria all new issues without pre-assigned development resources, i.e. where an individual or organization has not already committed developer time to work on them. If a feature or bug is not adequately described to hand off to a developer, the developers may follow up with the requester for additional information.
- Open Scrum meeting to assign work. On a monthly basis a virtual scrum meeting is held to assign development work for the upcoming, month-long sprint. Anyone in the community may join the call but only those willing to take on work assignments can participate. Required attendees include the ArchivesSpace Program developers, the Program Manager, Testing subteam lead (or representative) and Development Prioritization subteam lead (or representative). Members of the documentation sub-teams are also encouraged to join in order to take on documentation work associated with new functionality. A more detailed description of this meeting is available here.
- Development and testing. During weeks 1 – 3 of each month-long sprint, the Program Team and community developers work on code and documentation. As a developer completes a story, the work is handed off to a pre-assigned tester from the Testing sub-team. The Tester will be added as a watcher to tickets so they can be automatically notified when a features is ready to be tested.
- Quality assurance testing. During the last week of each sprint, the Program Team performs final tests on all work delivered during the sprint. Based on the results of Q/A testing, the Program Team indicates which stories are accepted for the scheduled release and which are rejected. Rejected stories may be resolved during the last week of the sprint, deferred to the next sprint, or placed into the backlog for a future release.
- Final testing and release. The designated Release Manager prepares a Release Candidate three-weeks in advance of the next release date. The ArchivesSpace Community Support Manager notifies the community of the presence of the release candidate, indicates new features and bug fixes in the release, and invites the community to test those additions as well as other areas of the application. Problems reported are cycled back to the Program Team for resolution. Problems may be resolved prior to the release and included in it, or removed from the release and targeted for a later release. The designated Release Manager prepares the release, after the community testing period is over and all resolutions made. The Community Support Manager announces the distribution of the release, indicating the new features and bug fixes that made it into the release, as well as those that ultimately "fell out".