Configuration to scale this bot across Status

[martinklepsch]

This bot could be the foundation for organisation-wide tooling across the various Status repositories.

Tooling concerns the bot can help with:

• process automation (github labels, projects etc.)
• deployment
• monitoring
• various kinds of notifications

An important point of this is to embrace that different repos/teams might have different needs. Thus a somewhat "overarching" configuration scheme could be implemented. This would allow teams to customize the various bot features based on their own needs (editing a config.yml in this repo could be sufficient). Once a user figured out how to configure stuff the conventions would remain the same for each bot making configuration a breeze. (Adequate documentation should be provided.)

Popular features would see increased development & feedback while not so commonly used features might slowly be faded out.

An added benefit of this is that we can move forward with more experimental features (like a nudge to welcome contributors personally which I suggested to @PombeirP) while providing a clear customization path.

---

What follows below is some initial idea for how this could be implemented with minimal effort.

A very first step towards this could be that each bot has a unique identifier $botName and a yaml file at the root of this repository could be filled with something like this:

$botName:
  globallyEnabled: true

status-im/status-react:
  $botName:
    disabled true
status-im/open-bounty:
  $botName:
    - welcome-style: 'contributor-notification'

A simple config.js could then expose this API:

Config.enabled(botName)
Config.enabled(botName, repoName)

Note: the repoName based approach could cause some issues with renaming.

What do you think @PombeirP? I think this could be a really nice way to allow teams to extend the bot stuff while keeping things useful for everybody.

Given that this is pretty straightforward to implement I might just whip up a basic PR extending config.js and writing some documentation.

---

EDIT

I saw that we use probot-config in some places but it spreads bot configuration across repositories and introduces some weird DSL (e.g. _extends) that will break sooner or later.

Colocating configuration in the bot repo itself will allow people working on the bot to refactor without much coordination effort.

[pedropombeiro]

To be honest, I think we can afford to let this become a problem before we decide to tackle it. The current config system is more than enough for the current needs, so I'd personally be much more comfortable building a replacement once I've felt the pain points from using the current one. I just don't feel I'm at that point yet. When we do arrive at that point, we can just create a bounty for it.

[martinklepsch]

@PombeirP by "the current config system" you mean probot-config?

Agree that it might not be a problem yet but if we want this bot to become a widely used tool throughout Status we should take care of it eventually.

Some examples that I'd like to configure right now:

• Disable PR review notifications for @flexsurfer
• Customize welcome bot for open-bounty (ping us on Slack instead, so we can welcome personally)

[oskarth]

Disable PR review notifications for @flexsurfer Customize welcome bot for open-bounty (ping us on Slack instead, so we can welcome personally)

Can we achieve this without generalizing the bot? I'm also not sure about creating custom features for individuals.

[pedropombeiro]

Regarding the disabling of notifications, we could add a config section where people can enter their GitHub handle in a list so that the bot doesn't notify them.

As for the welcome bot for open-bounty, I'd first want to hear from the team that they are willing to commit to doing that before going any further.

[martinklepsch]

As for the welcome bot for open-bounty, I'd first want to hear from the team that they are willing to commit to doing that before going any further.

I'm part of that team and willing to do that. 🙂

Can we achieve this without generalizing the bot?

I'm not necessarily pushing for an abstraction/generalization over all bots, just something where bots can retrieve configuration relevant to them. And some conventions where to put this kind of configuration. Fully optional — to be added whenever someone shows up and wants to customize a bot :)