Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Status
colourRed
titlePILOT
Status
colourGreen
titleVersion 2




Table of Contents

Introduction


The intent of this test plan is to define the testing and expected result of the Project Scope Statement Approval Pilot on Confluence using the “Project Scope Statement” space (https://confluence.hl7.org/display/PSS/Project+Scope+Statement ) and the Jira project: Project Scope Statement ( https:/s/jira.hl7.org/projects/PSS/issues/?filter=allopenissues ).

There are five (5) roles in the Project Scope Statement approval, all of which will test the Project Scope Statement approval process according to their role.

The Project Scope Statement was designed with the following in mind:

  • An effective tracking method must exist for PSS’s (Project Scope Statements) in their approval process, to include final approval.
  • The PMO (Project Management Officer) will be notified upon creation and publication of each PSS.
  • The most recent Static PSS template must be used by all PSS Creators (HL7 Project Scope Statement Template).
  • The PSS must undergo the follow workflow before final Approval:


Overview


Drawio
bordertrue
diagramNameversion 2.a confluence-jira
simpleViewerfalse
width1200
linksauto
tbstyletop
diagramDisplayName
lboxtrue
diagramWidth1806
revision2


Confluence Project Scope Statement Listener Page (for Pilot)


PSS Approvals in Jira

Roles


There are five roles in total for each PSS review. In all roles, the user is expected to be a registered confluence.hl7.org user.

  • Creators – Users within a workgroup that author and setup the initial PSS Template. This user will be responsible for “Watching” the PSS page.
  • Sponsoring WorkGroup – The initial group to review a PSS Draft. A vote (with link to PSS) will be necessary to decide approval.
  • Reviewing Groups – Co-sponsoring WorkGroups, FHIR Management Group, V2 Management Group, CDA Management Group, US Realm, Architecture Review Board, Steering Division – (one of the follow four groups: Infrastructure Steering Division, Clinical Steering Division, Administrative Steering Division, Organizational Support Steering Division), Technical Steering Committee – (group who will review and cast vote for the TSC
  • Project Management Officer – user who will conduct PMO updates
  • Administrator – user responsible for functioning PSS approval environment


Reviews


Reviews will be conducted by a state transition of sub-tasks according to appropriate approving group.

History of all actions is recorded under the "History" tab on the Parent Issue in Jira.

Agree

This transition against the sub-task for the reviewing group signifies that as the group approves of the PSS as it currently is. 

Disagree

This transition against the sub-task for the reviewing group signifies that some element of the PSS does not satisfy a criteria that the reviewing group is holding to.  A comment is required upon disagreeing with the PSS. Once the issue has been transitioned, the sponsoring WG will be notified. They will see your comment and may reach out to you through native Jira tools (@mentions or comments against the sub-task issue). After the issue is resolved, the reviewing group is still responsible for verifying the change and transitioning the sub-task to agree. If they do not, the TSC will have authority to question if issue was resolved or still in disagreement (through pilot). 


NOTE: any revisions are seen as supporting work to accomplish the PSS approval but will not be recognized in official workflow/approval. The TSC is the only official approval present.  


Testing Process


  1. A Creator will author a PSS in the appropriate space/ use existing PSS.  
  2. The Sponsoring WorkGroup will review/approve/comment for revision.
  3. The PMO will receive notification and insert Project ID into PSS.
  4. The Creator will transition PSS to Sponsoring Workgroup Approval, notifying applicable groups.
  5. Reviewing Groups will review/approve/comment for revision.
  6. The Creator will monitor PSS for all approvals/revisions/comments and transition
  7. Upon Consensus-Review completion/manual step/timeout (1 month) the TSC will be notified.
  8. The TSC will review/approve/reject/comment for small revision.
  9. Upon TSC approval the PSS will enter the Published State.
  10. Upon the Published State being reached, all feedback will be reviewed by Administrator and handled (either brought to group for approval/implementation or direct implementation
  11. Administrator will compose a Post Test Review and present to testing group.

Creation Process


How to Create a PSS PILOT

Review/Approval Process


How to Approve a PSS PILOT


For the Sponsoring WG

You will be receiving a notification for each Reviewing Group as they transition their sub-task. They may agree or disagree. If they disagree, they will provide a comment. You may then go in and review. Once, a conclusion has been reached and change made, you may transition the appropriate approval group's sub-task to "Review" so that they may be formally notified that a change has occurred. They will then come in and review. This cycle may continue until the reviewing group either agrees or the PSS is transitioned to the TSC either by a time constraint or curator. 


Specific Role Assignments


(those taking part in the PILOT)

Work Groups:

TBD


Management Groups:

TBD


US Realm:

Dave Hamill

Steering Division:

TBD

TSC:

TSC

Administrator: Joshua Procious


Pilot Walkthrough


Info

Placeholder for video walkthrough


Feedback/Issues


https://jira.hl7.org/secure/CreateIssue.jspa?pid=11400&issuetype=10200

Help/Good practices

  • Two tabs open. One with PSS in Confluence. One with Jira Issue.
  • If things behave unexpectedly, first check should always be if you're logged in for both Jira and Confluence. If you are not, certain elements will not be displayed. 
  • Documentation & Help