...
Maintenance releases necessary to address critical bugs may occur independent of this schedule.
Draft Process
Note - this is a general outline. Further changes may be made over time if ideas for improvement are raised, in particular to early steps (1 -3).
1.Submission
Users submit a feature request or report a bug in the ArchivesSpace Support JIRA
When: rolling basis
2. Initial evaluation of tickets.
ArchivesSpace Program Team (Brad, Christine, Chris & Brian) reviews stories in Support JIRA, request additional information if needed and/or respond to submitter if they think an issue / function is already part of the application; whether it’s a bug that’s already been reported; whether it’s functionality that’s institution-specific. (rolling basis)
May need to separately consider bug tracking and reporting as we could probably make some improvements but it's too big a topic to cover in today's meeting as well. Currently support requests come via a number of channels and this causes problem for everyone involved in the process. Need to encourage users to log tickets in support JIRA.
When: rolling basis
3. Move accepted tickets from Support to Dev JIRA.
ArchivesSpace Program Team (Brad, Christine, Chris & Brian) moves sufficiently detailed feature (and non-duplicative) requests and bugs into Development JIRA and categorize with a label, e.g. Epic e.g. 'EAD export'.
When: rolling basis
4. Prioritization / Grooming meeting.
Development Prioritization team meets and reviews and prioritizes all stories related to a particular Epic / label.
Development Prioritization Team will need to establish criteria and approach to prioritization. Initial ideas for criteria for group to consider:
What's in voted queue
Focus will be on what should be the product of a particular release - e.g. choose a few themes / epics.
Well-documented stories. Hydra Project has a good document about what constitutes a well-documented story **Chris F. to share link.**
potentially factor in some PUI work as a portion of Brian’s time will be focused on this ?
Also, be sure to share information with both documentation groups - TAC and UAC so that updates can be done during the release cycle.
When: Before start of each monthly sprint and/or once before start of a 4-month release cycle
5. Sprint Planning meeting.
Chris + Brian +Brad + chair of FP committee(?) + Testing team (?) meet to look at prioritized set of stories and assess what is possible within sprint & assign stories.
Sprint Planning meeting as handoff - devs would point stories, etc. This could also be an open call for the community to listen in on if interested.
When: Beginning of sprint cycle
6. Development & testing per sprint.
Developers begin work and indicate to testing team when stories are ready to be tested.
Testers for each feature to be identified before beginning of each sprint (?). Testers added as watchers to tickets so will be automatically notified when a feature is ready to be tested.
When: weeks 1 - 3 of each sprint
7. Q/A testing
Program team, and any others, test deliverables of the sprint during the last (4th) week of the sprint and indicate 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
8. Release
The designated Release Manager prepares a Release Candidate three-weeks in advance of the release schedule.
The ASpace 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 Q/A team for resoltuion. 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".
Groups involved:
Prioritization
...
Members: Brian Hoffman, (Julie Patton Prioritization Group liaison / Product Owner, Brad Westbrook - Product Owner), Testing Lead (and/or individual testers), other contributors, (heads of documentation teams may be interested in joining?)
Responsibilities:
for code contributions, unit tests should be included
[Brad to write up notes on overall testing strategy]
Meetings: Sprint planning meetings, 30min standups 3 times / week (M, W, F)
...