Categorisation of Alpha/Beta feedback
The suggestion is to define criteria for the categorisation of issues received in the Alpha/Beta/Member feedback stages.
This will enable us to prioritise effectively, and thereby restrict the changes being made during the later stages (Beta and Member releases) to Critical changes only. This will mitigate the risk of impact to the Production release, from changes that could wait for the next release cycle without having any adverse effect on the Production content.
This already takes place internally within SNOMED International, but would be even more effective if we could take into account criteria from the community during these deliberations, in order to ensure that members' interests are continually represented in this context.
The question for the TRAG is whether or not we can design effective criteria, or if this must be a subjective decision in all cases. If the latter, then we should discuss the formation of a CAB for Alpha/Beta feedback prioritisation.
If we can create useful criteria then we should do so, in order to then trial them during the next International release cycle.
Comments
Thanks Mikael - you're right in that we need to get confirmation from the authors on what level of "bad modelling" may constitute a critical issue, but to be honest I'd rather keep it simple, and state something like bad modelling is a failure (regardless of the type of modelling) that requires resolution before the Release.
Where it becomes really tricky is whether or not we agree to designate historical modelling as critical, or only new modelling in the latest authoring cycle, etc. This applies to almost all failures, so we need to discus this in detail in the meetings...
Ideas:
Document these categories, and provide many examples of each level to at least start the discussion off.
Segregate into techincal and clinical issues
Continue to communicate through the JIRA tickets
My initial thoughts are that from the technical side it is probably possible to create some relevant criteria. For example a criteria saying that everything must be consistent with RF2, like not allow two different concepts with the same concept id. A criteria requiring basic structural requirements, like not accepting an active concept without a parent (where the active concept is not 138875005 | SNOMED CT Concept (SNOMED RT+CTV3) |.) A criteria requiring that the concept model is followed. A criteria requiring the correct number of descriptions for the concepts, like exactly one preferred term. A criteria that require that the current file naming conventions are followed. Hopefully we can also identify some more criteria for what is important for a release to be easy to import in an information system.
However, if we also start to discuss criteria for bad modelling of relationships and descriptions I believe that it is much more tricky (but we can hopefully leave that to other groups to discuss. :-) )