Modernize the IRC Drupalbot

I know that @drpal tried to setup a bot based upon hubot, I think this was actually kind of successful.

This issue seems a bit reactionary. Functionally the code in this project works the same today as 2 weeks ago.

* What features are we missing?

I've been pretty happy with it and don't have any complaints with the way it works. There are plenty of open feature requests though and i'm sure the reporters would love some patches/review.

* What features should we clean up?

If it aint broke... but like I said i was pretty happy with things.

* Should we use a larger and pluggable bot like hubot?
* Should we continue to use php for development?

Seems like more of an infrastructure question then a question for this project? You'll guess my initial reaction I'm sure but I don't feel strongly, It just doesn't matter much to me. I've interacted with a lot of hubots and others over the years though and I've found Druplicon to behave better.

While I'm absolutely in favor of modernizing the bot used on freenode, I agree with neclimdul that this project is not the right place for it. As was mentioned the infrastructure issue queue would be better suited.

#1886646: Fire (Non UTF8 characters) kills bot seems to be fixed in this current bot now. I have dropped both fire and poo emoji in IRC and the bot stayed alive.

I looked at using hubot when we got ready for the replacement, however, it require a lot of custom coding to make it work like the bot project.

If we are going to keep this issue open, we should have some better defined goals that folks can work on. (Including choosing the tech stack)

Opt-in #drupal channel logging would be nice. I don't see a need to add user contributed pluggins to the drupalbot. I could see adding a pluggin system to the bot project, but not Drupalbot specifically.

I've toyed with the idea of a new bot for a while, so here's my take:

Foundations

Client

The client itself should run in its own process and should communicate with the actual server application via socket. Its only tasks should be:

• Parse messages and wrap them.
• Receive responses and post them.
• Receive IRC commands, execute them and return their results (e.g. channel stats).
• Optionally maintain a message stack of limited size in case the server goes down.
• Optionally maintain private logs of either raw IRC input or parsed messages.

That way we prevent further "fire kills bot" situations and can extend bot features without the need to restart the client (and have rejoin all channels).

Server

A server application listens to the socket, receives and processes messages and responds to them. Tasks would include:

• Parse a message and delegate it to plugins for further processing.
• Plugins retrieving command data by querying the DB and/or external APIs.
• Formulating and sending a response.

Web frontend

A web frontend provides the means to access public data, perform administrative tasks and collect user input (e.g. factoids). Editing permissions could be handled via one-time token links that are handed out by the client on request.

Commands / features

General

• Commands should receive their own prefixes/namespaces. This removes ambiguity and allows for more intelligent parsing and responses of higher quality.
• Each command that provides access to information should by default respond directly to the user that invoked it. An option should be provided to direct the response at another user.
• If queried during high load (e.g. during rejoins) messages should be discarded after a certain amount of time. Optionally a user may receive a notification once the bot is responsive again.

Factoids

Factoids are user-provided pieces of content. As such they range from quirky jokes to essential guidelines.

• Each factoid's edit history and editor should be reviewable.
• A factoid should be lockable to prevent further editing. Locking requests should be handled via issues.
• Users should be able to create aliases for factoids. Any factoid can be turned into an alias, and vice-versa.
• (Optional) Factoids should be assignable to one of a predefined list of several topics. Later on this could be expanded to allow for tagging.
• A searchable list of all factoids should be made public. If topics/tags were implemented, factoids should be reviewable by topic/tag.
• At a minimum the last access time of a factoid should be stored.
• Factoids should not receive multiple definitions. They may however be assigned related topics ("See also ...").

API

• API requests should link to api.drupal.org.
• Requests should be matched regardless of case.
• some degree of fuzzy matching should be provided. This could either be implemented as "Did you mean ..." or as responding for the top 3 results

Karma

The gamification of contributing on IRC. While it can easily be "gamed" itself and has no real significance, active users have repeatedly compared their scores and shared their motivation to reach higher scores.

• Karma commands should be less restrictive by allowing for additional text.
• Users should be allowed to add a reason ( "nick++ for ..."). Reasons will be tracked, along with the nick that gave them.
• Karma scores should not be listed publicly. Contributing should not be a contest, and having high scores listed can be discouraging.
• Karma reasons should be listed publicly (without a score sum). This acts as a public "log of appreciation". Discourages karma spamming/gaming.

Privacy

As we all know everything that happens on the internet stays on the internet. Still, to accomodate users, three levels of logging per channel should be provided:

1. Provide a public log.
2. Maintain a private log to help with statistics and potential outages.
3. Maintain no history at all.

While some users may want to opt out of any public tracking (see factoid history, karma log), only a limited number of bot interactions will actually leave such a trail. On the other end implementing an opt-out feature is nigh impossible:

1. Opt-out would have to be limited to registered nicks.
2. Given freenode's policy to free up nicks after a certain amount of time, the opt-out would have to be renewed.
3. Every single message would have to checked against the blacklist fairly early in the processing. Given the architecture outlined above this may put a noticable strain on the server.

Analytics

A certain degree of statistics gathering should be added for various aspects. These may either be tracked and derived on the server or separately by parsing message/response text logs. Aspects and benefits:

• Command usage to evaluate and prioritize features.
• Channel activity to be able to guide users to the "right" channel and minimize frustration (especially for new users unfamiliar with IRC). Optionally provide stats averaged per hour over a day.
• (Optional) Hot topics tracking. There may be a few data scientists in or tangent to the Drupal community that would love to create a fresh view of all that sweet, sweet data.

So, that's my take. Opinions?

Web frontend
A web frontend provides the means to access public data, perform administrative tasks and collect user input (e.g. factoids). Editing permissions could be handled via one-time token links that are handed out by the client on request.

It would be immensely useful to have links to a web client for #drupal channels listed on the bot site.

Karma
The gamification of contributing on IRC. While it can easily be "gamed" itself and has no real significance, active users have repeatedly compared their scores and shared their motivation to reach higher scores.

• Karma commands should be less restrictive by allowing for additional text.
• Users should be allowed to add a reason ( "nick++ for ..."). Reasons will be tracked, along with the nick that gave them.
• Karma scores should not be listed publicly. Contributing should not be a contest, and having high scores listed can be discouraging.
• Karma reasons should be listed publicly (without a score sum). This acts as a public "log of appreciation". Discourages karma spamming/gaming.

It would also be nice if IRC karma was linked to issue credit as well. Maybe have the bot publically post karma as d.o gives credit to issues. This could pose problematic in the case where 1200 users are given credit for a single issue, but there could be a threshold where credit is given silently.

Opt-out would have to be limited to registered nicks.
Given freenode's policy to free up nicks after a certain amount of time, the opt-out would have to be renewed

I wonder if Opt-out is more trouble than it is worth.

... One thing I forgot to mention: We also need some hard stats regarding the flood limits enforced by Freenode. The bot lives in dozens (?) of channels and needs to be able to respond to all of them. These channels range from high activity (#drupal-contribute) to once-in-a-blue-moon interaction. Stats include:

• Join intervals (I believe Druplicon used fairly conservative 2 seconds?)
• Message intervals (I've read some mention of 100-300ms being tolerated)
• Maximum message size (I believe this is defined by the protocol?)
• Does freenode staff hand out exceptions to these rules?

HI

Should we continue to use php for development?

While there is several other programming language based bots i don't see anything wrong with php

Bump.