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.
Tickets to use
ticketsTrackedByto point to the actor
- Allow projects to use
contextto 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
attributedTothe actor, but that’s confusing since we already use
attributedToto refer to the actor that created the project (unless we switch that to a
createdByproperty 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
context points to the actor managing the project. I’ll tweak the implementation when we make a decision on this.