3.4 KiB
Best Practices
First and foremost, your plugin must obey the The Three Laws of Robotics:
- A robot may not injure a human being or, through inaction, allow a human being to come to harm.
- A robot must obey the orders given it by human beings except where such orders would conflict with the First Law.
- A robot must protect its own existence as long as such protection does not conflict with the First or Second Laws.
Now that we agree that nobody will get hurt, here are some tips to make your plugin more effective.
Contents:
Empathy
Understanding and being aware of the what another person is thinking or feeling is critical to healthy relationships. This is true for interactions with humans as well as bots, and it works both ways. Empathy enhances our ability to receive and process information, and it helps us communicate more effectively.
Think about how how people will experience the interactions with your plugin.
Avoid the uncanny valley
The uncanny valley is the hypothesis that our emotional response to a robot becomes increasingly positive as it appears to be more human, until it becomes eerie and empathy quickly turns to revulsion. This area between a "barely human" and "fully human" is the uncanny valley.
Your bot should be empathetic, but it shouldn't pretend to be human. It is a bot and everyone that interacts with it knows that.
- 😄 "Latest build failures: {listing of build failures}…"
- 😢 "Hey there! You asked for the build failures, so I went and dug them up for you: {listing of build failures} … Have a fantastic day!"
Autonomy
Never take bulk actions without explicit permission
Being installed on an account is sufficient permission for actions in response to a user action, like replying on a single issue. But a plugin must have explicit permission before performing bulk actions, like labeling all open issues.
For example, the stale plugin will only scan a repository for stale issues and pull requests if .github/stale.yml exists in the repository.
Include "dry run" functionality
A dry run is when a plugin, instead of actually taking an action, only logs what actions it would have taken if it wasn't a dry run. A plugin must offer a dry run feature if it does anything destructive and should offer a dry run feature in all cases.
For example, the stale plugin will perform a dry run if there is no .github/stale.yml file in the repository.
Configuration
Require minimal configuration
Plugins should provide sensible defaults for all settings.
Provide full configuration
Plugins should allow all settings to customized for each installation.
Store configuration in the repository
Any configuration should be stored in the repository. Unless the plugin is using files from an established convention, the configuration should be stored in the .github directory. See the API docs for context.config.