Automate skill label generation

[dhruvkb]

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

• I would be interested in implementing this feature.

[kgodey]

I think it makes sense to build the skills based on .cc-metadata.yml and expand the technology list there.

I wonder if we could also encode branch protection in .cc-metadata.yml instead of storing it here, that way all configuration related to a repo could live in that repo. That should be a separate ticket though.

[Cronus1007]

@dhruvkb Shall i implement this one.

[dhruvkb]

Yeah @Cronus1007, please do! But let's start with a plan on how the .cc-metadata.yml file will look like before starting development.

[Cronus1007]

@dhruvkb Here what I am planning that first of all let us make a request on https://api.github.com/orgs/creativecommons/repos and then get all the pinned repositories. Then we can proceed to get the first three most prioritized technologies of the pinned repos.

[dhruvkb]

The skill label generation has to work on all CC repositories, not just the first one. Also why just the first three technologies and not all of them?

Another important consideration is regarding language and framework/library. For example, someone who is quite familiar with JavaScript might still experience some problems if the issue is very Vue-oriented... so the frameworks have to be factored in when building labels.

[Cronus1007]

@dhruvkb Let me a build a seperate folder for this and initialize this project by eod or should I build a local repo.

[Cronus1007]

Set the ADMIN_GITHUB_TOKEN environment variable with your GitHub token.
You will need a GitHub token with admin permissions to the creativecommons
GitHub organization.

Any opinoin regarding this?

[dhruvkb]

@Cronus1007 you can create a test organisation on GitHub and use your own personal access token to test your scripts on it.

[Cronus1007]

@dhruvkb Since I am much comfortable with javascript so shall I make a node app rather than django app.

[Cronus1007]

I have made a test repo depicting the behaviour .
https://github.com/Cronus1007/testing

[Cronus1007]

@dhruvkb I am able to write skills.json but due to some reason the api call is just restricted to first 30 repos of the cc organization. I may require some sort of help from your side to tackle this problem.

[dhruvkb]

The package you are using for the API call might be paginated. Please open a draft PR so that we can take a closer look at your code.

[zackkrida]

@dhruvkb @Cronus1007

Because this repository is already written in Python, I don't think I'm going to approve any code written in JavaScript. Having 90% of the codebase written in Python and a single script written in JavaScript creates additional maintenance burden and complexity in the repository.

@Cronus1007 if you'd like to attempt to work on this in Python, I'm sure our community on GitHub and Slack would be very willing to help you! Otherwise, unless @dhruvkb has opinions on why we should allow JavaScript, you're welcome to keep working on other issues. Thank you.

[Cronus1007]

@dhruvkb @Cronus1007

Because this repository is already written in Python, I don't think I'm going to approve any code written in JavaScript. Having 90% of the codebase written in Python and a single script written in JavaScript creates additional maintenance burden and complexity in the repository.

@zackkrida I agree with this part but in my #122 PR it is just a roght idea of the approach. But while merging I will make the transition from js to python.

[Cronus1007]

@zackkrida @dhruvkb I am done with the #122 PR to automate the process and generating the required skills.json via python mainly and even left few comments upon the PR.