Plugin Config Proposal

[0x4007]

• Still thinking through this but the objective is to be able to configure one's bot instance to enable certain capabilities.
• We can take our GitHub Events and then map those to URLs where the plugins are hosted.
• I'm still unsure what capabilities we should leave in the bot kernel "local plugins" which will execute instantly.
  • My default answer is to break apart every handler into separate plugins and then move them back into the kernel only if theres a usability issue regarding its decreased speed.

Events Example

https://github.com/ansible/webhooks.js-release/blob/6b8d9f69792bf16000cb609e649d31436ec528b5/dist-types/generated/webhook-names.d.ts#L1

Reference Config

https://github.com/ubiquity/ubiquibot/blob/3ee39e0239062acef83db760751989e7be8ff532/.github/ubiquibot-config.yml#L1-L8

New Config

payments:
  basePriceMultiplier: 1.5
features:
  newContributorGreeting:
    enabled: true
    header: "Thank you for contributing to UbiquiBot! Please be sure to set your wallet address before completing your first task so that the automatic payout upon task completion will work for you."
    displayHelpMenu: true
    footer: "###### Also please star this repository and [@ubiquity/devpool-directory](https://github.com/ubiquity/devpool-directory/) to show your support. It helps a lot!"
handlers: 
  # issues.labeled: # in reality these should be disabled to fallback to be handled locally and instantly.
  #   workflow: ubiquity/assistive-pricing
  # issues.unlabeled:
  #   workflow: ubiquity/assistive-pricing
  issues.closed:
    workflow: ubiquity/comment-incentives
    settings: # intentionally using a different word than "config" to differentiate between bot and plugin config
      comment: 
        elements:
          code: 1
          img: 0
          h1: 1
          h2: 1
          h3: 1
          h4: 1
          h5: 1
          h6: 1
          li: 0.5
          a: 1
          blockquote: 0
          i: 0
        totals:
          word: 0.1

Remarks

Technically speaking we can either create a single workflow to host multiple handlers, or to be more organized, we can make dedicated workflows/repositories per event handler.

Could be very interesting to follow the UNIX philosophy of small programs (plugins) that can pipe input and output for advanced interoperability. Imagine chaining ubiquity/comment-incentives and ubiquity/user-multiplier for example

It could also be useful to allow partner's to associate plugins with specific commands. That way projects can easily install their own slash commands. For example:

handlers:
  commands:
    start:
      workflow: ubiquity/self-assign
      # config: # Optional configuration for 'start'
    stop:
      workflow: ubiquity/self-assign
      # config: # Optional configuration for 'stop'

  events:
    issues.unlabeled:
      workflow: ubiquity/assistive-pricing
      # config: # Optional configuration for 'issues.unlabeled'
    issues.labeled:
      workflow: ubiquity/assistive-pricing
      config:
        labelType: "priority"
        notifyTeam: true
        teamMembers: 
          - "user1"
          - "user2"
        threshold: 5

ChatGPT generated example of a config for issues.labeled

[ubiquibot[bot]]

@@ No latest assign event found. @@

[0x4007]

handlers:
  commands:
    start:
      workflow: ubiquity/self-assign
      # config: # Optional configuration for 'start'
    stop:
      workflow: ubiquity/self-assign
      # config: # Optional configuration for 'stop'

  events:
    issues.unlabeled:
      workflow: ubiquity/assistive-pricing
      # config: # Optional configuration for 'issues.unlabeled'
    issues.labeled:
      workflow: ubiquity/assistive-pricing
      config:
        labelType: "priority"
        notifyTeam: true
        teamMembers: 
          - "user1"
          - "user2"
        threshold: 5

ChatGPT generated example of a config for issues.labeled