MeetBot, a supybot plugin for IRC meeting notetaking

MeetBot is a plugin to the IRC bot supybot to facilitate taking of notes during IRC meetings. This allows you to better communicate with your project or groups after the IRC meeting, as well as keep the meeting more under control and on-topic.



Let's go through, step by step, how a typical meeting might run:

< MrBeige> #startmeeting

We use the #startmeeting command to tell MeetBot to start the meeting. The person who calls the command becomes the chair - having the power to guide the meeting. However, by default MeetBot allows other participants to enter most things into the logs, since inviting contributions is generally a good thing.:

< MeetBot> Meeting started Wed Jun 17 05:00:49 2009 UTC.  The chair
           is MrBeige.
< MeetBot> Information about MeetBot at
  , Useful Commands: #action
           #agreed #help #info #idea #link #topic.

MeetBot gives us a little bit of information about the meeting.:

< MrBeige> #topic should we release or not?
-!- MeetBot changed the topic of #meetbot-test to: should we release
    or not?

We use the #topic command to tell MeetBot to move to the first topic. MeetBot sets the topic in the channel to the topic which is given on the line. Don't worry, the topic will be restored at the end of the meeting.:

< MrBeige> #info we have two major blocking bugs: the character set
           conversion, and the segfaults heisenbug in the save

When there is important things said, we don't want them to be lost in the irclogs. Thus, we use the #info command to make a note of it in the meeting minutes. It is also highlighted in the irclogs which MeetBot takes.:

< MrBeige> #agreed we give one week to fix these (no other changes
           accepted), and then release

We also have the #agreed command to use. This can only be used by the chairs of the meeting, and should (obviously) be used to document agreement. The rest of the line goes into the minutes as the thing agreed on.:

< MrBeige> #action MrGreen and MrMauve work together to fix the bugs
< MrBeige> #action MrBeige releases when done

We have the #action command. This one is works just like the last two, but has one extra feature: at the end of the meeting, it makes a list of "Action Items", useful for being sure things get taken care of. But there is more: it also makes a list of action items sorted by nick. This can be used to easily see what is assigned to you. In order for an item to be sorted by a nick, that nick has got to say something during the meeting (but also see the #nick command), and you have to use their nick exactly (use tab completion!).:

< MrBeige> #topic goals for release after next
-!- MeetBot changed the topic of #meetbot-test to: goals for release
    after next

Moving on to the next topic...:

< MrBeige> #info make it better
< MrBeige> #info release faster

Record some of the important items from this section.:

< MrBeige> #endmeeting

Hit the #endmeeting command. The meeting ends, and logs and minutes are saved:

-!- MeetBot changed the topic of #meetbot-test to: General
    discussion of MeetBot
< MeetBot> Meeting ended Wed Jun 17 05:03:45 2009 UTC.  Information
           about MeetBot at .
< MeetBot> Minutes:
< MeetBot> Log:

MeetBot conveniently tells us where all of the logs are stored. You can look at the logs and minutes online.

User reference


All commands are case-insensitive, and use the # prefix character. Not all commands have output. This might be confusing, because you don't know if it's been acted on or not. However, this is a conscious design decision to try to keep out of the way and not distract from the real people. If something goes wrong, you can adjust and have MeetBot re-process the logs later.

Starts a meeting. The calling nick becomes the chair. If any text is given on the rest of the line, this becomes the meeting topic, see #meetingtopic above.
End a meeting, save logs, restore previous topic, give links to logs. You know the drill. (Chairs only.)
Set the current topic of discussion. MeetBot changes the topic in the channel (saving the original topic to be restored at the end of the meeting). (Chairs only.)
#agreed (alias #agree)
Mark something as agreed on. The rest of the line is the details. (Chairs only.)
#chair and #unchair

Add new chairs to the meeting. The rest of the line is a list of nicks, separated by commas and/or spaces. The nick which started the meeting is the owner and can't be de-chaired. The command replies with a list of the current chairs, for verification (Chairs only.) Example:

< MrBeige> #chair MrGreen MsAlizarin
< MeetBot> Current chairs are: MsAlizarin MrBeige MrGreen


