UTG proposals go through several Jira workflow states from proposal to resolution. The documentation below describes each workflow state, providing links to additional guidance where appropriate.
Environment Setup
Upon initial creation of the UP Jira ticket, the proposal will be in the Environment Setup state. This state is intended for submitters to install an XML Editor and Sourcetree, which is required to manage your local vocabulary changes and push those changes back to the branch that you are using to submit your proposal.
From the Environment Setup state, users may either move into Waiting for Input (through the Identified Content Issue transition) or Proposal Draft (through the Draft a Proposal transition).
- Waiting for Input - Tickets should be transitioned into this state if the resolution of the ticket is unclear. Note that tickets in this state will not be picked up by any WG and it is the responsibility of the submitter to determine a resolution. Otherwise, the ticket will likely remain in this state for a very long time
- Proposal Draft - Tickets should be transitioned into this state if the resolution is clear and the submitter is ready to create the vocabulary changes.
Waiting For Input
Tickets in the Waiting for Input state note a vocabulary issue or change that is needed, but the solution may still be unclear. The submitter should communicate the issue or change request to the appropriate Work Group to determine a resolution.
Once the ticket has a resolution, it can be moved into the Proposal Draft state through the Draft a Proposal transition.
If it is determine that the change is no longer needed, it can be moved into the Change Not Needed state through the No Chg Req state.
Change Not Needed
Tickets in this state indicate that an issue or change request was logged, but it was determined that the change was not needed or that there is no issue to fix. The ticket is now closed.
Proposal Draft
The Proposal Draft state is the state where proposed changes will be made in a local copy of a branch of THO content that is specific to your ticket.
The following steps should be followed:
Create a Branch and Download Local Copy of Content
Specifying the Details Inside the Proposal
Saving and Committing Proposed Changes
If the changes are no longer needed, the submitter can Withdraw the ticket using the Abandon transition.
Submitted
Tickets in the Submitted state indicate that the proposed changes have been saved and committed to the branch specific to this ticket.
The Terminology Curator will pick up tickets in this state and start reviewing the content, at which point the ticket will be transitioned to the Content Check state.
There is nothing for the submitter to do at this point. However, if the submitter recognizes an error in the submitted content, they may pull the proposal back into Proposal Draft through the Return to Draft transition.
Content Check
Tickets in the Content Check state are being reviewed by the Terminology Curator. If the proposed changes do not cause errors in the THO build, the Curator will move the ticket into the Consensus Review state for voting. If the proposed changes cause errors, the Curator will move the ticket back to Proposal Draft and add a comment indicating the errors and/or what needs to be fixed to resubmit.
During this state, a Published Example link will be added to the proposal, which will link to a THO build that is specific to the branch of the ticket so that proposed changes may be reviewed in the context of THO.
QC Review
This is for Pro Forma tickets only. This allows for the submitter to visually verify their changes before they are implemented.
Consensus Review
The ticket is open for voting from the HL7 community. It is often helpful for the ticket submitter to socialize the proposal in an effort to solicit feedback and votes.
If the submitter needs to pause voting for any reason, the proposal can be transitioned to the Tabled state using the Pause Voting transition.
If the submitter receives feedback that something needs to be fixed, they may pull the proposal back into Proposal Draft through the Needs Revision transition.
If the submitter receives feedback that that change isn't needed, they may Withdraw the ticket through the Abandon transition.
For more information about the voting process, see Consensus Review and Voting Process.
Tabled
Tabled tickets are tickets in which the voting has been paused.
The voting can be resumed by pushing it back to the Consensus Review state using the Resume Voting transition. The proposal can also be pushed back into Proposal Draft through the Draft transition.
Meeting Needed
The Meeting Needed state indicates that a proposal is controversial and a meeting is needed to resolve the request. The Assignee of the proposal is required to set up a conference call (either on a Work Group call of the sponsoring WG, or a separate call with people who need to come to agreement). Setting up the meeting is a manual step outside of the Jira workflow.
For more information, see Handling 'Meeting Needed' Proposal Outcome.
Change Rejected
The Change Rejected state indicates that the community rejected the proposal and that the proposed changes will not be implemented. The ticket is now closed.
Withdrawn
The Withdrawn state indicates that the submitter determined that the proposed changes are no longer needed. The ticket is now closed.
Sent for Implementation
The Sent for Implementation state indicates that the proposed changes have been approved for implementation by the HL7 community but are awaiting implementation to the continuous integration (CI) build by the Terminology Curator.
There is nothing for the submitter to do at this time.
Queued for Next Implementation
The Queued for Next Implementation state indicates that the proposed changes have been implemented in the continuous integration (CI) build, but not yet in a published release.
To determine the next release date, please see the HL7 Calendar.
Proposal Implemented
The Proposal Implementated state indicates that the proposed changes have been implemented in a published release.