The ideas mentioned here mostly originated from discussions on the Zulip chat Feel free to discuss their implementation there, or add improvements of these ideas, or new ideas in the comments.
To me, contrib_bots sounds like contribute bots, which is definitely adequate for GCI.
It is, however, not a precise description of contrib_bots distinction from bots (which is
the limited API).
We could rename contrib_bots to something like bots_limited,
limited_bots, etc.
Right now, the structure of bots is a little unclear; some have an additional folder while some only have a singular .py file. To make things consistent, I propose:
- One directory
python, containing all<bot>.pyfiles. - One directory
help, containing for each bot: - A file
<bot>_help.md(for user docs) - A file
<bot>_info.txt(displayed when executing the bot) - One directory
config, containing for each bot: - A file
<bot>_config.md, the config file forrun.py - One directory
assets, containing for each bot: - One directory
<bot>(can be left empty, but should exist), containing: - All images, dependencies and additional resources the bot needs to function
-
Since
contrib_botsare supposed to be simple and lightweight, a single.pyfile should be sufficient for each bot. If needed, additional, bot specific small libraries and frameworks can be added in the bot's assets. -
A bot's
<bot>.pyshould be as lightweight as possible. Outsource list of names, numbers, etc. in the theassetsdirectory for your bot. The info message, which is right now present in every<bot>.pyshould be outsources into<bot>_info.txtin the help directory,run.pyshould fetch those messages when executing a bot and print them to the console.
Disclaimer: this might be an overkill. Simpler solutions like a command-line run-bot script are probably preferable.
Right now, executing bots via running run.py <bot> --config-file <config-file> is a bit tedious.
This procedure makes running multiple bots at once even harder, since the command needs to be reexecuted
for every single bot.
The idea of a manager bot has already been up in the chat, with people working on PRs for such a feature. A nice feature would be a "manager-bot", that executes, overviews and handles all the "worker bots". The manager bot could
- be run with a single config file that contains API keys for every worker bot one wants to execute.
- handle communication between bots
- implement global security measures, e.g. rate limiting
- Should the manager bot simply execute multiple instances of
run.py(simple solution), or be built onrun.py?
Games are fun. So are game bots. For Zulip users who want to play a little, we have started to propose and create game bots, like the tic-tac-toe bot.
To simplify and standardize their development, a central
game bot manager would be of use. The game manager could provide a set of functions for
game bots, like set_info(), set_state(), game_over(), etc.
Extend the game manager to support multiplayer games with 2 (or N?) Players.
Currently, bots have no graphical support, they can solely be accessed via chat. This makes accessing them harder, especially for new Zulipor infrequent Zulip users who don't read through all the docs.
######Solution Next to the compose box (or somewhere else), add a little interface for accessing bots. The interface should be accessible by all bots (or just selected bots?), meaning that a bot could register a new button/text-field there.
Right now, the bots in contrib_bots are idle, even though they add some great features
(who wouldn't want to know what 13.2 acres are in square-feet?). This is mainly due to
the, after all, developer focused run.py.
The manager bot mentioned early would already make deploying bots easier.
In addition to that, one could implement a graphical interface in settings
to quickly add/remove bots.
- Should such an interface be accessible to the adminstrator only, or should we let users individually decide which bots to use and which not? What about a combination of both?