This document includes information describing how Open-Source Community members participate in SPARCRequest release process.

SPARC release schedules:

*RMID release

**generally included in SPARC-Request releases

OPEN-SOURCE BUSINESS PROCESS MODEL

PROCEDURES

*Responsible parties' abbreviations appear in parentheses preceding the tasks below

Plan deliverables

1. (OS) Add a Pivotal Tracker (PT) Icebox story to report SPARC work requests.  Story types will primarily be feature or bug.  See specifics below on PT entry requirements.   

2. (PO) Define story requirements to move forward in the development cycle

3. (PO) Update labels to denote next steps for OS community

   1. (OS) For discussion - participate and respond to requests for additional information and discussion
   2. (OS) Operations agenda - participate in initial meeting discussions about the story that define requirements
   3. (OS) For review - perform and document a review of the proposed feature or reported bugs, recording institutional priority as a task on the story (see example below)
   4. (OS) Operational committee approved - refer to this final OS committee action for story status 

4. (PO) Include story in project Backlog section to prioritize for a release (iteration). 

5. (PO, PD) Determine stories that will go in next sprint cycle
6. (PO) Assign story to release
7. (PD) Update story state to Started, moving story into project Current Iteration section.  
8. (PD/PO) Completes story development and testing, per following workflow

1. (DV) Pick up story from Backlog top of list, above the release marker.

   1. Add self as owner & click the Start button

   2. Enter story comments, as well as provide updates at weekly meetings.  Get assistance as needed.

2. (PM) Drag backlog stories to the Current Iteration for maintenance as needed (e.g., assigning specific stories, record tracking & clean up, etc)

3. (DV) When finished work, click Finish button to move story into Finished state.

   1. Submit a Github pull request to have code applied to test environment. See Best Practice Styling Guide HERE.

4. (DV) After coding applied to test, click Deliver button to move story to Delivered state to indicate it’s now ready for testing.

   1.  Add story comments describing necessary deployment tasks (e.g., settings changes, rake tasks, local environment updates, etc.).  These provide instruction for any additional deployment post code changes needed.

      1. Also add these deployment tasks within the Tasks section of the Release Marker story (at the bottom of the Current Iterations) 

5. (PM) To begin documenting required testing, enter in reviews for: Test Design (primarily tests function) and Test QA (tests function + quality), as required for both types of reviews.  In general, a minimum of 2 people should test for acceptance of Features and for other types of stories as determined.  

   1. Test Design In Review status naming PC

   2. Test QA In Review status naming PM

6. (PC, PM) Test the story, entering in comments as needed to clarify work through testing results. 

   1. Enter story label for testing date (e.g., testing DATE)

   2. Record succinct description of Acceptance Testing, emphasizing outcome, questions and issues

   3. Attach any additional or details testing notes for reference

   4. As appropriate, engage user in reviewing the change, especially if a change was suggested by a user group.  Record any testing notes or change requests, updating story with acceptance as described below.

   5. If accepted with no additional changes needed:

      1. Add a review:

         1. (PC) Enter in Test Design Pass review with initials

         2. (PM) Enter in Test QA Pass review with initials

         3. (DV) May include code and/or security review with initials, as necessary

      2. (PM) Click Accept button to move story to Accepted state. It’s now ready for the release.

   6. (PM) If additional clarification needed before can be accepted, update story with questions and comments. Keep in Delivered state. 

   1. When clarification fulfills acceptance criteria:

      1. Enter in Test QA Pass review with initials

      2. Click Accept button to move story to Accepted state (or Finish button for Chores).  It’s now ready for the release.

   7. (PM) If unable to accept (e.g., due to more work needed, new issues, etc.):

      1. Add a review:

         1. (PC) Enter in Test Design Revise review with initials

         2. (PM) Enter in Test QA Revise review with initials

            1. Change state back to Started and update story with details. The story goes back through this Steps #3-#5 process through acceptance.

Prepare for Release 

1. (PM) Evaluate stories, with Team as needed

   1. Current Iteration for removal if story won't make it into the release.

   2. Backlog or Icebox for adding to the release

2. (PC) Draft Release notes on SPARC Wiki.

   1. Add stories as they are completed

3. (PM) Confirm all stories scheduled for release are accepted and documented for product deployment.

4. (PC) Prepare final Release notes

   1. Features & Bug Fixes (all stories)

   2. Rake Tasks and Setting Changes

   3. Programming Changes with Links to GitHub.

5. (PM) Review drafted Release notes for final edits.

Implement Release

1. (DM, SD) Deploy release to production

   1. Review the Current Iteration Release Marker for necessary tasks and instructions.

2. (PC, PM) Perform production testing/review 

1. Update the PT Release marker with testing notes.

3. (PC) Update Research community on release:

   1. MUSC Blog (Wiki): MUSC Internal Blog

   2. VPR Newsletter – email to Rachel Mehard.

   3. SCTR Newsletter – Communications Request Form

   4. Horseshoe website changes – Communications Request Form

Monitor Release

1. (PM, PC) Production monitoring for release application issues up to 2 weeks.

2. (DM, SD, DV, PC, PM) Fix any issues, as required.

3. (PM) Accept PT Release marker to close release.

4. (DM) Release GitHub for open-source community