Well, it is rather intuitive really, though likely my poor explanation skills made it seem like complex 
If you start modeling, then depending on how you define what you are modeling, you likely end up with wholly different models.
- āGiven code forges - whatever a forge is - we can āreverse-engineerā common features found in these applications and turn them into interoperable specifications for code forges to adopt.ā
Versus ā¦
-
āGiven common Revision Control needs of developers, as implemented in code forges and related tools we can define an interoperable specification for anyone implementing revision control.ā
- And on to the next sub-domain, e.g. Project Management spec that maps well onto code forges (but also on Trello).
Then on the terminologyā¦
Lifecycle. Any software project has a lifecycle and part of that lifecyle is supported by features in code forges. As it happens more and more of this lifecycle is added to forges as features (especially Github with others catching up, and certainly in its ecosystem the entire lifecycle is represented). It is also called software developmet process, but I find that less descriptive. During a project lifecycle there are multiple processes working in parallel or sequentially, and stages going from the projectās inception to its end-of-life.
Business domain. Any software project always translates some real-world requirements into abstractions written as code. The field of expertise where you are automating something with your software is called the business domain. Whether you explicitly name it or not, you always do ādomain modelingā in one way or another. Especially when writing reusable specifications imho recognizing the domain will be of great help in the modeling effort.
I call it business domain, but the Wikipedia is not up-to-par. The term comes from domain driven design. A business domain is more generic than an application domain where additional implementation details of the particular application may give a slighty different model.
The business domain is most valuable. Imagine there exist no developer tools and you ask a developer (the domain expert): āWhat do you need to be more productive in coding with your team?ā. No developer would answer: āI need a code forgeā. Instead they would say āI need to be able to to see the revisions each of us make, and able to act if thereās issues with itā. Thatās the basis to further drill down to their needs.
Donāt want to pile on more terminlogy, but sub-domains are also called Bounded Contexts. Hereās an example:
Picture that for e.g. Revision Control and Task Management contexts. Trello would be interested in Task Management, not so much in Revision Control, while most forges are likely interested to implement both (or gradually adopt context by context).
You also see duplication of concepts in each of the contexts in that diagram. Each context is internally consistent. They can stand on their own, and some concepts have slightly different meaning in other sub-domains. If (hypothetically) a code forge would have Dependency Management, then while modeling that thereās need to know about the concept of Repository, but this model is not interested in all the detailed properties of a Repository that may exist in the Revision Control context.