Handling Sum Rewards From All Active Plugins

[0x4007]

Similar to how GitHub actions supports capturing output from each step in CI, we should do the same. We should support rewards output (including support for negative values) as well as comment output.

Then the kernel can sum the requested permits and post them all in a single comment at the end when the issue is closed as complete.

Regarding comment output, if we support full HTML comment output from each plugin, we could generate the comment body by concatenating all of the comment outputs of every plugin invoked as a response to the given event.

I suppose there might be another standard useful interface property for passing around metadata between each plugin that is not intended to be comment display data or financial permit data.

This is an architectural conversation for how to standardize the plugin-kernel interface properties so that they work for all of our intended modular use cases.

So I guess for inputs every plugin should support some standard properties which right now aren't clear to me. I presume we will pass along event context from the kernel. I suppose we can pass in a string as the arbitrary input value, similar to a command line interface. This will allow us to serialize complex json objects if needed, or pass in simple string parameters to plugins if that's all they need?

[0x4007]

@gentlementlegen @whilefoo rfc on kernel-plugin interface design, and enabling negative permits (at least for one plugin to subtract rewards from the others in an invocation)

[whilefoo]

Similar to how GitHub actions supports capturing output from each step in CI, we should do the same.

We already support that - you can use any output from a plugin as input to another plugin

Then the kernel can sum the requested permits and post them all in a single comment at the end when the issue is closed as complete.

I'm not sure if kernel should be responsible for dealing with permits, it should only call plugins. I don't understand why we need to sum permits, won't conversation-rewards generate all rewards and permit-generation will generate permits based on that?

Regarding comment output, if we support full HTML comment output from each plugin, we could generate the comment body by concatenating all of the comment outputs of every plugin invoked as a response to the given event.

That's a good idea, a standard property like comment and then the kernel posts a comment when all plugins finish executing. So conversation-rewards can output a comment about reward summary and permit-generation outputs permits, then the kernel posts 1 comment containing both.

So I guess for inputs every plugin should support some standard properties which right now aren't clear to me. I presume we will pass along event context from the kernel. I suppose we can pass in a string as the arbitrary input value, similar to a command line interface. This will allow us to serialize complex json objects if needed, or pass in simple string parameters to plugins if that's all they need?

For now all plugins have these standard inputs. If the need arises we can add more

[0x4007]

I'm not sure if kernel should be responsible for dealing with permits, it should only call plugins. I don't understand why we need to sum permits, won't conversation-rewards generate all rewards and permit-generation will generate permits based on that?

That's a good idea, a standard property like comment and then the kernel posts a comment when all plugins finish executing. So conversation-rewards can output a comment about reward summary and permit-generation outputs permits, then the kernel posts 1 comment containing both.

The kernel should be responsible for dealing with permits in a similar way that I propose it would be dealing with the comments. I'll try my best to explain:

won't conversation-rewards generate all rewards

No, there are many future planned incentives that should not be handled by conversation-rewards for example, providing rewards for completing pull request reviews (i.e. approve, request changes) providing time estimates (Time: label.)

