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
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
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
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
@contextdefinition.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 drone.io 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 forg.es 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:
- Is it good enough for now?
- 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
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.