/start git submodule

[0x4007]

Task matchmaking will be very powerful when coupled with the /start logic in this plugin.

The key magic of /start is that it is designed to check if the assignee is already saturated with work (i.e. ¹ two concurrent tasks max) or needs to place their attention on any existing open pull reviews etc.

Task recommendation should have the ability to automatically assign team members based on how saturated they are. If for example the top three recommendations are

1. ² gentlementlegen
2. whilefoo
3. shiv810

But gentlementlegen is already working on two projects concurrently, then the matchmaking should automatically go to the next suitable candidate, Whilefoo.

The purpose of this proposal is so that we don't need to duplicate the logic in that plugin for matchmaking. ³ Instead, we should expose an API to have this plugin compute whether gentlementlegen can start or not.

1. Let's clone the command-start-stop repository as a submodule inside of the text-vector-embeddings repository and then invoke the logic locally.
2. Let's add the capability to assign collaborators based on the output of start logic. ⁴

cron future

We can constantly check the saturation state of team members and when they finish a project they can be automatically assigned to any that need to be completed, in order of priority. Then the AI manager will always be pushing to get urgent tasks done.

It will also intelligently not assign those who are already disqualified because that's also in the start logic! ⁵

Footnotes

1. ⚠ 68% possible duplicate - Double Task Recommendation ↩

2. ⚠ 77% possible duplicate - Improving Recommendations ↩

3. ⚠ 69% possible duplicate - /annotate ↩

4. ⚠ 74% possible duplicate - Task Matchmaking ↩

5. ⚠ 69% possible duplicate - Always Recommend Talent ↩

[ubiquity-os-beta]

Note

The following contributors may be suitable for this task:

Keyrxng

77% Match ubiquity-os-marketplace/command-start-stop#6

shiv810

75% Match ubiquity-os-marketplace/text-vector-embeddings#7

[Keyrxng]

I'm not confident that cloning the repo and using it as a submodule will work right out of the box the way you want it to reading the spec.

command-start-stop would need updated/refactored in order to work via that approach. So to me it makes more sense to open up an API from command-start-stop that runs the "vetting" steps without any of the actions as a result of the vetting.

[0x4007]

I think a plugin can't call another plugin directly with our architecture so that's why I changed from exposing a public api to a submodule.

[Keyrxng]

I think a plugin can't call another plugin directly with our architecture so that's why I changed from exposing a public api to a submodule.

Why can't a plugin call another? Sorry I may have missed an update.

---

The start-stop API exposed could use either no auth or the same handshake that the kernel uses.

• Convert plugin to cloudflare worker ubiquity-os/permit-generation#92
• Feat/workerize ubiquity-os/permit-generation#96

The idea of the above was that any plugin could call permit-generation maybe that has since changed but it's still possible afaik. E.G. kernel-telegram eventually will allow any plugin to call it's API for dms etc.

---

I think no-auth and/or a domain-based auth would work well with work.ubq as you could run the vetting for tasks to display also. Similar to the two endpoints via this pr.

[0x4007]

You're right about work.ubq.fi needing the start logic. Again this could be submoduled in possibly but a public API seems more straightforward. From a worker I can see this being possible but from an action I'm not sure.

The problem I see is that there are many tasks listed. Running a remote operation hundreds of times seems problematic. However if the code is client side (submodule) then it should not be a problem.

[Keyrxng]

From a worker I can see this being possible but from an action I'm not sure.

I'd say possible from an action too the difference being that we'd need to fire the workflow using a custom event via the kernel and/or dispatching the workflow directly using the APP_PRIVATE_KEY etc. The response we'd need to pull from output I'd expect.

The problem I see is that there are many tasks listed. Running a remote operation hundreds of times seems problematic.

Indeed although we wouldn't be running it against each task but simply checking the user against the network for assigned tasks which I'm sure is still handled via search api. This handles over-assignment quickly. For each PR we detect if they are 'allowed' to start another, in reality this number should always be relatively low.

For task access, which is now handled via priority + org permissions, we'd only need to permission check against a Set of partners, which would be cached. The new devpool data JSON contains labels etc for comparison client-side vs 'running it against each task'.

Worker or Submodule both are possible and have their own pros and cons, I'd lean towards API vs submodule but you raised valid points in support. EDIT: I realise I've sort of merged specs and products with this comment (as it affects at least three), my apologies.