Feat/experience check

[Keyrxng]

Resolves ubiquity-os/plugins-wishlist#26

It's rudimentary but something is better than nothing at least and is a good starting point for extending things further

• Uses https://github-readme-stats.vercel.app repo to pull stats as seen in my readme
• Adds experience config item

default: {
          minAccountAgeInDays: 365,
          mostImportantLanguage: { Typescript: 10 },
          languages: { Solidity: 10, JavaScript: 10 },
          statThresholds: {
            stars: 1,
            minCommitsThisYear: 1,
            prs: 1,
            issues: 1,
          },
        },

I'm unsure about default values other than minAccountAgeInDays and what ones we should give more weight to considering what we have to work with.

Rather than having to define a custom config for each repo I'm thinking we could pull stats using the repo/statistics endpoint for the payload repo and determine what sort of codebase it is then map languages to specific setups for mostImportantLanguage etc. But I think this should be handled in a separate PR.

---

If this would be better served as a standalone plugin let me know but it seems like this functionality should be built into the start/stop plugin.

QA:

• checks ubq-testing/command-start-stop#8

[gentlementlegen]

It is not written in the spec but I think there might be details on the requirements needed for the task displayed somewhere. Also given your code it seems to be based on the configuration, not task based. I think we should be able to set these individually per issue as it was stated in the specification.

[Keyrxng]

I think we should be able to set these individually per issue as it was stated in the specification.

This would require a change to how tasks are labelled to be effective wouldn't it and would also need a tier system that would correlate to the actual XP system that's not implemented at the moment.

It would be great to know that collaborator solving the above issues has prior experience with solidity and ethereum.

The spec aims to guard Solidity tasks based on prior experience which is handled with this implementation effectively as anyone with that experience should have it in their language stats

My thinking is that any solidity based tasks would exist in solidity-heavy repos so defining a config in that repo with mostImportantLanguage.solidity = 25 would suffice. Later maybe the config maps setups for each language eliminating the need for a custom config in each repo

---

Creating a new task labelling system that's inline with the vision of the XP system etc seems non-trivial and if that is what this xp check should be based on for the first iteration could we setup a task and define these things clearly and I will be able to work on what's needed to push this forward

[gentlementlegen]

This would require a change to how tasks are labelled to be effective wouldn't it

Yes that was what I thought, this way we could guard per issue, and also have any custom tag that would cover any tech (say we want Supabase experience, TypeScript, Solidity and whatnot). Otherwise I guess the finer we can get with a configuration is on a repo basis, which is maybe fine for now.

I do not know how important this is, and how fine grained we want to get! Maybe some input from @0x4007 would be helpful.

[Keyrxng]

Otherwise I guess the finer we can get with a configuration is on a repo basis, which is maybe fine for now.

I guess the markers other than account age could be removed as they seem sort of irrelevant and replaced with something like

experience:
 thresholds:
  solidity: 25
  typescript: 15
 languages:
  solidity:
   - ubiquity/ubiquity-dollar
   - etc..
  typescript:
   - pay.ubq.fi
   - etc...

but it's not very efficient as we'd need to define every single repo. Even mapping setups to specific languages (based on the github api repo stats endpoint) is going to make the config pretty huge. I'm trying to think of a more streamlined way of doing things

[rndquu]

I agree that we should be able to apply the "experience check" feature to individual github issues instead of the whole organization at once.

We should somehow let the plugin know that the issue is guarded:

• either by a new label (like Guard: solidity)
• either by a comment in the issue specification (basically the same Guard: solidity).

The issue with this approach is that it can be applied only to programming languages (keeping in mind that in the end we match contributor's languages from https://github.com/anuraghazra/github-readme-stats and original issue repository languages). It doesn't "guard" UI/UX or devops issues. Perhaps it's enough for v1.

[0x4007]

A label that says Requires: Solidity could be intuitive and dynamically parsable.

[Keyrxng]

A label that says requires: solidity could be intuitive and dynamically parsable.

Okay so a configurable array of suffixes and a prefix requires: , got it.

So say we apply the label, then we check the user's solidity percentage and what do we compare it against? Where does our issue-level threshold come from?

Is that another label like threshold: 25? Because that would only work for one filter per issue. Maybe requires: Solidity (25)?

Or we have requires: Solidity (Easy) etc, and map these to org-level customizable values?

[0x4007]

Or we have requires: Solidity (Easy) etc, and map these to org-level customizable values?

Interesting idea! I think senior and junior are precise enough for our needs, and easily understandable.

Difficulty: TypeScript (Senior)
Difficulty: TypeScript (Junior)

! Your experience level does not appear to be high enough to work on this task. 

I don't really like how "senior" and "junior" look.

Maybe it could be cooler to write Rank: TypeScript (Pro) and Rank: TypeScript (Mid).

[Keyrxng]

Interesting idea! I think senior and junior are precise enough for our needs, and easily understandable.

So would this be a global org config item that contains all of our mappings to our label languages and tags etc? I thought we'd define everything within the plugin config like:

- with:
    labels: 
      - solidity:
          - junior: 5
          - mid: 15
          - pro: 50
          - rockstar: 70

or something like

- with:
    ranks:
      - junior: 5
      - mid: 15
    labels: ["Typescript"]

first one is more granular but way more verbose. Also of the markers mentioned here, which ones should we keep and which ones should be removed?

[0x4007]

Let's keep the config simple and just follow this strategy. I suppose we would need to parse the file extension to determine the language.

[Keyrxng]

Closed because this will be it's own plugin and not an extension of start-stop, I'll pick this up tomorrow

[Keyrxng]

https://github.com/ubiquibot/task-xp-guard/pull/1