Stream: fhir/infrastructure-wg
Topic: Process question: tracking applied changes
Josh Mandel (Oct 16 2020 at 19:18):
OK, so I just ran this fun exercise looking at bundle reference resolution logic (live-stream; led to FHIR#29271 that I created just now).
Then I realized: this feels really familiar. I found GF#18235 from 2 years ago, where we had agreed to make improvements to the documentation for R4. The history shows the change as "Applied" on 2018-10-14, but when I review https://github.com/HL7/fhir/commits/master/source/bundle/bundle-notes.xml I see no changes mentioning issue GF#18235.
Josh Mandel (Oct 16 2020 at 19:19):
This is a super-manual process, so it's easy to see how things get out of sync. Maybe more of an FMG question, but I'm curious if folks have practices they've seen for keeping track of these kinds of things without two-sided manual data entry.
Vassil Peytchev (Oct 16 2020 at 21:11):
Did you notice the comment where Grahame referenced GH#c9067ba302 as (presumably) the commit that applied the changes?
Josh Mandel (Oct 16 2020 at 21:19):
I missed that -- good catch! (Though in any case, that commit doesn't contain the changes in question.)
John Moehrke (Oct 17 2020 at 13:54):
when I apply changes, I forward the list of CR that I applied to the workgroup mailing list. Asking them to confirm they see the change I made and to point out any mistakes. I include the list in the minutes of the next t-con too. I am not confident that anyone does this, but it gives them a chance to check-my-work. I have always been uncomfortable being the only one to check that I made the change. BUT, adding more overhead seems a step too far.
Josh Mandel (Oct 17 2020 at 16:46):
Yeah, that's a great example of a practice that spreads responsibility / checking a bit. I'm not saying we need to formalize something like this, but it's good to think about.
Grahame Grieve (Oct 20 2020 at 23:01):
I'm not sure what else we could do to guard against mistakes - presumably I made one
Grahame Grieve (Oct 20 2020 at 23:02):
I certainly did.
Josh Mandel (Oct 21 2020 at 16:05):
I'm not sure what else we could do to guard against mistakes
I mean, John's example is a good one, for what we could do -- it's basically the equivalent of "code review" (having someone other than the author review changes before merging), which is a standard practice in software engineering.
Josh Mandel (Oct 21 2020 at 16:05):
(I understand that trying to do this across all changes in FHIR would be untenable, because it would create a terrible bottleneck. But it's something we could experiment with for purely editorial changes, for instance.)
Josh Mandel (Oct 21 2020 at 16:07):
FWIW we do practice this in a few low-traffic areas; we use GH approvals for every pull request on bulk data (https://github.com/HL7/bulk-data/pulls?q=is%3Apr+is%3Aclosed for example). And while @Dan Gottlieb would probably say that 80% of the time these reviews add no value, we do occasionally catch stuff ;-)
John Moehrke (Oct 22 2020 at 17:59):
note that my process does not have them reviewing a PR. they just get to review the results and I will fix anything they find .
Last updated: Apr 12 2022 at 19:14 UTC
