Stream: fmg
Topic: Pre-Steps to First IG STU Ballot
Hans Buitendijk (Dec 19 2018 at 22:20):
Starting the discussion here on outline of a set of criteria.
The goal is to ensure that IGs have gone through enough connectathon and early implementations before they are submitted for their first STU Ballot. A straw proposal for the criteria would be:
- minimum of two FHIR connectathons
- an IG that is complete (per whatever IG criteria what completeness means)
- minimum of two IG review cycles (per new definition so it allows to be done at any time during the year, but not part of a ballot cycle - see proposal on eliminating Ballot for Comment, thus that is not an option in this proposal)
- minimum of ?X? implementers that have a working pilot/prototype
To further aid in clarity of when to ballot or not, and considering the varied use of Ballot for Comments, the challenges with the number of ballots during the standard ballot periods, we propose to also eliminate Ballot for Comment from the Ballot Cycles and only have reviews that do not intend to immediately lead to publications off-cycle. The current peer-review process should be enhanced to a better defined "Review Cycle" where there is better transparency on what topics are available for review, the timeframe, the target audience (team, community, everybody), as well as clear announcement approach, up to and including notifying the entire membership through some mechanism.
Thoughts?
Lloyd McKenzie (Dec 20 2018 at 15:11):
Rather than setting a minimum number of connectathons, my leaning would be "have a connectathon where a representative set covering the range of the intended implementer community successfully interoperates with no further significant substantive changes identified. If they can do that in one, great. If it takes them 5, so be it. In terms of number of implementers, my bare minimum would be about 6 - that's assuming there's only two application types and seeking at least 3 perspectives on each. Perhaps we could go as low as 4 in the situation where one of the partners is fixed (e.g. communicating to the FDA where they're the only possible recipient). But those should be "real" participants, not just proof of concept. You need to show that you've got engagement with the target implementer community.
I'm unsure about totally eliminating "For Comment" ballots, but I would like to see both "for comment" and back-to-back STU ballots become rare rexceptions. Perhaps a rule setting an expectation that balloting more than once every 3-4 cycles (except for back-to-back normatives dealing with substantive changes) requires advance dispensation? If you know that you only get one kick at the can every 12-18 months, it will presumably encourage work groups to focus and make sure they're genuinely ready.
Hans Buitendijk (Jan 03 2019 at 16:33):
I'm good with the first suggestion that focuses on meeting certain connectathon outcomes rather than a minimum number. Makes sense.
Regarding the suggestion to still have For Comment, so far the purpose of For Comments still seems to be able to be achieved through other mechanisms that can be managed outside the ballot cycle, so would still continue to recommend removing that. If ballots are limited for STU, what would the value be? Particularly as STU is an accepted publication state that can be referenced by rules, so need to still have a reasonable level of consensus, so I would not recommend to limit back-to-back STU cycles. It would seem reasonable that when an STU is published, it should not immediately go back into ballot the next round, so if we do it at a publication level, not ballot level, that may work.
Lloyd McKenzie (Jan 03 2019 at 16:54):
I think the difference between "For comment" ballots and peer reviews or equivalent is breadth of reach. A work group hitting its list server, reaching out on Zulip and beating the bushes of their contacts reaches one portion of the community. Balloting reaches a different portion of the community. If the work group is trying to attract the attention of those who don't normally pay attention, "for comment" might be the best way. But we definitely need to make them more focused. If I know that when I'm reviewing a "For comment" ballot my focus need to be only on answering 3 specific questions and that the rest of the content is just there to provide context for me to answer those questions, that's something I can probably do in short order and may well be willing to do so. Too much of the time right now, For Comment ballots are just work in progress that's hard to understand or evaluate with no guidance on where feedback is needed - and that's not useful.
Hans Buitendijk (Jan 09 2019 at 21:03):
Today that is true. I would suggest that the breadth of reach for peer reviews etc. can be as wide as For Comment and can be as focused, narrow, complete, incomplete and not bog down the Ballot Cycle.
Lloyd McKenzie (Jan 09 2019 at 22:12):
Breadth is really about how the invitation process works. To me, "peer review" means reaching out to your list server and Zulip. Ballot is using the formal HL7 and ANSI distribution mechanisms to seek review. If we allow "peer review" to use those mechanisms, it really ends up being indistinguishable from a "For comment" vote
Last updated: Apr 12 2022 at 19:14 UTC
