The authoring workflow on this platform is a departure from the previous workflow which you may have been working with in the IHTSDO Workbench.
The IHTSDO Workbench provided a single view and storage for all the work being done within an authoring cycle. This has been beneficial in allowing users to view all the work being done at a particular point in time, but it has also meant that authoring is done on top of unfinished work and has restricted the ability to make large changes to the terminology without impacting other authors at the same time.
The new authoring platform provides an approach based around branches, and moves away from the single central repository approach of the Workbench.
The core idea behind the new workflow is that all content project authoring should take place in a dedicated project branch instead of the release branch, commonly known as the
MAIN branch. This encapsulation makes it easy for multiple authors to work on a particular content project without disturbing the main release. It also means the
MAIN branch will never contain broken terminology and can be released at any moment, which is a huge advantage for continuous releases of SNOMED CT.
Like the IHTSDO Workbench, this approach still uses a central repository, and
MAIN still represents the official release history. But, instead of making changes directly on the
MAIN branch, as in Workbench, a new branch is created when there is a new content project, called a
project branch, providing a part of the repository for work to be done on that particular project, without impacting other projects. These
project branches are also intended to never contain broken terminology and therefore can be released as technology previews in isolation from the main release.
Therefore, in order to protect the project branch, any new authoring is done on
As an authoring task is identified a
task branch is created from the specific content project. A task has no restriction on the number of concepts that can be worked on during a task, but there are a number of considerations to take into account:
- how much can be reviewed
- tasks should not be kept open, or in progress for too long (no more than a few weeks)
Every time you start working on a new task that has been allocated to you, you should create a new branch for this task. As you only have a single long(always)-running branch in your repository,
MAIN, all new
project branches are based off of this
In the meantime, it might be that new content gets integrated into
MAIN from other projects while you're still working on your project. It's both recommended and simple to merge new stuff often from
MAIN into your
project branch. This ensures that you're staying up-to-date - and thereby reduces the risk of merge conflicts that come with large project promotions.