Content Tracker Prioritisation Criteria working page.
Considerations:
What are the criteria?
Is there an order the criteria should be applied in?
Weighting? Spider graph?
How many is too many?
Comments on being able to review priorities
Draft list of criteria (not in order and under development)
Issues impacted by Content request submissions
Consider if there is a cut off e.g. if a tracker is only impacted by 4 SIRS request should it still have top priority?
Foundational hierarchies
Support Member priorities
High usage areas e.g. very common disorders
How's that determined?
Comments
From group call: Weighting of the criteria needs to be considered. A spider graph may be a tool to support this.
Comments by Linda Parisien from Content Tracker prioritisation criteria Project
Hi Cathy and Elaine,
Thank you for providing us with the two documents. This is helpful to set the mindset, although it contains a lot of information...
I think as a starting point, some items should be more defined such as:
what is a minor change vs a major change
when is the fast track process used over the 'regular' one
what are the outcomes we'd want to measure:
process content that is simpler sooner in the workflow?
increase number of RFCs resolution using the fast track process?
decrease the number of unassigned RFCs on the tracker?
complete more RFCs in a cycle?
While looking at the Content tracker, I had a hard time to relate the 'Component' items to the 'Unresolved:By Priority' information on this page: /projects/IHTSDO/summary/statistics
First, to me the Member Forum Priorities defined on a yearly basis is a top-1 priority, then if a request is being made for an imminent implementation, that would be a top-2 priority, which would be followed by QA issues (top-3 priority) and other RFCs (top-4 priority). Of course there are more complex use cases that could potentially modify the priority such as:
When a request for same content is made by more than 1 country, this should increase the priority
Any content that went through the approval for concept modeling change or editorial change and SME guidance that meet the above criteria should be added to the worklists and prioritised appropriately. This would require an agile process to update tracker asap and get the work started on the RFCs
Then there is the level of effort required to achieve the changes to X number of concepts. This information will be useful to determine when and if the changes can be achieved within a time frame. That information coupled with the priority would perhaps be easier to manage... I am not sure about the categorisation but let's say level of effort (LE) 1= 1-99 concepts, 2= 100-999 concepts, 3=1000-4999 concepts 4= + 5000 concepts.
From the Content Project document, we have clear criteria for when a project is assigned. That information is not currently available from the tracker information. I would suggest a mention to the 'Component' or otherwise that identifies what is requiring:
a concept model change (CM)
an editorial guidelines change (EG)
a SME guidance (SG)
Alignment to editorial guidelines (AEG)
We could use for the Content Project the same LE indicator for the level of effort required or number of concepts that need to be changed.
One way to categorize criteria would be internal (to the terminology, examples include foundational hierarchies, facilitate modeling, increase consistency, ...) and external (to implementation projects, examples include SIRS, members priorities (by vote??), usage). Do we in any way prioritize criteria which can be measured vs. those which are based on opinion?