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

Commencez par examiner les champs YAML proposés dans cet issue et par comparer le GrimoireLab projects file et l’Eclipse Foundation initiative liés sous Prior art. Prenez en compte l’alternative des métadonnées de contrôle de version en parallèle d’un fichier du dépôt ; le travail est terminé lorsqu’un format convenu est atteint ou qu’une décision claire de ne pas en définir est prise.