Dynamically map the config property name to count the amount of matching webhook events that occur in the issue/pull timeline, and credit accordingly. In which case, this plugin seems generally useful for mapping any value to any event, in the context of an issue or pull!
All config should be quantitative, and follow the targets syntax as defined in @ubiquibot/conversation-rewards
This should not process the contents of comments. That is the responsibility of @ubiquibot/conversation-rewards
Write tests for all of these. I feel that this plugin may be aspirational but lets see how far we can get.
I am working on designing the config schema, and I wonder if it makes more sense to have two seperate plugins, one for issues only, and one for pulls only. Here I have a single plugin handling both, but perhaps the config can get a bit verbose and messy?
Heres a small example of a single (issue or pull) handler plugin config schema, which seems neat:
Dynamically map the config property name to count the amount of matching webhook events that occur in the issue/pull timeline, and credit accordingly. In which case, this plugin seems generally useful for mapping any value to any event, in the context of an issue or pull!
targets
syntax as defined in@ubiquibot/conversation-rewards
@ubiquibot/conversation-rewards
Heres a small example of a single (issue or pull) handler plugin config schema, which seems neat:
Below is handling both