User Tools

Site Tools


Tips When Writing Your Bot

  1. Consider choosing a language you are familiar and comfortable with. It ideally should be a language you have experience with, or read a book or couple about, to be comfortable with answers to basic questions like “how to define a function?”. and are two great starting points for book search.
  2. Think about using existing bots. Look for other bots which are already made in your language of choice. Would you like to play with one of existing bots and contribute to it? It may be a good learning experience, not any worse than making your own bot.
    1. There is a bots page: it lists several existing bots in a tree.
    2. This wiki also has pages dedicated to certain bots. <catlist bots: -noHead -noNSInBold>
    3. Bots to built upon (not in the channel right now). <catlist info:bots: -noHead -noNSInBold>
    4. Note the page named “bots/start”: it lists the bots that are or recently were running at the #botters channel with links to source. Most of them have a TODO or an issue tracker. Join the channel, see how they work, pick one you like and hack on it.
  3. Think twice before not using existing IRC frameworks. If you don't like existing bots, do you like existing libraries in your language? Would you like to base your bot off a library or raw sockets? Both are valuable learning experience, but if a library already does the job, hacking on it will be fun.
  4. Choose your userbase. You are now past the previous two steps and want to create your own bot from scratch. Think it over. What audience would use your bot? How likely would new contributors or useful feedback arise from the audience members?
    1. For example, I run a bot for Wikimedia channels and get feature requests once a fortnight or so; while there is no new contributors, I find it a rewarding activity as I can see the bot being used and its proper evolution.
    2. If you can't guarantee audience and want a bot just for yourself, be ready to doing the maintainer tasks. Backwards compatibility, prioritising bugs over new features. Discipline yourself.
  5. If you decided to write your own bot, double check that you follow some basic concepts:
    1. Use sensible defaults:
      1. In “average” channels, the bot shouldn't speak when uncalled for. Someone mentions an URL? Give a title for it only if the bot was addressed directly.
      2. No entry messages by default.
      3. A command the bot doesn't know? Consider ignoring it over a private notice, and a private notice over an in-channel reply.
      4. Admin-only commands should be a thing the bot doesn't know outside of /msg. The reaction to in-channel use of them should be same as for unknown commands to encourage any users who clone your bot , so they avoid spamming channels with “set” or “admin” commands; they are rarely of use to anyone (and a pastebin will do to demonstrate behaviour, which is rare).
    2. Make your code re-usable. Any part of your bot which is reusable should be in a module for others to use it.
    3. Choose a project hosting. IF there is a user-base, make sure that you have a proper wiki and/or bug tracker (and a revision control system!). Having every issue and feature documented is a good practice: a list of open issues is a good way to attract new contributors. Establish and follow your workflow.
      1. and are two sane hosts of projects with a wiki and issue tracker available.
      2. hosting-bots lists your options if you would like to host a site or repo for your bot yourself. Be ready to performing regular administrative tasks such as system upgrades, website software upgrades, watching logs. In this case, the load of maintaining your bot's repo and website is on you, while you also have more freedom in choice and don't depend on stability/budget of another hosting service.
  6. Tutorials and information: <catlist tutorials: -noHead> <catlist info: -noHead>
tutorials/tips_when_writing_your_bot.txt · Last modified: 2013/02/03 05:34 by gry