.
├── blogs
│   └── sgp-blogcncf
├── boards
│   ├── sgp-ghdiscuss
│   └── sgp-stackoverflow
├── core
│   └── generated
├── corp
│   ├── sgp-crunchbase
│   └── sgp-yahoofinance
├── email
├── packages
│   ├── sgp-brew
│   ├── sgp-choco
│   ├── sgp-crate
│   ├── sgp-deb
│   ├── sgp-deno
│   ├── sgp-go
│   ├── sgp-maven
│   ├── sgp-npm
│   ├── sgp-pip
│   └── sgp-rpm
├── rtc
│   ├── sgp-discord
│   └── sgp-slack
├── social
│   ├── sgp-linkedin
│   └── sgp-twitter
├── threats
│   └── sgp-nist
└── videos
    └── sgp-youtube

cnab.io is a great fit.

https://github.com/cnabio/cnab-spec#cloud-native-application-bundle-specifications

Cloud Native Application Bundles (CNAB) are a package format specification that describes a technology for bundling, installing, and managing distributed applications, that are by design, cloud agnostic.

The community has created implementations of the CNAB spec with
opinionated takes on authoring bundles. Some even use Duffle's
libraries to handle the CNAB implementation. If you want to make your own CNAB tooling, that is a great place to start!

...that are...

