V1: Artificial Intelligence

[0x4007]

AI powered features

• PR code refactoring
• Recruiting via GitHub
• Prevent duplicate issues
• Weekly reviews every week in the DevPool

[0x4007]

Refactoring code on PRs draft

kxxt/chatgpt-action#9 (comment)

At a high level, I'm hoping that it can parse CI test logs and find where it crashed/had an error. Then we can pass the source code of the file and say, here is the error on this line, please refactor etc.

Then the bot should make a new branch, commit the refactor, then open a PR to the current PR with the fixes so that we can easily merge/reject the proposed changes. Best if those changes also run against CI tests then we know right away if its good or not.

It might be able to run recursively continuously hitting a new error in CI so imagine brute forcing until we get a solution. That could be really interesting. Because of this, we might need to check the amount of commits of the current branch before it is committed again and before the branch is merged. We can set a max limit of e.g. 10 commits and kill the process in case it can't figure out how to refactor/fix the problem.

[0x4007]

"Robb Oat" a GitHub Bot that uses OpenAI Codex in order to fix code (it even opens a pull request!) I think I'll want to test on my fork.

robb-oat/server#2
https://github.com/marketplace/robb-oat

[0x4007]

Tagging developers on GitHub in an issue comment who already solved a similar issue

I think we could charge a lot of money (e.g. $10 per time a repo admin calls it) for this feature for two reasons: 1. if it works and 2. to limit spam/abuse

• We have a private database of 20k+ crypto developers.
• If we scrape all the issues that they have closed, we can compare the similarity to the current issue that we need new devs to handle.
• We already tested if we can ping them with a notification by commenting their handle. By default, GitHub will send an email and notify them on the GitHub notifications bar.
• Imagine if we post a new bounty/issue and then execute the command /recruit etc and the bot will post a comment to get the dev's attention on the issue like:

Hey @pavlovcik I looked around on GitHub for crypto developers and it looks like you solved a very similar issue before, ubiquity/ubiquity-dollar#342, and we'd like to know if you're interested in helping us out on this one for 500 DAI? Please let us know as soon as you can. Thanks!

Flow

• Code admin writes /recruit
• Bot checks dollars sent from registered project bounty wallet back to bot to "top up" the project's recruiting balance
  • If none, then the bot requests payment e.g. "

    • Please topup at bot.ubq.eth with your configured wallet address 0x29a2416f757b9b46e60309090cd7b6d32c856e43

  • Another configuration would be for the bot to pull it from their wallet directly if they granted permissions e.g. /recruit --pay
  • If yes, then the bot will comment

    • Searching on GitHub now for a developer who has solved a similar issue. You can cancel the current operation by commenting /cancel before I finish

• Bot deletes all the /recruit related comments, including the bot responses, and then leaves a new comment introducing the prospective candidate like in my earlier message above.

Appendix

