=== komputes_ubuntu is now known as komputes === nixterna1_ is now known as nixternal === nixternal is now known as Guest44311 === elky is now known as Guest19067 === nixternal_ is now known as nixternal === 50UAAANDT is now known as lamont === freeflying is now known as ZhengpengHou === ZhengpengHou is now known as freeflying === Guest98536 is now known as jussi01 === Guest8650 is now known as Zic === Pricey is now known as pricey\ === pricey\ is now known as pricey| === pricey| is now known as Pricey === yofel_ is now known as yofel [17:58] o/ [17:58] :) [17:59] hihi [18:00] hello [18:00] hi MenZa :) [18:01] hey topyli [18:01] hi all [18:01] 1 sec, brb [18:03] ok, Im back. role call - topyli Pici nhandler tsimpson [18:03] Hello [18:03] o/ [18:03] here sir [18:03] ok, we have quorum, hope Pici arrives soon [18:03] #startmeeting [18:03] Meeting started at 12:03. The chair is jussi01. [18:03] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [18:04] jussi01 has agreed to sacrifice himself as chair, right? [18:04] [topic] Revisit #ubuntu-ops policies including 'no idling' & +v [18:04] lol [18:04] New Topic: Revisit #ubuntu-ops policies including 'no idling' & +v [18:04] Daviey: this is you mate [18:04] \o [18:05] I'm not entirely sure how this point got attributed towards me. However, I'll gladly discuss it [18:05] It's seems not to be such as issue as it once was... However it would be nice if we could revisit it's reasoning [18:06] Why does this policy exist? [18:06] ? [18:06] i find the current policy useful. no idling keeps the channel on topic, and furthermore lurkers during mediation could be harmful [18:07] we have logs for transparendy [18:07] then there's the potential for 'noise' in the channel as well [18:07] +1, it also allows a way of simply seeing who needs attending to [18:07] aye [18:07] topyli: if you visit the logs you'll notice that the channel is often not on topic, with ops discussing non ops stuff.. Not saying this is a problem, but i'm not sure it validates a non lurk policy. [18:07] true [18:08] Daviey: no, its on topic when it needs to be on topic - when there are people waiting [18:08] Having this rule also avoids users simply joining -ops to "watch the show" which several users have admitted trying to do [18:08] jussi01: if people need attending to.. they can simply ask. [18:08] I think we'd be spending a lot of time trying to moderate the channel if it was a free-for-all-join party. [18:08] i'm not sure people need to be coached into asking questions, or needing help. [18:08] i.e. users trying to 'help' with the moderation process of other channels [18:08] I would prefer if operators tried to resolve the majority of situations in /query with the user. [18:09] doesn't that have the problem of not being logged ? [18:10] well, an issue being resolved doesn't necessarily need to be logged for bureaucratic purposes [18:10] Daviey, i think it's a separate issue if we want to remove random chat among ops on -ops. we could move it to -ot if needed [18:10] I'm not entirely sure how i feel about solving things in /query. I agree that things should probably be logged, but we have discussed the issue previously of people having to state their issues infront of quite a large ops audience. [18:10] Daviey: I see 3 other options... [18:10] the off-topic chatter in -ops would fit into the "Discuss general attitude for -ops, how we are expected to behave" item [18:10] Daviey: In channel... in -ops... or in a meeting like this/over email. [18:10] Daviey: Are any of those preferable? [18:10] Daviey: well, the appeals process specifies that if people feel unfairly treated, they are welcome to join -ops for mediation. [18:11] This is true, but the item of agenda is eseentially regarding not allowing lurkers in -ops. [18:12] Aye, my bad. [18:12] ok, are there more opinions on this? we need to keep the meeting moving - if not, lets have a vote. [18:12] a vote on what? [18:13] what are the benefits of allowing lurkers? [18:13] Pricey: if we should allow lurkers in -ops [18:13] I can't think of any [18:13] * Daviey proposes that people are allowed into -ops, including to lurk.. Unless they cause disruption where they are asked to stop. [18:13] the benefits of not allowing have already been mentioned [18:13] yep as Myrtti says, i don't think benefits have been mentioned [18:13] jussi01: ^ [18:13] I think the policy should be more clear, of we want to say that ops is only for discussion of issues it should be less offtopic [18:13] s/of/if/ [18:13] but that's part of another issue [18:13] I think that's another issue, like you said [18:14] Myrtti: I think that people should be able to lurk in a functional channel if they wish. [18:14] I honestly dont see any benefit of changing it, and none has been presented [18:14] similar to the lurkers in this channel right now. [18:15] Daviey: but what are the benefits? if there aren't any apart from "it would be nice", and there are clear negative effects... [18:15] Daviey: I think the possibility of a "virtual lurking" is there through the logs, which is enough imho [18:15] If a user is actually involved in the situation being discussed, we do invite them to -ops to contribute to the discussion. Why do we need to allow people to idle? [18:15] I don't the issue is why we should allow people, we should really be open by default. [18:16] I think a far preferable 'solution' is to try and conduct more of our work outside of -ops, in /query for example where it is less intense for the user. [18:16] I lurked for a long time in -ops for the benefit of myself in that I could see how operators did their job, i could learn from that [18:16] I think allowing people to lurk, is moving towards the more open applications procedure that is being developed [18:16] I see many people inviting people to -ops for a chat and I don't think that's always necessary. [18:16] popey: That could be done just as easily via irclogs.ubuntu.com [18:16] nhandler: +1 [18:16] Daviey, as for lurkers here, this channel is not the same as -ops. this is decidedly a public meeting. -ops discusses people's bans, personal conduct, etc [18:17] thats like telling people to ubsubscribe from a mailing list and that they should read it via lists.ubuntu.com instead [18:17] nhandler: that requires work.. going out and activly looking through things [18:17] Well popey is a "good egg", but he was asked to leave -ops after being a lurker and contributing for a number of years. [18:17] Which to me, is odd. [18:17] if the info is publicly available, there is no reason imo people cant sit and watch [18:17] if the info isnt public, different story [18:17] cjohnston: This isn't about those people. [18:17] I think the issue is that people won't just sit and watch [18:17] cjohnston: The ops have this, because people don't "sit and watch". [18:18] they'll inevitably join-in [18:18] I can't understand what benefit we'd gain for allowing hecklers in [18:18] Daviey: Some people don't like your or popey. [18:18] I think it's a recipe for disaster, for the reasons tsimpson outlines. [18:18] Alright, so are there any other benefits of allowing people to idle in -ops ? [18:18] -ops was open to lurkers for ages before the rule was changed, and the rule was changed not because of any disruption or confusion, but because of an unjustified fear someone was coordinating attacks while lurking in ops [18:18] and it's not personal towards popey or Daviey, it's in general [18:19] Myrtti: erm, i'm not sure how that is anything to do with me [18:19] I am allowed to lurk :) [18:19] Daviey: per Pricey [18:19] Would it be worth creating a "mirror" channel that is +m but all of the conversations from - ops are relayed, so people can watch in real time but not interfere in the discussion. ? [18:19] i couldn't actually parse what pricey said [18:19] jussi01: If we were to do that, why not just +m -ops and voice people involved in the discussion ? [18:19] I'm not sure why there is a feeling people will naturally interfere with a discussion. [18:19] popey: extra 'r' there sorry. "Some people don't like you or popey." [18:19] nhandler, that could work [18:20] "getting involved" =! interfere [18:20] nhandler: massive moderation issues with that [18:20] Daviey: human nature [18:20] nice [18:20] nhandler: because its then too hard for people to ask for voice [18:20] Pricey: that seems somewhat irrelevant [18:20] tsimpson: except, they didn;t [18:20] mc44: they don't because there is no one lurking [18:20] Daviey: I was replying to your "well popey is a "good egg",..." line. [18:20] tsimpson: maybe you weren't around when there was [18:20] there was +Z on hyperion [18:20] tsimpson: and amazingly, nothing happened! [18:21] Pricey: He's certainly not a troll, and being asked to leave after being involved for a number of years is bad form IMO. [18:21] mc44: I was in -ops before it was a no-idle channel, and I sometimes did jump into a conversation :) [18:21] Daviey: I'm not disagreeing with you :-) [18:21] before I as an op [18:21] tsimpson: I'm sure you caused havoc [18:21] tsimpson is a rascal! [18:22] Is there objection to having the policy removed as an experiment? [18:22] As much as this is an important subject, we have taken 20 mins on it, perhaps it would be best to move on now? [18:22] * highvoltage waves [18:22] the other part of this item is the +v policy, what issues are there? [18:22] jussi01: it would be great if we could do something. [18:22] jussi01: Rather than do a little iccc charter, then start irc operator guidelines, then drop that, then talk about the +v policy a little... etc. etc. [18:23] * Daviey assumes there isn't an objection to an experiement then. [18:23] Daviey: I certainly object to that. I dont think it serves any real purpose. [18:23] we can try it out [18:24] So far, we have had very few benefits listed IMO compared to the number of disadvantages. [18:24] jussi01: you bjectpurely on the basis of an experiment not serving a purpose? [18:24] <-- sticky keys. [18:24] I'd like to repeat my earlier point... that we try and use /query for more issues. In the majority of cases there's no need to invite people to -ops for a mass discussion. [18:24] Many of the points raised can be solved by people interested in the discussions looking at irclogs.ubuntu.com [18:24] its scary. [18:25] I think /query is fine for smaller issues or first time offenders. But for some more serious issues and repeat offenders, it can be benficial having discussion in -ops [18:25] Pricey: that's caused problems in the past with people making false accounts of what's happened in query [18:25] nhandler: yep [18:25] then minor issues have to be raised to the ircc because people are making up what happened in query [18:25] nhandler: That sounds great, but i know i tend to react to hilights - which is much harder using a log dump. [18:25] ikonia: That sucks. [18:25] Pricey: concur [18:26] Daviey: Surely you'd only be hi-lighted if you were a party in the issue, in which case you'd already be in the channel. [18:26] ikonia: But I'd hope people would still try and work it out. [18:26] ikonia: if it has to move further on... it has to move further on [18:26] Pricey: I think most people do and most people do use an initial query where possible [18:26] ikonia: and we've got the dispute resolution process for hte guideline [18:26] how about a moderated channel the bot automatically giving voices to people that have withstanding issue, ops being opped? ;-) yakshaving at its best [18:26] MenZa: no, my hilights are not my nick based only.. and i'm sure i'm not the only one. [18:26] ikonia: i'm just suggesting we utilise /query a little more, not replace -ops etc. [18:27] Pricey: I don't see that as a probloem, I know most guys do initiate a query to get the ball rolling [18:27] Daviey: neither are mine, but I fail to see what sort of hilights you'd set that would make it 'interesting' for you to join into a discussion, or watch it (apologies for the tone; I'm finding it difficult to phrase myself better) [18:27] Pricey: I fail to see how opening up ops and sorting issues in /query are related [18:28] MenZa: because I think a lot of the stuff we don't want people interfering with doesn't need to be in there in the first place [18:28] So, how does opening up -ops have to be a pre-requisite for taking issues in /query instead? [18:28] MenZa: that is not really the issue.. Not allowing people to lurk, is in directly against the enabling people to get involved with the ops team, particulary the direction of making it easier for people to apply. [18:28] its not [18:29] i'm not saying that [18:29] Daviey: There are other methods of helping out than idling in -ops [18:29] (I agree using /query often is a better option, but let's take that seperately) [18:29] we should be doing it anyway as much as possible imo [18:29] nhandler: I agree, but potential applicants should be able to see it more from the inside IMO. [18:30] * nhandler fails to see how seeing the discussion in an IRC client provides any more benefit than seeing it on irclogs.ubuntu.com [18:30] Daviey: ok, given. however, we are working to enable more communication between ops and users - for example the #ubuntu-irc-helpers channel that is coming up. I think a mirror channel solves the issue admirably, people can watch if they want, and all the current benefits are still in place [18:30] I personally feel the way it is at the moment fosters elitism. [18:31] A mirror channel is the only semi-sensible solution I've heard suggested so far, to be honest -- if I'm mediating, I'd prefer not to be interrupted in the process by a third-party wishing to give their side of things, but I still fail to see *how* we benefit by even doing that [18:31] jussi01: I don't really see another mirror channel's good [18:31] nhandler: because whilst its happening you can pm people involved to learn more [18:31] jussi01: (I understand you're just trying a helpful middle ground) [18:32] * Daviey still cannot see justification for not having an experiement. [18:32] maybe a general -ops channel (where the ops "hang out") and an issue resolution channel may be more what we need? [18:32] tsimpson: and which would be open? [18:32] Daviey: what is the proposed experiment? [18:32] tsimpson: that's not allowed for transparancy [18:32] require people interested in joining the ops team to lurk under the strict guidelines on dont get involved? [18:32] one for only issue resolution and one for the "ops team" [18:32] ikonia: why? [18:32] jrib: Dropping the no ideal policy, for a timed experiement. [18:33] MenZa: the issue resolution channel would be no-idle, like -ops is now [18:33] tsimpson: it's been suggested before and told it can't happen as people can't see what the ops are talking about - so that's not transparant [18:33] Daviey: but this was the previous policy already, no? [18:33] but the other channel would be open [18:33] tsimpson: that doesn't change anything though, does it? [18:33] both would be logged [18:33] what would the 'general' channel's purpose be? [18:33] it would go some way towards the issues Pricey is bringing up [18:33] jrib: and i didn't see it had a problem then. [18:33] MenZa: a team channel [18:34] right [18:34] I would far prefer an open channel, where we dealt with issues as and when they appear. [18:34] we can talk amongst ourselfs and with IRC users in the team channel, which is open to all [18:34] and the issue channel is just for that purpose [18:35] Overreaching rules, that could very easily damage the benefits we are able to give the community are not good imo. [18:35] The more contributors we have the better, and not everyone interested in what's going on and wanting to help out are bad. [18:35] Daviey: you did witness third-parties interfering at times though? [18:35] I would much prefer we deal with problem users interfering with the -ops activities as and when they become a problem. [18:36] jrib: but it never caused a *major* issue IMO. [18:36] I'm not 100% against trying it as an *experiment*, but I'd suggest a zero-tolerance policy against interference in this case [18:36] ok, so there a few options Ive seen, Daviey's experiment, the mirror channel, cjohnston's strictly monitored interested parties, tsimpson's general ops team channel. have I missed any? [18:36] i.e. if you even try to hop into an issue being dealt with, instant /ar [18:36] oh, and leave it as it is [18:36] jussi01, the "i'm happy right now" one :) [18:36] yes [18:36] just because someone isn't directly involved in an issue,it doesn't make their PoV invalid. [18:37] Daviey: How about we instate a votebot, then? [18:37] huh? [18:37] jussi01: the bot autovoicing on a moderated channel [18:37] Let people vote for or against! To ban or not to ban! [18:37] Daviey: I agree. It was an infrequent issue. I also think the channel would benefit from being open. It fosters a better image in my opinion. [18:38] MenZa: i'm not sure i agree with that, sounds like over engineering a non-issue.. But if you think it'sa good idea,it would be better to give it a seperate agenda item. [18:38] jussi01: "Making it entirely open and dealing with disruption when required." [18:38] We have already had complaints to the ircc about too many people in the mediation discussion, and we have talked to the ops about this, I dont see how adding still more people to those discussions helps [18:38] Daviey: I was being sarcastic [18:38] Daviey: Too many cooks spoil the broth and all that, what jussi01's saying [18:39] MenZa: sarcasism is less than constructive. [18:39] is there a chance we could start looking at things with common sense and without kid gloves ? [18:39] ikonia: ? [18:39] Daviey: Yeah; apologies. [18:39] or when someone comes in needing help, all invested parties go +v chan goes +m? [18:39] jussi01: there seems to be an overwhelming desire to please everyone for the sake of the "ubuntu way" rather than working out what is productive to help mediate the channels [18:40] cjohnston: that's quite impractical [18:40] ikonia: +1 [18:40] ikonia: I really don't like that idea... [18:40] tsimpson: the bot keeps track on who has an issue already [18:40] ikonia: We are not out to make stuff easy for us to 'mediate' the channels. [18:40] ikonia: If we need to put in hard graft... we need to put in hard graft. [18:40] ikonia: We want the channels to be as productive as possible. [18:40] tsimpson: ops would be ops, the people with bans/mutes would get voice, the rest could request for voice or ask at -irc/-irc-helpers [18:41] ikonia: *the channels be as productive as possible*. Our 'mediation' is not the priority here. [18:41] Myrtti: and when 2 people with bans/mutes join? [18:41] Pricey: moderate would have been a better word then [18:41] tsimpson: fifo [18:41] ikonia: I don't care, still a bad aim imo. [18:41] tsimpson: as it is now [18:41] ikonia: This shouldn't be about making it easy for us. [18:41] Myrtti: how do we determine someone is banned/muted? [18:41] Pricey: yeah, I can see how making easy moderation to help the channel flow for productivity would be a bad idea [18:41] As i said earlier,i feel that having a non lurk policy fosters elistismand we need to remember +o's only exisit to serve the users. [18:41] jrib: the bot does, it already does with the bantracker? [18:42] We don't seem to be going anywhere with this discussion in this party -- can I suggest that we possibly put this issue out on the mailing list, return to it at the next meeting? [18:42] I think maybe cjohnston's strictly moderated observers could work. ie. someon joins the channel, we ask how can we help, they say, Id like to observe, we then give them a set of rules for observers. [18:42] More input would be a good idea, imo [18:42] Myrtti: I see, so bot auto-voices anyone with bans/mutes in relevant channels? [18:42] jrib: yup [18:42] jussi01: If someone needs help, they will ask.. Why does anyone think they need prompting? [18:42] instant recognition of people with issues as a bonus [18:42] tsimpson: keep all ops +v, have a command (!ops) that when someone joins the channel and says !ops a bot voices them and +m the channel.. once the issue is resolved someone sets it -m... after setup requires only minor work [18:42] ikonia: its a secondary priority. [18:43] Myrtti: but there are issues for #ubuntu-ops that do not involve bans/mutes too [18:43] jrib: if ops are opped, they can see if someone requests for a voice or the issue can be handled at -irc/-irc-helpers [18:43] Daviey: because how many people think they are in #ubuntu? how many people who come in because of forwards and dont say anything, but need their issue dealt with? [18:44] Myrtti: I see, so the +v is for the benefit of the lurkers really [18:44] jussi01: Asking if they need help, will only encourage people thinking they are in #ubuntu :) [18:44] * MenZa looks at the clock. [18:44] jrib: one way of seeing it [18:44] we have spent 45 mins talking about this now, and we haven't got far [18:45] Can I re-state my suggestion above -- that we gather more input from the mailing list on it? [18:45] Can i requesta vote on removing the non lurk policy an a time limited experiment between this meeting an next? [18:45] I agree with MenZa [18:45] and* [18:45] [vote] Take this issue to the ML and re-visit next meeting [18:45] Please vote on: Take this issue to the ML and re-visit next meeting. [18:45] 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 [18:45] E.g. /msg MootBot +1 #ubuntu-meeting [18:45] only ircc vote please [18:45] +1 [18:45] +1 received from jussi01. 1 for, 0 against. 0 have abstained. Count is now 1 [18:45] +1 [18:45] +1 received from tsimpson. 2 for, 0 against. 0 have abstained. Count is now 2 [18:45] +1 [18:45] +1 received from topyli. 3 for, 0 against. 0 have abstained. Count is now 3 [18:46] nhandler: ? [18:46] well vote passed in any case. [18:46] Good work guys, some nice progress made here :-) [18:46] [endvote] [18:46] Final result is 3 for, 0 against. 0 abstained. Total: 3 [18:46] Pricey, right :) [18:46] jussi01: and a vote on my suggestion? [18:46] Daviey: Looks like its been overruled :-( [18:46] Daviey: next meeting [18:46] *sigh* [18:47] discuss on the ml please [18:47] Daviey, your suggestion is still valid [18:47] Daviey: we'l get all the options discussed on the ml [18:47] jussi01: You'll send out an e-mail with the current suggestions? [18:47] B[B[B[Bwhich mailing list?[Bwhich ml? [18:47] popey: ubuntu-irc@lists [18:47] the IRC one? [18:47] erk [18:47] * MenZa fixes popey's keyboard [18:47] [topic] Should the IRCC members be direct members of ~ubuntu-core-ircops and named channel operators [18:47] New Topic: Should the IRCC members be direct members of ~ubuntu-core-ircops and named channel operators [18:48] some background may be needed on this one [18:48] nhandler: around at all? [18:48] thanks [18:48] +1 [18:48] (for the last vote) [18:48] For this topic, we previously had IRCC members as OPs in the various channels through UbuntuIrcCouncil [18:49] If I understand the current plans correctly, after we start using LP to manage the access lists, the IRCC will become named-ops in the channels (since we are direct members of ~ubuntu-core-ircops) [18:49] Can't ~ubuntu-irccouncil be a member of ~ubuntu-core-ircops? [18:49] MenZa: it is [18:49] Can the IRCC only add themselves to channel flags lists by agreeing to at a meeting like this? [18:50] That isn't what this is about Pricey [18:50] jussi01: So, doesn't it... have access that way? [18:50] This is about whether we should be named-ops in the channels (as IRCC members) or if we should only have access through UbuntuIrcCouncil [18:50] What's the point in limiting yourself? [18:50] MenZa: it does. this is about being "named" ooperators [18:50] Oh, right. :) [18:50] If you've access through "UbuntuIrcCouncil"... that's just a hassle! put yourself down by name, save user's confusion? [18:51] nhandler: And it looks like your answer to my previous questino was 'yes'. [18:51] Because previously, there was an attempted separation between being on the council and being an Ubuntu OP [18:52] As a note, whatever we decide here will impact "Ops are welcome to apply for a role on the council and retain their Op status, but they are also informed that in the interests of having a separation of power, they also have the opportunity to step down as an Op temporarily." in the charter [18:52] nhandler: we would only be named-ops as long as we were in the council or a direct member of the team(s) for those channel(s) [18:52] What's the difference between being an op through the "ubuntuirccoucnil" shared nick, and your own? [18:52] 1. Its a hassle for you to do anything using the shared nick. [18:52] 2. Its *FAR* less transparent to users, at who is doing what, when the nick is used. [18:52] Pricey: one allows you access while on the council, one for a longer period [18:53] Isn't the intention of the UbuntuIRCCouncil nick just to be ... an emergency handbrake? [18:53] jussi01: Why can't you just remove 'bad' people? [18:53] Pricey: From what I was informed when I joined the council, having access through UbuntuIrcCouncil is similar to having access through *!*@freenode/staff/*. We aren't the primary OPs, we only intervene when no named ops are around [18:53] jussi01: surely LP integreation would auto remove access when not on IRCC [18:53] nhandler: I thought we were talking about 'core' channels? [18:53] Pricey: not really - identifying as the nick without /nick ing to it makes it fairly easy, I have an alias set [18:54] jussi01: That seems like needless bureacracy to me. (Yes I can't spell) [18:54] Daviey: thats the point, we have access through the ircc nick, no need to be a named op as well imho [18:54] jussi01: If you have been trusted to act in a channel, why make yourself jump through hoops? [18:54] jussi01: except the transparencey [18:54] jussi01: If you're no longer trusted to act in a channel, then your access should be removed? [18:54] jiboumans: with the LP integration, we would be named ops [18:54] gerr [18:54] jussi01: ^ [18:55] jussi01: And with 'transparency', it should be obvious to users who the ops of a channel are. [18:55] * Daviey proposes that this topic is moved to the mailing list and deferred until next meeting. [18:55] Guys -- perhaps this would be more relevant to discuss *after* deciding on the "Extend ubuntu cloaks to include more information" -- what if *!*@ubuntu/member/irccouncil/* had access? [18:55] Well, I guess it all depends on the role the IRCC is meant to play. Do we want them to be performing the everyday OP duties in the core channels? Or do we want the council to only act as an OP when no other OPs are around [18:55] * Pricey highfives Daviey [18:55] how/when we act as ops in those channels is the real issue I think you're getting at [18:56] Pretty much, I believe that is the core issue [18:56] tsimpson: exactly [18:56] what about an ircc member that wishes to drop their op status? for them, being auto-opped on even more channels is not ideal :) [18:56] topyli: Auto-OP was never being discussed. They might have OP access, but they will not be automatically OPed [18:57] they would show on access lists and be pressured to do op duties [18:57] topyli: I'd hope they are free to make the personal decision to not op channels if they don't want to. [18:57] topyli: However making them jump through hoops to operate if they want to op is silly! [18:58] true true, simpler is better [18:58] I dont think its useful, in the light of the charter and what was discussed at UDS wrt ircc members "stepping down as ops" etc its best they are not added just because they are on the ircc. [18:58] the majority of the channel stuff would/should be done by the channel ops, then core ops when needed [18:58] jussi01: sounds fine to me. [18:58] tsimpson: yes, then the ircc when stuff above that is needed [18:58] jussi01: I just don't like the idea of you removing people's ops and telling them to use the ubuntuirccouncil nick. [18:58] a council member would have to make a choice, to act as a core-op, or as the IRCC [18:58] Pricey: no, no removals would be done [18:59] jussi01: you guys own the core channels, if you want to add one of yourself to the channel flags list... then decide it! [18:59] Pricey: this is about adding them to the core op team [18:59] Pricey: We aren't removing their OP status. But for instance, I was not previously a core-op. Should I be added just for being on the IRCC? That was the issue [18:59] jussi01: so what on earth are we discussing? [18:59] is this literally a "what launchpad memberships do i have" issue? [18:59] Pricey: not really. [19:00] we are moving towards a hierarchy of operators, channel ops -> core ops -> council (at least from a Launchpad POV) [19:00] ok, shall we have a vote? [19:00] tsimpson: so again, a 'yes' to what i just said? [19:01] [vote] should IRC Council members be added to the core ops team ? [19:01] Please vote on: should IRC Council members be added to the core ops team ?. [19:01] 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 [19:01] E.g. /msg MootBot +1 #ubuntu-meeting [19:02] -1 [19:02] -1 received from jussi01. 0 for, 1 against. 0 have abstained. Count is now -1 [19:02] jussi01: This vote means the individual members of the IRCC team? [19:02] Pricey: the IRCC LP team will be a member (admin) of the core-ops team [19:02] nhandler: correct. [19:02] so an op in all core channels [19:03] as individual members [19:03] I'm glad we spent all that time on this launchpad groups issue. [19:03] -1 [19:03] -1 received from tsimpson. 0 for, 2 against. 0 have abstained. Count is now -2 [19:03] -1 [19:03] Rather than trying to sort out user's concerns with -ops etc. [19:03] -1 received from nhandler. 0 for, 3 against. 0 have abstained. Count is now -3 [19:03] -1 [19:03] -1 received from topyli. 0 for, 4 against. 0 have abstained. Count is now -4 [19:03] we can do it as needed [19:03] [endvote] [19:03] Final result is 0 for, 4 against. 0 abstained. Total: -4 [19:03] That could have been done in private by the IRCC [19:03] its not an issue that involves the community tbh. [19:03] Pricey: we have given extra time to that issue by allowing it to go to the ML. [19:03] It also affects the charter issue [19:03] Pricey: we are aiming for transparency remember [19:04] it could have been read on a log [19:04] * cjohnston hides [19:04] [topic] Discuss the IRC Council Charter [19:04] New Topic: Discuss the IRC Council Charter [19:04] [LINK] https://wiki.ubuntu.com/IRC/IrcCouncil [19:04] LINK received: https://wiki.ubuntu.com/IRC/IrcCouncil [19:05] I have made many changes to this charter based on feedback from many members of the community [19:05] I still don't like that voting line. [19:05] It caused issues in the past. [19:06] The decision shouldn't be dictated by what members voted. [19:06] Pricey: it changed? [19:06] I don't think its good enough [19:06] Pricey: suggestions please? [19:06] "Decisions will be made when a majority of the seated council is in agreement" [19:07] I have no issues with that [19:07] If you have 5 members, you need 3 to agree. [19:07] Pricey: no, I disagree [19:07] jussi01: that rule let us go against elky time and time again. [19:07] because when the cc is slow or something else happens, we dont want voting to happen with just 2, like was the case with Pici and I recently [19:07] jussi01: Decisions weren't made fairly because of the composition of people at meetings. [19:08] Pricey: read it again [19:08]