Difference between revisions of "Public Comment Process"

From QIBA Wiki
Jump to navigation Jump to search
Line 5: Line 5:
 
Note in the description below that the "secretariat" is understood to be the RSNA.  Specific tasks may be assigned to staff and/or contractors of RSNA in performance of the function.
 
Note in the description below that the "secretariat" is understood to be the RSNA.  Specific tasks may be assigned to staff and/or contractors of RSNA in performance of the function.
  
Period: 30 days
+
Period: 30 days (may be longer at the discretion of the committee)
  
 
* [[Review Process|Approve for public comment]] ('''Technical Committee''')
 
* [[Review Process|Approve for public comment]] ('''Technical Committee''')

Revision as of 19:20, 15 February 2013

Public Comment is intended to allow both regular participants in QIBA Activities and also those who don't have the time to dedicate to regular participation a chance to contribute their thoughts on proposed specifications before they are formally released. Comments are accepted from all.

Public comment should be considered the prelude to publication. A committee should be largely satisfied with the contents of a document before it is sent out for Public Comment.

Note in the description below that the "secretariat" is understood to be the RSNA. Specific tasks may be assigned to staff and/or contractors of RSNA in performance of the function.

Period: 30 days (may be longer at the discretion of the committee)

  • Approve for public comment (Technical Committee)
  • Tidy up PC draft (e.g. "accept all changes" in Word)
  • Post PC draft of Document on the Wiki (editor/secretariat)
  • Send announcement to mailing lists (secretariat)
    • detail location of document to be reviewed, deadline for comment submission, method of submission
    • provide a link to the QIBA Public Comment Template
  • Email comments to secretariat (Commenters)
    • commenters include committee members, other QIBA people, external bodies
    • this is the key point for asynchronous engagement
    • please use the provided comment form, it saves the editor having to transcribe your comments
  • Collate all comments into a spreadsheet or Word table (secretariat/editor)
    • sort by line number and priority (Low/Med/High)
    • re-title the leftmost column from "Leave Blank" to "#"
    • fill the leftmost column with incrementing numbers. Now you can refer to "Comment #43", or re-sort the table if you like
    • re-title the rightmost column from "Leave Blank" to "Resolution"
  • Resolve comments with priority Low (editor)
    • turn on Change Tracking in Word
    • for most Low comments (typos), fix it in the document and enter "Done" in the Resolution column
    • if any Low comments prove problematic, elevate to Med
  • Review Med & High comments (Technical Committee)
    • walk through document
    • each comment may be:
      • accepted = proposed text accepted as is
      • rejected = committee does not agree with issue (document reason, e.g. out of scope, )
      • resolved = issue accepted but resolved differently than proposed
  • Record decision and explanation (as needed) in the Resolution column of the table/spreadsheet (editor)
    • editor may find it useful to color code comment rows or resolution cells, e.g.
      • grey - resolved, document update done (if needed).
      • green - resolution decided, document still needs to be updated
      • yellow - currently under debate/discussion
  • Post resolution spreadsheet and updated Document on the Wiki (editor/secretariat)


The final resolution draft with all the comments resolved with change tracking still visible should be posted to the Wiki, along with the resolution spreadsheet. This helps people review the resolution of their comments and the changes that resulted from the Public Comment process

After that, you can "accept all changes" and once it has been approved by the Committee, post it as the "Publicly Reviewed Version".