Where to host ticket dependencies?
It makes sense to me, that a ticket gets to decide what other work items it depends on. Ticket dependencies are such small objects, just expressing a relationship, while at the same time having a significant effect on the work plan of a project (one simple work item can depends on several complicated work items). So I’m having 2 ideas:
- Decide that tickets always host their dependencies, so the way to create a new dependency is to send an
- Allow the same flexibility we have for Tickets, i.e. a ticket may decide it wants to host its deps, but also may support remotely-hosted deps out of its control, i.e. a dependency can be submitted using either
Offer, like with Tickets
Unless this gets feedback and arguments in favor of remotely-hosted deps, or unless ticket depenencies get some new properties and become bigger objects with more meaningful content, I’m going to default to the 1st option (it’s simpler).
Another question is how the depended-on ticket would be notified of the dependency. But that’s probably simple, it can work like this:
- The ticket dependency is submitted using
Createif we want to support remotely-hosted deps), the tracker of the depending ticket and the tracker of the depended-on ticket may/should both be addressed
- The ticket tracker sends out an
Accept, addressing the submitting user and the tracker of the depended-on ticket
- The tracker of the depended-on ticket sees the
Accept(or sees just the
Acceptand fetches the
Offerit refers to), and lists the depending ticket in its
dependants(i.e. reverse dependencies) collection