Unfortunately I have very little time. My feedback here should be considered as just providing ideas to ponder on some high level concepts, and not directly related to the specific details discussed above.
There’s obviously many different moving parts to the models that need to be defined. Above are just some aspects in what will become very intricate models. They say domain modeling (DDD) is best-suited for complex domains and ones that will evolve over time. “Forging Software” is definitely in that category.
In the discussion above I once again get the impression that concepts are discussed that belong in different sub-domains / bounded contexts. While they are or may be related, considering their interactions in a single model makes things very complex. In particular I wondered about:
-
Role: A generic concept. In Microblogging groups you may have “Admin”, “Moderator”. When modeling formal groups (say W3C SocialCG) you may have “Chair”, “Secretary”. In forges domains you may have “Maintainer”, “Developer”, “Admin”, but also e.g. “Tester”, “Technical writer”, etc.
-
Privilege / access permission: A concept that is part of the OCAP you are modeling. Now it may be that here there’s also the notion of a Role within that bounded context. But maybe that is not needed.
In general the separation means you can say:
- “The Actor is in a Role” → organization structure
- “The Actor has access permission” → OCAP bounded context
Different bounded contexts, and Roles are a universal concept. They return everywhere in different domains. In the AP Groups discussion in reaction to @Claire and @trwnh I mentioned a way in which arbitrary organization structures might be modeled in a standardized way. If this were a FEP it’d be ready for adoption in many different app types.
Take for instance Valueflows by @lynnfoster and @bhaugen, where currently both @bonfire and @openengiadina are creating implementations. Valueflows currently has their own definition on how to model roles, but they also rely on the The Organization Ontology already.
On Cultures. While I like the notion of specifying the “culture” of a project, I wonder if it is not too abstract a concept (considering the semantic meaning of Culture when people hear the term). I would rather stick with terms more closely related to software development where people are already familiar with. I’d love to elaborate on the idea, as it is very closely related to / part of the FSDL in some way or other.
Given the enormous diversity and variation and ways to set up development projects something very flexible is needed. I am thinking of something different than a “Culture” concept. Something more generic again as a building block of Fediverse domain models: Policies and Policy Types.
Suppose an Object or Actor has a policies collection. You can use it in a kind of aspect-oriented programming way to attach behaviors / bounded contexts / AP extensions to it. Does your Project have a particular organization structure? Well, then attach one or more OrganizationPolicies to it. Does it have a particular governance model? Attach a GovernancePolicy.
Going this route would be very flexible:
- Define a FEP for Policies.
- Any app or community can define their own policies, introduce new policy types.
- Some of these policies would be widely accepted, maybe standardized in additional FEP’s.
- Others would be very domain- or app-specific.
Again, just some morning 
thoughts. Sorry to not be more specific.
Update: Adding chat msg from ForgeFed matrix chatroom, as additional explanation.
[…] there may well be a concept of
Rolethat is particular to the OCAP bounded context. But it is not the same as a similarly named concept ofRolein an organization structure bounded context. There may be a mapping between them, though (in DDD terms this is called an ‘anti-corruption layer’. Each bounded context has a consistency boundary. The model within is always consistent (it is ‘bound’)).
As reflected in AP msg formats, namespaced, you’d get e.g.
org:Rolevs.ocap:Role. But I don’t have a clear picture of the OCAP model right now to be saying whether or not a role makes sense there.
