That would be the best way. Until now my experience was pinging @siljelb to update the file and later pinging @borut.fabjan to update adl designer (thanks!). Putting the file on github now made it more visible for others, what exists there, how is it made, etc
But how many would know that they need to come to the jira service desk and request?
I believe that to some the interaction are directly with the modelling tool, so maybe first some kind of info button should be available on the tools (like “can’t find a unit? click here”) and redirect to this service desk? (where it could also have a link to discourse)
And I am now wondering, this file I uploaded before came from ADL designer. Does other modelling tools also use it? What about conformance? (edit: i saw now this is a post on ADL designer, but i left it here for future thinking)
That board was unfortunately never used during a few years existed. Instead, changes were communicated mostly personally, or were just discovered accidentally in the (new subsequent version of the) tooling files. My take, since I adopted this specification component few months ago, was to apply standardized governance and publishing cycles that we have in openEHR (SEC + PRs/CRs) - if that seems unworkable then I would like to get feedback on why, etc.
In case of this PropertyUnitData.xml, even we (SEC) would maintain it and store it on GitHub, it still has to be “imported” into Archetype Designer - so @borut.fabjan help is still needed.
I think that is exactly what we should be doing - but there is an additional question: how does a clinical modeller or anyone (someone using the file in some R&D project, say) ask for NewWeirdRadiologyUnit to be added to the units? If we had a service desk project, and the URL of that project was embedded in the right place in tools, and maybe we have a button as well on the specs page, then people can just put their request into the tracker, and we process the requests, and re-release the file. So those requests are really just a special kind of PR that says: I think this code xyz is missing.
No, just a communication issue. It’s one thing for the people involved in specs to know this is the way it is done but inevitably people start a new thread on Discourse asking for help in how to model units. I’m suggesting there needs to be some prominent FAQ or similar public notification (not a tech tool) to try to circumvent this ‘groundhog day’ question from newbies, non-techs and everyone else who doesn’t know your strategy.
Thank you Heather, it is now getting clear to me what you meant by previous post. You are right, better communication will help; I will try to address this.
@heather.leslie - I like the idea of a specific Units topic on Discourse with perhaps a fixed post and link to the JIRA.
But often the questions are a bit more nuanced like - “I can’t find Squiggles per m2” which may require an expert to figure out if this is indeed missing or is perhaps out of scope.
Heather is correct that most newbies/clinical folks are likely to be a bit intimidated by JIRA. So perhaps more realistic for some ‘units’ experts to watch that topic and facilitate/ filter requests and make the CRs when appropriate.
Still think this kind of activity is better mediated through a bit of community advice / curation. i.e likely to be insiders who interact with the service desk rather than newbies
I agree. In some cases it even takes a bit of community thinking to decide what the required units actually are. For example, it took us a while to come up with the “Medication dose rate” property, with units such as “{MASS/MASS/TIME}” or “{VOLUME/AREA/TIME}”.
It almost just needs a pinned post here “So you cannot find a particular unit…” which could explain some of the common challenges with UCUM units, e.g how to find compound units, issues with weirdly name units -, what the heck Qualified real is all about, and then those curly bracket things etc. Finally if you still can’t find what you need , then feel free to ask for advice (and here’s the link to the Service request in JIRA, if you are happy to go ahead yourself).
Nope. It may be for a specific population, but not for all. And it is likely that this question is commonest for those of us who don’t usually/ever hang out on JIRA. We need to use the right tool for the job.
Jira service desk (for which we have a licence) is a tool for building a website with forms that are designed in the tool to look however we want. We can build a test one pretty quickly and demo it.
The ‘jira’ that you are thinking of is only an internal view of the above, seen by those who service the requests.
There are other tools that do the same job, and they all work pretty much the same way.
That’s ok - build it and we can hook up to it. No-noes objecting but we see it being used primarily by openEHR insiders such as @siljelb, and that a Discourse topic plus FAQs is a better place to have folks ask the original question, which normally involves some discussion.
Discourse FAQs are fine, we should have that as well.
But to ask for new terms in the Units file, or in any terminology, a request system of some sort is needed that queues requests for attention from the ‘insiders’. The requesters need a place to lodge those requests. Service desk is a good option. With about 15 mins configuration (more to do), I set up a Jira Service Desk project dedicated to collecting requests for new and changed terms/codes in the Property / Units file and also openEHR terminology.
Here’s what the ‘new unit request’ looks like (with no form-building at all). It is available at a portal within the openEHR jira space, i.e. it’s a pure form. It can be made prettier, simpler or whatever. Since it is hosted in a dedicated place, that URL can be used anywhere we want, and anyone who clicks it will land on this (or a similar) form.
I did understand.
I wasn’t disagreeing with your proposed technical process but rather suggesting that we needed to develop some frequent flier FAQs to explain the process and to link to the process, not to replace the process.