• frequently used for queries
• description fields (repos, orgs, user profiles, financial disclosures, etc

https://neo4j.com/docs/cypher-manual/current/indexes-for-full-text-search

CALL db.index.fulltext.createRelationshipIndex("taggedByRelationshipIndex",["FOLLOWS"],["date"], { eventually_consistent: "true" })

Creating a project roadmap will give a high-level understanding to would-be contributors of where the project is and where it is going. This should be visualized and easily digestible.

https://neo4j.com/developer/kb/how-to-avoid-costly-traversals-with-join-hints

https://medium.com/neo4j/relationship-chain-locks-dont-block-the-rock-e8db75254b63

Scope for Minimum Viable Product (MVP)

• #38
• import --> Neo4j database (via cypher), base entities in place
• #7
• minimal web based UI to explore graph
• JavaFX native app (running Neo4j in embedded mode)

Stretch Goals

• #40
• #53

https://github.com/quarkiverse/quarkus-neo4j

mvn io.quarkus.platform:quarkus-maven-plugin:2.7.5.Final:create \
    -DprojectGroupId=io.cncf \
    -DprojectArtifactId=panorama \
    -DclassName="org.acme.datasource.GreetingResource" \
    -Dextensions="neo4j,resteasy-reactive-jackson"

Quarkus has an AWESOME dev experience...IJW.

Questions that landscape-graph can help answer (seed) are below.

Definition of Done

• create GitHub Issue Template

• Use it to enter these (post word smithing), and document the others we've talked to in various meetings.

  • The Graph Model (Neo4j based) I’m implementing aims to help to quantify this.
  • What companies / Vendors are employing which projects?
  • What are the resourcing trends across the LF landscapes?
  • What momentum / velocity / growth / correlations can be found?
  • (chris) Can correlate project popularity with market cap?

• examples here https://github.com/devspace/awesome-github-templates
• reach out to https://github.com/cncf/tag-contributor-strategy

• Determine if iterative CDC/ETL style workflow is possible.
• POC Render the following using Envisaged Redux
  • single repo ( anything )
  • multiple repos in the same org (cncf/*)
  • multiple repos across orgs
• Create automated mechanism (script) to drive containerized video creation at scale in matrixed GitHub Actions
• Use langscape-graph to create videos for each project - one per repo, and one per aggregated project (across repos)
• Create mechanism to create one YouTube playlist per project, uploading videos. Comments should have the local commands needed to run it interactively via docker.

Resources for https://gource.io

• https://opensource.com/business/16/8/intro-to-gource
• acaudwell/Gource#229 (comment)

Envisaged Redux

• https://gitlab.com/Cartoonman/Envisaged-Redux
• https://envisaged-redux.vercel.app

Other / Old

Envisaged

• https://medium.com/@jamesbrink/envisaged-dockerized-data-visualizations-with-gource-78888b157f7f
• https://github.com/utensils/Envisaged
• https://github.com/FOSSRIT/gourciferous

GraphQL schema --> source of truth

Tasks

• #52

• MVP CNCF Schema

  • export data model from arrows.app --> landscape.graphql
  • generate full schema from types
  • srg-xyz type heirarchy
  • LandscapeEntity (base type)
    • Card (base)
      • Member
      • Project
      • TAG
      • TOC
      • EUG
      • Person

• use schema to drive data model instantiation --> neo

Moved to new/other issue(s):

• #51
• #96
• constraints and indexes, full text where it makes sense(#73, #20)
• use graphql to load data via mutations. (#63)

More Info

• https://neo4j.com/docs/graphql-manual/current/type-definitions/autogeneration
• https://neo4j.com/docs/graphql-manual/current/type-definitions/database-mapping/#_plural
• https://neo4j.com/docs/graphql-manual/current/type-definitions/database-mapping/#_using_jwt_and_context

resources

• https://neo4j.com/developer-blog/announcing-the-release-of-the-neo4j-graphql-library-3-0-0
• https://youtu.be/8Le6MeTvCAg
• https://github.com/johnymontana/neo4j-graphql-3.0-livestream

• 10k' diagram(s)
• Explain diagram (summary for each component)

Resources to review:

• https://www.cncf.io/community-infrastructure-lab
• https://github.com/CNCF/cluster

TLDR: Ask

• k8s cluster(s), either BM or cloud hosted (EKS, GKE, AKS, ...)
• GitOps workflows assumed (flux, argo, etc)

Start here: https://github.com/cncf/cluster/issues/new

This issue is something of a "spike" and should result in subsequent issues / tasks identified as Next Steps, and some understanding of timeline.

• reach out to contributor strategy for guidance
• put in place sane/rational templates as a starting point
• put in place sane/rational labels as a starting point
• push learnings/feedback/our templates back to tag-contributor-strategy

• https://medium.com/@halcyondude/on-measuring-developer-productivity-9a81a50175da

For each component of landscape-graph create a .md file articulating:

• what it is
• how it works
• what it provides
• why it was chosen

This forms the precursor to proper docs.

Scope

• Neo4j
• Neo4j ETL Tool
• gitbase
• JavaFX
• (to be determined): JavaScript library for front door (neoviz.js, ...)

cncf/landscape-graph is home to a variety of things.

• applications (both utility and end-user facing)
• daily update of landscape.cncf.io, sync'd and cleaned for import to the graph
• graphql schema definitions (source of truth)
• data model artifacts meant for both humans and robot consumption
• Sub-Graph Modules

CODEOWNERS to the rescue!

• https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
• https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features

Tasks

• design w/ artifact (markdown in this repo) for using it for the project
• Generate task breakdown
• DoIt();

cncf.github.io/landscape-graph

resources to incorporate into new contrib docs and/or landscape-graph library

links

• https://memgraph.com/blog/cypher-cheat-sheet

videos

• https://docs.brew.sh/Formula-Cookbook
• https://betterprogramming.pub/a-step-by-step-guide-to-create-homebrew-taps-from-github-repos-f33d3755ba74

• github.com/community-graph
• github.com/community-graph/documentation

Here's the model we have today:

...and how it relates to the community-graph's model:

Here's the community-graph model:

Note that the community graph data import uses the GH GraphQL api. In this project (landscape-graph) the bulk of git info will be coming from src-d/gitbase, however having the interactive / GraphQL mechanism is also useful.

• The git model is already quite close, however the current landscape-graph model doesn't model Issues, and it probably should.

• Add Issue to the Git Model
• Determine what else we should take (now), and what to do in the future (new issues)

• Review the template provided by CNCF
• Create copy in landscape-graph
• @halcyondude to submit CNCF Service Desk request

Sub-Graph Modules

Goals

• facilitate interactive, dynamic expansion of the graph using the core model as a nucleus and/or seed.
• learn from k8s! Don't make "special" kind:'s of things (e.g. Pod, Deployment, Ingress) part of a "built-in" data model, then a custom mechanism for extensibility (CRD's). Instead make the core data model structured with the same compositional mechanisms.
• work with a broad, arbitrary set of targets, environments, toolchains, and compositional frameworks
• Enable a community to gel around this project such that work can happen safely in parallel
• facilitate self-service + automated
  • modern CI (GitHub Actions) to validate SGM's work at PR level
  • autogenerate comprehensive documentation
  • allow exploration and composition
• able to be easily distributed on existing transports.
  • OCI images are a great fit. https://github.com/cnabio/cnab-to-oci

Tasks

• implement inheritance model (see below)

• implement dependency mechanism

• implement core data model as { sgm-base, sgm-cncf, sgm-xyz, ... }

  • base: (e.g. Object)
  • landscape: for all Linux Foundation Landscapes (see https://landscapes.dev)
  • sgm-cncf: Card, Member., Project., TOC, TAG, EUG. Licenses, GitRepo)
    • sgm-cncf-docs (DD's, Charters, governance)
  • sgm-git (Commit, Author, Branch, ...)
  • sgm-github (Issue, PR, Comment, Workflow/Action, Teams (nested)

• Sub-Graph Modules: Design and Architecture

  • Create Summary info, slides, and a blog post ("How to extend our graph")
  • reach out to neo4j for feedback on sub-graph module approach
  • reach out to CNAB.io project to assess viability
  • sgm:blog + template + examples

Types of Sub-Graph Modules (SGM)

Each of these is an Interface, acting as a base class with shared properties. Reasons to structure in this way include:

1. enables treating classes of things polymorphically while leaving concrete instances' portion of state undisturbed.
2. lowers the barrier to entry for new contributions
3. provide blast radii for the model as a whole
4. facilitate pruning and cardinality reduction of test surface requisite to validate changes in CI. As even casual data sets have the potential to be non-trivial in size, and potential cost, an intentional & structured approach is warranted.

Each module shall have:

• base metadata (name, version, ...)
• GraphQL Schema fragment
• cypher, javascript / other expression of orchestrating growing/pruning/mutating/refactoring/... the graph
• Description / Documentation covering entities
• png, svg,
  • portion of the model (from arrows.app or similar) <-- used for visual diff later
  • (optional, preferred): SVG/png used for Bloom and other front ends to annotate nodes
• sample data, patterns, and queries
• (optional) label map providing association between the module's own names/terms, and what they might be called in the broader data model that the SGM is being loaded into. This will reduce fragility, and provide a mitigation for the inevitable label name mismatches that could happen as a result of parallel development. it'll also make these more portable
• CI

Taking this approach facilitates creation of a rich set of capabilities impacting model training, CI, and developer experience.

By using snapshots of the graph (Graph Projections TODO doc link) in a manner similar to virtual machine snapshot trees (esx, hyper-v, ...), CI can

• quickly set up base cases and test variations for as a matrix
• enable smart cross-SGM dependency-aware CI to be used, such as https://zuul-ci.org or similar workflows
• enable automated ML model experimentation and training at scale
• per-PR live instances

We'll also benefit from a sustainable, portable, useable data model that is documented.

(TODO: update w/ final set)

.
├── blogs
│   └── sgm-blogcncf
├── boards
│   ├── sgm-ghdiscuss
│   └── sgm-stackoverflow
├── core
│   └── generated
├── corp
│   ├── sgm-crunchbase
│   └── sgm-yahoofinance
├── email
├── packages
│   ├── sgm-brew
│   ├── sgm-choco
│   ├── sgm-crate
│   ├── sgm-deb
│   ├── sgm-deno
│   ├── sgm-go
│   ├── sgm-maven
│   ├── sgm-npm
│   ├── sgm-pip
│   └── sgm-rpm
├── rtc
│   ├── sgm-discord
│   └── sgm-slack
├── social
│   ├── sgm-linkedin
│   └── sgm-twitter
├── threats
│   └── sgm-nist
└── learning
    └── sgm-youtube

ACTIVE DEVELOPMENT

Closely related to this issue is: #4 (branch)

How GraphQL Interfaces Work

https://neo4j.com/docs/graphql-manual/current/type-definitions/interfaces/#_directive_inheritance

Any directives present on an interface or its fields will be "inherited" by any object types implementing it. For example, the type definitions above could be refactored to have the @relationship directive on the actors field in the Production interface instead of on each implementing type as it is currently:

interface Production {
    title: String!
    actors: [Actor!]! @relationship(type: "ACTED_IN", direction: IN, properties: "ActedIn")
}

type Movie implements Production {
    title: String!
    actors: [Actor!]!
    runtime: Int!
}

type Series implements Production {
    title: String!
    actors: [Actor!]!
    episodes: Int!
}

interface ActedIn @relationshipProperties {
    role: String!
}

type Actor {
    name: String!
    actedIn: [Production!]! @relationship(type: "ACTED_IN", direction: OUT, properties: "ActedIn")
}

https://neo4j.com/docs/graphql-manual/current/type-definitions/interfaces/#_overriding

In addition to inheritance, directives can be overridden on a per-implementation basis. Say you had an interface defining some Content, with some basic authorization rules:

interface Content
    @auth(rules: [{ operations: [CREATE, UPDATE, DELETE], allow: { author: { username: "$jwt.sub" } } }]) {
    title: String!
    author: [Author!]! @relationship(type: "HAS_CONTENT", direction: IN)
}

type User {
    username: String!
    content: [Content!]! @relationship(type: "HAS_CONTENT", direction: OUT)
}

type PublicContent implements Content {
    title: String!
    author: [Author!]!
}

type PrivateContent implements Content
    @auth(rules: [{ operations: [CREATE, READ, UPDATE, DELETE], allow: { author: { username: "$jwt.sub" } } }]) {
    title: String!
    author: [Author!]!
}

Core Data Model

https://github.com/ferstl/depgraph-maven-plugin