Ticket dependency: Just the URI of another ticket, or a Relationship object?

The most basic obvious way to specify a ticket’s dependency on another ticket is to list the URI of the dependent ticket. However this simplicity has implications:

  1. Can’t specify any properties about this dependency, e.g. when was it created and what kind of dependency it is and who added it
  2. Can’t refer to the dependency as an object, which in particular means that adding and removing deps is done using the generic Add and Remove activities

The advantages of using a dedicated TicketDependency type (would be a subclass of the AS2 standard type Relationship, see AS2 Vocabulary spec):

  1. Can specify properties of the dependency, e.g. when was it created and what kind of dependency it is (e.g. does the dependency mean that work on ticket A can’t start until B is resolved, or does it mean work on ticket A can start but can’t be completed until ticket B is resolved? And it is a dependency required by laws of nature, or a dependency defined manually for work breakdown structure?) and who added it
  2. Can create and remove dependencies using Create { TicketDependency } and Delete, which is more expressive than generic Add/Remove, although comes at the cost of possibly keeping a Tombstone for every deleted dependency etc. Also, since tickets can have both deps and reverse deps, every dep creation implies an rdep creation in the dependent ticket, and similarly for dep removal. We’d probably publish only the dep creation, and do the rdep creation implicitly, but there’s something cleaner about having the dependency be a first-class object

Thoughts / ideas / proposals? :slight_smile:

1 Like

I think a separate type is justified here as you’ve outlined.

I would like to see some kind of “type” in the TicketDependency which would map loosely to, or at least allow replicating, various dependencies in popular systems like GitHub, Jira, etc. This should probably not be a strict Enum though, but the spec could list common values?

1 Like