ForgeFed and FSDL: An organization model

On the ForgeFed matrix channel @fr33domlover posted:

I’m starting to reach a project grouping and organization model that feels powerful, flexible and complete, and covers the systems used by the various forges

I’m still thinking where would be best to post the idea to get feedback so I’m starting here, for some brainstorming and informal discussion :slight_smile:

Projects involve a variety of actor types. In some forges, there would be a combined repository actor that handles all the aspects of the project: it’s a repo, it’s a ticket tracker, it’s a patch tracker, all-in-one. But in some forges, these things are separate components. And some components, such as CI, UI string translation, static site generation and serving (a.k.a pages), code coverage/stats, distro package repositories etc. etc. are often separate components. Managing access controls and settings for them separately is inconvenient, if there’s no way to group them into logical Projects. And perhaps even allow Projects to have Subprojects. Browsing and exploring may be inconvenient and too low-level for humans, if there’s no way to group components and explore them on the high level overview of projects, communities, etc.

So the first part of my proposal is: To have another actor type, called Folder or Project or something like that, under which related components can be grouped and managed together. Whenever settings are applied to a Folder, they’re automatically delegated to the components under it. Having these Folders also allows convenient browsing and exploration of projects, rather than browsing tiny components that don’t make much sense to humans.

But there’s another thing to handle, related to grouping and access control: Teams and people’s roles within a team.

So the second part of my proposal is to use Group actors, representing a team of people. People are assigned a role within a team, and teams are assigned some (perhaps limited) access to Folders. And that’s how access control is managed. Teams can inherit access from parent Teams and share access with child Teams, so maintaining access controls for big organizations can be convenient.

The Folder concept is somewhat available on GitLab (except it also uses the folders as teams), and the Group concept is somewhat available on github-for-business, based on the github docs (except the teams aren’t tied to any folders). So this approach I’m proposing combines the two, providing a flexible and decentralized way to collaborate. Of course forges can choose to use one of the systems without the other, or make them work together, i.e. every Folder is also a Group and vice versa. But the greatest power is probably achieved when they’re used alongside each other :slight_smile:

Both of those are completely optional: Teams can have access directly to a Repo, even if the Repo doesn’t belong to any Folder. And a Folder can give access to individual people, without involving any Teams. And of course it’s possible to use neither system. But the minimal recommendation would probably be to either use all-in-one actors, or use a Folder/Project for each set of related components.

Thoughts / comments?
If this is all too abstract or confusing, I can explain more, especially if you ask specific questions about the stuff you want clarified :slight_smile:

I responded in the same line of thought as prior discussion: ForgeFed versus FSDL: How do they relate?:

What is hard in giving good feedback here, is that one almost has to spend almost as much time thinking on these questions as you did to be considerate enough. I am now just formulating an impression while on my morning coffee before going to the office…

First I’d like to say that it may be useful to create Concept Maps of the existing software that is used as input for this analysis. Simple diagrams with circles and relationship arrows. Might also be helpful to track how these forge products evolve as they add new features.

Second, I feel again this tension between modeling business domains vs. application domains. Are you looking at functionality & features as they appear in the app and then placing them in a model, or looking at the software developer activities in a more general sense and independent of any forge platform?

Or maybe it is worth looking at both, and consider models at different abstraction levels / layers? Where thinking of the low-level transport protocol and message payloads alone isn’t enough to get a comprehensive and intuitive universal model… a mental picture based on what developers do, not what tools they use?

If you look at the tools, the software forges, then Repository is some overarching concepts under which a large part of the forge model resides. That’s an application model. When doing domain modeling there is no application. The tasks / activities people do are central. And there’s no mega-big application model to elaborate / figure about. Things are split into sub-domains that have their own consistency boundaries (they are bounded contexts). They each stand on their own, and are (relatively) independent.

When you look up Repository on the internet, the Wikipedia page places this concept in the domain of Version Control: “In version control systems, a repository is a data structure that stores metadata for a set of files or directory structure”. When you think about just the sub-domain of Version Control it relieves your mind as you don’t have to think at the same time what the Repository’s role is in Continuous Integration sub-domain. And it can be wholly different. In the bounded contexts these concepts have different meanings. And in the final model they’ll have different properties. It makes them manageable within their sub-domain. Unnecessary cruft need not be considered (in the application that is different, because here everything meets).

While different sub-domains may share the same concepts (but with different meanings & properties; whatever is relevant and consistent within the context), other sub-domains may not have the concept at all. Take e.g. a Project Management sub-domain. It may have Projects, Boards, Tickets and Notes… but no Repository.

Why am I spending all this text? Because I want to demonstrate that taking an application modeling vs. a business modeling approach will likely lead to wholly different outcome on how the ForgeFed specifications are crafted. If ForgeFed specs define the AP vocab extension / wire protocol for forge federation then:

  • Application modeling approach: Will likely see Repository as some kind of top-level object with a large amount of properties to facilitate all its relationships across the application (the unified model thereof). Risks becoming some kind of “god object”.

  • Business modeling approach: Will see Repository as a very lightweight object, that can be specialized for particular (sub-)domains based on domain-specific AP vocab extensions that are added to its @context definition.

The business modeling approach will see the many, many vendors / FOSS developers of developer tools most happy, as they can focus on a part of the spec that applies directly to their product / project. Mattermost won’t need to figure out the Project Management aspects from Version Management which isn’t interesting to them. And can safely ignore Project Management sub-domain.

