User Tools

Site Tools


Task force

It's a working group that has the responsability to fix “issues” in a source In JIRA it is a Project (example ESSENCE Task Force in JIRA )


Membership is automatically collected from OMG Database (Chairs and Voting Members)


Voting Members


Assistants can be added manually by chairs. (They are called Members)



In JIRA it is an Issue of type “Issue” (example Issue #174 of Essence 1.0


Workflow state, indicate where we are in the process


Indicates what disposition was selected for the issue

Affects Version

In what specification the issue was reported/applies (is moved over Task Forces when it is deferred)

Fix Version

Two things: The Ballot where the issue proposal is voted, plus in what specification the issue was resolved. Serves as documentation and queries.


The members of a task force make proposals to “fix” an Issue by creating a JIRA “Sub-Task” and indicating on the “Issue Type” the disposition they want for the issue. Resolve, Close No Change, Duplicate, Defer, etc.

Technically, for JIRA both OMG Issues and Proposals are JIRA Issues, just having different Issue Types (Issues vs Defer Issue Types)

Once the create the proposal, they can edit the content (which will go into the report) and then move the proposal to “ready to vote” state. Then the Chairs can “Schedule”the proposal in a Ballot.



Source Specifications

Target Specifications

Task Force Report

Chairs configure some specific information (example here) There is a syntax to specify document numbers, URL paths and contents of a zip file. Report is generated automatically following OMG P&P format. You can generate any time until the task force is closed.


  • Do deferred or transfered issues appear as open?, even after the Task Force and the board approved the TF Report.
  • Do we handle Multiple versions of a specification if applies?
  • What is the target of a transfer? Another Task Force or another Specification, which in turn will be handled by a Task Force?
  • The specification field is editable after creation?


Task Force projects has a list of source specifications and a target specification.

Every issue has a specification where it was first reported in. The public form has a specification field. Task Forces issues are created with the first source specification.

We should not allow creation of issues in the taskforce after the comments deadline is reached. After deadline issues are created via the public form and Juerguen can move an issue to the taskforce if the team agrees.

We need to store the specifications in OMG databae

  • Submissions need to be in the specifications table, since it is the source for FTFs.
  • RTFs have the final specification as souce.
  • Specifications contains the following fields: Name, version, acronym and mailing-list
  • Every issue is created with a specification attached to it.

Issues Navigation

I propose the following ways to traverse the issues

  • Issues by the reported Specification (the field attached to the issue. e.g. BPMN 2.0) (e.g. issues/specifications/BPMN2.0)
    • Issues in this list may belong to different project, and they can be in any status.
  • Issues by Task Force (the JIRA project) (e.g. issues/task-forces/BPMN21RTF)
    • Issues in this list are always open until the task force resolve them. when the TF closes, all issues will be closed.
  • Issues by Specification Acronym (BPMN, many specifications share the same acronym) (e.g. issues/specifications/BPMN)
    • This includes all issues from all specifications that have the same acronym
  • Issues by mailing list (specification will have a mailing list) (e.g. issues/bpmn2-rtf)
    • generally mailing lists map to acronyms, but this is the one that closely match the existing way

Task Force Creation

  • When a task force is chartered,
definitions.txt · Last modified: 2014/06/17 17:57 by admin