This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "FHIR Ballot Process Review"

From HL7Wiki
Jump to navigation Jump to search
Line 35: Line 35:
 
* Freida Hall – re:  It must be possible to seamlessly move ballot items between work groups in an efficient manner with no risk of items becoming unassigned or not properly tracked – Excellent! It would be great if this could work more efficiently for all ballots.  What about tracking deferred items "Considered for Future Use" – do they roll over for development for next ballot cycle?  
 
* Freida Hall – re:  It must be possible to seamlessly move ballot items between work groups in an efficient manner with no risk of items becoming unassigned or not properly tracked – Excellent! It would be great if this could work more efficiently for all ballots.  What about tracking deferred items "Considered for Future Use" – do they roll over for development for next ballot cycle?  
 
* Freida Hall – does every commenter/participate need a gForge log in?  Will there be a recorded webinar for novices?
 
* Freida Hall – does every commenter/participate need a gForge log in?  Will there be a recorded webinar for novices?
 +
* Grahame's response to Frieda:
 +
** yes, it would be lovely to get rid of free comments. I've seen several ballots miss them, and they tend to be unfocused and general and hard to resolve. It would be good to replace 'see ballot from so-and-so' with a structured field rather than than text (and maybe enforce that the ballot is actually submitted - we had one ballot where a pile of people referenced a ballot that was never submitted. Fortunately it was draft for comment)
 +
** Agree that which columns are appropriate in the spreadsheet depends on the nature of the document being balloted.
 +
** question of frozen-ness is interesting. In at last some cases, they get re-opened later because of editorial issues arising. This already happens in practice, but has no traceability. We need to sort out a policy here. I'd rather that the task itself is updated in an ongoing fashion, so that the ballot can see what's happened
 +
** non-valid - we always consult the balloter and ask them to clarify. Things we call non-valid really obviously are, but they could always appeal to TSC. Shouldn't happen though
 +
** HL7 needs to provide gForge training generally as well - don't know what is in place with regard to this

Revision as of 02:44, 23 March 2015

Instructions

3/9/2015 - Wiki based review of the draft FHIR Ballot Process

  • This wiki based review of the draft FHIR Ballot Process is sponsored by the TSC as well as the following groups: FMG, FGB, EST and Publishing.
  • The comments submitted during this review will be reviewed and acted on by FMG. The TSC will have final approval of the proposed process.
  • The wiki review is one of the steps identified in the TSC's process for adoption of new process document found here: http://www.hl7.org/documentcenter/public/procedures/IntroducingNewProcessesToHL7.zip
  • The comment period is open from 3/9/2014 through EOD 3/20/2015.
  • The draft FHIR Ballot Process is here: FHIR Ballot Process
  • During the comment period, please submit your comments below including at least your name, item, existing wording, proposed wording, and comment. Thank you.

Comments

