-
Notifications
You must be signed in to change notification settings - Fork 18
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
Feat/experience check #17
Conversation
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. |
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.
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 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 |
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. |
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 |
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:
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" |
A label that says |
Okay so a configurable array of suffixes and a prefix 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 Or we have |
Interesting idea! I think senior and junior are precise enough for our needs, and easily understandable.
! 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 |
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? |
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. |
Closed because this will be it's own plugin and not an extension of |
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
repo
to pull stats as seen in my readmeexperience
config itemI'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 formostImportantLanguage
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: