The diagram opposite describes how the branching strategy will relate to work flow and workflow states. The perspective on workflow and the relationship between the terminology server and JIRA will evolve as the details of the implementation become known.
Branching
The release candidate branch is a permanent branch. When a content project is identified, a project branch is created in the terminology server (TS). Content is not edited directly on the project branch. When content is edited or created, a task branch is created in the TS. Content edits are associated with the task branch. When tasks are completed the content created and edited for the task is merged back to the project branch. When projects are completed the project content is merged onto the release candidate branch. The release candidate is exported periodically (e.g. daily) and content that was created since the previous export is sent to the release and release validation services.
Traceability
When a content project is identified, a JIRA project is created, and the JIRA project identifier associated with the TS project branch. Task branches are associated with the same project identifiers, or identifiers of sub-projects. In this way, all content associated with a project branch and project-task branches is associated with the identifier of the JIRA project in terms of which content is being edited. Thus, content that is released can be traced back to the request (also associated with authors).
Workflow
There are two levels of workflow. Both are managed in JIRA.
- Project workflow, which applies to the request as a whole as it progresses through the phases of the content development workflow. The diagram here applies to project workflow.
- Task workflow, which applies to content that is authored, validated and reviewed. The diagram opposite applies to task workflow.
Workflow states can be defined as necessary in JIRA, and managed according to the flow required on a per project basis. The authoring team would control these. Therefore the diagram shows only examples where workflow states might transition. When implemented, the workflow states will likely be different to those shown here.
10 Comments
Rory Davidson
I would like to understand what happens in the non-ideal scenario where content assigned to a task (unit of work), and assuming this generally will be more than a single change on a task branch, what would happen when only some of the content gets approved and others get rejected?
Does this mean that the whole task would wait for everything to be approved, or would the task (and related JIRA ticket) be split?
Robert Turnbull
The batch moves through workflow as a whole. It is not broken up.
Robert Turnbull
The reviewer regresses the task to a prior workflow state. The original author is notified. Information about why the batch was rejected is conveyed to the original author.
Robert Turnbull
In fact, assuming the formation of an editorial panel, there's likely to be a need for workflow that assigns batches to the panel.
Robert Turnbull
In all cases authors and reviewers must be able to communicate all the issues in a way that enables the author to access the affected content easily.
Rory Davidson
In that assignment to the panel, would a batch be the same batch as a whole, I.e. a task from one author? If 800 out of 1000 concepts were fine, the batch still goes for review to the editorial panel?
Robert Turnbull
Yes. However we will have to be practical about the sizes of batches.
Robert Turnbull
Given that task branches can be destroyed, if a large batch of fully imported content were imported and later found to be "not right" the task could be destroyed, the batch fixed and re-imported. Many ways to skin that cat, depending on the situation. But we must pick a place to start.
Rory Davidson
Having tasks go through as a whole makes the solution more straightforward but scenarios still need to be walked through.
Also need to consider where the workflow is applicable in the solution, I.e. :
For discussion...
Steve Archbold
A natural starting point would be when the author adds tasks through the matrix editor user interface, either directly, or (as agreed for the MVP) through importing data for a set of tasks previously defined (could be a set of 1). Defining a row in the matrix editor = creating a task branch = creating a ticket in Jira?
From a purely logical point of view, a task would naturally map to a JIRA feature ticket within an associated Jira project, unless we need to map authoring projects into a single JIRA project for performance/scalability reasons, in which case the project could be a feature ticket, and the task would map to a dependent child ticket, all within the same Jira project?