IRCteamproposal
|
Size: 3582
Comment:
|
Size: 2282
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| == #ubuntu-release-party access list == I would like the council to review and potentially amend the access list in #ubuntu-release-party before the launch date to consider removing the ubuntumember ship cloak users from the access list. The last party channel was a very rowdy channel and a strong portition of the ubuntu member cloak holders where not mature enough to manage the channel without playing silly games. I understand the channel is supposed to be a fun place but kicking people for fun and placing bans in a channel is not part of that fun. I would suggest adding the core channel operators to the list and removing the membership cloak access. |
|
| Line 8: | Line 6: |
| == Channel logging and publishing of logs from Freenode IRC network == I would like to discuss the legal issues surrounding the use of logging and publishing of logs of chat within the various Ubuntu IRC Channels. It is an issue I have been concerned about for some time and it is my belief that such practices are not compatable with EU Privacy Directives and the laws of various EU Member states. It is my opinion as a professional in this area, that such practices would require the explicit informed consent of all parties whom are being logged and that simply using a notice on join to inform users they are logged does not meet the burden of informed consent. For more information please email alex at privacy dot org. == Consider deactivating ~ubuntu-irc == This team exists from before we had separate Launchpad teams for the operators of each channel. It currently doesn't serve much of a purpose. I would like to propose that we "shut it down" for the time being. By that, I mean deactivating everyone, making it restricted, and changing the description to make it clear that it currently serves no purpose. This would help eliminate any confusion about the team's purpose, stop people from trying to join it, and allow us to revive the team at a later point if we have a need for an ~ubuntu-irc team. |
==+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. |
Please Put any background information for your Agenda issue here.
Agenda Entries
==+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.
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)