This page lists differences between the old FHIR gForge tracker mechanism for managing specification feedback and ballot submissions and the new Jira tool.

  1. Real Submitter is now gone.  Jira automatically captures the reporter and in Jira all issues will be submitted by the person with the issue.  Jira does not (and will not) support capturing issues "on behalf of" anyone else because anyone who wants to submit an issue on Jira can easily register for an account and do so.
  2. Ballot-related fields (Ballot, Ballot Weight) are no longer tracked as part of the Specification feedback issue.  Instead, they're managed as children of the Ballot Submission issues
  3. The Url field is now called Related URLand it is required to be a single URL and must pass a regular expression check to ensure it's a valid link
  4. Reviewing Work Group is now restricted to a single selection.  (This has always been policy, but it's now enforced).
  5. Resouce(s) and HTML Page(s) are now called Related Artifact(s) and Related Page(s) and now change their dropdown contents based on which specification is selected.  As a result, it'll now be possible to choose from a list of artifacts and pages appropriate to a particular implementation guide or other specificaiton.
  6. The rule requiring at least one Artifact or Page is now enforced by the tool
  7. In Person is now a list of individuals rather than a boolean - so it's now possible for multiple people to ask for in-person representation when resolving the same issue
  8. Group and Schedule are now "tag" fields - meaning that any manager can define a new label and that multiple labels are possible.  (Note that labels are shared across product families)
  9. Based on the change to Group, Tooling-related changes are no longer treated as a separate work group, they're instead handled with tags
  10. Waiting-for-input email is now handled using Assignee
  11. Business rules are now enforced, for example "Waiting for Input" can only exist when there's an assignee, duplicates can't point to other duplicates, etc.
  12. Duplicates are now listed in a field rather than in a tab
  13. Submitters can now edit their issues and retract their own issues (so long as no ballot, vote or other links point to the issue)
  14. Transitions are now driven by clicking on a button rather than just changing the status and pressing "update"
  15. Bulk changes can now occur for up to 1000 issues rather than just 25 at a time
  16. Bulk changes can now change free text elements (though doing this will be uncommon)
  17. Queries can now include complex filters, rather than just selecting drop-down elements.  This includes searching text content of free-text fields
  18. Rules about what changes and resolutions are possible for balloted artifacts, technical corrections, etc. are now enforced.
  19. It's now easier for multiple ballot comments to be linked to the same issue.  A summary of the impact of votes (Outstanding Negatives) is now a field on each issue.
  20. It's no longer possible for the same voter to tie the same issue to multiple ballots
  21. Items can now capture "raised in version"
  22. The list of available versions is now specification-specific
  23. The list of available specifications, versions, work groups, artifacts and pages is now managed by source maintained in Git rather than tracker-specific drop-downs
  • No labels