IRCteamproposal
Differences between revisions 1 and 31 (spanning 30 versions)
|
Size: 2512
Comment:
|
Size: 1594
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. * 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. 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
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)