Mapping Code Forge specifications to Social Coding FSDL

Note: This topic has been renamed, and the first part of the discussion is now out-of-context. Jump here to continue the discussion.


In Redefining and positioning the forgefriends project - #11 by aschrijver I propose merging what is now ForgeFed into a new initiative. A suite of interoperability specifications called:


forgefriends-fdsl-logo-square

Forgefriends FSDL

FSDL is a set of specifications that define standards for code forge interoperability across the development lifecycle. ForgeFed’s prior work is continued in this standardization track. Issue Management, where forgefriends initial implementation aims for, is too. The specifications are broken into modules that constitute bounded contexts of the software development lifecycle.

That is a large scope (aligning with Mission and Vision), and to be manageable should an initiative that is:

  • Crowdsourced. Inviting and easy for anyone to contribute.
  • Incremental. Gradually evolving and maturing over time.
  • Extensible. Constituent parts form a larger whole, a framework.

While I very much agree what you propose makes sense in theory, I still don’t see how it can translate into a decision of any kind unless someone is committed to take action. Working on making this a reality would require a significant amount of work.

Forgefriends FSDL is an empty “coat rack with many hooks to hang your coat on”. As you implement forgefriends proxy code, you work according to specifications that define the interoperability (and based on standards such as AP and DVCS). These specs need to be documented, I presume, and you can do that in your repo hoping the next forge implementer will find them. Or you can document them on one of the logical “coat hooks” that FSDL provides, namely the one labeled “Issue Management specification” for the initial use case you focus on.

It’s interesting that we always end up in the same place: you express many visions and for the most part I share them. I like them a lot even, as visions. They do not require anyone to commit anything, they are just what they are: inspirations that influence me on a daily basis.

We diverge significantly on how these visions are implemented. Your approach is to plant seeds inspired by these visions in as many places as possible and let them grow on their own. My approach is to plant only a few seeds, when someone is around to water them and watch them grow.

Since I worked on forgefriends for the best part of 2021, the project as a whole is heavily influenced by my approach. For instance every category in the forum was created because someone committed to work on what it contains. The infrastructure of the project (lab, cloud, etc.) was created because someone committed to maintain it. etc. One of the benefits of this approach is that whenever someone discovers the project and wants to participate, there is at least one person to be with them. It is not an empty space.

The drawback is that there are no empty spaces dedicated to a vision and inviting to people potentially interested in discussing them. I think it would be nice to have an Incubator category in the forum with sub categories where empty spaces dedicated to a vision could be created. There would be no need for a decision to create a sub-category.

What do you think?

1 Like

Yes, indeed.

The broader visionary framework serves to inspire people to commit themselves, increasing the likelyhood they do so, when they see a path of potential and opportunities to jump in and contribute. Like landscaping a big garden and picturing it first. Ideally I want that landscape to offer a multitude of points where people can jump in, to shape their own ideas. Invariably when they do so, cross-pollination starts to happen and they will be helpers to your cause as well.

Btw, it is not just planting seeds and “let them grow on their own”. The fact that they are there means that we’re able to draw attention to them and say “Look, what we intend to become. You can be part of this”. And I myself - while forgefriends is not my primary project - will give bits of water and nourishment whenever I encounter something that relates to them.

As we discussed on Matrix yesterday, the Forgefriends FSDL will not be an empty space. You are already coding interop-related things and FSDL is where the specification of that can mature. Specification an activity that occurs side-by-side and in parallel to coding. It will help as a assurance of your “Interoperability” requirement to the code project.

“Forge friends”, the ongoing community effort to bring full interoperability to code forges, will need to address standardization in a set of specifications that go well beyond what current standards (AP and DVCS) provide out-of-the-box. They will subsets of these and in particular ways and specific business rules to take into account.

I like the idea of an incubator. Currently there’s already the #discussions:ideas category that serves a similar purpose. But “incubator” is more actionable. Conveys that we want people to experiment.

Yet, I still want to explore having a Forgefriends FSDL as one of the central pillars of the whole concept of “forge friends”. To me it makes a lot of sense if all projects in the forgefriends ecosystem contributed their interop specification to a set of maturing standards.

The incubator category is created. What about moving this topic there? And maybe create a subcategory for FSDL too?

The FSDL sub-category would set an example of what the Incubator category is about: for projects that are more than ideas and yet waiting for someone to actively engage and make progress.

1 Like

Let’s do that. I will make the move and create the subcategory for FSDL.

1 Like

I understand this is how you see it. My perspective is different: the specs are in the shape of tests that evolve with the forgefriends codebase for the time being.

Yes, I understand. That is how you intend to create specs for your code project. Others might then later distill that into something more useful for an Open ecosystem, unless you also intend to create Docs explaining the interop, which you can place directly in FSDL.

In my explanation of various terms I make the distinction between “Forge Friends” → the concept, and “Forgefriends” → the code project. I am referring to the former here. As depicted in my diagram draft I just brainstormed, there are 4 pillars that stand on top of the Mission and that uphold the Vision. It is a depiction of what “Forge Friend” means, in my mind currently.

As you suggested “Forge Friends”, the concept, might be refered to as “forges.social”, but I think in terms of positioning - how that “speaks” to people, the general appeal of that term - that the latter is a much less strong and attractive terminology use.

1 Like

It is done.

1 Like

I have renamed this topic from the text below to the current title:

Forgefriends Free Software Development Lifecycle: Forge specifications incubator project

Reason is that FSDL has moved to the new Social Coding forum in a top-level category Social Coding FSDL - Discuss Social Coding

2 Likes