Support for .github model

[ljharb]

(reposting from slack)

hi! i just saw the insights example spec file, and it seems like it's 1 file per repo - from both an OSPO and a "large open source org" perspective, anything that can't be configured for multiple repos at once via the .github repo is somewhat of a nonstarter.
I personally have 400+ repos across over a dozen users and orgs, and making 15 files is far more reasonable an ask than making 400+ :-)

is there a way this spec could be adapted to work for this existing workflow that everyone's come to rely on from github?

[eddie-knight]

This needs to be added to the roadmap, as inheritance is a topic the community has flagged for detailed investigation following initial exploration. Leaving this issue open due to it being a great suggestion— but labelling it as "not ready" for the moment.

[eddie-knight]

@ljharb which values would you like to see handled at an organizational level? I can see potentially something like contribution policy and dependency policy could be shared across many projects... maybe some others?

My second question is regarding intended use... How are you envisioning that the parent data is ingested alongside the child data? When a human or automated reader look for insights on a repo, do you expect that they would look at a predictable location in GitHub/GitLab/Bitbucket/etc to find the inherited information? Or would the child file include a reference to the parent file?

[ljharb]

@eddie-knight virtually everything that's not project-specific - contribution policy, security testing, security contacts, vuln reporting, from a quick scan of the list.

It must not require a change in each individual repo; the way .github works for most things is that the first item found in the following list "wins":

• $owner/$repo/$file (if allowed at the root)
• $owner/$repo/.github/$file
• $owner/.github/$file (if allowed at the root)
• $owner/.github/.github/$file

In this case, since some items (or sections) would live individually and some shared, I'd assume that the same logic would apply at that granularity - iow, as soon as you find an item or section, that's the final value, and you keep moving up until every item/section is defined.

[eddie-knight]

I've been having a hard time with this topic because it sounds to me like this is strictly an issue for ingestion, and I don't think the specification should have an opinion on the matter.

If a tool is built to handle this GitHub use case, that's great! But what would be different in the spec?

[ljharb]

The spec should cover the location of the file, and what should be in it - and in the event of platform-specific merging, needs to be unambiguous about what things can live where, and on what granularity things can be overridden.

In other words, “ingestion” is the only way to use the spec, so it’s the most important piece.

[eddie-knight]

@ljharb could you create a PR to specification.md with your proposed change?