=== czajkows1i is now known as czajkowski === yofel_ is now known as yofel === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann [18:00] o/ [18:00] hi [18:01] jussi: ikonia: About? [18:01] hi [18:02] moment pls [18:03] Hello [18:04] just waiting on jussi, then I think we can start? [18:05] woo, 2 seconds of lag [18:05] hi all [18:05] howdy [18:05] heyas [18:05] hi, forgot to watch the watch [18:05] right. so who is leading this meeting? Seeker`? [18:06] jussi: fancy using mootbot? My connection appears to be doing strange things [18:06] #startmeeting [18:06] Meeting started at 12:06. The chair is jussi. [18:06] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [18:07] Basically, to start, can we have a clear, concise defintion of the current plans for the core-ops team, as well as confirmation as to whether it is simply a plan, or has it been passed by the IRCC? [18:07] [topic]Basically, to start, can we have a clear, concise defintion of the current plans for the core-ops team, as well as confirmation as to whether it is simply a plan, or has it been passed by the IRCC? [18:07] New Topic: Basically, to start, can we have a clear, concise defintion of the current plans for the core-ops team, as well as confirmation as to whether it is simply a plan, or has it been passed by the IRCC? [18:08] As I understand it, this is something the IRCC had planned last cycle, but havent implemented yet. [18:08] as a council member I'd expect better than "as I understand" [18:08] I want a clear definition of the status [18:09] By planned do you mean "Written a draft" or "agreed upon"? [18:10] And, if it is the latter, when was it agreed upon? (as per my email on wednesday) [18:11] Right. So, it has been agreed upon, last cyle, at UDS. You can find the definition of a core op on: https://wiki.ubuntu.com/IRC/IrcTeam/OperatorRequirements [18:11] Ok. Is there a defintion of the function of a core-op? [18:12] according to that wiki, it's an operator of the core channels, that's it [18:12] Seeker`: inthe document I mentioned I beleive it shows what it is. [18:12] or "a" core channel [18:12] ikonia: well that is it [18:12] "A Core Operator is someone who has operator status in all of the Ubuntu core channels."? [18:12] jussi: so confirm, it is an operator who is an operatin in "a" core channel [18:12] ahh, All of the core channels [18:12] ikonia: no. it is. A Core Operator is someone who has operator status in all of the Ubuntu core channels. [18:13] jussi: then there are no current core ops [18:13] Operators in the the Ubuntu Core operator Team will be required to mentor new operators. [18:13] This means when a new operator is appointed, an Ubuntu Core operator will be assigned to them as a mentor to help, guide and answer any specific questions. [18:13] ikonia: correct. [18:13] ok [18:13] jussi: Is there a good reason for not having all users that are an operator on *A* core channel being given access on *all* core channel? (Possibly after a probation period, as appropriate) [18:14] I suggested that recently... somewhere... [18:14] I forget when and where. [18:15] Seeker`: In my opinion yes. This is what I was so adamant about at UDS. Different channels operate differently, -offtopic is different to #u, Kubuntu channels are different again. I dont think we should be giving every op in one of the core chans access in all of them without thinking if they are suited for the purpose or even want that responsibility [18:16] Seeker`: Some people have access on particular channels, but don't care to be involved in others. [18:16] so then the definition of a core-op is wrong [18:16] well the bottom line is, it would be useful for emergencies (and any op knows an emergency when they see one. but a #ubuntu op won't necessarily know what -devel is like [18:16] ikonia: how so? [18:16] jussi: so, to be clear, someone that is a core-op will have a duty to be intimately familiar with the operation on each and every channel on the core channels list? [18:16] jussi: and, furthermore, is there anyone that currnetly meets that definition? [18:17] Seeker`: that's incorrect [18:17] i would suggest no such duty. they would have ops on all channels so they can aid in emergencies [18:17] jussi: well, it's an operator that has +o in all the core channels, yet you've just said that people can have ops in a core channel but not be suitable for another core channel. So will core channels have core channel ops and non-core channel ops ? [18:18] what you appear to actually be suggesting is 2 teirs, a senior op and a standard op [18:18] ikonia: A Core Operator is someone who has operator status in all of the Ubuntu core channels. [18:18] A Channel Specific Operator is an operator who has access in one or more core channels, but not all. [18:18] topyli: not based on what jussi just said. If the reason that an op can't be given access to all channels is because the channels operate differently, a core-op will have to understand the operation of each of the core channels before they can be given the core-op status. [18:19] ok, lets step back [18:19] Now, May I point you all to read my email to the list about 1/2 hour ago, as it affects this situation. [18:19] we have different [topics] here, Seeker` [18:19] 1.) are the council all in agreement of what a core op is [18:19] yes/no [18:19] Seeker`: I have +o on some channels. I have no interest in it being global. [18:19] ScottK: you don't have to use +o on channels that you don't want to. [18:20] Seeker`: That's correct. It's nothing to do with needing to learn stuff. [18:20] ikonia: as documented on the wiki, yes [18:20] topyli: agreed. [18:20] topyli: ok, so the definition on the wiki is all 5 members agreement of a core op [18:20] excellent, that's one thing clarified [18:20] But I'm not sure I *like* the current incarnation. [18:21] jussi: I don't see anything that directly affects the definition or duties of a core op in that email, just what channels people are expected to hang out in. [18:21] Pici: noted, but with al 5 of you agreeing on what a core op is, is there a reason this hasn't been implemented/started [18:21] Seeker`: I dont see a need for "core ops". In that definition, there are no core chans, and no core ops. [18:22] ikonia: Its been about how you become a core op (form my perspective) [18:22] jussi: how do you ? [18:23] jussi: your email only says that the scope of -ops is extended across the namespace, not that the current, agreed upon definition of a core op will go away. [18:23] ikonia: you abpply to the ircc. However, Im talking about the criteria required for us to say yes. [18:23] Both types of operators are required to follow the requirements set out in this document. The process to become a Core Operator is the same as for a Channel Specific Operator, except for the following: [18:23] To apply to become a Core Operator, you must first be an active operator in one, or more, of the core channels. [18:24] jussi: ok, so this is anothe application thing [18:24] jussi: do core-ops have to be intimately familiar with the operation in each and every one of the core channels? yes or no? [18:25] The culture in all the core channels should be the same if they all follow the same set of guidelines. [18:25] In my opinion the basic definition of a core op is defined, but not the full expectations and responsibilities. [18:25] IdleOne: the culture of all channels within the ubuntu name space should be the sanme [18:25] jussi: Just to be clear: This isn't the only way one can become a channel op. I don't think Kubuntu gave away it's ability to appoint ops when they let the IRCC in. [18:25] ikonia: agreed [18:25] ScottK: thats correct. [18:26] so that would mean that any op from any channel should be able to op in any other channel. [18:26] OK. [18:26] ScottK: then that makes a joke of the recruitment processs [18:26] Seeker`: do you want my opinion or the ircc? [18:26] jussi: the ircc. [18:26] Is this the IRCC meeting? [18:26] ScottK: to become an op you have to go through the recruitment process [18:26] yes [18:26] it is? [18:26] I have applied to be an op for #ubuntu and #ubuntu-offtopic [18:26] ikonia: I'm not required to care. Kubuntu Council gave IRCC access to Kubuntu channels and can take it away if IRCC interferes too much. [18:26] Seeker`: thats an unanswerable question givent your format of answers. [18:27] ScottK: then the goverence is broken [18:27] bilalakhtar: this meeting is not for approving ops. [18:27] ScottK: not that I disagree, but this is pointless process [18:27] ikonia: I'm fine with going back to the old way where Kubuntu ran it's old channels. [18:27] ikonia: the IRCC can't go stepping over other councils, and we don't intend to [18:27] you have to go through th process of becoming an op, unless you don't want to in which case the kubuntu team can just pick you [18:27] old/own [18:27] jussi: it isn't an question that can have any other answer than yes or no. Either you have to be intimately familiar with the operaiton of every channel on the list or you dont [18:27] tsimpson: yes it can [18:27] tsimpson: you ARE responsible for the name space [18:27] no, it can't [18:27] take responsability for the channels, or remove them from the name space [18:27] Both councils should respect each other. [18:28] kubuntu is the project, not the IRC ] [18:28] either it complys with the ubuntu council's IRC policy or there is no point [18:28] jussi: which is it? [18:28] ikonia: No problem. We'll move to OFTC. We've done it before. [18:28] ScottK: I'm not calling you for it at all, i just don't see the point of having an IRC council running the channels....unless other don't want it to [18:28] Hold on, this is not about pushing any part of the community away [18:29] it is either responsible for the namespace, or it's not [18:29] no, Kubuntu should not have to move to OFTC. I think it's perfectly acceptable the the IRCC and Kubuntu council can work together [18:29] Seeker`: nobody is going to answer such a question now [18:29] topyli: why not? [18:29] tsimpson: I agree. [18:29] Seeker`: neither. its undecided. [18:29] tsimpson: it's not working together [18:29] tsimpson: it's following the process, unless it doesn't want to [18:29] jussi: So over 6 months after the term was agreed upon, the conditions of gaining the position still haven't been defined? [18:30] Do you not think that is in the least bit ridiculous? [18:30] ikonia: ok, so we can have #kubuntu--*, but there will be no Kubuntu people there, great [18:30] Yes. I think its very ridiculous. And I think that we need to get back on the horse. [18:30] tsimpson: well, what's the point of having the council if the kubuntu community can ignore it [18:30] tsimpson: so you have a channel that does what it wants "great" [18:31] ikonia: We need to work together. Just like the other Ubuntu teams do. We're not in charge of them and they're not in charge of us. [18:31] ikonia: no, we work together. not because we impose restriction on each other, but because we choose to co-operate [18:31] Pici: but you are defining policies that can be ignored [18:31] what's the point ? [18:31] jussi: ok, at the moment there are core-channels and non-core channels. non-core channels (generally loco channels) are responsible for appointing their own ops, whereas core channels are done by the ircc. How will the appointing of ops be managed without the distinction between core and non-core channels? Will the IRCC be responsible for appointing loco ops? [18:31] i'm unable to follow this. what's the topic? [18:32] we go through weeks of definingin this pointless recruitemnt proces that cannot be broke, oooh...unless kubuntu wants to [18:32] topyli: my fault, sorry - I'll shut up, but I will raise and progress this [18:32] have we established what a core op is? i think we have. can we have another topic? [18:33] have we established what a core channel is? [18:33] topyli: We have estabilished that a core op in an op in all core channels. Thats about it [18:33] http://www.youtube.com/watch?v=AU9-TRVbhkE [18:33] IdleOne: yes [18:33] LINK received: http://www.youtube.com/watch?v=AU9-TRVbhkE [18:33] Seeker`: ok [18:33] Seeker`: No. But we can work with the Loco Council if we think an operator should be removed? [18:33] er, -? [18:33] IdleOne: yes [18:34] SPooN: if thats your participation in a meeting - don't speak again [18:34] SPooN: Seriously? You're spamming a link in a meeting of IRC operators? [18:34] SPooN: this is supposed to be a meeting and you pointing stupid links is crazy and not wewlcome [18:34] welcome [18:34] Pici: So how do you define which channels the IRCC is responsible for appointing ops in without the core-channel definition? [18:34] ikonia, Pici: definition of spamming. [18:35] SPooN: stop now, your doing other ubuntu channels, stop it [18:35] jussi: ^ [18:35] you're? [18:35] remove him please [18:35] ok. [18:36] jussi: So how do you define which channels the IRCC is responsible for appointing ops in without the core-channel definition? [18:36] I was under the impression that there was a core channel definition. [18:36] there is [18:36] there is [18:36] -18:21:54- :jussi : Seeker`: I dont see a need for "core ops". In that definition, there are no core chans, and no core ops. [18:36] https://wiki.ubuntu.com/IRC/IrcTeam/Scope [18:36] ages old, and way out of scope of this meeting [18:36] Which channels are core-channels? [18:36] [LINK] https://wiki.ubuntu.com/IRC/IrcTeam/Scope [18:36] LINK received: https://wiki.ubuntu.com/IRC/IrcTeam/Scope [18:36] Pici: I'm asing jussi about the propsal he sent to the list [18:36] Just because IRCC has authority does not necessarily mean they are the sole authority. That's OK. [18:37] but he seems to have gone quiet [18:37] Sorry, had to zip off to the WC. [18:37] ScottK: I don't disagree, but if you can bypass the processes that are carved in blood because you want to, it makes a mockery of it, however that's not for this meeting, I'll raise it with the council seperatly [18:38] ikonia: It's with the Kubuntu Council's permission that the IRCC has any authority in Kubuntu channels. [18:39] ScottK: fully understood, I'll raise it and keep you in the loop [18:39] ScottK: i don't think breaking up our namespace is on the agenda right now [18:39] I must leave, apologies [18:39] topyli: It is if IRCC insists that in core channels it owns the only process for approving channel ops. [18:40] Seeker`: please differentiate that proposal from something coming from the IRCC - That one is my ideas. Now, about the IRCC's appointing of ops, Im not exactly sure right now - this is afterall a proposal. I have chatted about it with several people, but I havent yet cleared that exactly in my mind. [18:41] I would like to make a proposal for a change to the definition of a core-op. Please read http://pastebin.com/mM4Rqvp7 [18:42] Seeker`: That proposal hasn't been agreed on or voted on by the IRCC. [18:42] Or, rather, an elaboration of the purpose of a core op. [18:42] WHich seems to be, as yet, undefined. [18:42] Seeker`: to that I strongly disagree. Which seems to be the issue here. [18:43] jussi: which part do you strongly disagree with? Because the people won't be intimately familiar with the operation of all channels? At present, we can have users sitting there spamming porn and swearing in a channel, and there is nothing we can do about it because there aren't the right ops active. That doesn't come down to channel-specific discresion, it is clearly wrong. [18:44] If core-ops start abusing the system, people will complain. At which point, the IRCC can reassess their suitability to be an op. If noone abuses it, it isn't a problem. [18:44] Seeker`: then we need to recruit more ops for the channels, not dump ops on a few people across a lot of channels. [18:45] remember, in the case of core-ops. one would have to already be an op in a core channel before becoming a core-op [18:45] jussi: That may be true, but I think Seeker`'s proposal would help now until we have more. [18:45] jussi: however many you recruit there will still be occasions where noone is active, unless literally everyone has +o. [18:46] there will likely still be occasions where no one is active, even if everyone has +o [18:46] I like parts of Seeker's suggestion, but I don't think that anyone would apply to become an operator of another channel if they already have +o there. [18:46] for various reasons [18:46] Seeker`: in which case we have the ircc and freenode staff [18:47] jussi: is the ircc always about? Why do we need to call staff when we have a channel full of ops? Are staff more trusted to understand the operation of channels than ops are? [18:47] you just said all the ops were inactive at this point [18:48] topyli: all of the ops that have +o in that channel [18:48] I think it was made clear that in "emergency cases" one would not need to be familiar with the inner-social-workings of a channel [18:48] Seeker`: then the ircc and staff are the next stop [18:48] I have a question. [18:48] (lacking core ops) [18:48] We shouldn't be relying on staff to police the channels, especially when there are people active that the IRCC has judged to be suitible ops [18:49] It isn't staff's job to op our channels for us [18:49] uh, agreed. they handle the whole network [18:49] (which our channels happen to be on) [18:50] so we should remove staff access from our channels, as it's not their job to act in there? [18:50] topyli: As i understand it, they aren't responsible for the running of individual channels. They are there to stop network trolls [18:50] Seeker`: thats right. But they are there on the access list in case of emergencies - as I beleive they suggest on their website [18:50] part of the job for staff is acting in emergencies when no channel ops are available, and they have access [18:50] Seeker`: exactly. now how does this discussion advance our core ops issue? [18:51] tsimpson: we should give the current ops access in the core-channels in case there is a need. [18:51] * Pici sighs [18:51] topyli: Because the exact job of a core-op, or how they are selected, is undefined, and it needs to be defined. [18:51] IdleOne: but when if no ops are available then? [18:51] instead of hoping that there is a staff member [18:51] tsimpson: Then, in that case you call staff [18:51] Seeker`: now you're talking [18:51] Pici: don't ask to ask, just ask ;( [18:51] tsimpson: staff goes idle at time also, then what? [18:51] tsimpson: why bother having ops at all? Just call staff? [18:52] Can we please try to actually make some progress this meeting? [18:52] IdleOne: exactly, we're not going to "fix" the issue of there sometimes being no one available to act [18:52] LjL: I gave up on that question. [18:52] even if we have everyone on the access list [18:52] the point here is that there is a large pool of ops and it is under utilized. [18:52] i'm going for a smoke [18:52] * LjL huggles Pici [18:53] Ok, so does the IRCC not trust the ops they have chosen? Are they not convinced of their ability to make reliable judgements? [18:53] I sit idle in most of the core-channels anyway and willing to sit in more channels if needed but my being there and not being able to act in an emergency is a waste of tools [18:54] Anyone on the IRCC care to answer? [18:54] If you trust us, give us ops in all core channels, if not, why do we have +o in any core channels? [18:54] I personally agree. But I think I'm a minority here. [18:55] tsimpson: jussi: topyli? [18:55] Either we come up with a decision here or we're back where we started. [18:55] Seeker`: that question is moot. the council chooses ops they trust [18:55] topyli: so why not trust them to have +o in all core channels? [18:55] So we should be trusted to use our judgment in an emergency [18:55] Seeker`: is that a suggestion? [18:56] becasue i'd like one [18:56] topyli: you saw my proposal? [18:56] I'll suggest it. [18:56] ok let's set a topic and discuss [18:56] Pici: please suggest it clearly so we have it on the record. [18:56] just so there is no confusion [18:57] so far i have seen one, all-encompassing, topic, later learned that this is an ircc meeting (?), and understood very little of the rest [18:57] During their probationary period operators should only have access in one channel. When that period ends, and the IRCC are in agreement, the operator receives access in all the core channels. [18:57] +1 [18:57] +1 [18:57] I strongly disagree with this proposal [18:57] a probabtion of 3 months should be long enough to decide [18:57] -1 [18:57] jussi: in one line, on what grounds? [18:58] same to topyli [18:58] I'd like to hear suggestions for improvement if you disagree. [18:59] if we are considering it, then how about we break it up a little? ie: Ubuntu ops, Kubuntu ops, etc [18:59] (just another suggestion) [18:59] we'll have a better chance of recruiting any ops at all if we pick people who know a channel well and appoint them there [18:59] Seeker`: channels are different. different things are "emergencies". Alternate proposal "if" we have core-ops, then the current format "core ops apply, ircc approves" [18:59] clearly there is an asymmetry between hiring and firing ops. Hiring is easy, removing is many layers of hassle and emotional tumult. Unless we are suggesting the IRCC is omniscient, there are obviously bad ops. Not letting everyone have ops in all channels minimises this [18:59] LjL: this too. [19:00] LjL: that is the purpose of the probation period. If somene isn't suitable for +o in all channels, they shouldn't have it in any. [19:00] if they are "bad ops" remove the status. [19:00] Then break -offtopic operators into another group. [19:00] It does seem a bit odd that -offtopic is in the definition of core. [19:00] Those are the only channels where I feel that the operator/user interaction is different. [19:00] Pici: that could have merit [19:00] Pici: and #kubuntu-* ? and the devel chans? [19:00] topyli: If someone is capable of opping one core channel, they should be capable of doing it in all of them [19:01] Seeker`: i disagree [19:01] ScottK: all that means is that the IRCC manages it, rather than it being another "team" of people [19:01] jussi: and what will determine whether someone becomes a core-op or not? [19:01] jussi: What about them? [19:02] jussi: I would bundle -devel type channel in generally [19:02] there are at least three distinctive types of channels. devel, support, ot [19:02] jussi: Do you really think that we handle things differently in #u, compared to #k or #u-devel ? [19:02] topyli: what would make someone suitable for opping one channel and not another? [19:02] I suspect most developers would rather want to develop than worry about IRC management [19:03] Pici: #u is different from #k, yes [19:03] tsimpson: Can you explain why? [19:04] Pici: for instance, the rules absolutely must be applied in #u, as it is so busy any disruption is felt. that's not the case in #k [19:04] So it's ok time to time for someone to swear in #k? [19:04] no [19:05] but a line or two of offtopic chatter is not as disruptive in #k as it is in #u [19:05] ok but +o in an emergency does not include a little offtopic chatter [19:05] so there are people with +o in some channels they aren't capable of determining whether something is disrupting the channel or not? [19:06] If so, are they really capable ops? [19:06] I consider an emergency something like, racism, excessive swearing, links to porn.... [19:07] even when a channel appears to be idle for a long period [19:07] that sort of stuff is unacceptable [19:07] It seems that most of the IRCC has strongly disagreed, then ran away [19:08] an emergency force would be good, and core ops would be good for that. i think the question is now, should everybody be core then? [19:09] it does lead to having lots of ops who are never there. is this bad? i don't know [19:09] I get the feeling that the IRCC doesn't actually trust the ops they have, or their own ability to appoint ops that they trust in the future. Not giving people +o in channels because staff exist isn't a good reason for not giving them +o; It is making decisions about running the namespace because there is some sort of backup in the form of an external entitiy, and not relying on people who have volunteered and wish to help ubuntu. Don't give peop [19:09] I don't think so. it leads to having more ops who can respond if needed [19:09] we would also have lots of idlers with +o who don't know the culture. is this bad? perhaps [19:10] Seeker`: the council currently nominates people for -ot ops who they trust to be able to work -ot [19:11] topyli: a capable op is able to look at a situation and the channel and determine an appropriate action. If someone isn't capable of reading a situation sufficiently well that they can't do it in more than one channel then they are good ops [19:11] bad example, as the channel is possibly one of trickiest :) [19:11] It should be clear to ops if a topic is causing discomfort to the users of the channel [19:11] in your dreamworld [19:12] i would like it to be clear too. however, i'm afraid it is not [19:12] I'm not suggesting that peopel be given core-ops status so they can just run around with a banhammer. If something gets to the point wher epeople go searching for ops, then the situation needs to be at least looked at. [19:13] If the situation is borderline, people already familiar with the ubuntu namespace opping would be better placed to make a decision than staff [19:13] i still think emergencies might be the lowest common denominator which we could talk about. those are actually identifiable [19:14] Ive spoken to a staffer and : when staff already idle in most of the big channels, poking them about a troll/spammer when no OPs are around is perfectly acceptable and done all the time [19:14] So you are completely against adding another layer of security? [19:14] except in the case of applying for core-op status [19:14] jussi: the fact that staff exist is not a good reason for not giving more people +o. [19:15] jussi: As staff exist, do you even need more than 1 op? Or maybe just the IRCC? [19:15] Seeker`: and I totally agree with giving more people +o, but with the process of certain channels, not just lumping it on everyone [19:15] agreed. however, i don't think we should define core ops as the sum of core channel operators [19:16] jussi: if people don't want to +o in a channel, they don't have to [19:16] jussi: but at least that way, all operators will have the option to. [19:16] Seeker`: wait, is that all operators or all core channel operators? [19:16] jussi: your arguments at the moment stink of "We don't trust the ops" [19:16] topyli: all core-channel operators [19:17] right [19:18] core channel operators should have a better idea of where exactly the line is, even on channels that they raen't usually active on, meaning that they can take more appropriate action to that channel than staff can, which is more like using a canon to kill a spider. core channel ops are probably more likely to take the time to catalyse with a potential problem user than staff will. [19:19] Seeker`: so you basically share Pici's proposal (or Pici reprhased yours, i don't know). core channel ops are core ops, and they have +o on all core channels (after probation). correct? [19:19] topyli: yes. [19:19] Seeker`: its similar to the upload rights. if a person applies for per package upload, should we just give him access to all of universe and main? no! if a person wants access to main, they need to apply. same goes here. its not that we dont trust the ops, just that the ops need to apply and be approved, not just lumped across the whole load of channels. [19:20] Why do they need to apply? [19:20] The arguments against this proposal I've seen are 1) Staff exist and 2) Not everyone understands all of the channels. Based on argument 2, staff should not be given access to all core channels, because they don't understand the ins-and-outs of each channel. [19:20] and it isn't a whole load of channels. it's 8-9 channels [19:20] there is a difference between access and emergency-access [19:21] 14 channels sorry [19:21] channels are there own little community [19:21] Either "staff exist" is a valid argument, which means that concerns about people not understanding channels is an invalid argument, or the opposite. Pick one. [19:22] no, no [19:22] there is a difference between access and emergency-access [19:22] i agree with jussi that it should not be automatic. people should apply for core op status so 1) they show interest and commitment, and 2) to make the ircc aware and force them to review the applicant [19:22] My assertion is that core-channel ops will have a better understanding of the channels and will therefore be able to make better decisions than staff in more borderline cases [19:23] that doesn't mean it has to be hard to get core op rights [19:23] topyli: there shouldn't be two standards for ops. [19:23] topyli: you shouldn't have "ok ops" and "good ops", you should only have "good ops" [19:23] How would you then define who has "emergency access" and who are the regular chanops? [19:23] there should be a process, for the reasons i named there [19:23] Or you will have two standards enforced on all of the channels [19:23] channel ops come from that channel, that community. they are active there and people see and know them [19:23] jussi: a wiki page? [19:23] no. access is access [19:23] Then we need to come up with a real process. [19:24] Saying that 'people can apply' isn't a process. [19:24] topyli: you've had 6 months to come up with a process and failed. [19:24] creating an LP team and applying for membership is process enough [19:24] jussi: giving all core channel ops +o on all core channels and having a wiki page is easier than maintaining different access lists on each channel. [19:25] Seeker`: it has not been very urgent apparently [19:25] topyli: so it never gets done until it is urgent? [19:25] Seeker`: we work in urgent things before non-urgent things [19:25] Seeker`: well someone has to think it's necessary [19:25] (now) [19:25] topyli: If it isn't necessary, why defined the term int he first place [19:26] "Lets think up a term and define it, just in case someone thinks we might need it at some point in the future"? [19:26] Seeker`: as you said, that's not what happened [19:26] If a job needs to be done, get on with it, if it doesn't then stop giving yourselves more work to do. [19:26] back then the idea was to create a midlevel team just like the one you seem to want [19:27] topyli: I don't want a mid-level team. I want all core-channel ops to have the same level of access. [19:27] ok so you have a different idea. you want the original modified [19:27] Same level of technical access that is. Social issues are different, and there should be a social solution to them. [19:27] again, access is access [19:29] technically, yes. But we have all sorts of social constructs round access. These are currently too complicated or not implemented. I am pushing for a simplified set of social rules around access, while providing better coverage in channels with the existing pool of ops [19:29] Seeker`: i have to go. could you add the issue (something like pici formulated there ^ or my version, or your own version) and add it to next meeting's agenda? [19:29] I need to go, my wife is just home and I have other hings to attend to [19:30] and please make it fathomable :) [19:30] I suggested it over an hour ago, and we havent maanged to get anywhere [19:30] its just jussi saying "I DISAGREE BECAUSE I'M RIGHT" and then disappearing for 10 mins [19:30] Seeker`: I don't think that's appropriate [19:30] and "we trust all of the ops, but not enough to give them +o on all core channels and not abuse it" [19:30] we have not. i think we have some sort of proposal that might be discussable. that's huge progress over what we had an hour ago [19:30] and "we need more processes" [19:31] Seeker`: would you do it then? [19:31] topyli: I made the same proposal at the UDS meeting two weeks ago. [19:31] frankly, i haven't seen a proposal, i have seen rants. the one from 15 minutes ago is better. let's continue from there [19:31] There wasn;t any progress then [19:31] and there wasn't any tonight [19:32] -18:41:55- : Seeker` : I would like to make a proposal for a change to the definition of a core-op. Please read http://pastebin.com/mM4Rqvp7 [19:32] 50 minutes ago. [19:32] there is no process going ahead right now, we have not decided to implement anything [19:32] we'll consider your proposal [19:33] ... [19:33] I thought we already considered it. [19:33] And we started a vote, and two people voted no. [19:33] I don't feel that jussi or topyli will, because they have stated from the time they saw the proposal that they disagree, have just been presenting the same argument over and over again, without listening to other members of the IRCC, or any of the op team that they are meant to represent and support. [19:33] Then we went off track. [19:33] what was the decision? [19:33] i only understood it about 15 minutes ago [19:33] I don't know. [19:34] Pici: i must have missed that part [19:34] They are more interested in building up complexity and process in a council that is already sluggish and unwieldy. [19:35] And I asked for suggestions on how to fix it and we never got a concrete answer. [19:35] Seeker`: if they disagree, it is their right to do so [19:36] And taking over 6 months for a descision for an environment that is based entirely around real-time interation is stupid [19:36] tsimpson: But they aren't listening to reason, or the people they are supposed to represent [19:36] in your opinion [19:36] I've had countless PMs saying "I agree with you" and noone saying "You are wrong", apart from members of the IRCC [19:37] Seeker`: The IRCC needs to represent all of Ubuntu IRC users and not just Ops. [19:37] ScottK: Right now they are doing a whole lot of support for the users and none for the ops. I don't feel supported by the IRCC at all. [19:38] Seeker`: OK, but I disagree with your statement that the purpose of the IRCC is to support ops. [19:38] Every attempt by an operator to make prgress on a topic, or get a resolution is met by "Well, we made this decision over 6 months ago, it isn't implemented yet" or "We haven't had time", or various other non-actions [19:38]