Add an ACTION item to the minutes. Provide irc nicks of people involved, and will be both a complete listing of action items, and a listing of action items sorted by nick at the end of the meeting. This is very useful for making sure this gets done. Example:

< MrBeige> #action MrGreen will read the entire Internet to
           determine why the hive cluster is under attack.

If MrGreen has said something during the meeting, this will be automatically assigned to him.


Add an INFO item to the minutes. Example:

< MrBeige> #info We need to spawn more overlords before the next


Add a link to the minutes. The URL will be properly detected within the line in most cases - the URL can't contain spaces. This command is automatically detected if the line starts with http:, https:, mailto:, and some other common protocols defined in the UrlProtocols configuration variable. Examples:

< MrBeige> #link is the main page
< MrBeige> is the main page
< MrBeige> #link the main page is
           so go there
< MrBeige> the main page is so go
           there.  (This will NOT be detected automatically)

Less-used commands

Sets the "meeting topic". This will always appear in the topic in the channel, even as the #topic changes. The format of the IRCtopic is "<topic> (Meeting Topic: <meeting topic>)". (Chairs only.)
List recognized supybot commands. This is the actual "help" command.
Add an IDEA to the minutes.
#help (alias #halp)
Add a HELP item to the minutes. Confusingly, this does not give supybot help. See #commands.
#accepted (alias #accept)
Mark something as accepted. The rest of the line is the details. (Chairs only.)
#rejected (alias #reject)
Mark something as rejected. The rest of the line is the details. (Chairs only.)
Write out the logs right now. (Chairs only.)
Make a nick be recognized by supybot, even though it hasn't said anything. This is only useful in order to make a list of action items be grouped by this nick at the end of the meeting.
Remove the last item from the meeting minutes. Only applies to commands which appear in the final output. (Chairs only.)
When logs are saved, remove the permissions specified in the configuration variable RestrictPerm. (Chairs only.)
#lurk and #unlurk
When lurk is set, MeetBot will only passively listen and take notes (and save the notes), not reply or change the topic This is useful for when you don't want disruptions during the meeting. (Chairs only.)

Provide a friendly name which can be used as a variable in the filename patterns. For example, you can set filenamePattern = '%(channel)s/%%Y/%(meetingname)s.%%F-%%H.%%M' to allow #meetingname to categorize multiple types of meeting occurring in one channel.

All spaces are removed from the rest of the line and the string is converted to lowercase. If meetingname is not provided, it defaults to channel. (Chairs only.)

Hints on how to run an effective meeting

Please contribute to this section!

  • Have an agenda. Think about the agenda beforehand, so that attendees are not tempted to jump ahead and discuss future items. This will make it very hard to follow.
  • Liberally use the #action command, making sure to include the nick of the person responsible. It will produce an easy-to-scan list of things to do, as well as a sorted-by-nick version. This will make these things more likely to get done.
  • In the same spirit, liberally use #info on important pieces of data. If you think you'll want to refer to it again, #info it. Assigning someone to watch the meeting to #info other people's lines (if they forget) usually pays off.
  • Don't be afraid to tell attendees to wait for a future topic to discuss something.
  • Delegate where possible and have those interested discuss the details after the meeting, where applicable. No need to take everyone's time if not everyone needs to decide. (This only applies to some types of meetings)
  • Sometimes one chair to manage the topic at hand, and one chair to manage all people who are going off-topic, can help.



Unfortunately, MeetBot seems a bit complex to configure. In order to keep things straight, keep this in mind: MeetBot has two distinct pieces. The first ( and friends) is the meeting parser and note/logfile generator. This part can run independently, without the supybot plugin. The second part interfaces the core to supybot, to make it usable via IRC.

When reading about how to run MeetBot, keep this in mind, and if something is applicable to features, just supybot features, or both.

This design split greatly increases modularity (a "good thing"), and also allows the Replay functionality. It should also allow other bot plugins to easily be written.

Replay functionality

