Continual Improvement to the Frequent Delivery process
This is an area where we can consider, discuss and agree new improvements to the various Processes that support the Frequent Delivery of our products.
Potential Improvements:
USER DOCUMENTATION
Several end users have contacted Guillermo to request more information on the transition to more frequent delivery (and/or more frequent updates to the dependent content of both extensions and derivatives).
It would be great if we could provide people with a white paper or presentation (both from a Content and Technical perspective) on
How the transition went
Benefits realised
Lessons learned
Risks
etc
This should be targeted at both the Supplier level + the end users level for max effect
Does the presentation myself and Maria gave cover this? Or could we add an area on the website??
RELEASE NOTES
Can translators please have more detailed release notes - automated to the extent of having EACH component change listed out?
NEW REQUIREMENTS FOR SONJA:
Option for detailed release notes as well as the standard level for all Releases (as per Guillermo's requirement above) - either in the RNMS (preferable) or in the Delta Generation Tool?
It would be great to also link each Component change to the relevant high level change note in the official Release Notes as well (eg)
Release Notes March 2023:
Drugs Changes:
Component 1 changed
Anatomy changes:
Component 1 added
Component 2 removed
Component 3 changed
Quality Initiative:
Component 1 changed
Component 2 inactivated
https://projects.jira.snomed.org/browse/INFRA-8739 RAISED
RNMS-65 created to track development
Explicit annotations in the Release Notes to that each component change in the Delta period is linked to a specific Template
Comments
@Dion McMurtrie; Good point about the delta file names.
Dsicuss file naming implications
I see no reason to not include multiple new effective time values in a release. As stated the format allows for it and it does not go against the TIG. The Australian Extension has in fact done this in the past.
What more frequent releases means for the biannual releases is probably to be determined - are they in any way special or are they just another release. For example the Australian Extension has moved to monthly releases, and aside from the two updates of international content a year there are no "special" monthly releases each year.
The only obvious exception may be to produce a January and July delta that is relative to the last January/July for those that are wishing to consume biannual deltas, but this may not be necessary - i.e. may not be meeting a need for anyone.
Perhaps something for another issue, however the current file naming conventions are somewhat deficient with respect to Delta files. The key issue is that while they identify the release the Delta file is for, they do not identify the release the Delta file is relative to. In the case of wanting to make a Delta file that rolls up all the changes for a 6 month period of releases this is quite problematic. Worse if you pick up a Delta file for the current release that is relative to a release ahead of the content you currently have loaded - a case that is much more likely to occur if there are more frequent releases. I think that to avoid possible confusion and mistakes it would be wise to amend the file naming conventions for Delta files to include this information.
Finally I don't see that it is likely that it will be necessary to make multiple releases a day, therefore the day granularity should suffice. If that is a problem the format does support ISO 8601 timestamps, but I think it unnecessary.