As @zigdon brought up in review of #101, Bucket plugins really don't say what they do except by their names.
I don't like Perl's multi-line comments (the only "real" syntax I've found is =for comment [... lines go here, no indents supported ...] =cut, but I'd be happy to be shown alternatives.
Meanwhile, starting plugins with # BUCKET PLUGIN is currently the only requirement. Below that, a block of single-line comments describing the plugin's function would be nice to have. For example (extra-short lines used for illustration):
# BUCKET PLUGIN
# haiku:
# This Bucket plugin detects haikus in chat
# (lines of 5, 7, and 5 syllables) and saves them
# in a factoid named "Automatic Haiku".
sub route { # [... plugin code continues]
The description block might also include metadata like plugin author, version number, and so on—but let's start with just a description of what the plugin does. Once we figure out what is wanted, I'll open a PR and start writing descriptions for the existing plugins in the repo.
As @zigdon brought up in review of #101, Bucket plugins really don't say what they do except by their names.
I don't like Perl's multi-line comments (the only "real" syntax I've found is
=for comment [... lines go here, no indents supported ...] =cut, but I'd be happy to be shown alternatives.Meanwhile, starting plugins with
# BUCKET PLUGINis currently the only requirement. Below that, a block of single-line comments describing the plugin's function would be nice to have. For example (extra-short lines used for illustration):The description block might also include metadata like plugin author, version number, and so on—but let's start with just a description of what the plugin does. Once we figure out what is wanted, I'll open a PR and start writing descriptions for the existing plugins in the repo.