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.