IRCteamproposal
|
Size: 2512
Comment:
|
Size: 3826
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| == Future and purpose of the IRC Team == | Please Put any background information for your Agenda issue here. |
| Line 3: | Line 3: |
| The IRC team is currently described on launchpad as: | = Agenda Entries = /* Entries here are for current agenda items */ |
| Line 5: | Line 6: |
| The Ubuntu IRC operator team is responsible for managing the Ubuntu channels on freenode. | == Support channel bug parsing == |
| Line 7: | Line 8: |
| * Ubuntu-IRC is a team of operators, approved by the Ubuntu IRC Council. * The team exists to give Ubuntu channel contacts a ready pool of enthusiastic, trusted operators for their channel should they need it. * Channel contacts should also hopefully be able to trust a user belonging to this group if that user requests access. |
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 |
| Line 11: | Line 28: |
| The IRC Council accepts new members to this group after observing the sustained positive contribution of an operator in one or more Ubuntu channels. More information is available at the ircteam wiki: https://wiki.ubuntu.com/IrcTeam The question is, is the scope of the team still current, and is more guidelines on how people are assessed for eligibility to join the team necessary? Please feel to add your thoughts and idea here, and bring them to the next council meeting. == Criteria for +v in #ubuntu-ops == Currently there is a rather haphazard way of adding people to the voiced (+v) operator list in #ubuntu-ops. We need to have a uniform and standardized proceedure for eligibility for +v in #ubuntu-ops. The purpose of +v is to show users who are operators in the channels that #ubuntu-ops covers, to understand who can deal with their query. Therefore, in my understanding, an operator in one of the core channels, that are managed by the ubuntu-irc team and come under the scope of #ubuntu-ops, should have +v in that channel. All others should not be permitted under the no idle rule. Comments on this view are welcome below: - == Implementation of same system for #ubuntu-irc == Currently there is an issue with finding operators from the loco channels when a problem arises, and is asked about in #ubuntu-irc. I propose we implement a similar system in #ubuntu-irc, so as operators from the loco channels are easily recognized and able to be found in a simple and timely manner. Discussion here: - == Usage of +v in #ubuntu-ops and #ubuntu-irc == There has been some thought that perhaps it would be better that only operators who are available make themselves +v, so when a person enters #ubuntu-ops/-irc they can quickly see who is actually available to sort out their query. This point is very open for discussion, so points here: - All these points will be discussed at the next IRCC meeting. Thank you. |
---- = 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. |
Please Put any background information for your Agenda issue here.
Agenda Entries
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
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.
IRC/IrcCouncil/IRCteamproposal (last edited 2014-02-28 14:04:44 by host217-36-92-70)