Info | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
11/21/2022
|
This document includes information describing how Open-Source Community members participate in SPARCRequest release process.
SPARC release schedules:
R1 | R2 | R3* | R4 | ||
---|---|---|---|---|---|
SPARC-Request | X | X | |||
SPARC-Dashboard** | X | X | |||
SPARC-Report** | |||||
SPARC-Forms** | |||||
SPARC-Admin** | |||||
SPARC-Fulfillment | X | ||||
SPARC-Catalog | X |
*RMID release
**generally included in SPARC-Request releases
PROCESS
Pivotal Tracker is the project-planning tool used to track development work for each managed product. Deliverables are in the form of stories (virtual cards) that move through a workflow of different states. Priorities are established and transparent so team members know what needs to be done, what is being done, and when it will be completed. See quick start & demo of Pivotal Tracker HERE.
OPEN-SOURCE BUSINESS PROCESS MODEL
PROCEDURES
RESPONSIBLE PARTY | ABBREVIATION* |
---|---|
Project Ops Team | PO |
Project Development Team | PD |
Open-Source Member | OS |
*Responsible parties' abbreviations appear in parentheses preceding the tasks below
(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.
(PO) Define story requirements to move forward in the development cycle
(PO) Update story label to denote next steps or information for OS community
- (OS) For discussion - participate and respond to requests for additional information and discussion
- (OS) Operations agenda - participate in initial meeting discussions about the story that define requirements
- (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)
- (OS) Operational committee approved - refer to this final OS committee action for story status
- (OS) Institutional name_contribution - contribute to the story development, following steps 7-10 below)
(PO) Include story in project Backlog section to prioritize for a release (iteration).
- (PO, PD) Determine stories that will go in next sprint cycle
- (PO) Assign story to release
- (OS) - refer to label for release assignment (e.g., version 3.9.0)
- (PD; OS) Update story state to Started, moving story into project Current Iteration section.
- (PD/PO; OS) Complete story development and testing, per following workflow.
- (OS) Participate in the development and testing process by:
- Responding to any requests for information or testing through comment entry in the story's Activity section.
- Entering in pull request when contributing development code. Include any rake tasks as comments in Activity section.
(PO) After story acceptance, added to release documentation list
(PD) Release deployed to production
Review the Current Iteration Release Marker for necessary tasks and instructions.
(PC, PM) Perform production testing/review
Update the PT Release marker with testing notes.
(PC) Update Research community on release:
MUSC Blog (Wiki): MUSC Internal Blog
VPR Newsletter – email to Rachel Mehard.
SCTR Newsletter – Communications Request Form
Horseshoe website changes – Communications Request Form
Monitor Release
(PM, PC) Production monitoring for release application issues up to 2 weeks.
(DM, SD, DV, PC, PM) Fix any issues, as required.
(PM) Accept PT Release marker to close release.
(DM) Release GitHub for open-source community.
- (OS) Access release documentation for implementation planning
- (OS) Following 2-week release monitoring, expect to get communication of SPARC's availability for you to implement.