55ae151 Vocabulary & Modeling: Add 'Team' type and related properties (#165)

Authored and Committed by fr33domlover a year ago
    Vocabulary & Modeling: Add 'Team' type and related properties (#165)
    
    The `Team` type represents a group of people working together. Each team member has a role within the team. Teams can be given access to projects and to their components, and the access is passed to the team members, based on their role.
    
    ---
    
    Q1: Why isn't Team a subtype of Group?
    
    A: I'm considering that, right now no actual benefit, see #163
    
    Q2: Why do teams inherit access *to* their subteams, rather than collecting access *from* their subteams?
    
    A: Because that's what makes sense for how humans organize in teams. The opposite creates a situation where the people at the top can access everyone's stuff, *and* keep stuff that nobody else can access. The option I picked is the "people power" option, where the people in the small subteams get the general access that the parent team has (stuff the whole organization shares together), and then they get to have their own stuff that they control. In other words, control flows towards the people with the skills and trust, rather than towards the people who happen to be first and enforce a hierarchy upon others. It may sound like a visionary thing, but it's actually the same way github lets orgs define teams.
    
    Q3: Why use a custom property `subteams` for children, but the AS2 `context` for parents?
    
    A: Because there's no good match for the children property in AS2 (I also looked at some RDF ontologies but couldn't find anything that really felt right). I'm considering to use a custom property for parents too, just for consistency, but not sure. `context` should work.
    
    Q4: Why does `subteams` map to a `Collection` while `context` just lists parents without a `Collection`?
    
    A: There aren't clear guidelines for when to use a `Collection`, when to use an RDF `List` and when to use a simple multiple-values-for-a-property, but I'm observing a pattern that's used in AP, e.g. with `replies` and `inReplyTo`, and which makes sense to me:
    
    In a nested structure where parents have the authority about who their children are (because they provide them some service), and where parents can have many children but children have few parents,
    
    - the parents list the children using a `Collection` that can be paginated and items can be added and removed,
    - while the children, mostly just for information, list the parents they have and whose services they use.
    
    Parent teams provide a service to subteams: They delegate to them access to resources. And teams can have many children, but probably few parents, probably just 1 in mose cases. So, it fits the case described above. It also works the same with ForgeFed's ticket dependencies, for a similar reason.
    
    **This PR is the 2nd in a series of 4 related PRs:**
    
    1. #163: Add the Project type
    2. #165 (i.e. this PR): Add the Team type
    3. #166: Describe grant delegation system (we need it for access control for projects and teams)
    4. (Not opened yet) Describe access controls for projects and teams:
    	- Add (or remove) Person to Project
        - Add (or remove) Team to Project
        - Add (or remove) a component (e.g. Repository) to a Project
        - Add (or remove) a Team to a component (e.g. Repository)
        - How grant delegation is used in all of these
    
    1 and 2 are quite simple but 3 and 4 are going to be complicated, so I'm splitting to 4 to make review easier :-)
    
    Co-authored-by: fr33domlover <fr33domlover@riseup.net>
    Reviewed-on: https://codeberg.org/ForgeFed/ForgeFed/pulls/165
    Reviewed-by: Anthony Wang <xy@noreply.codeberg.org>
    
        
file modified
+112 -0
file modified
+121 -0