Problem
Skill labels need to be manually set up in skills.json. This
- increases manual work on the part of repo maintainers to ensure that the skills listed in a different repo (this one) are up to date
- causes redundancy of information that is already present in
cc-metadata.yml under the technologies key in each repo
Description
The technologies key could be expanded to a more verbose structure to describe languages, libraries and frameworks and then used to eliminate the need for skills.json entirely. This presents benefits such as
- richer information about the technological make-up of our projects
- automated sync of labels with technologies
Alternatives
The improvements to .cc-metadata.yml can be a good-to-have part of the feature if there isn't a consensus to proceed with that. But the automation of skill labels is still beneficial. Also it does not have to be binary, a combination of .cc-metadata.yml and skills.json would also be a fine solution.
Implementation
Problem
Skill labels need to be manually set up in
skills.json. Thiscc-metadata.ymlunder thetechnologieskey in each repoDescription
The technologies key could be expanded to a more verbose structure to describe languages, libraries and frameworks and then used to eliminate the need for
skills.jsonentirely. This presents benefits such asAlternatives
The improvements to
.cc-metadata.ymlcan be a good-to-have part of the feature if there isn't a consensus to proceed with that. But the automation of skill labels is still beneficial. Also it does not have to be binary, a combination of.cc-metadata.ymlandskills.jsonwould also be a fine solution.Implementation