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

Start by reviewing the proposed YAML fields in this issue and comparing the GrimoireLab projects file and Eclipse Foundation initiative linked under Prior art. Consider the source-control metadata alternative alongside a repository file; done means reaching an agreed format or a clear decision not to define one.