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

Bắt đầu bằng việc xem xét các trường YAML được đề xuất trong issue này và so sánh GrimoireLab projects file cùng Eclipse Foundation initiative được liên kết dưới Prior art. Hãy xem xét phương án thay thế là siêu dữ liệu kiểm soát mã nguồn cùng với một tệp trong repository; hoàn thành có nghĩa là đạt được một định dạng đã thống nhất hoặc một quyết định rõ ràng là không định nghĩa định dạng đó.