=== Ursinha` is now known as Ursinha === Ursinha is now known as Guest88816 === Guest88816 is now known as Ursinha === Ursinha is now known as Guest74101 [10:45] hmms [10:51] * funkyHat wiggles [10:52] * bkerensa rides the pogo stick around [10:58] * Pici yawns [10:58] hi all [10:58] =o [10:58] 3am [10:58] hello [10:58] howdy [10:58] wow [10:58] dedicated, I am impressed [10:58] ohai [10:59] I plan to go right back to sleep after this ;) [10:59] lets crack on then :) [10:59] #startmeeting IRCC team meeting [10:59] Meeting started Sat Jan 14 10:59:20 2012 UTC. The chair is AlanBell. Information about MeetBot at http://wiki.ubuntu.com/AlanBell/mootbot. [10:59] Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | IRCC team meeting Meeting | Current topic: [10:59] hi all, who is here for the meeting o/ [10:59] ô/ [10:59] o/ [10:59] o/ [10:59] * Pici waves [11:00] 0/ [11:01] Hello and welcome to the first team meeting of the new IRC Council [11:01] woo [11:01] I would like to start the meeting by thanking our predecessors for all that they have done over the past few years, and in particular thanking them for their assistance during the handover [11:02] ]o [11:02] jussi, elky, topyli, tsimpson, nhandler thanks very much [11:02] :) [11:02] and special congratulations jussi on the new baby \o/ \o/ [11:02] \o/ [11:02] \o/ [11:02] :) [11:02] #topic welcome and introductions from the new IRC Council === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | IRCC team meeting Meeting | Current topic: welcome and introductions from the new IRC Council [11:03] topyli will be along in a sec, but the new council is Pici topyli funkyHat and myself [11:04] Pici: funkyHat: want to say who you are? [11:04] I think you all know me by now. [11:04] Or at least, I hope so ;) [11:04] :) [11:05] I am the leader of the Ubuntu-UK loco team, and I do a bit for the Accessibility team [11:05] I am not an op in the core channels so I have been running about learning stuff over the last couple of weeks [11:05] Anyway, feel free to give me a pm at any time if you want to take about anything. I'm always available. [11:05] Hi, I'm Matt Wheeler. I've been an operator in #ubuntu-offtopic for quite a while now, and I'm also slowly working on my packaging skills with the intention of joining the MOTU team, but university is taking first priority at the moment [11:06] topyli: hi topyli, who are you? [11:06] aren't there supposed to be 5 members (and Hello!) [11:06] I'm pretty much always idling on here too, so feel free to pm me as well. I have nice hats ❡⢁) [11:06] ts2: i think not enough applied [11:06] ts2: yes, will get to that in a sec [11:06] ok [11:06] ts2: we couldn't enough blood from the fourth one to make them weak enough to apply [11:07] here is the agenda: https://wiki.ubuntu.com/IRC/IrcCouncil/MeetingAgenda [11:07] s/fourth/fifth/ [11:07] i'm juha siltala. i'm an op in #ubuntu-offtopic and a couple of loco channels (i think still) i used to be in the previous council [11:07] #subtopic announcement of the chair of the IRCC [11:08] Oh, I guess I should state my name for the record like everyone else. Benjamin Rubin, op in lots of channels, was on the council before the last, etc. [11:08] i'm pretty easy to reach on irc, so go ahead and bother me :) [11:08] I lost the game of rock-paper-scissors and as a forfeit I ended up as chair of the IRCC [11:08] There is no particular reason why we have to have one chair throughout the term of this council, so we might shuffle things about at some stage [11:08] but right now I am happy to be the [11:08] chair [11:08] \o/ [11:08] great! [11:08] !return | AlanBell [11:08] AlanBell, please see my private message [11:09] haha [11:09] eh [11:09] heh even! [11:09] ⢁) AlanChair [11:09] #subtopic the empty seat [11:09] As you may have gathered, the IRCC should be 5 people and we have 4. [11:10] We will leave the seat empty for the time being, our colleagues from the Community Council will be assisting us in the short term [11:10] we hope to hold an election to fill the remaining seat during the Q cycle. [11:10] That post would be set to expire at the same time as the current council so it would be a slightly shorter term than normal [11:11] any comments on that plan? [11:11] for the record, i don't see it as a very pressing matter [11:12] Agreed, I think the way AlanBell describes is just fine [11:12] theoretically it can lead to tricky votes though, but that's why we have a chairman [11:13] yeah, I am not really anticipating a deadlock on anything, but if we do I would certainly want the opinion of our CC advisors before using the casting vote [11:13] Agreed. [11:13] yes [11:14] ok, slight change to the agenda has been requested and I am bumping the #lubuntu item up to the top to allow people to get away [11:14] #topic Welcoming #lubuntu === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | IRCC team meeting Meeting | Current topic: Welcoming #lubuntu [11:14] :) [11:14] Hi #lubuntu! [11:15] we have put out the call for ops for the #lubuntu channel which is great [11:15] finally :-P [11:15] http://fridge.ubuntu.com/2012/01/06/lubuntu-call-for-operators/ [11:15] i think the nomination period ends right about now, wo we should have ops soon [11:16] looks like 12 people found their way through the application process to hit the join button https://launchpad.net/~irc-lubuntu-ops/+members [11:16] Oh, right. Hello [11:16] AlanBell: btw jussi is still listed as an admin of that? [11:16] after the meeting we will mail the IRC discussion list with the list of names and links to wiki pages and invite comments from the existing ops [11:17] Myrtti: refresh the page ;) [11:17] good good [11:17] Of course people are free to make commentary to the IRCC directly if they feel it more appropriate. [11:17] I had been wondering about that fr a week or so now [11:17] yes, please email us directly or pop into #ubuntu-irc-council [11:18] I think we should go through and make our decisions some point this week [11:19] I would like to make a request [11:19] Sure. [11:20] would the IRC council consider the possibility of allowing the applicants to see the comments others have left after the nominations, anonymised if needed, if they so request? [11:20] I'd personally benefit from hearing what others think I may need to improve on [11:21] +1 [11:21] * AlanBell ponders [11:21] I don't need a reply to that now, just tossed it out there [11:21] That'd help, if I knew them at all they could PM me (best to do it when mi"M more awake) [11:22] if we decide to do so, we should mention this when requesting comments [11:22] topyli: yes [11:22] Constructive critisicm is good, I don't see any obvious downsides at the moment. [11:22] topyli: and that [11:22] ok, people are encouraged to leave comments and testimonials on wiki pages, or pass private comments to the council - which I think would not be expected to be passed on, however when we accept / decline people we can pass feedback to them [11:22] I think if someone is being declined we should explain why [11:23] the reason I'm asking this is that when I applied for -server ops I got nothing on the wiki page [11:23] I'd even like to know what I can work on if I am accepted [11:23] Agreed. I think the decline comments have either been very vague or non-existant as of late. [11:23] Myrtti: you are still in the pending queue for server ops [11:23] AlanBell: possibly, I haven't checked [11:24] I have :) [11:24] Myrtti: We're aware that the current queues are something that we need to work. [11:24] we could tidy up the comments even to the point of just listing bullet points or something [11:25] ok, so this week we will be accepting a bunch of operators into the induction period [11:25] anyway, as an active ops on #ubuntu I'm used to getting negative, nonconstructive criticism all the time, but it's the constructive I've not had for years [11:25] heh [11:25] and we want to be a bit more organised about induction this time [11:26] we will be assigning mentors as we have done in the past, but we are also going to organise a number of training sessions in -classroom [11:26] stuff like how to set bans, extbans, IPV6 bans etc [11:26] how to mediate with problem users [11:26] good idea [11:26] how the bots work [11:26] +1 [11:27] even bots not currently used in #lubuntu, when they have 1600 idlers they might well want floodbots [11:27] sounds like a good idea even for current ops [11:27] of other channels [11:27] Aye [11:27] yes, they would be open to all [11:27] lecturers are obviously most welcome :) [11:28] i'd like to nominate myself for that, will have a talk with you about it latert [11:28] call for lecturers in the mailing list? [11:28] or is this it :-P? [11:28] yeah, but we need to have a chat about the topics to cover in a bit more detail [11:29] I'll volunteer for Irssi basics if such is deemed as interesting to people [11:29] great [11:29] so yes we will do a call for instructors, perhaps with some specific topics we want to include [11:30] and some people might be voluntold [11:30] Hopefully not though ;) [11:30] Yeah, that'd be interesetngi to attend as long as wit was a good time (irssi one) [11:30] Pici: it is an akgranerism I just wanted to use ;) [11:30] AlanBell: ;) [11:32] perhaps a Google poll /similar would be good to have to get a feeling on what might be wanted in addition to the basics [11:32] why Google? we have Launchpad, and it provides such fines polls! [11:32] so in summary, please comment on the applicants to help us decide (and decide who needs which mentor), the new ops will be invited into -ops (where they will be advised to be slient in the short term) and -ops-team and have bantracker access [11:32] and we will be doing a structured training course [11:33] looking at dates, it seems the induction will basically run to the Precise launch date which is nice [11:33] any more to say on the topic of welcoming #lubuntu and the new ops? [11:34] I'll just say welcome as well ■▎⢁) [11:34] ok, thanks Unit193, feel free to stick around or wander off o/ [11:35] #topic Review last meetings action items === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | IRCC team meeting Meeting | Current topic: Review last meetings action items [11:35] #progress topyli to finally mail council about the operator recruitment process [11:35] Right, thanks AlanBell! I'll read the rest when I wake up [11:35] well we have been kind of discussing this one a bit [11:35] i haven't mailed the council, so this is not done [11:36] we have a bug for this topic, I would be quite happy to just have comments on that [11:36] We have been looking at metrics from the last few rounds of recruitment drives [11:37] I think we should park this action, and come back to it when we get to reviewing bug 884671 in a minute [11:37] Launchpad bug 884671 in ubuntu-community "Ubuntu IRC operator recruitment is slow and ungainly" [Undecided,New] https://launchpad.net/bugs/884671 [11:37] #progress topyli to ask if eir can be tweaked to ignore floodbots [11:37] heh, you did this :) [11:38] done! yeah! [11:38] booyah [11:38] the response was unenthusiastic [11:38] Not surprising imo. [11:38] it was. but patches are welcome [11:39] I never understood this request tbh, eir dealing with floodbot bans is a good thing right? [11:39] just eir shouldn't ban the floodbots [11:39] AlanBell: eir actually nags the floodbots though [11:39] LjL: you also had a plan B of some sort, making the floodbots ignore eir :) [11:39] yeah. i just wonder one thing [11:40] is it actually helpful for eir to spell out each mute that the floodbots do? [11:40] i think it does, and found it quite annoying in -ops-team [11:40] Yes I was going to say, the other issue is how much eir is flooding -ops-team [11:40] ok, lets move on from this action which was done, and come back to eir/floodbots in a sec with the bugs [11:41] #topic Open items in the IRCC tracker === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | IRCC team meeting Meeting | Current topic: Open items in the IRCC tracker [11:41] we have closed an action which was a duplicate of the lauchpad bug about eir [11:41] there was an old appeals process, did that get closed topyli? [11:42] it sort of did. the user is not convinced, but i don't think we can improve our decision to please them even more [11:43] ok, and their ban has been resolved anyway [11:43] it is, the user just sometimes still complains about it being there in the first place [11:44] but that's a different problem [11:44] ok, can we close it without the system sending them a mail to remind them about it? [11:44] yes, close it [11:44] we'll get to bantracker zero!d [11:44] last activity on that was in November [11:45] yup, then we have nothing in the private tracker at all [11:45] but now we have lots of launchpad bugs :) [11:45] yes [11:46] if anything comes back in the tracker we will mention it in a future meeting [11:46] but launchpad bugs are the way forward [11:46] #topic Review Bugs related to the Ubuntu IRC Council === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | IRCC team meeting Meeting | Current topic: Review Bugs related to the Ubuntu IRC Council [11:46] #subtopic bug 892501 Floodbots - need a re-write to be under ubuntu operator team control - ikonia [11:46] Launchpad bug 892501 in ubuntu-community "Floodbots - need a re-write to be under ubuntu operator team control" [Undecided,New] https://launchpad.net/bugs/892501 [11:46] Fix committed \o/ [11:47] I am very pleased to announce that the floodbots will go through a managed process of being open sourced [11:47] there are beginnings of a project to get on with this [11:47] yay [11:47] nice [11:47] The first step happened this week when we worked with LJL to set up a launchpad project for them [11:47] Canonical have provided private code hosting and a small team will work with LJL to get the code ready for wider public scrutiny. [11:48] The first commit of the floodbot code was done on Tuesday [11:48] https://launchpad.net/floodbot [11:48] I'd like anyone who would like to work on the floodbots code to get in contact with the IRC Council or me. [11:49] yup, that would be great [11:49] I think we now have a good strategy for the future of the floodbots and I believe the concerns expressed in this bug are now resolved [11:50] i agree [11:50] any further high level comments about the floodbots? we can discuss details at a later meeting I think [11:51] ok, moving on [11:51] #subtopic bug 892500 eir is still not fit for purpose in #ubuntu -ikonia [11:51] Launchpad bug 892500 in ubuntu-community "eir is still not fit for purpose in #ubuntu" [Undecided,New] https://launchpad.net/bugs/892500 [11:52] https://bugs.launchpad.net/ubuntu-bots?field.searchtext=[eir] [11:52] I have been trying to understand eir a bit, and what it does, and what it should do [11:53] and I have been trying a few different experiments, figuring out how we can make the messages more useful by linking them to the bantracker etc [11:53] I'd much rather see ubottu managing these things than eir. If the FloodBots not being "under operator team control" was a problem, then I don't see how eir is any better in this. [11:53] also discovered that when it does a nagflood it maxes out at 10 messages [11:53] I personally think that its features should be folded into ubottu (either new bantracker or old). The current implementation is a bit clunky and of course we don't have direct control. [11:54] I agree with LjL and Pici [11:54] I think now eir is configured reasonably well, and being used reasonably well, but still doesn't add a huge amount of value [11:55] it seems that the floodbots could be extended to tidy up their own bans or ubottu could be extended to do the good bits of what eir does [11:56] improving eir and contributing back enhancements to freenode is an appealing concept, but fewer bots seems like a less complicated architecture [11:56] I think thats something that most of us can agree with [11:57] Indeed, integrating both bots is never going to be easy, and probably needs effort on both bots [11:57] What is it exactly that ubottu and the floodbots don't do yet? [11:57] LjL: remind us of expired bans [11:57] Annoy the ops in -team ;D [11:58] Doesn't ubottu does that in PM though? [11:58] funkyHat: a noble cause! :) [11:58] right, on a per-op basis. The nagging in the team channel, so ops could see each others bans, is not a feature requested by ops but by the ircc originially i think [11:59] Well, I suppose nagging everyone has a purpose, but in my opinion it just means that everyone will ignore all the spam. [11:59] To me, doing it in PM seems much cleaner. [11:59] If an op wants to review someone else's bans, they can still do it through the bantracker. [12:00] I agree, and I still like to know whether we are responsible for each others bans or not, and to what extent [12:01] I think the policy is that people don't "own" bans as such [12:01] Agreed. [12:02] do the bans pile up less now though? that was the original purpose i think [12:02] topyli: yes, there's a nice trend http://status.nullcortex.com/other/other/ircbans.html [12:02] I think they've improvd that. ^^ [12:02] i think there are less panic situations about full trackers [12:03] Definitely that as well. [12:03] topyli: ubottu was also changed to remind us of bans, though, as mentioned. How much is it eir and how much is it ubottu? [12:03] Would it be possible to have some bot give a list of bans periodically in -team, ideally with more than one ban per message? [12:03] So we would still get the reminders, but with significantly reduced annoyance? [12:03] LjL: that's true [12:04] funkyHat: To what purpose? You can get at the bans with a /mode b, and if you cram them into one message, there won't be space for any comments about them so what's the added value? [12:04] funkyHat, LjL : that's what I intended with my script, this overview hold more (useful i hope) information [12:04] yes [12:04] indeed, I was going to ask - what about *statistics* in #ubuntu-ops-team instead? [12:05] not the individual bans, but information about the status [12:05] LjL: I'm thinking of something similar to eir's current behaviour, where it nags about recent bans or bans that haven't been put on a quiet list [12:05] LjL: exactly, a per-op reminder and general stats in -team [12:05] funkyHat: I think we'd get the same complaints we have now about eir. Ops won't accept something that they feel has no added value to just peeking the banlist. [12:06] Much to the chagrin of the bot coders, I think we may need to play with a few implementations to see what works best. [12:06] agreed [12:06] bit of prototyping and experimenting [12:07] Really? Shouldn't we just start with requirements? [12:07] where is the fun in that? [12:07] hehe [12:07] I lean on the prototyping and experimenting [12:07] anyhow, please file requirements as bugs here: https://bugs.launchpad.net/ubuntu-bots?field.searchtext=[eir] [12:07] really? isn't that what got us in this situation? [12:07] oCean: Of course. But we know that sometimes whats described in features doesn't always translte well to practice. [12:07] LjL: hm ok. I would find that less annoying than the current behaviour, but if it's going to still annoy others just as much then there's no point [12:07] a requirement as a bug? [12:08] oCean: yes [12:08] so they can be tracked and discussed [12:08] oCean: I don't think so. What got us in this situation was prototyping and experimenting that kind of failed, but which was still pushed. [12:08] Yes that's pretty standard practise for software development ;) [12:08] (requirements as bugs) [12:08] tag it [eir] for the time being even though it might not end up implemented in eir [12:10] ok, I think until the next meeting we should keep eir, whilst actively tinkering with other plans, make sense? [12:10] I'm not so sure. What about we tentatively remove eir and "advertize" ubottu's ability to remind of bans, and see if the banlist grows? [12:11] Yes, I'm all for removing it [12:11] dunno, what does everyone think? speak now . . . [12:11] I agree with LjL, we've had quite a long time of "testing" eir and people still aren't happy with it. Lets test not having it and see what goes wrong [12:11] afaik eir also has handy autoremove timeouts, which ubottu doesn't [12:12] ah, it also has a load of them in it's memory right now [12:12] I personally have been using those autoremove things, and I've noticed that a number of other ops do as well. [12:12] Despite the spam, I find that a worthwile feature. [12:12] Is it possible then to just remove some of the nagging from #ubuntu-ops-team? [12:13] we could maybe shut it up, or move the control channel? [12:13] #ubuntu-ops-monitor would be a more fit place in my opinion [12:13] It's a more "opt in" channel [12:13] LjL: me too [12:13] er, mine too [12:14] right now if someone set a %~30d eir will have it on the todo list to remove that, I wouldn't want to remove eir right now and have that not happen [12:14] That's a valid point. [12:14] AlanBell: there's bans set #~365d - we have to wait at least 1 year? [12:15] oCean: Well, no, it would "simply" require a transfer to ubottu [12:15] oCean: not too worried about # it is the % I want to happen [12:15] AlanBell: nvm the # or %, it's as LjL says, at one point we have to transfer it. [12:16] Well, oCean, we simply can't do it right now, ubottu doesn't have the code for *that* yet [12:16] I understand [12:16] Ok, best choice seems to be to leave eir in the channel then [12:17] ok, so should we find out if we can move the eir control channel to -ops-monitor and maybe turn down the nag frequency to 24 hours or something? [12:17] let's see if we can make it more quiet one way or another, but leave it [12:17] * bkerensa must depart to bed (4:17am) gnight [12:17] AlanBell: I don't care how frequent it is as long as it's in #ubuntu-ops-monitor personally [12:17] LjL: Is there any problem with eir sending notices to -ops-monitor? [12:17] AlanBell: please note that the nag frequency is the same as the frequency that eir uses to actually remove [12:18] Pici: technical problems you mean? There shouldn't be, but if the floodbots act up, it should be easy to fix them [12:18] bots shouldn't react to notices (that is what they are for) [12:18] LjL: okay [12:18] AlanBell: Well, the floodbots do react to notices in #ubuntu, by banning the noticer :) [12:18] heh, OK [12:18] moving the nags seems like the best solution that would let people who want to see them still enjoy them [12:19] +1 [12:19] ok, lets find out if we can do that without it forgetting its current todo list for #ubuntu [12:19] AlanBell: Unfortunately or whatever, there is a difference between what the RFC say and what people use notices for... [12:20] Can I ask if generating my overview every now and then is useful? [12:20] #action ircc to move eir control channel to -ops-monitor if this will preserve existing ban timeouts [12:20] ACTION: ircc to move eir control channel to -ops-monitor if this will preserve existing ban timeouts [12:20] oCean: yes, it is [12:21] is [12:21] Ok, does it need some form of pw protection? [12:21] ok, lets move on to the next bug [12:21] oCean: i wouldn't think so, it's all info that can be obtained from /mode b, no? [12:21] LjL: no, not the expiry times [12:21] Ah, I see. [12:22] Maybe that does. [12:22] Ok, I'll look into that, let's continue [12:22] #subtopic bug 912783 IRC votes and surveys go to the ubuntu members which excludes some operators - LJL [12:22] Launchpad bug 912783 in ubuntu-community "IRC votes and surveys go to the ubuntu members which excludes some operators" [Undecided,New] https://launchpad.net/bugs/912783 [12:22] we have discussed this internally and with the CC [12:23] there are two slightly separate questions here, voting and the survey [12:23] the irc Members group was set up specifically for voting and we want Ubuntu Members to have a say in the governance of Ubuntu [12:23] ultimately it's up to the CC who are included in the electorate, not us. but surveys are another thing [12:24] if you are an op in a core channel then that is a significant and sustained contribution to Ubuntu and you would be well placed to apply for membership through the IRCC or another membership body [12:25] the recent survey was deliberately sent to the IRC Members, but future surveys if we do them could be sent to all members, all ops, ops of specific channels or any other arbitary group that seems sensible at the time based on what we want to ask [12:26] Please consider the possibility of more actively encouraging ops to become members, then, and make it clear they don't have to feel embarrassed if their only contribution appears to be being an op. [12:26] yes, lets do that [12:26] aye aye [12:26] yes [12:27] ok, so we will add a comment to that effect to the bug and close it off I think [12:27] Ok. [12:27] #subtopic bug 884671 Ubuntu IRC operator recruitment is slow and ungainly - jussi [12:27] Launchpad bug 884671 in ubuntu-community "Ubuntu IRC operator recruitment is slow and ungainly" [Undecided,New] https://launchpad.net/bugs/884671 [12:27] this is how the core ops team has grown over the last 2 years http://people.ubuntu.com/~alanbell/coreops.png [12:28] about 4 people per release cycle [12:28] we certainly don't want the process to discourage people from applying. where it does, we should of course fix it [12:28] we currently have 23 applications pending for core channels (which includes existing ops, and probably people we would decline) [12:29] I am thinking that we should use the #lubuntu induction as a model and move to a more release cycle based regular thing across all channels [12:29] so each release we would process the pending queues for all channels and then run an induction/training for the new intake all together [12:29] sometimes we just need ops and sometimes we don't, though [12:30] I was honestly thinking of a move in the opposite direction, i.e. going back (*additionally*, not as a substitute to the process!) to actively "pinging" people who the council finds fit, and making the process as smooth as possible for them. [12:30] so we might end up overstaffed in a few areas [12:30] how is that a bad thing? [12:30] I've been here for some time, and while of course things have changed and cannot be treated the same way as before, I guarantee that the old way of appointing ops had its share of advantages. [12:31] I certainly wouldn't make it a *more* process-driven thing than it is now. [12:31] AlanBell: well it would be a good problem to have if anything, i suppose .) [12:31] LjL: I can certainly see us encouraging some people to apply, I am just thinking of making it more regular and predictable and in line with the cadence of the release cycle [12:32] AlanBell: But why? If someone can be a good op *now*, and the Council knows that, why wait? [12:32] LjL: at the moment we keep people "like Myrtti in -server" hanging for so long in the queue that they forget they are there [12:33] LjL: so that we can do a more organised induction [12:33] AlanBell: Well, then maybe you aren't all so convinced they should be good ops, or something. I don't know - what's stopping you from accepting or declining? [12:33] the what huh? [12:33] -server is crazy [12:33] for some reason we won't put ops in it ??? [12:33] I've sat on the list for about 18 months now [12:34] I think I'm on the pending list for -server too, heh [12:34] I'm too, I think... [12:34] LjL: applications from existing ops we could probably process very fast and as they happen [12:34] I think we need to actively work the list, not wait for a new cycle. [12:34] Pici: +1 [12:34] +1 [12:34] it would be helpful to decline people who are not fit quicker [12:35] rather than making them go through the song and dance [12:35] be a bit more common sense rather than ticking boxes [12:35] well, in principle nothing prevents us from giving ops to anyone we like as it. we just haven't done so [12:35] ikonia: I was just going to say something like that [12:35] as it is* [12:35] topyli: -ops is a great example of that [12:35] topyli: Is there a particular reason then? [12:36] I was told to go through the whole application process, update my wiki all that sort of stuff to get ops in -ops, and to be honest, it just seemed like a waste of time as at that moment, we where empty handed [12:36] in the same way for server [12:36] at the time I applied -server was getting hit with issues, but the processes was a total waste of time [12:37] i can't remember why we don't. i do know why the process ended up like it is, but i don't know how we stopped the "old way" [12:37] rather than applying common sense [12:37] ok, I think we need common sense and a fast process for existing ops adding more channels [12:37] Seriously, "good" people will burn out before they have a chance of getting ops. It's happening. [12:37] exactly [12:38] you get fed up of trying to push it/get the issue resolved [12:38] And tight processes like this always end up scarying away "good" people who don't like to brag, and attract sillier people instead. [12:38] but the opposite is also true, [12:38] someone like bacta can apply for ops and be told to go through the proces [12:38] I say we work the queues every meeting and look at our procedures for adding existing ops on-the-fly [12:38] rather than just saying "no, that's not going to happen" [12:39] Pici: +1 [12:39] or before every meeting, or some other sane but regular cycle [12:39] isn't there a team owning this ? [12:39] getting it regular is what I am aiming for [12:39] eg: when someone applies, deal with the request [12:39] Pici: That's fine, but please please also don't sleep on people you spot in #ubuntu or anywhere who you think are good, and as AlanBell says, "voluntell" them. [12:40] "When the Ubuntu IRC Council notices the need to have more operators in a particular channel or channels, they will send an email to the ubuntu-irc mailing list." [12:40] that is the level of current regularity [12:40] Working the queues != asking for more ops [12:40] AlanBell: Getting it regular also risks meaning closing the door to some lovely irregularities. I hope you don't want that to happen. [12:42] I think whatever "policy" we have on the process we can still make common sense exceptions, like ikonia said [12:42] (We've been at this for nearly two hours now :/) [12:42] The fact you all have been chosen for this IRC Council position *does* mean you're trusted to know who deserves being dragged into being an op. [12:42]