Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Note - this is a general outline. Further changes and refinements may be made over time if ideas for as groups are get underway with new cycle and ideas as improvement are raised, in particular to early steps (1 -3).

1.Submission

Users submit Who: Users

Process step description: Submit a feature request or report a bug in the ArchivesSpace Support JIRA

...

2. Initial evaluation of tickets.

Who: ArchivesSpace Program Team (Brad, Christine, Chris & Brian) reviews

Process step description: 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  

It would be good for some group to consider improvements to steps 1 - 3 to in particular 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 also 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.

Who: ArchivesSpace Program Team (Brad, Christine, Chris & Brian) 

Process step description: 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'.

...

4. Prioritization / Grooming meeting.

Who: Development Prioritization team

Process step description:  meets and reviews and prioritizes all stories related to a particular Epic / label. See charge of prioritization group (below) for additional info. After prioritization meeting, group 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.

Who: Chris + Brian +Brad + chair of FP committee(?) + Testing team (?) meet Fitzpatrick, Brian Hoffman, Julie Patton Prioritization Group liaison (co-Product Owner?), Brad Westbrook - Product Owner, Testing Lead (and/or individual testers), other contributors, (heads of documentation teams may be interested in joining?)

Process step description: 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 will also be an open call for the community to listen in on if interestedTesting team lead to identify testers at beginning of each sprint (before, during or after sprint planning meeting?). 

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 Who: Agile Team

Process step description: Agile team to work on code and documentation and testers to test functionality as stories are delivered.

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

Who: Program team , and any others, test ( + others?)

Process step description:  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

When: last (4th) week of the sprint

8.  Release

Who: Release Manager, Community Support Manager 

Process step description: The designated Release Manager prepares a Release Candidate three-weeks in advance of the release schedule.

...

Problems reported are cycled back to the Q/A team for resoltuionfor resolution.  Problems may be resolved prior to the release and included in it, or removed from the release and targeted for a later 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".

When: three-weeks in advance of the release schedule - release date

 

Groups involved:

Development Prioritization

Task:  On the basis of feature requests and bug reports filed in the development catalog, this team prioritizes development work for each schedule features release (1 per every four months) in advance of the first sprint for each features release.  

...

Leader/ Scrummaster: Chris Fitzpatrick

Members: Chris Fitzpatrick, Brian Hoffman, (Julie Patton Prioritization Group liaison / (co-Product Owner?) , Brad Westbrook - Product Owner), Testing Lead (and/or individual testers), other contributors, (heads of documentation teams may be interested in joining?)

...