Create a base reward for users within this plugin

[gentlementlegen]

          Yes I do agree that we should be able to chain these results. It's just that this plugin never had the capability to actually attribute rewards to a user, this was the responsibility of `conversation-rewards`. We could think of splitting this and have the logic here later on.

Originally posted by @gentlementlegen in https://github.com/ubiquibot/assistive-pricing/issues/27#issuecomment-2338184070

This plugin should output a Reward compatible output to be able to be chained with other plugins. The current shape of the rewards is as follows:
https://github.com/ubiquibot/conversation-rewards?tab=readme-ov-file#data-structure

What this plugin should output is the following section:

"userName": {
  "task": {
    "reward": 37.5,
    "multiplier": 1
  }
}

which corresponds to the current reward within the label divided by the amount of users assigned to the task. Once in the output, chained plugins could pick this up and use it for further calculations.

[0x4007]

Perhaps property name changes to:

"userName": {
  "rewards": {
    "sum": 37.5,
    "multiplier": 1
  }
}

Note that subtraction and division can be performed with negative sum and fractional multiplier.

[gentlementlegen]

Not sure how assistive-pricing can apply these kinds of calculations? It only knows about the labels and assigned users.

[0x4007]

If every plugin can output some type of standard property like rewards then the kernel can pass everything along to the permit generation, which I think is sort of a core feature of the system.

[gentlementlegen]

I think plugins should just rely on a object output because rewards are not needed by all the plugins. We can also consider exporting types from the plugins themselves so other plugins can import them, but we should minimize coupling.

[0x4007]

I think plugins should just rely on a object output because rewards are not needed by all the plugins.

Sure but what is the schema of object? If it isn't standardized then interoperability will be a mess.

[gentlementlegen]

Interoperability will be worse if we introduce heavy coupling.
If the kernel is responsible to define the Rewards then any change on the rewards content would imply changes on the kernel.
If the conversation-rewards is responsible to define the rewards shape, other plugins should reference this package as well.
If all plugins consider using an object then no coupling is introduced, coming with the downside of have less completion.

The last case is used by GitHub Actions for example, where output is expected to be an object but doesn't provide any typings. In our case since all plugins are optional, and order of execution is undefined, I think we should follow the same solution because we can never ensure the content or shape of the output.

[0x4007]

I think we should follow the same solution because we can never ensure the content or shape of the output.

Yes I agree I think we should model our config after GitHub Actions syntax unless we have a really good reason otherwise.

[gentlementlegen]

For reference: https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/passing-information-between-jobs