Please Put any background information for your Agenda issue here.

Agenda Entries

Entries here are for current agenda items

Support channel bug parsing

Is there reason to make bugnr responses disable in #xubuntu? Also they been disabled in #kubuntu and #ubuntu couse (said in #ubuntu-irc) It takes more bot processing power. Ubottu takes bug nr and asks LP for header and project info and status and replies in channel. With this info ppl in channel can comment even without opening bug if they seen it or they can make it been read if program is known and that leads to faster fixing. The reason why this bugnr bot script was made- to make faster understand about what is bug and witch program it affects so faster they can be solved. Now replacement is (as said in #ubuntu-irc) /msg ubottu bug nr bug that is: 1.) Time consuming writing this line /msg ubottu bug nr 2.) Processing still power

• a.) if everyone who sees bug nr now will use this command that will be more processing power

3.) It doesnt work. So now only solution is making long line of url but to see description it needs to be written/pasted (time consuming) or link needs to be opened by those who see link. Since without description link is posted its either: 1.) Too much Opened without moving in solving - time wasted and LP server power wasted more without any movement in direction of solving bug couse if opened maybe who opens cant comment on bug couse doesnt know programm. 2.) Not opened - still bug not solved. If problem is processing power then removing this bugnr processing option from #Ubuntu saves this power a lot couse theres a lot users but removing from #xubuntu savings arent seenable couse in #xubuntu bug nr are posted 0-2 a day. That makes missing reason why to remove for #xubuntu bug nr response. Since reason for channels is to make comunity live and Ubuntu be fixed then solution isnt removing bot option bug giving bot faster server. Computer is meant for processing. Still computer with script runs still consumes electricity still uses internet. Also id like to know when and how was this decision made and what are reasons. And how they help make Ubuntu better. And why replacement is made time consuming and doesnt work. Who wants to make bug triging slower starting with removing this option from #Ubuntu #Xubuntu #Kubuntu

Reference Entries

Entries here are kept only for reference

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.