PTC interface

This section develops the PTC interface exposed to project procedures. Discussion with procedure owners showed that they are either already using Redmine (ERD), intend to (CRD), or are willing (PMO and XO) to use it for the project procedure workflow management interface to PTC.

Redmine software at EuXFEL

Redmine version 3.3.3 project management software is available and is used for single tasks, e.g. email driven ticket creation addressing daily operating activities, through to multi-task workflow management.

Procedure-Redmine name clashes

Unfortunately Redmine and EuXFEL names for things often clash. The following table defines the name meanings used throughout this document.

name	meaning in this document
project	Project owners objective, e.g. Integrate a commercial camera into EuXFEL control, timing synchronization, and DAQ system. It is not the Redmine definition.
procedure	The workflow triggered by the project owner to implement the project, e.g ERD, PMO…
workflow	Each project in a procedure runs through a set of tasks which result in its completion. The set is the workflow and it can be the same for different projects, but does not have to be.
task	A single work deliverable in a project’s workflow, e.g. implement external trigger.
issue	A Redmine issue is similar to a task, but issues are implemented by Redmine as different tracker types.
tracker	Different Redmine tracker types express different issue properties, e.g. status and transition, needed to allow issue to work in a workflow
status	The Redmine state of an issue, e.g. Open , In progress, Closed…
transition	The Redmine transition to another issue state status which are allowed for the tracker implemented.
task-group	A set of tasks which are grouped together for implementation handling. Their Redmine equivalent is an issue with sub-issues (aka children).
request-task	A task w/o parent or children tasks is a request for a project.
project-anchor	A task-group w/o parent is the top-level task of a project. Remember that task-groups have children!
developer	A worker who implements a task.
manager	A manager of project progress.

Fine tuning requirements

A number of fine tuning changes w.r.t. to Redmine, both usage and internal definitions, are needed to allow PTC to expose a single interface to all procedures.

PTC interface workflow requirements

These are few and largely associated with formalizing the initial request and review process. For CRD and ERD procedures this requires:

• request-task creation should be created via a browser form and failing that via email.
• the request-task should remain a parentless and childless task whilst status is Open. In the ERD procedure Open is used by the PEPs to idenitify who assists the project owner filling out the ERD document. For the CRD procedure text needed
• the request-task migrates to a project-anchor when the status is changed to Under Review and sufficient sub-task structure is added for the review process. For the ERD procedure the review meeting requires all DATA groups to participate. For the CRD proceedure text needed
• the project-anchor status is changed to New when the project is accepted, otherwise it is Rejected.
• the sub-task structure of the project-anchor is expanded to satisfy the requirements of the project by the procedure manager, the PTC interface requires only that the project-anchor status and milestone align with the project state. This can be update is rule driven and can be automated.
• Rejected, Cancelled, and Closed projects are moved out of the Redmine project-id to the Finished project-id with the project-anchor status and milestone properties updated leaving lower level properties unchanged.

For PMO and probably any other long procedures there is no PTC participation in the review process and the PTC creates a project-anchor and associated sub-task structure that represent the project w.r.t. DATA resource tasks needed. Otherwise the requirements for long procedures are identical (is PMO’s on-hold needed) to those of CRD and ERD processes.

Workflow tracker selection

Following discussion with CRD and ERD procedure owners the Redmine ‘Task’ tracker previously used is replaced by the ‘Elvis’ tracker which implements the workflow shown below.

Additionally Elvis requires the use of:

• the (Redmine) Category which is a string associated with a workflow task with content selected from a pull-down menu of predefined sentences. The aim is to allow the developer to expose the current state of the work on the task to workflow viewers. This mechanism is better suited to this purpose than other possibilities like %_done which is too subjective when details of the task are unknown to the non-developer. The concept follows a requirement specified by PMO.
• the (Redmine) integer custom-field Duration (hrs) in which the developer inserts the integrated hours spent on the task. This field allows the actual time spent on the task between the start_date and the due_date. Duration allows the comparison of expected task time and actual time to be automatically calculated at project closeout. It does not allow the efficiency of the deveolper to be calculated. The Redmine time spent plugin is not used.

How different roles work with Elvis

Developer:

• When the task is assigned to a developer the status is New. Note that if a change of developer is required the status may not be New when they start
• When working on the task the status is In Progress
• If work is stopped due to an internal cause like the PM must act (e.g. provide the test hardware, repair broken hardware, report on a developer implementation question, etc.) or a Dept group must act (e.g. fix faulty s/w, f/w or h/w) set the status to Blocked
• If work is stopped for an external reason (e.g. a design issue must be resolved by PM or PO, h/w vendor is required to update f/w, etc.) set the status to Feedback
• If the task is finished the status should be set to Resolved

Redmine procedure managers (PTC for long and PEPs for short procedures):

• When the request is injected the status is Open
• During Open any tobe dones with the request (e.g. documentation) should be resolved and when ready the task status set Under Review with sufficient workflow task extension to allow the review (e.g. the ERD stakeholder board)
• after review the status should be set New or Rejected.
• For New additional workflow tasks should be added (e.g. ERD addition of implementation tasks) w/o Assignee assignment. The workflow is updated in Redmine w/o assignees until it can be scheduled.
• Managers should remember that there may be many implementation tasks (each in New, In Progress, Feedback, Blocked, or Resolved) and managers must ensure that implementation task status is correctly reflected by the anchor task status by using RAL aspects of the tooling.

Both developers and managers must set task (Redmine) categories when tasks statuses are changed by using an appropriate Category sub-class item. There is a sub-class for each Elvis status value and a category corresponding to the status value should be set - unfortunately it is not possible to liit the choice to the actual status value. The following figure illustrates setting a category.

Redmine task update Category selection (preliminary content)

Additional PTC interface requirements

These aim at improving PTC work efficiency and use the python tooling described later. The functionality provided is:

• rule based automation of Redmine procedure handling
• executive summaries of all project of a procedure.
• rule based automation of meeting agendas
• injection of project work flow tasks defined by rules or in appropriately structured Excel spreadsheets. The latter are particularly suited for PMO projects, where cost-estimate FTE task estimates also specify resource time usage.

Further Alfresco usage

Alfresco usage by procedure owners is not affected by the PTC-Redmine interface and the use of tags to allow jquery network identification of the folder of procedure project documents should continue.