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

Image Added

PROCEDURES

*Responsible parties' abbreviations appear in parentheses preceding the task

OPEN-SOURCE BUSINESS PROCESS MODEL

Describes Open-Source Community process for product bug fixes and features implementation

Image Removed

PROCEDURES

Plan deliverablestasks below

1. (OS)

     

    Add a Pivotal

   tracker

   Tracker (PT) Icebox story in the SPARC-OS Development project to report SPARC work requests. 

   See story types definitions - these will

   Story types will primarily be feature or bug.  See specifics below on PT entry requirements.   

   Image Removed

   Image Added

2. (

   PL, PM, DM, SD

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

   .

3. (

   PM) Label for outcome as needed (e.g., os cmte approved, etc.)
4. (PM) Drag story to Backlog
   1. Backlog is designed house upcoming stories that are prioritized for a release (iteration). 
5. (PM) Create/Update Release Marker
   1. Update Backlog Release story title for the next release.  It will be used to distinguish between backlogged stories ready for pick up - those above this marker are eligible.
   2. Create new Current Iteration Release Marker story as a milestone marker, labeling it for current release.  It will be used for final release notations.
      1. Current iteration displays in-progress (started) stories that are prioritized to be worked on for the current release.
6. (PL, PM) Prioritize in Backlog for what can go in the next release & what developers can pick up to work on, labeling for the next release.
   1. Remove previous label if story no longer being added to next release, as applicable
   2. Bugs are placed at top, then features, then chores.
   3. Release story appears at the bottom of prioritized stories to delineate between those currently scheduled for a release.

Fulfill deliverables

Image Removed

1. (DV) Pick up story from Backlog top of list, above the release marker.
   1. Add self as owner & click the Start button.  This moves story which moves story to Started state & into Current Iteration
   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

   PO) Update 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 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)Image AddedRatings: 

      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

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

6. (PO, PD) Determine stories that will go in next sprint cycle
7. (PO) Assign story to release
   1. (OS) - refer to label for release assignment (e.g., version 3.9.0)
8. (PD; OS) Update story state to Started, moving story into project Current Iteration section.  
9. (PD/PO; OS) Complete story development and testing, per following workflow.
   Image Added
10. (OS) 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

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

12. (PD) Release deployed to production.  

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