FHIR Chat · Public Review of FMM 4/5 changes

Stream: fmg

Topic: Public Review of FMM 4/5 changes

Lloyd McKenzie (Jan 18 2018 at 19:36):

Our rules require that we seek public review of substantive changes to FMM 4 & 5 artifacts before applying them. Realisticly, we're not going to have time to do that as we prepare for ballot. My recommendation is that we hold the comment period coinciding with the ballot. Does that seem reasonable to everyone?

John Moehrke (Jan 18 2018 at 20:33):

what does "before applying them" mean? There certainly needs to be a public opportunity for breaking changes once we get up to FMM 4+; but isn't that just the normal HL7 governance? Meaning if a breaking change comes from the May ballot, it mostly requires that portion be possibly re-ballotted?

John Moehrke (Jan 18 2018 at 20:34):

can you provide the context behind your question. that might help

Lloyd McKenzie (Jan 18 2018 at 23:04):

We seek formal feedback from implementers outside of the ballot process before we make breaking changes to FMM 4/5 artifacts.

Lloyd McKenzie (Jan 18 2018 at 23:04):

What I'm suggesting is in the lead up to May, we may need to seek feedback after applying certain changes and do it in parallel with the ballot process.

Lloyd McKenzie (Jan 18 2018 at 23:05):

Feedback goes direct to the product director and may come from those who don't have ballot privileges.

John Moehrke (Jan 19 2018 at 00:18):

ah, that context is important to understanding your question. That part of our governance I read differently when I originally reviewed it. I didn't understand it in the same way. Thus having an example is critical to understanding your interpretation. In my original read, I was seeing a ballot process as that mechanism used to get review by implementers. I had not expected a in-line step as you describe. Not that I expected that workgroups would not include implementers, and seek their input; but rather that the formal review period was part of the normal ballot governance. Where any breaking change to a balloted material is put back out for another ballot so that the community can react to the resolution. This is critical in my experience as I have voted positively on a ballot, only to have something changed by another ballot comment in a way that I disliked. So it isn't only those that comment negatively that need to see these breaking changes, but also those that thought the first revision was good.

John Moehrke (Jan 19 2018 at 00:20):

thus in my view. This is what the ANSI approved governance and the ballot process is for; anything short of that is not right.

Lloyd McKenzie (Jan 19 2018 at 00:50):

Our point is that we make a commitment to implementers whether they're HL7 members or not. We will consult with you before we make substantive changes to FMM 4 or 5 artifacts. They don't get to "vote". They don't get a veto. But their opinion will be considered (and have considerable weight) when a committee decides whether to make a change and will also influence how a committee chooses to respond to ballot feedback. This process has already been exercised multiple times - announcements have gone out on the FHIR list and on the product directors blog soliciting feedback and reporting on the results, so it shouldn't be a new thing. I'm not proposing that we change this aspect and I'd be highly opposed to merging it into the ballot process. I'm just suggesting that due to tight time constraints, we might need to reverse the order of "consult implementers" and "apply change".

Grahame Grieve (Jan 19 2018 at 10:02):

ballot is a perfectly reasonable method of seeking implementer feedback; no need to do both, if they can coincide - we just need to draw implementers attention to the changes and their opportunity to comment