IRCteamproposal
Please Put any background information for your Agenda issue here.
Agenda Entries
Add eir to #ubuntu
Currently, ubottu has basic support for nagging operators to review bans that they set. This functionality is rather limited (LP: #521842). freenode operates a bot named eir (http://freenode.net/eir.shtml), which provides some more advanced ban tracking functionality. It supports setting expiration dates/times and comments for bans, quiets, and certain channel mode changes. When a ban expires, eir can either send a notification to a channel or automatically remove the ban. The default behavior is configurable, but you can always specify alternate behavior for a particular ban.
One issue that I foresee is that we currently rely on the ubottu ban tracker quite heavily. ubottu also is configured to prompt operators to comment on their bans and nag them to review them. eir performs both of those tasks. However, eir will not log its comments to the ban tracker. If we decide to start using eir, we will want to work with the bot developers to configure ubottu not to send such requests for comments or ban reviews, and instead try and have it parse the comments set in eir. This will allow us to utilize the best features of both bots.
For default settings, I was thinking about setting a default expiration time of 24 hours. When bans expire, eir will send a notice to #ubuntu-ops, but will not remove the ban automatically. Both of these settings can be configured on a per-ban basis if necessary. Information and usage examples regarding the use of eir can be found on the freenode website (http://freenode.net/eir.shtml).
Reference Entries
Create a basic IRC operator technical guide, how to get +o, how to use /remove, using the Bantracker, etc
We, as operators, tend to use scripts to help in administering the channels we operate in, these scripts are useful and we encourage them. However an IRC operator should know how to preform every action manually. Too often it seems we rely on scripts or bots to do these things for us, this is fine until they break or malfunction. A good grounding in IRC commands is essential and something I don't think we have amongst all of our operators. This includes:
Asking ChanServ to give you +o
- Setting a relevant ban (not to wide or to narrow)
- How to find bans for a specific nick
- How to remove bans properly
- How to quiet/mute a user
- How to use /remove
- Using the Bantracker effectively.
- How to communicate concerns/reasons behind a ban or kick/remove via comments.
- Always comment on bans/kicks/removes/marks, having to read through a log is not quickest way to find out why the action was taken.
- Update comments as the issue progresses.
- Catalysing should always be the first method used to resolve issues.
- When to use a quiet/mute (to provide an opportunity to talk to the user) instead of just removing.
- How to react to /msg abuse, what actions can be taken.
- How and when to use forwards, rather than bans.
+o in -ops
At the moment, the set of people able to +o in -ops seems a little arbitrary. It is more than a little silly that people that have been trusted to moderate the core channels aren't trusted to be able to moderate -ops. On numerous occasions I have had to call !ops in -ops to get rid of a spammy or plain abusive individual, which has on occasion gone without response for a significant length of time. If there is a concern about abuse of the power in -ops, perhaps there should be a probation period of, say, 6 months between being made an op in a core channel and being granted +o access in -ops, to ensure they have a clear idea of how the channel should operate.