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

Closed
opened 2 years ago by fr33domlover · 2 comments

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? :)

Forum topic

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? :) [Forum topic](https://talk.feneas.org/t/ticket-dependency-just-the-uri-of-another-ticket-or-a-relationship-object/80)
fr33domlover commented 2 years ago
Collaborator

Should we extend Relationship, using a new custom TicketDepedency type, or use Relationship itself? Forum topic

Should we extend `Relationship`, using a new custom `TicketDepedency` type, or use `Relationship` itself? [Forum topic](https://talk.feneas.org/t/extending-the-relationship-type/87)
fr33domlover commented 2 years ago
Collaborator

We'll have TicketDependency, which will be a subtype of Relationship.

We'll have `TicketDependency`, which will be a subtype of `Relationship`.
Sign in to join this conversation.
Loading...
Cancel
Save
There is no content yet.