• Assuming that I have enough budget e.g. $500 for 50 issues, this would be really interesting to tell the bot to go through all the open and unassigned issues and recruit for all of them. One developer recruitment per issue will make it feel much more personal and perhaps avoid spam issues.
• We will need to allow the candidate to command the bot to remove themselves from the database so that we never contact them again if they aren't interested. We will add them to a new "do not contact" database table so that we can continue populating our database but we'll just make sure to skip candidates that appear on the "do not contact" list.
• We technically could do /recruit and /recruit @ubiquity (or current partner's org name) to limit the search only within a certain organization. This could be a useful tool to automatically assign to one's own team members. We could also limit it to just one's own org name instead of targeting other orgs.
• We could technically also just assign the bot (us) as the recruiter and be eligible for the organization's recruiting incentive reward which should be baked into this bot too.
• We could consider a LInkedIn Sales Navigator-like product where we provide access to our database, and they can go and pick who they want but I think the bot picking is more elegant.

[0x4007]

Prevent duplicate issues

Once the bot as the capability to measure the similarity of issues, it should have a new handler when a new issue is made. It should automatically check the repo for similar issues. If it is e.g. 80% similar or higher, it can comment right away linking the similar issue with its similarity score as a warning.

This will reduce duplicate issues from being created.

[0x4007]

Vector similarity

Vector similarity refers to a measure of the similarity between two related items. For example, if you have a list of products, you can use vector similarity to find similar products. To do this, you need to convert each product into a "vector" of numbers, using a mathematical model. You can use a similar model for text, images, and other types of data. Once all of these vectors are stored in the database, you can use vector similarity to find similar items.

Used in: https://github.com/mckaywrigley/repo-chat

Source: https://twitter.com/mckaywrigley/status/1650961890447851520

[0x4007]

https://github.com/Dicklesworthstone/fast_vector_similarity

[0x4007]

Weekly reviews in the DevPool from all bounties in network

• what-the-diff supports slack but if we can make it work with telegram that would be far more crypto native.
• Posting this weekly update in the devpool along with the new bounties would be a huge luxury.

We closed seven pull requests last week! 🚀
This week, we added more tests for the ERC20Ubiquity contract, fixed a bug that was causing incorrect balances to be displayed in the footer, added spell checking for dapp and contract scripts, added a custom 404 page, implemented the ERC-2535 Diamond standard, fixed a bunch of Slither issues, adapted the contract to simplify UBQ farming, and fixed a bunch of warnings.
Great job everyone! 💪

[sergfeldman]

3 projects based on the GitHub data:

Bounty-Developer matchmaking - identify the most appropriate developers to solve a certain bounty.

Developers management system - optimize and automate management of development teams.

Project development reporting - provide analytics and predictions of the development success for the investors and community.

[0x4007]

Bounty-Developer matchmaking

Is a dope one but its already handled by bullet point 3 under Appendix of "Tagging developers on GitHub in an issue comment who already solved a similar issue"

We technically could do /recruit and /recruit @ubiquity (or current partner's org name) to limit the search only within a certain organization. This could be a useful tool to automatically assign to one's own team members. We could also limit it to just one's own org name instead of targeting other orgs.

Can you write a draft spec of the development reporting? Please make sure to deeply inspect the insights/analytics that GitHub already currently offers (they have a new analytics experience on the organization level insights/analytics tab https://github.com/orgs/ubiquity/insights)

Developers management system

This one I'm unclear on if we already discussed the idea (I assume we have) I already forgot. Can you clarify some details?

[sergfeldman]

Bounty-Developer matchmaking

I would suggest automating the flow as much as possible like Autopilot.
The repo admin sets the budget for the particular issue, and then only reviews the PR that solves the issue.

The entire proceses of the Bounty-Developer matchmaking (ie selecting a developer, changing a developer to a new one in case of not success, etc), and the bounty resolution till the PR should be performed without a need of any action from the repo admin.

Can you write a draft spec of the development reporting?

Yep, I will write the draft. It will take some time.

Developers management system

Here is the draft
https://github.com/orgs/ubiquity/discussions/15

[0x4007]

The entire proceses of the Bounty-Developer matchmaking (ie selecting a developer, changing a developer to a new one in case of not success, etc), and the bounty resolution till the PR should be performed without a need of any action from the repo admin.

Cool idea! I'm just a little skeptical because I feel like unless if the developer is currently "enrolled" in our DevPool, they will need some convincing.

Also after writing the below section, I feel like there are benefits to being more hands-on in selecting the type of talent you want to work on the bounty.

Recruiting Filters

For example:

/recruit @ubiquity --completed 1

Probably not the best syntax (but good for those familiar with working on a command line) the intent here is that we're calling the "recruit" command, filtering in the @ubiquity organization, and then using the "completed 1" parameter which means that they have already completed one bounty (and are familiar with the DevPool.)

Another level of this could be:

/recruit @ubiquity --completed 2

Only select a bounty hunter with 2 minimum completed bounties.

If we have too many filters there is a good chance that no results will be found unfortunately.

[0x4007]

Meeting minutes regarding full autopilot/automation (automatic recruiting of devs on new issues)

• allow for full autopilot for less picky repo maintainers
• allow for manual /recruit function calling if desired

[sergfeldman]

Competitors for the Bounty-Developer matchmaking
https://github.com/marketplace/codespread-prod
https://codespread.io/

[0x4007]

Competitors for the Bounty-Developer matchmaking

https://github.com/marketplace/codespread-prod

https://codespread.io/

Looks like they do hourly like upwork.
I'm skeptical about the talent pool; ours is industry specific

[0x4007]

I think that we can convert all of our bot commands into natural language processed inputs. We could listen for @ubiquibot tags (?) and then parse the natural language using ChatGPT to determine which function the user is most likely referring to.

Example:

• @ubiquibot please register my wallet address to be pavlovcik.eth
• @ubiquibot set my payout multiplier to be 0
• @ubiquibot show me the help menu

We could leave in the direct bot commands as they are far more concise, but natural language processing should make interacting with the bot more user friendly.

[rndquu]

Yes, ChatGPT is extremely good at intent recognition, i.e. it can parse @ubiquibot please register my wallet address to be pavlovcik.eth into the /wallet command under the hood (but we still need to extract the address ourselves). This way we can have ChatGPT on the "front" side while still maintaining the good old command interfaces as a fallback.

[sergfeldman]

If we are going to build with OpenAI API then it would be good to get an organisational access.
Better if it is requested to the @pavlovcik credentials to keep the control.

The API is already available for companies
https://openai.com/blog/introducing-chatgpt-and-whisper-apis
https://platform.openai.com/account/org-settings

There are examples of the tasks, including the one for this case - natural text to command
https://platform.openai.com/examples/default-text-to-command
https://platform.openai.com/examples

[0x4007]

If it's free please sign us up