From c12977c13d28bc6fce45a194671731e2a9ab1ce7 Mon Sep 17 00:00:00 2001 From: fr33domlover Date: Wed, 29 May 2019 09:19:10 +0000 Subject: [PATCH] FEDERATION.md: Document actor choice in Vervis/ForgeFed --- FEDERATION.md | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) diff --git a/FEDERATION.md b/FEDERATION.md index 603a150..6cdf7b1 100644 --- a/FEDERATION.md +++ b/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