[20:01] <jussi> right, who is here?
[20:02] <jussi> topyli: tsimpson nhandler Pici?
[20:02] <topyli> heyhey!
[20:02]  * tsimpson is here
[20:03] <jussi> ok, we have quorum...
[20:03] <jussi> tsimpson: bout your turn for chair, right?
[20:04] <tsimpson> probably
[20:05] <tsimpson> #startmeeting
[20:05] <MootBot> Meeting started at 14:05. The chair is tsimpson.
[20:05] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[20:05] <tsimpson> [link] https://wiki.ubuntu.com/IRC/IrcCouncil/MeetingAgenda
[20:05] <MootBot> LINK received:  https://wiki.ubuntu.com/IRC/IrcCouncil/MeetingAgenda
[20:05] <tsimpson> [topic] Offtopic Guidelines
[20:05] <MootBot> New Topic:  Offtopic Guidelines
[20:06] <tsimpson> [link] https://wiki.ubuntu.com/BenjaminRubin/OfftopicGuidelines
[20:06] <MootBot> LINK received:  https://wiki.ubuntu.com/BenjaminRubin/OfftopicGuidelines
[20:06] <tsimpson> not sure if Pici is about
[20:06] <tsimpson> but it's been on the agenda a while now
[20:06] <jussi> that link basically says:
[20:06] <jussi> To be placed under the 'Language and Subject' heading in our guidelines
[20:06] <jussi> Our offtopic channels are designed to be places where people can be in company of others while talking about subjects that they enjoy. We realize that many of us enjoy figuring out computer problems, but we respectfully ask that if a conversation is turning into something that you would more likely see in our support channels, that you bring it there instead. That said, if someone asks you to move your support conversation into one of our
[20:06] <jussi> support channels, please do so.
[20:07] <jussi> Im +1 on this, no problems
[20:07] <topyli> i think the last sentence is the relevant one
[20:07] <topyli> the rest is dressing :)
[20:08] <jussi> Im happy to have a vote that we add this, if you like?
[20:08] <tsimpson> it's something that we have done before, this is just putting it into writing
[20:08] <topyli> yeah. let us vote
[20:09] <tsimpson> [vote] Add the above to IRC/Guidelines under Language and Subject
[20:09] <MootBot> Please vote on:  Add the above to IRC/Guidelines under Language and Subject.
[20:09] <MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
[20:09] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[20:09] <jussi> +1
[20:09] <MootBot> +1 received from jussi. 1 for, 0 against. 0 have abstained. Count is now 1
[20:09] <tsimpson> +1
[20:09] <MootBot> +1 received from tsimpson. 2 for, 0 against. 0 have abstained. Count is now 2
[20:09] <topyli> +1
[20:09] <MootBot> +1 received from topyli. 3 for, 0 against. 0 have abstained. Count is now 3
[20:09] <jussi> excellent
[20:09] <tsimpson> [endvote]
[20:09] <MootBot> Final result is 3 for, 0 against. 0 abstained. Total: 3
[20:09] <tsimpson> so who wants to do that?
[20:09] <jussi> give it o Pici
[20:09] <tsimpson> [action] Pici to edit the guidelines wiki
[20:09] <MootBot> ACTION received:  Pici to edit the guidelines wiki
[20:10] <topyli> i would change the wording, but i can talk to Pici about it
[20:10] <tsimpson> [topic] Dealing with Ubuntu IRC Problem Users
[20:10] <MootBot> New Topic:  Dealing with Ubuntu IRC Problem Users
[20:12] <topyli> nhandler wanted to submit his document for review by the team. i'm happy with the content of it, but it's a bit meditative and needs to be formatted
[20:12] <ikonia> can you provide context of this document ?
[20:12] <ikonia> or background to the item ?
[20:13] <topyli> well
[20:13] <topyli> it aims to reduce trigger happiness
[20:13] <ikonia> great, more documentation and process
[20:14] <topyli> it tries to reinforce the guidelines we already have. first you +q and talk to the user, and so on. you don't declare people trolls right away and ban them
[20:14] <topyli> that sort of thing
[20:14] <ikonia> no
[20:14] <ikonia> there shouldn't be a first you do this, then you do that, it should be" you use common sense for the sitaution "
[20:15] <topyli> it's often not happening, so i do support documentation
[20:15] <ikonia> then speak to the people it's not happening with
[20:15] <ikonia> rather than put another document / process in place
[20:16] <jussi> I disagree, having guidelines are a good thing.
[20:16] <topyli> in fact it's already in the operator guidelines, as well as the leadership guidelines. assume best of the user, give them benefit of the doubt
[20:16] <ikonia> the guidelines are there, there doesn't need to be another document to backup the guidelines
[20:16] <tsimpson> if we do have a set of guidelines then we don't have to rely on an interpretation of what should be done
[20:16] <ikonia> you arleady have guidelines though, why is there a need for another document
[20:17] <tsimpson> we aren't planning to have something that says "you must do this...", but something that guides our general enforcement of the channel rules
[20:17] <ikonia> you arleady have guidelines though, why is there a need for another document
[20:18] <jussi> I think nhandler's intention is this will get merged nto the guidelines, but of that I am not certain.
[20:18] <topyli> if we followed the loose guidelines we already have, we shouldn't have a need for more precise documentation. but we seem to be failing
[20:18] <tsimpson> the other guidelines aren't really a policy, more a set of technical solutions
[20:18] <tsimpson> this one is intended to be more of a behaviour guide
[20:18] <ikonia> topyli: if people are not following the guide;omes. lets speak to them, instead of doing another doucment
[20:20] <topyli> yes we should do that as well
[20:20] <ikonia> you should do that, full stop
[20:20] <ikonia> one of the complaints/feedback to the council in the recent troubled times was due to not listening to the community, or communicting
[20:21] <ikonia> one of the things was too much process, not enough common sense
[20:21] <ikonia> and lack of communictaion
[20:21] <ikonia> communicate with people if you feel they are not in line with the guidelines
[20:21] <ikonia> stop making processes of processeses, of documents
[20:22] <ikonia> the team is small, most would welcome communication rather than another guidelines/policy being pushed at them
[20:23] <topyli> maybe you should look at the document though, once we decide to submit it for evaluation. then decide whether or not you like it
[20:23] <tsimpson> the current section on op behaviour is very terse, we are expanding on that
[20:23] <ikonia> topyli: I take the point, but I feel the council should stop working on documents like this and start actually gaining the confidence of the operators and community it serves
[20:23] <jussi> and submitting the document to you for evaluation and help is part of communicating and inclusion.
[20:24] <ikonia> jussi: same point, submitting a document that doesn't need changing, isn't what people want,
[20:24] <tsimpson> currently there really is near no policy on how ops should act, so users can not tell if an op is overstepping their bounds or acting inappropriately
[20:24] <jussi> We arent forcing changes, just saying, ok, this is happening, we are writing some stuff down, and allowing you to take part.
[20:24] <tsimpson> that is a cause of problems
[20:25] <ikonia> tsimpson: there are guidlines exactly the same as the users
[20:25] <tsimpson> operators have more requirements on their behaviour than users do
[20:25] <topyli> ikonia: operators have committed to much more than that
[20:26] <ikonia> topyli: yes, but those commitments/guildlines are called out in the same way as the users
[20:26] <IdleOne> IMO the problem is interpretation of the guidelines, one op will judge something to be a violation and an different op will not.
[20:26] <jussi> ikonia: so you object to us modifying the guideline?
[20:26] <ikonia> if you are going to call out specific operator rules/guidlines that an operator can be judged on, you need specific user rules that can be applied
[20:26] <ikonia> jussi: yes, at this time
[20:27] <nhandler> o/
[20:27] <jussi> Well until you read the document, when nhandler gets her...
[20:27] <tsimpson> hey nhandler :)
[20:27] <jussi> hi nhandler
[20:29] <topyli> nhandler: so. we were trying to decide whether or not to submit your draft for discussion, but the discussion started without it :)
[20:30] <topyli> i for one think it's a good base and should be submitted on the mailing list
[20:30] <nhandler> [LINK] https://docs.google.com/Doc?docid=0ASFFoXLMT-guZGhoZmZxNG1fNTYyaHB3NzNxZGM&hl=en&authkey=CNCQ__wP
[20:30] <MootBot> LINK received:  https://docs.google.com/Doc?docid=0ASFFoXLMT-guZGhoZmZxNG1fNTYyaHB3NzNxZGM&hl=en&authkey=CNCQ__wP
[20:31] <ikonia> I find the concept of this document not required, and I find the situation it will bring - users complaining it was not followed unacceptable
[20:32] <tsimpson> so you are saying that users should not be able to hold operators accountable?
[20:33] <topyli> users should complain right now if something goes against the spirit of that doc
[20:33] <ikonia> nope, I'm saying they should be judged on common sense
[20:33] <ikonia> not by a document
[20:33] <tsimpson> common sense seems vary wildly
[20:33] <ikonia> I don't think it does
[20:34] <ikonia> most people in the operator team are in agreement on most users behaviour and when it doesn't agree it talks it thorugh and it's resolved with the user
[20:34] <ikonia> I don't see an issue currently, if you do, we need to talk about it
[20:35] <ikonia> I really find the word "job" thorughout the document inappropriate, although I appreciate the context it's meant in
[20:35] <topyli> let's submit it to the mailing list. we need feedback from everyone in the team who wants to chip in, not the few who are here
[20:35] <tsimpson> we aren't deciding to implement the changes, we are only discussing the document at the moment
[20:35] <topyli> not useful debating details in the meeting. let's decide whethr or not submit it
[20:35] <tsimpson> comments and modification are welcome
[20:36] <ikonia> cat /dev/null > document
[20:36] <ikonia> send it to the list
[20:36] <nhandler> One thing we would also like is some help converting it to a nicer wiki format
[20:36] <nhandler> Bullets are much nicer than long documents :)
[20:36] <ikonia> can I ask the council to also outline a similar document for council jobs, commitments and behaviour please.
[20:37] <topyli> the irc council's duties and behavior are dictated by the community council, we can't really do that
[20:37] <nhandler> Which are outlined at https://wiki.ubuntu.com/IRC/IrcCouncil/Charter
[20:37] <ikonia> topyli: sure you can
[20:38] <ikonia> nhandler: that is not specific and does not call out specific behaviour rules, such as your document
[20:38] <ikonia> I'd like to see documentation for how the council should handle situations, that they can be judged on
[20:38] <tsimpson> situations such as?
[20:38] <ikonia> common things, like responding to email requests
[20:39] <ikonia> a council member must always be active in -ops to comply with nhandler suggestion of eslcation to a council member
[20:39] <ikonia> things like that,
[20:39] <ikonia> it is your job to respond to an email request within 2 working days, etc
[20:39] <IdleOne> I understand the need for a general "this is how you should handle a situation" document so all the ops can be on the same page. What worries me is that if we starts creating these documents without covering every possible situation they will end up being used against ops who don't follow them to the letter.
[20:40] <topyli> ikonia: please open an item for a council meeting, and discuss this. we are talking about nhandler's draft
[20:40] <ikonia> topyli: no, I'm asking the council members (one of them) to take an action for this
[20:41] <topyli> on what? being on call at all times on -ops?
[20:41] <ikonia> document the processes you follow for core issues,
[20:41] <nhandler> IdleOne: Which is at this point something that has not happened and can be dealt with when and if the time comes. The document does address several issues that have come up in the past
[20:41] <topyli> the email responsiveness request is certainly valid and true
[20:41] <ikonia> topyli: that's part of it, yes, a council member must be available in -ops at all times to fall in line with nhandler's documented and judged escalation path
[20:42] <nhandler> ikonia: Uh, where are you getting that from?
[20:42] <ikonia> nhandler: you're document
[20:42] <IdleOne> nhandler: at this time I am not against such documentation so current and future ops have a base line to follow. I will reserve judgment on the semi-final version when it is available
[20:43] <topyli> ikonia: the document suggests consulting other ops. if the issue persists, contact the council
[20:43] <nhandler> ikonia: Care to point me to the part where that is stated?
[20:43] <ikonia> yes, so there will need to be a council member available
[20:43] <tsimpson> ikonia: the document just says to contact a a member of the council, not that they need to be in -ops
[20:43] <topyli> it doesn't mean you should consult the council within 10 minutes of someone cursing on #ubuntu
[20:43] <tsimpson> we have our own council channel, and email
[20:43] <ikonia> tsimpson: ok, then a council member needs to be availabvle 24x7 for escalation
[20:43] <ikonia> by irc/email/whatever
[20:44] <ikonia> topyli: if there is an issue of persistant ban evasion, the path is to escalate to the council, the council must be available then to deeal with it
[20:44] <tsimpson> we need to be contactable 24/7, which we are
[20:44] <ikonia> that's not documented
[20:44] <tsimpson> neither is what you are saying
[20:44] <ikonia> tsimpson: that should go in your rules and behabvioru document I've requested
[20:45] <ikonia> tsimpson: it is, in nhandler's proposal
[20:45] <tsimpson> no, it says that you should contact a council member, not contact them directly and await a response before doing anything else
[20:45] <ikonia> tsimpson: yes, so if it goes to another op, they can't resolve it, it needs to go to the council, then the council need to be available
[20:46] <ikonia> that's the path the document says as a set of rules to be followed
[20:46] <topyli> exactly
[20:46] <topyli> which btw is how things are now
[20:46] <ikonia> if you are documenting an escalation path, they need to be available, more so as you are using this document to judge operator decisions
[20:46] <IdleOne> they are available, via irc and email
[20:46] <ikonia> topyli: no it's not, the council are not available 24x7 to deal with eslcation,
[20:46] <ikonia> no they are not
[20:47] <tsimpson> ikonia: well fortunately we are only asking for comments on the document now, not implementing it
[20:47] <ikonia> tsimpson: you're getting comments back
[20:47] <tsimpson> yes, I know
[20:47] <tsimpson> that's what I did mean there, sorry
[20:47] <ikonia> cool
[20:48] <IdleOne> ikonia: the ability to contact the council is already implemented, but we can't not expect anybody to be available 24/7 to resolve an issue immediately
[20:48] <IdleOne> can not*
[20:48] <topyli> we need more than one comment though. nhandler, would you action this by sending the email?
[20:48] <ikonia> IdleOne: yes you can if you are being judged on the escalation path
[20:48] <nhandler> topyli: Yes
[20:48] <ikonia> IdleOne: this document is to judge operators and assure they follow a procedure, if that procedure ends with passing the imediate issue over to the council, they need to be there to take it, which as irc is 24x7 they need to be hter
[20:49] <topyli> nhandler: great. meeting moves on :)
[20:49] <ikonia> what's the next item ?
[20:49] <nhandler> Giving me a formal [ACTION] ;)
[20:49] <topyli> :)
[20:50] <tsimpson> [action] nhandler to send the document to the IRC mailing list for discussion
[20:50] <MootBot> ACTION received:  nhandler to send the document to the IRC mailing list for discussion
[20:50] <IdleOne> ikonia: in a case like a persistent ban evader, if the council isn't around to act within 5 minutes we can continue to set bans/mute the problem user. I think you asking for anyone one of us (IRCC and ops team) to be here 24/7 to deal with an issue is unrealistic
[20:50] <ikonia> IdleOne: I agree it's unrealistic and uncalled for, but I'm not writing a document that says here is what you do
[20:51] <topyli> no new bugs on launchpad
[20:51] <ikonia> finished any of the other outstanding items ?
[20:51] <IdleOne> the document isn't a firm "this is how to do it" but more of a this is how you can handle a situation if unclear
[20:51] <ikonia> IdleOne: I find the doucment insulting
[20:51] <tsimpson> [topic] Any other business
[20:51] <ikonia> IdleOne: it IS a firm how you do it
[20:51] <MootBot> New Topic:  Any other business
[20:52] <ikonia> tsimpson: yup, finished any of the other outstanding items ?
[20:52] <ikonia> shell policy, long term problem user policy, etc ?
[20:52] <ikonia> you know the stuff that was raised months ago ?
[20:53] <ikonia> I've got quite a list here
[20:53] <topyli> status is at https://wiki.ubuntu.com/IRCCouncil/TeamReports , hoping it's up to date :)
[20:53] <IdleOne> ikonia: I don't mean to keep harping about it but I didn't read as a law that must be followed.
[20:53] <ikonia> IdleOne: then you didn't read it correct, it is a document showing how operators should act and be judged on it
[20:54] <ikonia> topyli: doesn't really explain that much
[20:54] <IdleOne> I will read it again.
[20:54] <topyli> nobody is being judged btw
[20:54] <ikonia> topyli: well, you are as you are saying operators are not following the guidelines so this document is to set out a clear policy that should be followed
[20:54] <ikonia> therefore if you don't follow it, there is room for judgment
[20:55] <topyli> it is a howto
[20:55] <ikonia> really, that wasn't what was said at the start, it was said people where not following the guidelines
[20:55] <IdleOne> ikonia: what worries me is that we will end up being judged by the problem users and they will use such documents as base to argue/fight op decisions
[20:55] <ikonia> IdleOne: I fully agree,
[20:55] <IdleOne> I am not worried about being judged by my peers
[20:55] <tsimpson> IdleOne: that's why there is an appeal process with humans managing the process
[20:55] <ikonia> ok, so back to the meeting
[20:56] <ikonia> can I again request the council members take an action to document there issue resolution process with timescales and commiemtns
[20:57] <topyli> which process is that? what we have done is we're making an effort to not have issues without an owner. i hope that will help
[20:58] <ikonia> topyli: you must have a process to follow for dealing with issues and requests including commiments to respond by $X time etc ?
[20:58] <ikonia> or is that process just common sense ?
[20:58] <topyli> since you don't want documentation, you must be trying to make a joke
[20:58] <ikonia> no, if you're pushing down documentation on how to behave, I want to see documented your behaviour and process commitments
[20:58] <ikonia> it's a two way street
[20:59] <ikonia> I'm still waiting for my actions to be implimented or responded too, yet  you all seem to find time to write some more documents for the operators to follow
[20:59] <tsimpson> we already have that in the charter
[20:59] <ikonia> so lets have it a two way street, lets document your processes and guidelines and commitments to be used
[20:59] <ikonia> tsimpson: no, the charter is vauge, it doesn't set out the processes or the time scale commitments
[20:59] <ikonia> tsimpson: the charter is as vague as the current operator guidlines that don't appear to be acceptable
[21:00] <ikonia> you want to get specific, I want to see specifcs for your commitments, process and behaviour too
[21:00] <tsimpson> we are not the directly user-facing IRC ops
[21:00] <ikonia> I don't feel the council has been living up to the charter, so I want to see it clearly agreed
[21:00] <topyli> we are right now trying to craft a document in concert with the whole team. we are not "pushing down" anything. please try and work on basis of reality, even when ranting
[21:00] <tsimpson> what part of the charter do you think we failed at?
[21:00] <ikonia> tsimpson: yes you are, and you are user facing to the IRC team (me)
[21:02] <tsimpson> ikonia: what part of the charter do you think we failed at?
[21:02] <ikonia> hello ?
[21:02] <IdleOne> yes
[21:03] <IdleOne> ikonia: ikonia_ I think you are lagged.
[21:03] <ikonia> sorry my connection is having an issue
[21:03] <ikonia> ok, it seems to be back, apologies
[21:04] <tsimpson> the meeting is overrunning
[21:04] <ikonia> then I'll drop it and take it to the list
[21:04] <ikonia> (I'm sure you can guess I'm not very happy with this)
[21:04] <tsimpson> [action] tsimpson to complete the fixed agenda items
[21:04] <MootBot> ACTION received:  tsimpson to complete the fixed agenda items
[21:05] <tsimpson> #endmeeting
[21:05] <MootBot> Meeting finished at 15:05.
[21:05] <topyli> if the council is not fulfilling the charter, that's important. ikonia, please do bring it up
[21:05] <IdleOne> thanks for the meeting.
[21:05] <ikonia> topyli: I've brought it up before
[21:05] <ikonia> I don't see change
[21:05] <ikonia> I see the same loop
[21:07] <topyli> i see abstract unhappiness, with no fixable issues or suggestions how to improve. might be a language issue though, mine's not perfect
[21:07] <ikonia> topyli: it's not, it's just total lack of faith with what the council are doing
[21:07] <ikonia> topyli: I'll raise it for the next meeting
[21:07] <topyli> good, thanks