And as an aside, more related to Marketing aspects, and FSDL Ecosystem Alliance I also added:

I am quite sure that both Github and Gitlab are modeling their products going from business domains. They don’t have the concept of a “forge”, which is a term mostly only used in FOSS circles. I analysed their positioning a bit on the forgefriends forum.

Now this is interesting more from a marketing perspective as well. Many people haven’t heard of the term “forge”. I learned it myself when I found the ForgeFed project. But we can make The Forge be the proud alternative to proprietary software development platforms. But the “forge” itself denotes an application. From the perspective of business modeling / domain driven design the top-level domain can be said to be “Forging Software”. It encompasses the entirety of our craft. It deals with craftsmanship. And with “forge” and “forging software” not claimed by commercial entitities we can make it terminology that is truly owned by the FOSS community: Forging software is about crafting free software projects.

This mission of positioning, branding The Forge a central theme, a key concept, can fall to the Forgers Ecosystem Alliance, and get their future home at website.

Fr33domlover assured that business domain perspective will be considered for ForgeFed:

Thank you for the input! I’m on a tight schedule but I assure you the approach involves both business modeling and application modeling (lately more of the latter due to the tight schedule with the funding). And in ForgeFed, the different project components are already decoupled (although defined in the same spec) and Repository is just Version Control and there’s no god object.

However, in some forges (such as GitLab, Gitea, github), the same object handles Version Control, Issues and PRs. And in the ActivityPub actor model, it’s perfectly acceptable to have that object be a single actor whose type is Repository and TicketTracker and PatchTracker. Even though I model things as decoupled concepts, I also make sure to think about how those all-in-one forges would implement federation. I’m not necessarily in favor of the all-in-one approach, but some forges do that, and ActivityPub is flexible enough to be able to represent those cases.

As to concept models: I like the idea! But right now I’m way too busy for that. Since the funding deadline is near, and since I want to provide access control features in the spec soon, and refine them gradually via more research (rather than waiting years before touching the spec), and 2 questions I’m asking about my proposal are:

  1. Is it good enough for now?
  2. Is it safe enough to try?

I have 3 weeks to work before I take a vacation / relax my schedule a lot, and I want to do meaningful stuff in them (and get the funding too!). And an awesome thing could be to get that proposal into the spec and implement it in Vervis. I do have other funded tasks, such as federated PR submission, but that’s already 90% done and I’d rather do the final tweaks later, after these intensive and special 3 weeks.

Just to clarify, the proposal is made to fit the domain model, and it quite naturally arises when considering a decentralized actor model. Fortunately, it happens to very beautifully coincide with access control and grouping features that GitLab and github have, but it’s not the reason I came up with the model :slight_smile:

In Vervis, the experimental/reference forge I’m developing, those different components are different actors, and I try to put unusual/innovative/different ideas into Vervis to make sure ForgeFed gets a wider perspective than how GitLab/Gitea/gitlab do stuff. I also look at tools like Gerrit (code review), Taiga & OpenProject (task management), CI servers, etc. etc… to examine components and services that aren’t built into those all-in-one forges.

Project as a ‘container’ concept

To my feedback that Folder seems semantically not suited to be widely used in the ForgeFed specs:

@fr33domlover wrote: How would you feel if it was called Project?

A single software project can use many components: VCS repo, ticket tracking, PR/MR/patch tracking and code review, CI, CD, code checks and scans, dependency library tracking, pages rendering, UI string translation, wiki, snippets, UI design sheets… probably lots more stuff… and those components are loosely related to each other. For example, it’s hard (for machines and for humans) to guess that some 5 repos, 2 ticket trackers, 1 CI recipe and 1 generated static sites all comprise what the human authors of these components would call a single project.

And if it’s hard to guess, then:

  • They probably won’t be displayed together in UI, which would be quite inconvenient and confusing
  • The people managing those components would have to manage access controls and other settings for each component separately, which can be very cumbersome
  • The team wouldn’t be able to see an overview of the components and a report of their status

So I’m proposing to have a type for grouping components into collections that make sense to humans and make their life easy. And those collections can be nested! A project inside a project inside a project, etc. etc.

In apps like Gitea, GitLab, github etc. there’s a limited form of such grouping, where a “repo” is actually a god object that also includes issues, PRs, CI and lots of other stuff. So 1 repo with 1 tracker, 1 wiki, etc., no other grouping into logical projects. In ForgeFed, I’d like the grouping to be flexible, to allow FSDL related software to federate regardless of which component(s) in the ecosystem it provides. Allowing people to grab the components they want and put them in a basket called My Project (or Our Project). Allowing a logical Project to use repos hosted on Gitweb, trackers hosted on Taiga, CI hosted by Woodpecker, i18n/l10n hosted by Weblate… etc. etc… and to use as many components of each type as it wants. Maybe 6 repos, 2 wikis, 3 issue trackers and 1 container registry? Or any other combination that makes sense :slight_smile:

What do you think?

1 Like

I second the idea of having a Project actor type defined to be a software project as a whole. It could be as simple as a URL and a description. A Repository would logically be part of a software Project. Right now the summary of the Repository (as given in example) suggests it is the software project itself which is kind of confusing. This is close to what I proposed a few months ago, before ForgeFed moved to

I’m not overly worried about this project becoming a god object. It will be an object from which one is expected to discover all other objects related to a given software project but that’s a good thing to have, even if it is a very large amount of unsorted objects.

1 Like

I branched off the comment about Marketing to its own idea on this forum:

“Forging free software”: Branding and positioning smartly