Let's say you had a meeting which happened a while ago, and you would like to update the logs to a newer format. If supybot was the only way to use MeetBot, you'd be out of luck. Luckily, there is an independent way to replay meetings:

python /path/to/ replay /path/to/old_meeting.log.txt

You run the file as a script, giving the subcommand replay and then a path to a .log.txt file from a previous meeting (or from some other source of IRC logs, it's essentially the irssi/xchat format). It parses it and processes the meeting, and outputs all of the usual .html, .log.html, and so on files in the directory parallel to the input file.

This is useful if you want to upgrade your output formats, MeetBot broke and you lost the realtime log and want to generate a summary using your own logfiles, remove or change something in the logs that was incorrect during the meeting. As such, this is an important feature of MeetBot.

However, this does make configuration changes harder. Since the replay function works independent of supybot, any configuration that is done in supybot will be invisible to the replay function. Thus, we have to have a non-supybot mechanism of configuring MeetBot. There was a supybot way of configuring MeetBot added later, which can adjust most variables. However, if something is configured here, it won't be seen if a file is replayed. This might be OK, or it might not be, depending on the variable.

Configuration configuration

This is the non-supybot method of configuration, and allows the most flexibility. It works for configuring supybot, too, but requires shell access and a MeetBot reload to change.

Configuration is done by creating a file in the plugin directory, or somewhere in your PYTHONPATH. It works by (automatically, not user-visible) subclassing the Config class.

Here is a minimal usage example. You need at least this much to make it run. Put this in before you first start supybot:

class Config(object):
    # These two are **required**:
    logFileDir = '/home/richard/meetbot/'
    logUrlPrefix = ''

Two other more commonly used options are:

filenamePattern = '%(channel)s/%%Y/%(channel)s.%%F-%%H.%%M'
MeetBotInfoURL = 'http://some_other_side.tld'

Place all of the configuration variables inside of the class body like this. is imported via python, so all the usual benefits and caveats of that apply. It causes a subclass of the main Config object. Thus, you can do some advanced (or just crazy) things like add a new meeting command, meeting agenda item type, or more. Some of these ideas are documented under the "Advanced configuration" section below.

To reload a configuration in a running supybot, you can just reload the plugin in supybot --- the module is reloaded. Specifically, /msg YourBotName reload MeetBot.

Supybot-based config

This is the system that configures MeetBot based on the supybot registry system. Thus, it can be adjusted by anyone with the proper supybot capabilities. However, the configuration in the supybot registry won't be used if the replay functionality is used (see above). Thus, for example, if you configure the MediaWiki writer using supybot.plugins.MeetBot.writer_map, and then replay the meeting, the MediaWiki output will not be updated.

To enable this system, first the supybot.plugins.MeetBot.enableSupybotBasedConfig variable must be set to True. Then the MeetBot plugin must be reloaded:

/msg YourBot config supybot.plugins.MeetBot.enableSupybotBasedConfig True
/msg YourBot reload MeetBot

Now you can list the values available for configuration (the list below may not be up to date):

/msg YourBot config list supybot.plugins.MeetBot
----> #endMeetingMessage, #filenamePattern, #input_codec,
      #logFileDir, #logUrlPrefix, #MeetBotInfoURL, #output_codec,
      #pygmentizeStyle, #specialChannelFilenamePattern,
      #startMeetingMessage, #timeZone, #usefulCommands,
      enableSupybotBasedConfig, and public

Setting a value for a variable:

/msg YourBot config supybot.plugins.MeetBot.logUrlPrefix

Most variables (those with # prepended) can be set on a per-channel basis (they are set up as channel-specific variables).

At present, not all variables are exported to supybot. All string and boolean variables are, as well certain other variables for which a wrapper has been written (writer_map in particular). If a variable doesn't appear in the supybot registry, it can't be set via the registry.

If you want to disable supybot-based config for security reasons, set dontBotConfig to True in your custom configuration class in

Required or important configuration

These variables are set either in (in the Config class) or in the supybot registry.

The filesystem directory in which the meeting outputs are stored, defaulting to ".". Required.
The URL corresponding to logFileDir. This is prepended to filenames when giving end-of-meeting links in the channel. Required or supybot's URLs will be missing.

This defaults to '%(channel)s/%%Y/%(channel)s.%%F-%%H.%%M', and is the pattern used for replacements to identify the name of the file basename (including possible sub-directories) in which to store the meeting output files. This is the suffix to logFileDir and logUrlPrefix.

Variables available for replacement using %(name)s include: channel, network, meetingname. Double percent signs (e.g.: %%Y are time formats, from time.strftime.

You should not include filename extensions here. Those are found from the writers, via the variable writer_map.

Putting these all together, a set of variables could be:
  1. logFileDir  =  /srv/www/meetings/
  2. %(channel)s/%%Y/%(channel)s.%%F-%%H.%%M
  3. (.html, .txt, etc, extensions come from writers_map)
This is a URL given in beginning and ending messages and minutes files as a "go here for more information" link.

writer_map configuration

writer_map tells how we want to output the results of the meeting. It is, as you can guess, a mapping from filename extensions (.html, .log.html, ...) to what we want to output to that file (writers.HTML, writers.HTMLlog, ...)

Using, it is python dictionary listing what output formats will be used to write our final results to a file, along with extensions to use. For example, in

import writers

class Config:
    writer_map = {
        '.html': writers.HTML,
        '.txt': writers.RST,

If an extension begins in .none the output will not be written to a file. Note that you can't have the same extension multiple times due to the way python dictionaries work: use .none1, .none2, etc.

This can be configured through supybot. To do this, set supybot.plugins.MeetBot.writer_map to a space-separated list of WriterName:.extension pairs (note the different ordering from the python dictionary). For example, to list the current setting (in private message with the bot):

<MrBeige> config plugins.MeetBot.writer_map
<MeetBot> HTML2:.html HTMLlog2:.log.html Text:.txt

And to set it (again, in private message with the bot):

<MrBeige> config plugins.MeetBot.writer_map HTML2:.html HTMLlog2:.log.html Text:.txt

There is a special way to pass arguments to writers. Learn by example:

writer_map = {

or via supybot:

config plugins.MeetBot.writer_map|mwsite=|mwpath=Meetings

The available writers are (with default extensions, if enabled by default):

TextLog (.log.txt)
Plain-text logs suitable for replaying. This does not have to be explicitly enabled listed-- it is automatically enabled whenever it is needed (currently, only when a meeting comes realtime from supybot, not when being replayed)
HTMLlog (.log.html)
Alias for the current default HTML-pretty logs output format, currently HTMLlog2.
Writes the logs in a HTML-pretty, CSS-customizable way (see section below).
HTML (.html)
Alias for the current default HTML output format for the meeting notes, currently HTML2.
Meeting notes, in a numbered list HTML output format. Configurable via CSS (see section below).
Text (.txt)
A meeting notes format, as a plain text file

MediaWiki output.

The MediaWiki writer has the ability to upload to a MediaWiki site directly. You use the custom variables mwsite: site name to upload to, mwpath: subpage to upload to (final location is %(mwpath)/%(file_basename)), ``mwusername and mwpassword: username and password to log in as.

An upload is attempted if mwsite is given. A login is attempted if mwusername is given. An example configuration:

writer_map = {
PmWiki output. This doesn't upload to a PmWiki instance, but that could be added later.
This writer allows a user-defined template to used to output the meeting logs. This allows complete control of the output by embedding special tags into templates. This writer depends on the Genshi templating engine. For information on how the templating engine works, please see its website or the example templates provided.

To use the templating engine, you must specify the template file to use. This is done via a special argument syntax. Instead of an file extension name, the extension should be specified as .EXTENSION_NAME|template=TEMPLATE_FILE, with the metavariables explaining what the parts do. For example, in one would do:

class Config:
    writer_map = {
        '.tmpl.txt|template=+template.txt' = writers.Template,

When setting a template writer by the suybot registry, one would do:

/msg YourBot config plugins.MeetBot.writer_map <other writers> Template:.EXTENSION_NAME|template=TEMPLATE_FILE ...

TEMPLATE_FILE is an absolute or relative filename. As a special case, +TEMPLATE_NAME can be used to specify a path relative to the MeetBot source directory. This is used to include the default templates: +template.html or +template.txt .

Obsolete writers are:

Old HTML writer. This one requires the Python module pygments to be installed. HTMLlog2 was written to remove this dependency. HTMLlog2 is just as pretty as this is, and HTMLlog2 is configurable via CSS.
Old, table-based HTML writer.
ReStructured Text output. Since ReStructured Text is a bit strict in it's parser, user input from the IRC meeting will often mess up the conversion, and thus this isn't recommended for true use until better escape functions can be written. (There is no security risk from this plugin, ReST is run in secure mode).
This runs the ReStructured Text writer, and uses docutils to convert it to HTML. This requires the docutils package of Python to be installed.

Other config variables

These variables are set either in (in the Config class) or in the supybot registry.


An int listing which permissions to remove when using the #restrictlogs command. It is best to use the python stat module to set it:

RestrictPerm = stat.S_IRWXO|stat.S_IRWXG
specialChannels and specialChannelFilenamePattern
When you are doing MeetBot testing, you would rather not have nonstop different filenames each time you do a test meeting. If a channel is in specialChannels, it will use specialChannelFilenamePattern instead of filenamePattern when storing logs. specialChannels is a tuple listing channel names. Example: the defaults are ("#meetbot-test", "#meetbot-test2") and '%(channel)s/%(channel)s' (note that there is no time-dependence in the name).
Tuple of protocols to use to automatically detect link. Example: the default tuple is ('http:', 'https:', 'irc:', 'ftp:', 'mailto:', 'ssh:').
How commands are detected. See code.
Style for the Pygments module to use to colorize the IRC logs. The default is "friendly".
Timezone used in the bot. Note: This will not yet work on a per-channel basis. The default is "UTC"
If this is set to true (default false), then upon each line being input, the Text writer will rewrite the data. This means that people joining the meeting late can catch up on what they have missed. It doesn't play will with the #meetingname command, since the filename would then change during the meeting, and it doesn't delete the old filename(s).


Message printed at the beginning/end of the meetings. Some %(name)s replacements are available: chair, starttime, timeZone, endtime, MeetBotInfoURL, urlBasename.


Input and output character set encodings.
See the description in the section above.

cssFile_minutes and cssFile_log

If given, this is a file containing CSS for the .html and .log.html outputs (HTML2 and HTMLlog2 writers). Embedding control is described below.

If this value is the null string or 'default', then the default CSS is used (see css-*-default.css in the MeetBot distribution). If this value is 'none', then no stylesheet information is written whatsoever.

Note that for when embedded (see below), cssFile should be a filesystem path readable locally. When you are not embedding, cssFile should be the URL to the stylesheet, and this value given is included literally to the output.

cssEmbed_minutes and cssEmbed_log

If these are True, then the contents of cssFile (above) are read and embedded into the HTML document. If these are False, then a stylesheet link is written.

Advanced configuration

This gives a few examples of things you can do via Most people probably won't need these things, and they aren't thoroughly explained here.

You can make a per-channel config:

class Config(object):
    def init_hook(self):
        if == '#some-channel':
            self.logFileDir = '/some/directory'
            self.logFileDir = '/some/other/directory'

Make a per-channel writer_map (note that you shouldn't change writer_map in place):

import writers
class Config(object):
    def init_hook(self):
        if == '#some-channel':
            self.writer_map = self.writer_map.copy()
            self.writer_map['.mw'] = writers.MediaWiki

The display styles (in html writers) can be modified also, by using the starthtml and endhtml attributes (put this in

import items
items.Agreed.starthtml = '<font color="red">'
items.Agreed.endhtml = '</font>'

Adding a new custom command via (This likely won't make sense unless you examine the code a bit and know esoteric things about python method types):

import types
class Config(object):
    def init(self):
        def do_party(self, nick, time_, **kwargs):
            self.reply("We're having a party in this code!")
            self.reply(("Owner, Chairs: %s %s"%(
        self.M.do_party = types.MethodType(
                                       do_party, self.M, self.M.__class__)

Make a command alias. Make #weagree an alias for #agreed:

class Config(object):
    def init(self):
        self.M.do_weagree = self.M.do_agreed

Supybot admin commands

These commands are for the bot owners to manage all meetings served by their bot. The expected use of these commands is when the bot is on many channels as a public service, and the bot owner sometimes needs to be able to monitor and adjust the overall situation, even if she is not the chair of a meeting.

All of these are regular supybot commands (as opposed to the commands above). That means that the supybot capability system applies, and they can be given either in any channel, either by direct address (BotName: <command> <args> ...) or with the bot prefix character (e.g. @<commandname> <args> ...). If there are commands with the same name in multiple plugins, you need to prefix the command with the plugin name (for example, BotName: meetbot recent instead of BotName: recent)

These are restricted to anyone with the admin capability on the bot.

List all meetings.
Saves all active meetings on all channels and all networks.
addchair <channel> <network> <nick>
Forcibly adds this nick as a chair on the giver channel on the given network, if a meeting is active there.
deletemeeting <channel> <network> <saveit=True>
Delete a meeting from the cache. If save is given, save the meeting first. The default value of save is True. This is useful for when MeetBot becomes broken and is unable to properly save a meeting, rendering the #endmeeting command non-functional.
Display the last ten or so started meetings, along with their channels. This is useful if you are the bot admin and want to see just who all is using your bot, for example to better communicate with those channels.

To connect to multiple IRC networks, use the supybot Network plugin to manage them. First, load the Network plugin, then use the connect command to connect to the other network. Finally, you need to tell supybot to join channels on the new. To do that, you can use network command <other_network> join <channel>. (Alternatively, you can /msg the bot through the other network, but you'll have to register your nick to it on the other network in order for it to accept commands from you.)


To speak with other developers and users, please join #meetbot on

Code contributions to MeetBot are encouraged, but you probably want to check with others in #meetbot first to discuss general plans.


MeetBot is primarily used as a supybot plugin, however, it is designed to not be limited to use with supybot. Thus, there are some design choices which are slightly more complicated. contains the core of the MeetBot code. Most meeting functionality modifications would begin here.

  • The Meeting and MeetingCommands are the core of the meeting loop.
  • The Config class stores all of the local configuration information. An implicit subclass of this done for local configuration. A proxy is set up for the Config class to engage in the supybot-based configuration ( contains MeetingItem objects of different classes. These hold data about different #commands, most importantly their formatting information. contains the code to write the output files. It depends on the objects in to be able to format themselves, and the various classes in here,,, are all supybot based files. (yes, the supybot/not-supybot split is not as rigorous as it should be). All of the supybot commands to interact with the meeting and send lines to the Meeting object are in If you want to add a supybot-based feature, this would be the place to start.

Source control

To get a copy of the repo, the first time, use the get command:

darcs get                        # dev
darcs get  # stable

After that, to get code updates, use the pull command:

darcs get                        # dev
darcs get  # stable

Darcs truly supports "cherry-picking": you can pull patches from either branch at will (They will be kept synchronized enough so that this works). You may skip any patches you do not desire, and pull any later patches as long as you have all earlier dependencies.

To send code back, you can use darcs diff -u for a simple strategy, or you may record and send actual darcs patches. To record darcs patches at first:

darcs record     # 1) interactively select the group of changes
                 #    (y/n questions)
                 # 2) Enter a patch name.  Say yes for entering a
                 #    long coment
                 # 3) Enter in a descriptive comment.  See other
                 #    patches for a model, but I tend to use a
                 #    bulleted list.

The send command will send a patch to the developers via a HTTP POST:

darcs send

If it is not signed with an authorized PGP key, it will be forwarded to the developers, and the developers can manually approve and apply the patch. Developers can have their PGP key added.

There are many other useful darcs commands. Discuss on #meetbot if you would like to find out more.

The darcs push command is the counterpart to pull, and used to move changes around when you have direct write access to the remote repository.

Help and support

The channel #meetbot on is the best place to go.