UbiquiBot Capabilities Overview

[0x4007]

Capabilities Overview

Organized by release milestones:

• MVP: Setup #67 - This is required to start pitching to prospective partners.
• Alpha: Payments #68 - These are essential capabilities that we need in order to start onboarding prospective partners.
• Beta: Financial Incentives #70 - This automates the financial related capabilities. At this point we should ideally be looking at integrations with our dollar.
• V1: Artificial Intelligence #107 - The fancy features that will allow us to promote the project as "AI powered"
• V2: Levels & Achievements #71 - The gamification of the platform. This will likely also require custom UIs (either Chrome Extension injected or a dashboard.)

---

• feat: Communication #69 - Communication is miscellaneous and should be regarded as low priority but eventually completed.

[0x4007]

• It's easier for me to post a new comment when I randomly have an idea and I post from my phone.

For any new issues created (from these discussions) be sure to link back to the original discussion for the specification of the issue. Do not copy the spec. The reason why is because this is ever-evolving and those specs become stale very quickly relative to the current development velocity (and the updating of spec designs.)

[0x4007]

Sort of a half baked idea but I was skimming over this thread

https://twitter.com/prtydao/status/1593288065757462530?s=46&t=-bPfKufC5IsS9N-nlRW0-A

And it inspired me for two things

1. We can brand the bounty system in a more grand/high tech way talking about enabling us all a natively decentralized work future etc

2. If we could have the community vote by either sending money or just signing a vote to bump up issues/bounties. After quorum the issue can be made into an official bounty.

[0x4007]

An interesting incentive for pull request reviewers to do a good job could be a delayed permit to be generated.

For example, if a pull request is not reverted in one month (configurable) the bot will generate a “high quality review award” otherwise if the pull request I reverted for any reason (e.g. a bug was found) then the permit will not be generated and a warning message will explain why.

It could be structured as a “half up front, half later” payout for reviewers.

Sometimes a revert might be the best action to indicate a contested payout/review so we could always consider a command from an admin toggling the payout generation.