Consider using the landscape YAML file as data source

[tegioz]

Hi 👋

We've started looking into this and there are some points we'd like to comment with you 🙂

• Multiple repositories per project

In the landscape.yml file, each project contains a repo url. In CLOMonitor, projects can have multiple repositories (they do often), so we'd need to get that information from the landscape.

• Additional information per repository

This point is related to the previous one. In addition to being able to list multiple repositories per project, we also need some extra information defined per repository in addition to the url. At the moment this would be mainly for the checks sets. In CLOMonitor, each repository is assigned one or more checks sets, which defines the checks that will be run on it. This information should also be available in the landscape.yml file.

• Missing data

There are some projects (~25, not always the same ones) that miss some information, like the accepted_at or the devstats_url fields. Some of the features in CLOMonitor rely on them, so it'd be great if they could be added.

There will probably be some more points to address, but this should be a good start.

Thanks!

BTW do you think we could display a CLOMonitor report summary per project on the Landscape page somehow? 😇

/cc @caniszczyk @jeefy

[chalin]

/cc @nate-double-u

[nate-double-u]

BTW do you think we could display a CLOMonitor report summary per project on the Landscape page somehow? 😇

+1

[tegioz]

BTW do you think we could display a CLOMonitor report summary per project on the Landscape page somehow? 😇

+1

Do you know who could we talk to to make it happen @nate-double-u ? 🙂

[tegioz]

Hi 👋

Projects management is now handled via data files (please see #547 for more details). If you need to add, update or delete projects, you can do so by editing the data file of the corresponding foundation in this repo.

This is an intermediate step towards using the landscape data file as a data source for CLOMonitor. Once we agree on how to proceed with the changes required to the landscape data file, we can add it as an additional format supported by the registrar component. This way, if CLOMonitor was to be used out of the Linux Foundation scope, users would be able to pick the format that suits their needs best, instead of being forced to follow the landscape data file format.

/cc @caniszczyk @jeefy

[aliok]

Multiple repositories per project
In the landscape.yml file, each project contains a repo url. In CLOMonitor, projects can have multiple repositories (they do often), so we'd need to get that information from the landscape.

• Projects might have more than 1 GitHub organization
• Projects might have more than 1 repository
• Projects might be creating/archiving repositories frequently

...
Additional information per repository

• Not all repositories are good for CLOMonitor/CLOTributor
• Repositories have different checksets

Ideally, as a maintainer, I don't want to do anything about CLOMonitor/CLOTributor. I would want everything to be automatic.
Or, if there are some manual tasks I need to do, I want some tool/person to tell me "you need to do this and that".

So, how about:

1. Specify GitHub organizations in CNCF landscape YAML for projects
2. Iterate over all repositories in the orgs
3. If a repo has .clomonitor file, with all the settings for the repository (checksets, include/exclude, etc), use it
4. If repo doesn't have it
   a. Skip the repository
   b. Send an automated notification (not sure where? CNCF Slack? project mailing list? etc?) to the maintainers to take care of the repository (this notification should be sent for entire project, not per repository)

Send an automated notification

This can even be a manual email from the CLOMonitor people initially

[aliok]

Hm, related...

How is the process look like for Devstats?