Pattern idea: Common metadata format to aid discovery of Inner Source projects

Following on from a conversation in the ISC Slack, would a metadata file added to Inner Source repos in source control (e.g. inner-source.json or inner-source.yaml) aid discovery of Inner Source repos within an organisation? If so, should we define a common format for this metadata?

Alternatively, should this information be derivable from your SCM tool (GitHub/GitLab/Bitbucket etc.)? This would negate the need to add a file to each inner source repo in your organisation.

One suggested format:

# description should be one paragraph
description: This is where you describe the purpose to your users.  
Is this a component library, is this a template project, what 
benefit is there to me if I use this library in my own project. You
Could even say something about how the project is versioned here. 


# github pages or a conflunce link by default 
# could be a readme for the project
documentation: https://github.com/InnerSourceCommons/InnerSourceLearningPath/

# technologies used
technologies: Javascript, React, Graphql, etc..

# comma separated list, name <email> (url)
maintainers: Barney Rubble <brubble@flintstones.net> (http://barnyrubble.tumblr.com/)

Prior art:

• GrimoireLab projects file format.
• Related initiative at the Eclipse Foundation

Beginne damit, die in diesem Issue vorgeschlagenen YAML-Felder zu prüfen und die unter Prior art verlinkte GrimoireLab projects file und Eclipse Foundation initiative zu vergleichen. Berücksichtige die Alternative mit Source-Control-Metadaten neben einer Repository-Datei; abgeschlossen ist die Aufgabe, wenn ein vereinbartes Format oder eine klare Entscheidung, keines zu definieren, erreicht wurde.