This document

describes Open-Source Community members

participation in SPARCRequest release process.

SPARC release schedules:

*Research Master ID (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 in the SPARC-OS Development project to report SPARC work requests.  Story types will primarily be feature or bug.  See specifics below on PT entry requirements.   Image RemovedImage Added

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

3. (PO) Update labels story label to denote next steps or information for OS community, who performs the following actions, per labeled status:

   1. (OS) Todostories - begin considering the topic, which will move into another status to further define requirements
   2. (OS) For discussion - participate and respond to requests for additional information and discussion
   3. (OS) Operations agenda - participate in initial meeting discussions about the story that define requirements, if needed.
   4. (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)Ratings: 

      1. High: essential to business operations

      2. Medium: fairly important to business operations

      3. Low: little to no importance on business operations

   5. (OS) Operational committee approved - refer to this final OS committee action for story status 
   6. (OS) Institutional name_contribution - contribute to the story development, following steps 7-10 below

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
   1. (OS) - refer to label for release assignment (e.g., version 3.9.0)
7. (PD; OS) Update story state to Started, moving story into project Current Iteration section.  
8. (PD/PO; OS) Completes Complete story development and testing, per following workflow.
   Image Modified
9. (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.

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

11. (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.

12. (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) 

13. (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

14. (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 communityOS) Participate in the development and testing process by:
   1. Responding to any requests for information or testing through comment entry in the story's Activity section
      Image Added
   2. Entering in pull request when contributing development code.  Include any rake tasks as comments in Activity sectionImage Added

5. (PO) After story acceptance, added to release documentation list

6. (PD) Release deployed to production.  

   1. (OS) Access release documentation for implementation planning
7. (OS) Following 2-week release monitoring, expect to get communication of SPARC's availability for you to implement.