[00:54] <Jordan_U> syrius is trolling in #ubuntu
[00:54] <Jordan_U> _16BitSubsystem_ As well
[00:54] <IdleOne> looking
[00:55] <Jordan_U> Thanks.
[01:03] <IdleOne> Since the trigger was just recently used I think we need to reevaluate the use of !away. I think that when a user sets an |away nick and sending them that factoid is a little over kill. I understand if there are multiple nick changes then it becomes annoying. I think !away should be used when there is an annoying away message being sent to channels only.
[01:05] <persia> I think it has much greater applicability in low-volume channels.  Lots of times a channel shows activity drawing several regulars when nothing is happening, and I tend to be aggressive using !away to ensure that folk still respond, rather than getting that cried-wolf feeling.
[01:09] <IdleOne> persia: I am sorry to say, but I just read what you said 4 times and sadly I have no idea what you said. perhaps it is me not reading it properly I don't know.
[01:10] <persia> So, some channels have low activity.  There are often some people who will notice *any* activity in that channel, and head over there (strong specific interest).
[01:10] <persia> When someone has nick changes due to being away, that causes apparent channel traffic, drawing these folk.
[01:10] <persia> When it happens a lot, these folk stop responding so quickly, as an increasing number of their responses provide no content.
[01:11] <persia> So, for these channels, I tend to be fairly strict about enforcing avoidance of nick-change-on-away so that the special-interest folk continue to be available on demand.
[01:11] <persia> For channels with lots of traffic, where habitues need to watch more, and not switch back for every entered line, this may be less critical.
[01:13] <IdleOne> might just be me but I don't think that a simple nick change every few hours is that big of a problem in any size channel.
[01:14] <IdleOne> when the away nick is accompanied by an away message being spammed to the channel, yes that is a issue.
[01:15] <persia> Makes a *huge* difference in channels that get 1-2 conversations a day, like #ubuntu-powerpc
[01:16] <persia> There's only 5-6 people who consistently do powerpc support, but having them all jump everytime someone wanders off for a while doesn't encourage them to keep jumping.
[01:18] <Seeker`> a sensible client will have different alerts for "nick change" to "someone said something"
[01:18] <Seeker`> IdleOne: one person nick changing isn't a problem, 200 is
[01:18] <persia> Seeker`, Yeah, well, I guess we need patches for some clients then :)
[01:19] <IdleOne> Well the issue is not that important to me. I was just thinking out loud a guess.
[01:19] <IdleOne> s/a/I
[01:19] <Flannel> http://sackheads.org/~bnaylor/spew/away_msgs.html
[01:20] <persia> Not incredibly important to me either: just wanted to provide a counterexample.
[08:57] <Tm_T> ...someone with proper connection and a keyboard ^
[11:00] <ikonia> we need to stop the floodbot auto open proxy detection
[11:00] <ikonia> it's filling up the ban list
[11:03] <ikonia> why is ljl's metabot banned in #ubuntu ?
[11:06] <Tm_T> err?
[11:06] <Mamarok> ikonia: because it is runnign wild, reconnecting every few minutes
[11:06] <Mamarok> check #ubuntu-meta
[11:06] <ikonia> ok, so shall we ask him to stop using it or try to get him a stable host to run it on
[11:06] <persia> Probably better to offer the choice
[11:06] <Mamarok> stable host is preferred :)
[11:09] <jussi> its not such a big issue to deal with if it is a problem is it? yes, we would like a stable host, but still, remember someone is giving this service to us free - interuptions happen on occaision.
[11:12] <ikonia> it's not happening on occasion
[11:12] <ikonia> ljl's host in general has been flakey
[11:12] <ikonia> I'll get him on one of my boxes in a DC
[11:12] <persia> So, the options are 1) to help him get a more stable host, 2) to lose the service during periods of instability
[11:12] <ikonia> that will make it go away
[11:13] <persia> Good choice :)
[11:13] <jussi> excellent. I was just wary of saying to someone "get a new host or get out"
[11:14] <ikonia> there has to be some rules on running a bot
[11:14] <ikonia> a stable host must be one
[11:14] <ikonia> (everyone gets some interuption
[11:14] <ikonia> )
[12:31] <Pici> oops
[12:37] <chandru_in> My IP address is being blocked when I try to join #ubuntu.  How are these IPs to block decided?
[12:37] <persia> Mostly based on previous abuse from those IPs.
[12:37] <bazhang>  FloodBot1 has kicked chandru_in from #ubuntu (Open proxies are not allowed)
[12:37] <persia> (no, this isn't perfect: help make IPv6 a reality, and abolish NATs and dynamic IPs)
[12:38] <chandru_in> It is not an open-proxy.  Sometime back a spam bot infected us and so I guess we're blacklisted.  Anyway to get ourself whitelisted?
[12:40] <persia> Needs discussion with an #ubuntu operator.  Hang out here a bit and one will help you.
[12:40] <chandru_in> thanks persia
[12:45] <bazhang> chandru_in, try now
[12:45] <chandru_in> no luck bazhang
[12:45] <bazhang> chandru_in, still fixing, sorry about that
[12:46] <chandru_in> no problem
[12:49] <bazhang> chandru_in, try again please
[12:50] <bazhang> chandru_in, success?
[12:50] <chandru_in> thanks bazhang it did work
[12:50] <chandru_in> :)
[12:51] <bazhang> chandru_in, sorry for the mixup
[12:51] <chandru_in> no problem, bazhang.  It is a minor inconvenience to keep the spam out
[12:54] <bazhang> LjL has suggested when he's not around to ask said users to get a cloak to workaround
[13:00] <Pici> bazhang: thanks, sorry I had to step away.
[13:00] <bazhang> Pici, no problem :)
[13:41] <ikonia> are we really comfortable with this open proxy detection from the floodbots ?
[13:47] <Tm_T> hmmh, should go through the bans and comment them...
[13:56] <jussi> ikonia: why shouldnt we be?
[14:04] <ikonia> well, it's placing a lot of bans, are they all tried and tested
[14:04] <ikonia> are they all valid
[14:05] <Tm_T> hi/hei SerzZ
[14:21] <Pici> heh
[14:22] <Tm_T> I'm still behind very slow and choppy gsm connection so don't count on me
[14:25] <Tm_T> PM:d him
[14:26] <Tm_T> hopefully bbehaves
[14:50] <Tm_T> I have to go
[15:26] <Tm_T> back for a moment, anyone have an idea from where SerzZ is possibly banforwarded?
[15:26] <Pici> I don't see anything using the bot.
[15:26] <Pici> SerzZ: Can we help you?
[15:27] <Tm_T> Pici: see idle time (:
[15:27] <jussi> Tm_T: I see nothing with the bt even
[15:28] <Tm_T> right, I wonder how he ended up here, as he just sent me email about something else
[15:28] <Pici> Oh, thats the same guy?
[15:29] <Tm_T> never seen him before
[15:29] <Tm_T> or atleast don't remember
[15:33] <Tm_T> oh well, will ask him, thanks (:
[18:14] <elky> Uh. Mahen23 is now joining -women to soliciting hugs.
[18:14] <pleia2> second one this week
[18:15] <elky> mahen23 has been lurking around in -ot for a while
[18:15] <Pici> meh.
[18:15] <Pici> Sorry for feeding, I forgot that he doesn't idle there.
[21:41] <Seeker`> should we not wait until core-channels and core-ops have been properly defined before recruiting more ops?
[21:46] <persia> If there's a shortage of ops causing issues, I think it ought be safe to try to get channel-specific ops prior to a definition (but wait for a real answer from IRCC)
[21:47] <Seeker`> persia: if there is a shortage of ops causing issues, it is a good reason to the definitions sorted ASAP
[21:47] <Seeker`> persia: seeing as they have been awaiting definition for quite a while
[21:47] <IdleOne> I don't understand why we need to apple for ops in -ops
[21:47] <IdleOne> apply*
[21:48] <persia> I guess.  As someone who finds the idea of "core channels" distasteful, I'm tempted not to ever define them, but I do see your point.
[21:48] <Seeker`> persia: same here. But there seems to need to be a definition of both core-channels and core-ops. I believe the former has been defined, the latter hasn't really.
[21:49] <Seeker`> IdleOne: For a laugh? Because the IRCC doesn't already have enough to do? Because the current definition of what a core-ops is is currently broken? All of the above?
[21:49] <ts2> do you want us to define a core-op, and then have people apply to be a core-op (if needed)? or do you just want to get some more ops in here?
[21:49] <ts2> I'm confused as what you're asking for here
[21:49] <persia> ts2, I think rather it would be good to have more ops on channels in need of more coverage.
[21:50] <IdleOne> ts2: honestly I am confused about the email asking for people to apply to be an op in this channel
[21:50] <ts2> -ops is a core channel, people must apply to be ops in core channels
[21:50] <Seeker`> ts2: I've requested more ops in here on several occasions, and each time I was told that it depends on getting both core-channels and core-ops defined
[21:50] <IdleOne> but I am already an op in a core channel
[21:50] <IdleOne> #ubuntu is a core channel
[21:51] <Seeker`> ts2: I've not yet seen a definition (or an agreement from the IRCC) on the latter.
[21:51] <ts2> IdleOne: so?
[21:51] <IdleOne> so why do I need to apply for ops in here?
[21:51] <ts2> IdleOne: people must apply to be ops in core channels
[21:51] <IdleOne> or am I mistunderstanding something about the email?
[21:51] <Seeker`> ts2: And there are several people trying to get a discussion sorted about what a core-op is at the moment, including members of the IRCC
[21:52] <Seeker`> IdleOne: Being an op in a core channel doesn't mean you are a core op.
[21:52] <ts2> Seeker`: we have decided to get more ops here while that's being decided, yet you seem to disagree?
[21:52] <Seeker`> IdleOne: for some reason.
[21:52] <Seeker`> ts2: If you desperately need more ops in here, give people ops. If it isn't that desperate, get stuff defined first.
[21:52] <IdleOne> but the IRCC already has a pool of core channel ops to chose from. Why do we need to apply?
[21:53] <ts2> because -ops is a core channel
[21:53] <persia> IdleOne, Consider it instead, expressing a willingness to serve.
[21:53] <IdleOne> that isn't an answer
[21:53] <Seeker`> persia: but it isn't that; It is an application
[21:53] <Seeker`> persia: the fact that we are idling here is expressing a willingness to serve.
[21:53] <ts2> yes it is, you must apply to have +o in each core channel (that's the process)
[21:53] <Seeker`> ts2: where can I find the definition of a core op?
[21:54] <persia> Seeker`, You're right: see earlier comment about my thoughts on "core" :)
[21:54] <ts2> Seeker`: we are not talking about a core op
[21:54] <IdleOne> ts2: did you apply to have ops in here?
[21:54] <ts2> no, it was added before the process
[21:54] <IdleOne> did any of the IRCC or current ops in this channel
[21:55] <IdleOne> so all the current ops get grand fathered in
[21:55] <Seeker`> ts2: where does it state that you have to apply for ops in each and every channel?
[21:55] <ts2> IdleOne: at least for now, if you want to propose somethig else, you should add an item to the meeting agenda
[21:56] <ts2> Seeker`: https://wiki.ubuntu.com/IRC/IrcTeam/OperatorRequirements
[21:56] <Seeker`> ts2: The OperateorRequirements document only talks about becoming a channel-specific operator. Which I already am.
[21:56] <IdleOne> I am not going to add any item to the meeting agenda. I am also not going to apply for something I have already applied for and was approved to be, a core channel op.
[21:57] <Seeker`> IdleOne: but that isn't a core-op. For some reason.
[21:57] <IdleOne> if that means I won't have +o in this channel, so be it.
[21:57] <ts2> Seeker`: https://wiki.ubuntu.com/IRC/IrcTeam/OperatorRequirements#Operator%20application%20proces
[21:58] <IdleOne> Honestly I am insulted by the separatist attitude that has been creeping into this team. core channel op, core-ops.
[21:58] <IdleOne> it scares me.
[21:59] <Seeker`> ts2: But I am already a channel-specific operator, and was before that document was drafted, doesn't that mean it doesn't apply?
[21:59] <IdleOne> the IRCC is the core-op team but now we need a sub team of core-ops
[21:59] <ts2> core-ops is non-existant right now, how can something which does not exist scare you?
[21:59] <ts2> Seeker`: only for the channel(s) you already have +o in
[21:59] <IdleOne> an invisibility suit doesn't exist either but the posibility of it still scares me
[22:00] <Seeker`> ts2: it can scare him becuase it is something that is planned?
[22:00] <ts2> no, it's planned to be considered
[22:00] <ts2> the IRCC has not decided to implement anything yet
[22:00] <Seeker`> ts2: it has. According to jussi.
[22:01] <Seeker`> He stated in the UDS discussion last week that it had been decided by the IRCC that a core-op would be someone that is an op on all core channels.
[22:01] <Seeker`> So which is it? The IRCC has agreed on it? Or are they planning on talking about implementing it?
[22:02] <ts2> the IRCC is discussing it
[22:02] <Pici> I think that the fact that we're even all confused about it means that somewhere the process has broken down and either it is flawed, or perhaps the policy in question is also flawed.
[22:03] <IdleOne> There is flaw in there somewhere that is for sure
[22:03] <persia> I certainly heard some concerns as a result of that statement in the UDS session, and have been assuming it was a personal statement, rather than a formal resolution.
[22:03] <Seeker`> Pici: that was kinda my original point. If the IRCC doesn't even know what it is doing, is right now really the time to be recruting more ops?
[22:03] <ts2> Seeker`: recruting more ops has nothing to do with the core-ops issue
[22:03] <Seeker`> ts2: it has everything to do with it.
[22:04] <ts2> only if we decide to implement core-ops
[22:04] <Seeker`> ts2: Seeing as I have been told several times that getting more ops in here is dependant on the term being defined
[22:04] <ts2> as that hasn't happened, it does not
[22:04] <Seeker`> ts2: you already have!
[22:04] <Seeker`> There are two types of operators in the Ubuntu IRC channels, Core Operators and Channel Specific Operators.
[22:04] <Seeker`> A Core Operator is someone who has operator status in all of the Ubuntu core channels.
[22:04] <Seeker`> There is a definition of a core op on the operator requirements page
[22:05] <Seeker`> but its a definition that not all the IRCC seem to believe they have agreed to
[22:05] <Seeker`> and is a severely broken definition
[22:05] <ts2> that page was wrote when we were planning core-ops, so it was included there. we also created the LP teams for that
[22:05] <nhandler> Seeker`: We said that we might not have a need to recruit operators for this channel if we get the core op team established (as that would also serve to provide more operators in here). As there currently are no such operators, we are putting out a call for more channel operators in here like we have done for other core channels in the past
[22:06] <IdleOne> to be an op in here you have to be an existing op in a core-channel?
[22:06] <Seeker`> nhandler: So why have my requests for more operators in here before been denied due to the pending definition of what a core op is?
[22:06] <nhandler> IdleOne: To apply to be an OP in here, yes
[22:06] <Pici> But not a core-operator... which is different.  Its confusing.
[22:06] <nhandler> Seeker`: They were delayed
[22:07] <ts2> IdleOne: see our idle policy
[22:07] <Seeker`> nhandler: is there a difference?
[22:07] <persia> I'd volunteer as an op here if the definition were different, but I don't have the attention to track most of the current "core channels" enough to have any interest in being an op there.
[22:07] <Seeker`> persia: there is a difference between a core-op and a core-channel op
[22:08] <IdleOne> nhandler: I don't think I should have to apply for op status in this channel. actually I think by not having ops in this channel my ability to be effective when resolving issues is limited.
[22:08] <Seeker`> you would be applying for the latter
[22:08] <ts2> for the final time, the call for ops in here has nothing to do with the core-ops issue
[22:08] <nhandler> Seeker`: Yeah. Denied means that it won't happen until the definition does. Delayed means that we wanted to wait to see if the core ops would get established
[22:08] <Seeker`> ts2: so why was I told it did in the past?
[22:08] <persia> Seeker`, Sure, but I don't believe I qualify for either.
[22:08] <Seeker`> nhandler: I was told that it would not happen until the definition does. Therefore it was denied.
[22:11] <Seeker`> I don't honestly see how you can be recruiting more ops when members of the IRCC cannot agree on what has been defined and what the definitions actually mean. The IRCC is currently extremely broken, and recruiting more people in to the mess is a pretty dumb idea.
[22:11] <ts2> Seeker`: recruting more ops in here has nothing to do with the core-ops issue
[22:12] <Seeker`> I get different answers about things from different members of the IRCC, and the answers I get from individual members isn't even self-consistent.
[22:12] <Seeker`> ts2: Please explain why I was told it was dependant on it before then?
[22:12] <ts2> if we were waiting on a definition, we would not ask for ops here
[22:13] <ts2> Seeker`: because we didn't want -ops to be a special-case
[22:13] <Seeker`> If it is not dependant, why was I told on multiple occasions that it was?
[22:13] <nhandler> Seeker`: Look at the meeting logs from 2 meetings ago. I believe this was all discussed there
[22:14] <Seeker`> nhandler: what date was that?
[22:14] <nhandler> Seeker`: I don't know from memory. Probably second week of October (or around there)
[22:15] <Seeker`> nhandler: nothing on https://wiki.ubuntu.com/MeetingLogs/IRCC or https://lists.ubuntu.com/archives/ubuntu-irc/2010-October/date.html#start for that time period.
[22:16] <Seeker`> nhandler: so where are the minutes / log?
[22:16] <nhandler> Seeker`: Not sure if the minutes/logs got prepared. The raw irc logs are still availabe on irclogs.ubuntu.com
[22:17] <Seeker`> nhandler: so who failed at "Reference meeting log at MeetingLogs/IRCC" from the fixed agenda items?
[22:18] <nhandler> Seeker`: It isn't "failing". And the negative attitude isn't helpful. We all have real lives and other obligations. We do as much as we can for Ubuntu in our free time, but other things do come up. You are more than welcome to prepare minutes if you want to. Otherwise, they will get done when someone gets a chance
[22:19] <Seeker`> nhandler: there was a regular agenda item that wasn't covered. That is a failure on the part of whoever chose to chair the meeting to carry out their duties. If you use mootbot, it isn't even hard to get the logs.
[22:20] <Pici> Fine.  Someone messed up.
[22:21] <nhandler> No, someone got busy. This really isn't the end of the world. Sure, having minutes are nice (which is why we added that bullet). But this isn't the first time they haven't gotten done and it won't be the last. Other teams (including councils, development teams, and LoCos) all have similar things happen
[22:22] <nhandler> As the person who prepares the monthly team reports, I would like to mention that the IRCC is actually one of the better teams when it comes to preparing detailed minutes from their meetings
[22:22] <Seeker`> nhandler: Ah, you're defensive because you chaired that meeting?
[22:22] <Pici> Yes, but as I mentioned at the UDS session, we're not too good at documenting what we do outside of the meetings.
[22:23] <nhandler> Seeker`: No clue, I might have. But I'm defensive because you are attacking instead of trying to have a constructive discussion at this point
[22:23] <Seeker`> nhandler: because there has been such a big deal over transparency and process in the IRCC over the last year, so much time spent defining procedures, and they aren't even being followed.
[22:24] <nhandler> Seeker`: Then help us out instead of simply attacking.
[22:25] <Pici> Stating the issues is helpful, but we need to move beyond that and come up with fixes.
[22:25] <Seeker`> nhandler: I'm not the one that said I have the time to do the job by applying for it. If I could guarantee I had the time for it, I would apply myself this time round; Sadly due to health issues I can;t.
[22:28] <IdleOne> Issue: This channel needs more ops, the op call in the email and the calls from current ops on multiple occasions is proof of that. Fix: Take the existing pool of ops and add them to the access list for this channel.
[22:28] <Pici> Seeker`: You don't need to be on the council to help us.  And I hope that the health issues aren't serious, you're a valued part of the team.
[22:29] <Pici> Er, that sounded a bit weird, I do really mean it though.
[22:29] <Seeker`> Well the issues are a) The IRCC can't agree on what it has decided; b) There isn't a consistent definition of what it has (or hasn't) decided on c) The IRCC spends an eternity definiting procedures and documents, resulting in nothing getting done; d) The procdures that took forever to be defined in the interests of transparency and accountability aren't even followed
[22:30] <Seeker`> The solution: Stop taking 6 weeks to define something simply and follow the procedures the IRCC defined
[22:31] <Seeker`> There was an agreement that there are more ops needed in here and for this channel to be treated like any other channel on the 9th october
[22:31] <nhandler> And that is what led to this email
[22:31] <Seeker`> it took 25 days for that email to then be sent out
[22:32] <nhandler> Seeker`: Yeah, with UDS in the middle and other stuff going on.
[22:32] <Seeker`> ts2: how long did that email take to write?
[22:32] <Pici> Does it matter?
[22:33] <IdleOne> but this channel is not like any other channel. This is the channel we send users to when there is a problem. When that user is even more of a problem in this channel most of us can't do anything about it but hope that someone with +o in here is active.
[22:33] <Seeker`> Pici: My point is that the email didn't take (or shouldn't have taken) 25 days to write
[22:33] <Pici> Seeker`: You're right, but it did.
[22:34] <Seeker`> There are things that noone other than the IRCC can do. These things are not being done in a timely manner.#
[22:34] <nhandler> IdleOne: Don't forget, we have *!*@freenode/staff/* on the access list for this channel (as well as all other channels). This means that if no OPs are around, staff can always help out
[22:34] <nhandler> Seeker`: And writing an email is not one of them
[22:34] <nhandler> Or at least drafting it isn't
[22:35] <Seeker`> nhandler: That specific email? Yes, imo
[22:35] <Seeker`> or could I send an email to the list right now opening applications for #ubuntu-server ops?
[22:35] <IdleOne> nhandler: freenode staff should not have to get involved. If we had +o in here we wouldn't need to bother them with trivial channel specific issues. Staff has bigger problems of their own to handle.
[22:35] <Pici> I personally think the problem is that no one attends our meetings, and we end up making decisions in a vaccuum.  As much as we want to make sure that we always have our operators and user's interests in mind we sometimes fail.  Then people only start to complain once we start putting procedures in place.
[22:36] <Seeker`> nhandler: you are sitting in a channel of 40 or so ops, why on earth do staff need to get involved?
[22:36] <IdleOne> I didn't get a reminder email for the last meeting.
[22:36] <Pici> Thats why I'm chaning *my* mind on some of the stuff we've done, because I've realized that our operators hate it.
[22:36] <ts2> IdleOne: the times are not dynamic
[22:36] <Seeker`> Pici: Yes, that is a problem, but things like meeting minutes being written up, or taking 25 days to send a short email doesn't help.
[22:36] <nhandler> IdleOne: The reminders are a convenience. The meetings are all on the fridge (like other meetings in the community) and on the wiki
[22:37] <IdleOne> nhandler: I am not blaming anyone about not getting a reminder email. Just saying that for me they are very convenient.
[22:37] <Seeker`> Pici: Since I realised just how badly off track this stuff seems to have gone, I've been to both IRCC meetings to try to contribute.
[22:37] <nhandler> IdleOne: Glad you like them ;) It didn't help the meeting was Halloween in the US ;)
[22:38] <Pici> Seeker`: I'm glad you have.  I'm sorry we couldn't get to your issue last meeting.
[22:38] <persia> Nor that it was during UDS travel for many
[22:38] <Pici> I want us to succeed, and its hard when we don't get feedback until its too late.  There isn't a particular person to blame about that, I think we're all at fault.
[22:39] <Seeker`> Pici: can you give a summary of the workload for the IRCC during an average week?
[22:39] <nhandler> Seeker`: Depends on the week. All I can say is that this week, things like this eat up a LOT of the free time we do have for working on Ubuntu
[22:39] <Pici> Seeker`: I can't pin down specifics, but we've been spending some time in the past few weeks dealing with loco channel issues, loco logging, etc.
[22:41] <IdleOne> nhandler: I apologize if I sound negative. I really am not trying to be. I just don't like the idea of separating op, core channel op, core-ops. I feel that the IRCC is the core-op team. the rest are channel ops. certain ops are asked to idle here as part of being an op in certain channels, I am fine with that but why do we need to idle here if we have no real ability to enforce the rules of this channel.
[22:44] <IdleOne> example: I ask a user to part this channel after an hour of being called names and they refuse to, continue to insult and be rude. I have to call !ops in this channel (with the hope that someone is active with +o) in the mean time I have showed the active troll and the trolls who read the logs that I have no power so what I say means nothing.
[22:44]  * Pici got hilighted by that.
[22:44] <IdleOne> sorry
[22:44] <Pici> Its okay ;)
[22:45] <Seeker`> One thing I do object to is being told I shouldn't use the ! ops trigger to get a troll removed from here when there isn't anything else going on
[22:45] <Pici> IdleOne: Thats the type of discussion I'd hope to see at this meeting... whenever it happens.
[22:45] <Seeker`> for idling etc.
[22:46] <IdleOne> Pici: all this defining of core channels and core ops is a giant waste of time. this channel has more then enough ops currently in #ubuntu,#k,#x etc that if they were all added to the access list there would be no more need for us using the ops trigger in here.
[22:47] <IdleOne> I don't want god like powers but I do want all the trolls out there in "log reading land" to know that if they come to this channel they won't be able to get away with abusing us.
[22:47] <nhandler> IdleOne: And that is certainly one possible solution that has been looked at (and will probably be looked at more in the future if necessary). We also have a few other solutions that we are thinking about to try and decide if they might prove to be even better solutions than either of these
[22:48] <IdleOne> but right now you are asking for applications, which will take time. This issue is immediate and needs an immediate solution.
[22:49] <IdleOne> add the current ops to the access list.
[22:49] <Pici> As much as I don't like beauracracy and I don't you all don't like it either, we can't just do that if its against our current policies. Either we change the policies or we just don't do it.
[22:50] <Pici> (I also hate trying to remember how to spell beauracracy)
[22:50] <Seeker`> Are there not enough IRCC members here right now to be quorate? :P
[22:50] <persia> And the policy changes have to happen in a meeting, for transparency, which is frustrating, but the alternative would be madness.
[22:50] <IdleOne> the current policy?
[22:50] <Pici> IdleOne: The one you don't like.
[22:50] <IdleOne> there is no clear and agreed upon policy
[22:51] <IdleOne> it's not just me who doesn't like it. there are other members on the ops team who don't like it.
[22:51] <Pici> IdleOne: I know.....
[22:52] <IdleOne> good teams have great leaders, great leaders listen to what the team wants.
[22:52] <IdleOne> the team does not want to wait for another month+ for this
[22:52] <IdleOne> imho
[22:52] <Pici> IdleOne: I want to get it sorted out this weekend.
[22:53] <Seeker`> Jussi still hasn't replied :/
[22:53] <IdleOne> I hope it can be
[22:55] <IdleOne> bureaucracy *
[22:55] <IdleOne> heh it was bugging me
[22:55] <IdleOne> sorry
[22:56] <persia> IdleOne, It's not just bureaucracy: it's a *good* thing that policy changes happen in meetings, otherwise there's no way we can know what policy is unless we follow *everything*.  With policy changes restricted to meetings, we can review meeting minutes and know policy.
[22:57] <Seeker`> persia: sadly, meetings aren't properly documented atm, so it can be hard to know even when stuff is decided in meetings
[22:57] <persia> Seeker`, I consider that a separate bug :)
[22:58] <nhandler> Seeker`: It was one meeting. And they all happen on a set schedule, so it is not /too/ much effort to look up the logs on irclogs.ubuntu.com for that day
[22:58] <IdleOne> persia: I agree with you on when and where policy should be made but if something is broke it needs to be fixed. Talking about maybe considering applying a policy and then pushing it back because every little word/title needs to be defined...uhg it smells of big government.
[23:00] <persia> It is governance.  We need to do it right.  We need to start from the basis that those we choose to govern us are doing their best, and ask how we can help to make it better.
[23:01] <IdleOne> well won't way of making it worse is adding more layers of governance
[23:01] <IdleOne> s/won't/one
[23:02] <Seeker`> nhandler: fair enough. I'll just point you to the last action of that meeting http://novarata.net/mootbot/ubuntu-meeting.20101009_1500.html
[23:02] <Seeker`> which was preceded by [15:40:46] <nhandler> In that case, any volunteers to do the post-meeting tasks? If not, I'll do them.
[23:02] <persia> IdleOne, I agree.  That's why I don't like "core".  I think we ought just have CC/IRCC/OPS, but that has scaling issues, and probably ends up burning out IRCC fast.
[23:03] <Seeker`> If people are volunteering for stuff they genuinely don't have time for, it needs to be stopped
[23:03] <nhandler> Seeker`: Yes. I always ask for volunteers first. No one volunteered to do them, so they get done when I get a chance.
[23:03] <IdleOne> I think we need to stop trying to blame anybody for not having done something. Life happens.
[23:03] <nhandler> Seeker`: You would rather have us say "Well, there are no volunteers, so they will not get done this meeting" ?
[23:04] <Pici> IdleOne: agreed.
[23:04] <Seeker`> nhandler: I would rather have people who say they will do something do it
[23:05] <Seeker`> imo, if you chair a meeting, you are implicitly saying you agree to do the associated work, and if you don't have time for it you shouldn't do it.
[23:05] <persia> There's a gap there.
[23:05] <persia> No.  Chairing a meeting is work needing doing, and adding responsibility for any unclaimed actions in the meeting only makes it harder to find chairs.
[23:05] <Seeker`> Thats why I wrote mootbot, to make it so easy you have the summary there already, with hyperlinks to the relevant places in the meeting.
[23:06] <Seeker`> persia: mootbot came about because I chaired a 2 hour long -uk meeting, which I then had to trawl to summarise, because I chaired it.
[23:06] <Pici> Seeker`: And we all love mootbot.
[23:06] <Pici> Don't think we don;t.
[23:07] <persia> Seeker`, Ah, so your assertion is only that chairs should publish minutes, not that they should be responsible for declared actions?  I'm comforable agreeing to that.
[23:07] <Seeker`> persia: yes
[23:07] <Pici> Gentlemen, as much as I'd like to continue talking about this, I'd also like to eat. So if you don't mind, don't treat my silence as not caring.
[23:08] <Pici> Thank you.
[23:08] <Seeker`> Pici: enjoy
[23:08] <IdleOne> Bon appetit