Representing the actor managing a project

We’ve been maintaining the flexibility, where nothing (maybe except for users) is forced to be an actor. When you want to interact with a forge object, there are properties in ForgeFed that tell you which actor to talk to. That allows for a flexible actor topology where different systems can be used together to provide forge features, and it works “magically” because federating forges don’t assume a single actor or a single server manages all the aspects of a project.

When a ticket dependency is created, I want to notify the trackers of both tickets (the depending ticket and the depended-on ticket, it may be the same actor or different actors). Right now, context is being used to refer from the ticket to the project. But in order to notify the actor, I need to know which actor to address. The project may or may not be an actor. How do I tell?

Before I throw some ideas, important note: the Ticket type is being used both for “issues” and for “merge requests”. So if we e.g. reuse ticketsTrackedBy here, we need to remember that this would apply to merge requests as well, which may be a bit confusing.

Some ideas:

  • Allow Tickets to use ticketsTrackedBy to point to the actor
  • Allow projects to use context to point to the actor

I think the 2nd one is cleaner, have the project refer to the actor instead of having each and every ticket do that separately.

context is a very general property though. If we use it, either we can’t use it to represent a tree of nested projects, or we decide that you need to iterate using context until you find an object that doesn’t have that property, and that’s the actor. But that means none of those projects in the tree can use context for any other purpose, otherwise the algorithm will fail.

We also have other attributes discussed previously:

  • attributedTo: Project would be attributedTo the actor, but that’s confusing since we already use attributedTo to refer to the actor that created the project (unless we switch that to a createdBy property etc. e.g. from Dublin Core)
  • managedBy: Proposal for a new property in ForgeFed, for objects to refer to the actor that manages them, that would be easy for coding but the downside is defining a custom property rather than reusing existing standard stuff


For now, in Vervis I’m going to do the following: If the project (i.e. the context of a Ticket) doesn’t have context and does have inbox, then it’s the actor to contact. If it has context but doesn’t have inbox, then context points to the actor managing the project. I’ll tweak the implementation when we make a decision on this.