Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feat/experience check #17

Conversation

Keyrxng
Copy link
Member

@Keyrxng Keyrxng commented Jul 27, 2024

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

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:

@gentlementlegen
Copy link
Member

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
Copy link
Member Author

Keyrxng commented Jul 28, 2024

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
Copy link
Member

gentlementlegen commented Jul 28, 2024

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
Copy link
Member Author

Keyrxng commented Jul 28, 2024

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
Copy link
Member

rndquu commented Jul 30, 2024

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
Copy link
Member

0x4007 commented Jul 30, 2024

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

@Keyrxng
Copy link
Member Author

Keyrxng commented Jul 31, 2024

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
Copy link
Member

0x4007 commented Jul 31, 2024

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
Copy link
Member Author

Keyrxng commented Jul 31, 2024

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
Copy link
Member

0x4007 commented Jul 31, 2024

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 Keyrxng closed this Aug 7, 2024
@Keyrxng
Copy link
Member Author

Keyrxng commented Aug 7, 2024

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

@Keyrxng
Copy link
Member Author

Keyrxng commented Aug 8, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Check dev experience on starting an issue
4 participants