Creating a ticket dependency

Where to host ticket dependencies?

Ticket dependencies are objects of type TicketDependency (as discussed previously), and each Ticket maintains a Collection of its dependencies of other Tickets (as discussed previously).

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:

  1. Decide that tickets always host their dependencies, so the way to create a new dependency is to send an Offer activity
  2. 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 Create or 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:

  1. The ticket dependency is submitted using Offer (or Create if 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
  2. The ticket tracker sends out an Accept, addressing the submitting user and the tracker of the depended-on ticket
  3. The tracker of the depended-on ticket sees the Offer and the Accept (or sees just the Accept and fetches the Offer it refers to), and lists the depending ticket in its dependants (i.e. reverse dependencies) collection

I’m just passing by, but have some feedback (I’m not fully informed, so sorry in advance where I’m off the mark, these are just thoughts that popped up with me)…

Why do you use Offer semantics and is there a need for both Offer and Create in option 2? Wouldn’t a Create in all cases suffice? Is the Offer semantically appropriate, or should it be reserved for other purposes?

To me an offer means that both sides are actively involved in the offering process, almost like in a manual, explicit procedure between 2 actors. This could very well be your intention and there’d be UI on both ends to facilitate this (the offer would almost entail an issue in itself).

FreeDictionary on Offer:

a. To present for acceptance or rejection; proffer: offered me a drink.
b. To put forward for consideration; propose: offer an opinion.
c. To present in order to meet a need or satisfy a requirement: offered new statistics in order to facilitate the decision-making process.

Clause c) may best fit the bill here, but ‘present’ may just mean 'display that there is an TicketDependency’ and how that’s handled afterwards is another matter (e.g. by returning an Accept at some future date to formally acknowledge the dependency).

Until that time the Create{TicketDependency} just behaves like a ‘mention’ in the ticket where it was created, and an entry in the timeline of the ticket that was targeted.

As an example @csarven in a recent GH ticket about AP + Solid mentioned (hashtagged) a whole bunch of related GH tickets. This is great, as it is now plugged into the project at relevant places. The timeline references there can be either ignored or pique someone’s interest.

If you have TicketDependency in a ticket’s timeline you could just show the relationship type as a label. Instead of currently:

csarven mentioned this issue 3 days ago
ActivityPub SocialCG reaching out to Solid #4

You could have:

csarven mentioned this Codeberg ticket 3 days ago as a critical dependency.   [Accept]
ActivityPub SocialCG reaching out to Solid #4

Pressing the Accept button at a later time would not be part of this transaction, and would create a new timeline entry. Whether or not the repository allows these linkbacks (remote or otherwise) could be part of configuration settings.

I am very much in favor of allowing remotely-hosted deps. In this example both AP and Solid standardization happens all over the place and had csarven mentioned Codeberg or Gitlab issues I would certainly want to know when reading the issues there.

PS. Off-topic, but related to tickets: Retaining compatibility of tickets to the fediverse.