Enter your comments below this line.

  • Ioana Singureanu: We need to create a very specific type of tracker (regarding metadata) that ensures we have all the metadata required by ANSI/balloting. The current FHIR "Issues" tracker is not quite sufficient because it does not support the information in the ballot spreadsheet.
  • Ioana Singureanu: We could create one tracker per product, one per release, one per ballot. What are the the pros and cons of each?
  • Ioana Singureanu: We could also use a tracker for "to do" items instead of a "todo.txt" file: http://gforge.hl7.org/gf/project/fhir/scmsvn/?action=browse&path=%2Ftrunk%2Ftodo.txt&view=log
  • Brett Marquard: Is it possible to add custom metadata field to group comments? For example, the 'comment grouping' column in the existing spreadsheet is very helpful for categorizing comments and planned discussion dates.
  • Brett Marquard: Is it possible to export proposed dispositions for block vote?
  • Brett Marquard: Is it possible to record votes in gForge? Meeting meetings are an important backup.
  • Brett Marquard: Will there be a way to assign vote counts to multiple comments at once?
  • Brett Marquard: Is there a way to state comments are related to a specific project and resource?
  • Paul Knapp: This should be tested for accuracy of import and export of ballot spreadsheets.
  • Paul Knapp: This should be load tested and perhaps the import process can serve as that load test to identify if we may have load issues during actual use at the May WGM.
  • Grahame: agree with Ioana. We need to create the right fields and enforce their use correctly. I believe that we need: ballot id, commenters id (can be hidden), disposition, (agreed change = disposition comment), committee that made the disposition, date vote, vote details (text field for mover/seconder/counts). Also we need an outcome for withdrawn
  • Grahame - observationally, committees struggle with the difference between the task disposition and the ballot disposition. I'd rather collapse these to a single list
  • Grahame - the "reason" field is useless, we should get rid of it
  • Freida Hall: re: ballot comments are submitted through the standard ballot procedure (e.g. excel spreadsheets) submitted using the HL7 Ballot Desktop. (Free text comments are accepted as well, though not preferred.) – Suggestion: would discourage "Free text" comments by adding 'by prior arrangement with ? Co-Chair, else you could end up with unexpected magnitude of free text that may be challenging to manage. Unless this is referring to the existing "Free text" on the Ballot Desktop, which is at the ballot level, not the line items comment level.
  • Freida Hall: re: The following columns have been removed: Ballot WG, Artifact ID, Chapter, Pubs, Disposition External Organization, Referred To, Received From and Notes – Since this project was generalized to HL7 Ballots, please don't remove these columns from existing ballot comment spreadsheet unless validate 'non-use' further; some are being used in other WGs.
  • Freida Hall: re: Additional columns have been added to capture ballot URL, Tracker Item #, Summary, Disposition Date, Mover/Seconder – What is 'Summary' – summary of discussion about the item prior to or discussion after motion? Disposition Date, Mover/Seconder would be useful in all reconciliation spreadsheets.
  • Freida Hall: re: There are multiple comments about the changes to the spreadsheet but don't see sample spreadsheet to view the changes. - Where is example of the revised spreadsheet?
  • Freida Hall: re: Reconciliation Process Reconciliation occurs following the HL7 GOM, bylaws, and processes, and also subject to the various committee DMPs – please add 1) HL7 Essential Requirements; this was in the GOM but moved to separate document and synchs with ANSI Essential Requirements (Normative Ballots) 2) Co-Chair Handbook, which includes 20 pages of instructions re: balloting.
  • Freida Hall: re: The only difference between the FHIR ballot reconciliation process and other ballots is that FHIR uses gForge as the authoritative mechanism to track the status of the ballot line items instead of using the ballot spreadsheets – Please clarify, is this only during the reconciliation process, then status is 'frozen' once Final Reconciliation spreadsheet is extracted/posted to the HL7 Ballot Desktop?
  • Freida Hall – What are voter's 'appeal' rights for items FHIR considers "non-valid"? Or is this equivalent to existing "Not Persuasive", which has already been defined in the ballot comment spreadsheet? Suggest considering re-use of "Not Persuasive" or "Not Related" if same concept.
  • Freida Hall – is distribution of consolidated spreadsheet once at the beginning of reconciliation, or periodically as updated as backup in case of gForge issue, e.g. comment submitter has not obtained login, connectivity problem, etc. (suggest the latter).
  • Freida Hall – re: It must be possible to seamlessly move ballot items between work groups in an efficient manner with no risk of items becoming unassigned or not properly tracked – Excellent! It would be great if this could work more efficiently for all ballots. What about tracking deferred items "Considered for Future Use" – do they roll over for development for next ballot cycle?
  • Freida Hall – does every commenter/participate need a gForge log in? Will there be a recorded webinar for novices?
  • Grahame's response to Frieda:
    • yes, it would be lovely to get rid of free comments. I've seen several ballots miss them, and they tend to be unfocused and general and hard to resolve. It would be good to replace 'see ballot from so-and-so' with a structured field rather than than text (and maybe enforce that the ballot is actually submitted - we had one ballot where a pile of people referenced a ballot that was never submitted. Fortunately it was draft for comment)
    • Agree that which columns are appropriate in the spreadsheet depends on the nature of the document being balloted.
    • question of frozen-ness is interesting. In at last some cases, they get re-opened later because of editorial issues arising. This already happens in practice, but has no traceability. We need to sort out a policy here. I'd rather that the task itself is updated in an ongoing fashion, so that the ballot can see what's happened
    • non-valid - we always consult the balloter and ask them to clarify. Things we call non-valid really obviously are, but they could always appeal to TSC. Shouldn't happen though
    • HL7 needs to provide gForge training generally as well - don't know what is in place with regard to this