FEDERATION.md: Document actor choice in Vervis/ForgeFed

FEDERATION.md

@@ -469,6 +469,54 @@ trivial to do.
 
 #### (1) Actors
 
+How to decide which types of objects are actors and which aren't?
+
+The proposal here is that the following types be actors:
+
+- Person
+- Project
+- Repository
+- Group/Organization/Team
+
+And other types such as these not be actors:
+
+- Ticket
+- Merge request
+- Patch
+- Diff
+- Discussion thread
+
+The lists above are just an example of the proposed rule for determining which
+objects should be actors and which not. It's not necessarily always obvious,
+but the proposed guideline is:
+
+- If the object needs to be able to publish activities, it should be an actor
+- If the object is stand-alone and its meaning is self-contained, it should be
+  an actor
+- If the object's meaning and context are semantically inherently tied to some
+  parent object, it shouldn't be an actor
+- If an object doesn't need to send or receive activities, even if it's self
+  contained, there's probably no need to make it an actor, because it
+  practically doesn't participate in actor-model communication
+
+Examples:
+
+- A ticket/issue/bug is created with respect to some project, repo, software,
+  system, the ticket is inherently a part of that parent object, so tickets
+  would generally not be actors
+- A project or repository are generally self-contained entities, and even if
+  some forge has users as top-level namespace and repos are created under
+  users, the user managing/owning/sharing a repo is just a matter of access
+  control and authority, *it isn't a part of the meaning of the repo itself*,
+  and the repo could easily change hands and change maintainers while remaining
+  the same repo, same software, same content, same meaning. So, repos and
+  projects would generally be actors.
+- A group/organization/team is a self-contained object, a set of users along
+  with access control and roles and so on, and it needs to be able to receive
+  update activities that update the team members list, structure and access and
+  so on, even though a team isn't a user and probably doesn't publish
+  activities. So, teams would generally be actors.
+
 #### (2) Authorization and roles
 
 #### (3) Comments