Ticket deps are small objects just specifying a relationship. And it makes sense to me, that deps are essentially parts of the work that needs to be done on a work item, and a work item gets to control its list of dependencies. So, I'm inclined (both in spec and in Vervis) do ticket dependency creation using the Offer flow, without a Create flow. It's simpler and perhaps safer.
If anyone has insights/thoughts/objections/arguments in favor of remotely-hosted ticket deps (i.e. a ticket's dependency objects can be hosted on other servers than the ticket itself), please comment in the forum thread linked below.
Ticket deps are small objects just specifying a relationship. And it makes sense to me, that deps are essentially parts of the work that needs to be done on a work item, and a work item gets to control its list of dependencies. So, I'm inclined (both in spec and in Vervis) do ticket dependency creation using the `Offer` flow, without a `Create` flow. It's simpler and perhaps safer.
If anyone has insights/thoughts/objections/arguments in favor of remotely-hosted ticket deps (i.e. a ticket's dependency objects can be hosted on other servers than the ticket itself), please comment in the forum thread linked below.
For now, I'm going forward with the `Offer` flow.
[Forum thread](https://talk.feneas.org/t/creating-a-ticket-dependency/301)
Ticket deps are small objects just specifying a relationship. And it makes sense to me, that deps are essentially parts of the work that needs to be done on a work item, and a work item gets to control its list of dependencies. So, I'm inclined (both in spec and in Vervis) do ticket dependency creation using the
Offer
flow, without aCreate
flow. It's simpler and perhaps safer.If anyone has insights/thoughts/objections/arguments in favor of remotely-hosted ticket deps (i.e. a ticket's dependency objects can be hosted on other servers than the ticket itself), please comment in the forum thread linked below.
For now, I'm going forward with the
Offer
flow.Forum thread