SPARCRequest Wiki

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 20 Next »

Last Updated On:

3/14/2023

IN PROCESS

This document describes Open-Source Community members participation in SPARCRequest release process.


SPARC release schedules:



R1R2R3*R4
SPARC-Request





X
X
SPARC-Dashboard**



X




X

SPARC-Report**

SPARC-Forms**

SPARC-Admin**

SPARC-Fulfillment
X


SPARC-Catalog
X


*Research Master ID (RMID) release

**generally included in SPARC-Request releases

DOCUMENTATION 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 worked on, and when it is completed.  See quick start & demo of Pivotal Tracker HERE.



OPEN-SOURCE BUSINESS PROCESS MODEL








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




PROCEDURES



RESPONSIBLE PARTY

ABBREVIATION*

Project Ops Team

PO

Project Development Team

PD

Open-Source Community Member

OS

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


  1. (OSAdd 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.   

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

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

    1. (OSTodostories - 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)
    5. (OS) Operational committee approved - refer to this final OS committee action for story status 
    6. (OSInstitutional 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) Complete story development and testing, per following workflow.
  9. (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
    2. Entering in pull request when contributing development code.  Include any rake tasks as comments in Activity section
  10. (PO) After story acceptance, added to release documentation list

  11. (PD) Release deployed to production.  

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