Imagine a future where organizations codify their own direct financial incentives for their contributors. Conversation rewards is definitely a cool general purpose example, but its far from the only idea that I have (and I'm sure other partners will have.) To accomodate this future, we need to support "payment requests" from every plugin invoked in a webhook handler event chain.

Plugins should also have the ability to modify the rewards outputs of others.

One planned example of this is our developer relations (referral) system, with "zero sum" rewards. This will subtract from a contributor's reward, and pay the person who referred them. You can read more about it in my proposal here.

[tiilliir]

/wallet 0x58e83b330158ba79de3cac0bc5b190f6ea000e69

[ubiquity-os]

+ Successfully registered wallet address

[tiilliir]

+ Successfully registered wallet address

/help

[0x4007]

@Keyrxng why doesn't help work? It seems that the bot reliability is not 100%

[gentlementlegen]

/help

[ubiquity-os]

Available Commands

Command	Description	Example
/help	List all available commands.	/help
/allow	Allows the user to modify the given label.	/allow @user1 label
/query	Returns the user's wallet, access, and multiplier information.	/query @ubiquibot
/start	Assign yourself to the issue.	/start
/stop	Unassign yourself from the issue.	/stop
/wallet	Register your wallet address for payments.	/wallet ubq.eth

[gentlementlegen]

@Keyrxng why doesn't help work? It seems that the bot reliability is not 100%

Pretty sure /help didn't work because there is also quoted comments above the command itself (so not recognized as a command).

[Keyrxng]

@Keyrxng why doesn't help work? It seems that the bot reliability is not 100%

Pretty sure /help didn't work because there is also quoted comments above the command itself (so not recognized as a command).

/help

yeah seems you are right mentlegen

[0x4007]

/help

[ubiquity-os]

Available Commands

Command	Description	Example
/help	List all available commands.	/help
/allow	Allows the user to modify the given label.	/allow @user1 label
/query	Returns the user's wallet, access, and multiplier information.	/query @ubiquibot
/start	Assign yourself to the issue.	/start
/stop	Unassign yourself from the issue.	/stop
/wallet	Register your wallet address for payments.	/wallet ubq.eth

[0x4007]

.
/help

[ubiquity-os-beta]

Warning!	This task was created over 199 days ago. Please confirm that this issue specification is accurate before starting.
Deadline	Sat, Oct 26, 1:05 PM UTC
Beneficiary	0xE80FC2700ec6faF5f0347a2E7E7798FAf548e1c3

Tip

• Use /wallet 0x0000...0000 if you want to update your registered payment wallet address.
• Be sure to open a draft pull request as soon as possible to communicate updates on your progress.
• Be sure to provide timely updates to us when requested, or you will be automatically unassigned from the task.

[ariesgun]

/stop

[sura1-0-1]

/help

[ubiquity-os-beta]

Available Commands

Command	Description	Example
/help	List all available commands.	/help
/allow	Allows the user to modify the given label type.	/allow @user1 label
/ask	Ask any question about the repository, issue or pull request	/ask
/query	Returns the user's wallet, access, and multiplier information.	/query @UbiquityOS
/start	Assign yourself and/or others to the issue/task.	/start
/stop	Unassign yourself from the issue/task.	/stop
/wallet	Register your wallet address for payments.	/wallet ubq.eth

[ubiquity-os-beta]

Deadline	Fri, Dec 13, 6:54 PM UTC
Beneficiary	0xB13260bfEe08DcA208F2ECc735171B21763EaaF6

Tip

• Use /wallet 0x0000...0000 if you want to update your registered payment wallet address.
• Be sure to open a draft pull request as soon as possible to communicate updates on your progress.
• Be sure to provide timely updates to us when requested, or you will be automatically unassigned from the task.

[ubiquity-os-beta]

Passed the deadline and no activity is detected, removing assignees: @sura1-0-1.

[surafeldev]

/help

[ubiquity-os-beta]

Available Commands

Command	Description	Example
/help	List all available commands.	/help
/allow	Allows the user to modify the given label type.	/allow @user1 label
/ask	Ask any question about the repository, issue or pull request	/ask
/query	Returns the user's wallet, access, and multiplier information.	/query @UbiquityOS
/start	Assign yourself and/or others to the issue/task.	/start
/stop	Unassign yourself from the issue/task.	/stop
/wallet	Register your wallet address for payments. Use '/wallet unset' to unlink your wallet.	/wallet ubq.eth

[surafeldev]

/wallet 0x331D1C984A43087427BBC224Cb4aD9f019336e75

[surafeldev]

/wallet 0x331D1C984A43087427BBC224Cb4aD9f019336e75

[ubiquity-os-beta]

+ Successfully set wallet

[surafeldev]

/start

[surafeldev]

/start

[gentlementlegen]

/start

[ubiquity-os-beta]

Warning!	This task was created over 262 days ago. Please confirm that this issue specification is accurate before starting.
Deadline	Sat, Dec 28, 10:34 AM UTC
Beneficiary	0x0fC1b909ba9265A846b82CF4CE352fc3e7EeB2ED

Tip

• Use /wallet 0x0000...0000 if you want to update your registered payment wallet address.
• Be sure to open a draft pull request as soon as possible to communicate updates on your progress.
• Be sure to provide timely updates to us when requested, or you will be automatically unassigned from the task.

[gentlementlegen]

/stop

[sura1-0-1]

/start

[ubiquity-os-beta]

! You do not have the adequate role to start this task (your role is: member). Allowed roles are: collaborator, admin.

[surafeldev]

/start

[ubiquity-os-beta]

! You do not have the adequate role to start this task (your role is: member). Allowed roles are: collaborator, admin.

[surafeldev]

@0x4007 ! "You do not have the adequate role to start this task (your role is: member). Allowed roles are: collaborator, admin." why I can`t work on this task I have already created PR also have file on it.

[SyedMoin-lab]

/start

[ubiquity-os-beta]

Important

• Be sure to link a pull-request before the first reminder to avoid disqualification.
• Reminders will be sent every 1 day and 18 hours if there is no activity.
• Assignees will be disqualified after 3 days and 12 hours of inactivity.