=== asac_ is now known as asac === pak33m|cuposoul is now known as pak33m === swoody_ is now known as swoody [07:59] Good morning all! [08:00] * Pici yawns [08:00] if you say so :) [08:00] Allo [08:00] ooh, we are all here! :D excellent! [08:02] can someone start up mootbot? [08:02] #startmeeting [08:02] Meeting started at 02:02. The chair is Pricey. [08:02] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [08:03] * Hobbsee waves [08:03] [link] https://wiki.ubuntu.com/IrcTeam/IrcCouncil/MeetingAgenda [08:03] LINK received: https://wiki.ubuntu.com/IrcTeam/IrcCouncil/MeetingAgenda [08:03] I guess we'll start at the start? [08:03] why not? [08:03] :D [08:04] Sounds logical [08:04] [topic [08:04] [topic] Criteria for +v in #ubuntu-ops and the future and function of the IRC team [08:04] New Topic: Criteria for +v in #ubuntu-ops and the future and function of the IRC team [08:05] Currently there is a rather haphazard way of adding people to the voiced (+v) operator list in #ubuntu-ops. We need to have a uniform and standardized proceedure for eligibility for +v in #ubuntu-ops. The purpose of +v is to show users who are operators in the channels that #ubuntu-ops covers, to understand who can deal with their query. [08:05] Therefore, in my understanding, an operator in one of the core channels, that are managed by the ubuntu-irc team and come under the scope of #ubuntu-ops, should have +v in that channel. All others should not be permitted under the no idle rule. [08:05] Thoughts? [08:06] To slightly add to that, myrtt asked about how that works for freenode staff. [08:06] myrtti [08:06] Do we have a list of 'core channels' anywhere? [08:07] I was just going to ask that as well. [08:07] staff have access in our "core channels", so get +v (IMO) [08:07] Pricey: I dont beleive so. perhaps that needs to be defined? [08:08] I think it would help. [08:09] most/all the channels under "Support and talk channels" (https://help.ubuntu.com/community/InternetRelayChat) should be "core", right? [08:09] there are others though, like -devel channels [08:09] I think the -team channel should be core as well though. [08:10] I don't agree with all. [08:10] how does #ubuntustudio-* incorporate? (or does it at all?) [08:11] nalioth: whats your opinion? [08:12] i'm here! [08:12] elky: great. [08:12] i thought the loco teams were not considered "core channels" [08:12] nalioth: +1 [08:12] nalioth, they never have been. unless extenuating circumstances such as becoming havens for misbehaviour, they've always been left to their own devices. [08:14] We have #ubuntu-irc for loco channels, would anything else fall under -core channels or are we just going to have to cherrypick from what we currently have access to? [08:14] #ubuntustudio has a forward from #ubuntu-studio, but is not "officially" supported by Canonical [08:14] i think if we overcatagorise, it's only going to become more confusing and less useful [08:15] nalioth: as I understand it, Ubuntu studio has similar if not same status as xubuntu. [08:15] i see -irc as being "team channels" rather than "core channels", so not even limited to "loco" [08:15] elky: I had the same feeling. [08:16] main derivative channels though, are something beyond "team" though, imho. [08:17] I guess "core" should be (official)-variant support/devel/offtopic [08:18] tsimpson: that sounds sane. however, define official. [08:18] tsimpson: aside from (official)-[country code]* [08:18] canonical official [08:18] -devel ? [08:18] "(official)-[country code]*" is loco, which we all seem to agree is -irc [08:19] Pricey: yes [08:19] So something along the lines of http://www.ubuntu.com/products/whatisubuntu/derivatives - officially supported + recognized? [08:20] Are they not looking after themseles? [08:20] which? [08:20] -devel [08:20] * Hobbsee wonders how ubuntu netbook remix fits into all of this [08:21] Pricey: we're not here to decide who "looks after themselves", but which channels are 'core channels' for the purposes of having an op presence in -ops [08:21] -devel tends to look after itself (please poke myself or others on the ops list around and we'll drop into -ops) [08:21] oh but they can 'stay' in -ops... [08:21] okies [08:21] UNR doesn't have its own support channel afaik. [08:22] or, alternately, the "canonical sponsored" list here: https://wiki.ubuntu.com/DerivativeTeam/Derivatives [08:22] Pici: does for Kubuntu [08:22] Oh? [08:22] or is that just devel.. [08:22] tsimpson: just devel afaik [08:23] yes, the wiki agrees :) [08:24] ok, so lets try get a resolution here? are we using the list here: https://wiki.ubuntu.com/DerivativeTeam/Derivatives (sponsored) or here http://www.ubuntu.com/products/whatisubuntu/derivatives (supported + recognized) ? [08:25] so.. $officiallysupported-[devel|offtopic] and #ubuntu+1? [08:25] is the /Derivatives list current... i mean, are all those still active derivs? [08:26] elky: gobuntu an jeos are the only 2 Im not certain about [08:26] Pici, what about if derivs want us to manage more than just that for them, though? [08:26] jussi01, which is why it's worth clarifying [08:27] or not do anything at all [08:27] elky: Sounds like they should be in -irc then [08:29] Ok, my proposal is to go with the list on http://www.ubuntu.com/products/whatisubuntu/derivatives - thoughts? [08:29] I would side with the officially supported and recognize [08:29] Could we write down our own separate list. [08:29] i agree with jussi01 [08:30] copying that one if necessary [08:30] Pricey: do you feel something is missing from that list? [08:30] jussi01: no no, just we are in control of a list we write ourselves. [08:31] "core" should be clearly defined under the team wiki somewhere, if only for reference [08:31] tsimpson: agreed. [08:31] Can we get something written down and then we can all agree on it at some point? But for now move on as we have a general idea of what we want? [08:32] I think maybe if we say something like: the list on http://www.ubuntu.com/products/whatisubuntu/derivatives + others under the IRCC discretion. [08:32] Pricey: that list jussi01 linked to is 'what we want'. we are not responsible for non-official *buntu deriviatives [08:33] Pricey: can we at least agree on the concept that +v is given to core channels ops, (in -ops), with a core channel list to be defined? [08:33] hmm, what will happen to those ops that now have +v, but aren't ops in core channels? [08:34] we'll move them to -irc [08:34] [VOTE] +v is given to core channels ops, (in -ops), with a core channel list to be defined, those with +v now but that don't match will be moved to -irc [08:34] Please vote on: +v is given to core channels ops, (in -ops), with a core channel list to be defined, those with +v now but that don't match will be moved to -irc. [08:34] 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 [08:34] E.g. /msg MootBot +1 #ubuntu-meeting [08:35] council please [08:35] +1 [08:35] +1 received from elky. 1 for, 0 against. 0 have abstained. Count is now 1 [08:35] +1 [08:35] +1 received from Pricey. 2 for, 0 against. 0 have abstained. Count is now 2 [08:35] +1 [08:35] +1 received from jussi01. 3 for, 0 against. 0 have abstained. Count is now 3 [08:35] +1 [08:35] +1 received from nalioth. 4 for, 0 against. 0 have abstained. Count is now 4 [08:35] Pici? [08:35] +1 [08:35] +1 received from Pici. 5 for, 0 against. 0 have abstained. Count is now 5 [08:36] [endvote] [08:36] Final result is 5 for, 0 against. 0 abstained. Total: 5 [08:36] funky stuff [08:36] Anything else or shall we move onto the next one? [08:36] Pricey: 1 min [08:37] Pricey: I kinda included this under the same subject on the agenda, but I wanted to talk about implementing a simialr system in -irc. [08:37] Currently there is an issue with finding operators from the loco channels when a problem arises, and is asked about in #ubuntu-irc. I propose we implement a similar system in #ubuntu-irc, so as operators from the loco channels are easily recognized and able to be found in a simple and timely manner. [08:38] maybe make it a new topic? [08:39] sounds sensible [08:39] Only thing is, again, how do we define the chans for -irc? [08:39] [topic] issue with finding operators from the loco channels when a problem arises [08:39] New Topic: issue with finding operators from the loco channels when a problem arises [08:40] Yeah I think that's too complicated and overreaching. You can ask for general help there, there's still /msg chanserv help access [08:41] jussi01: [officially supported channel] - [country code] is gonna be the majority membership. Any channel not falling under the [core *buntu* channels] banner would also fall under -irc [08:41] I think the main problem is going to be figuring out who has access in the channels that -irc is supposed to be for and having someone maintain that list for +v [08:41] I'm not sure how +v would help when looking for, eg, an -es op [08:41] this is true [08:42] tsimpson: #ubuntu-es ops might wish to add a highlight for "#ubuntu-es" in -irc [08:42] perhaps we should be encouraging that on the wiki also [08:42] nalioth: sure, but them having +v in -irc or not, won't help much [08:43] and then the requesting user can be assured (seeing the +v) that it is an operator they're speaking with [08:44] My concern still stands. [08:44] They should be able to find that out from /msg chanserv access [08:45] its going to be quite a huge list also. [08:45] I think we need something, but maybe +v isnt it. perhaps one to go think on? [08:46] Unless we have some automated way of maintaning that, I don't want to be the one to have to go through and add/remove access for it. [08:46] looking at an access list doesn't necessarily show all ops, what if an op is using a grouped nick? [08:46] (eg: me) [08:47] -irc isn't really used that much anyway, and was created for the loco ops to mingle rather than user queries? [08:49] We'll think about that a bit more and get back to it unless anyone has anything to add quickly. [08:50] Agreed. [08:50] [topic] Modes in/proper usage of the #ubuntu-irc-council channel [08:50] New Topic: Modes in/proper usage of the #ubuntu-irc-council channel [08:50] The IRCC has a dispute resolution channel called #ubuntu-irc-council. The proposal is that this is a moderated channel, with the IRCC voiced, as well as any relevant parties to the dispute resolution process. If a person needs voice, this will be actioned by a council member. It will be an idle-able channel, with logbots for transparency. [08:51] I'm not sure if moderation is needed all the time? [08:51] or needed [08:51] If its +m how do we know who needs voice? [08:51] Pici: +z [08:51] they let us know in -ops [08:51] or pm [08:51] Keep council +v if necessary to distinguish us. [08:52] Pricey: that sounds like a good solution to me [08:52] Doesn't seem right to stop people speaking to us until we're ready. [08:52] Pricey: so your proposal is have is in sleeping state similar to -ops and +m when needed, like described above? [08:52] Sure. [08:53] If there's someone we don't want part of some procedure, we get rid of them. [08:53] it imght be an idleable channel, but it's not a chatter channel. [08:53] idleable? [08:53] if it's 'idleable', it's gonna gain chatterboxes [08:53] Yes, it needs not have a no idle policy [08:53] idleable and unmoderated, tha tis [08:53] nalioth, then we're no better off than we are with just -m [08:53] we need to have the process transparent and see-able [08:53] it just adds another level of complication and another channel I have to watch [08:54] i personally think that it should be idleable but +m [08:54] No idle unless theres something being discussed. [08:54] -ops is transparent, with the log bot, but we don't allow idlers [08:54] tsimpson, yes, to avoid audience trolling [08:54] What are the benefits f +m? [08:55] Although if someone wants to get in touch with the IRCC, currently they need to go to the mailing list. [08:55] surely if irc-c is idleable, you'll get the same [08:55] tsimpson: not if it's +m [08:55] Pricey: as elky mentioned, avoid audience trolling. [08:55] or am I being overly paranoid [08:55] Pici, that's so that it's archived in a manner that doesnt involve searching through irc logs, and that frankly sucks badly [08:56] jussi01: can we not just +m when necessary? [08:56] oh, pricey, did you see that new Aston Martin on High street today? oops this isn't a chat channel [08:57] nalioth: no idle policy means they shouldn't be idling in there anyway [08:57] Pricey: the thing is the shouldnt be a no idle policy [08:57] we have a 'no idle' channel now [08:57] i would like 'drive by' comments [08:57] if you have an unmoderated channel that's just for irc council people, and the person with the issue, and will silence anyone else from talking, what does that actually gain you from the current situation, where you can silence those who you don't want talking anyway? [08:57] what concerns me is the possibility of trolls idling there for the purpose of making the resolution process hard. [08:58] Hobbsee: the point is then there can be observers, in real time to the process [08:58] elky: there's n idle policy, so get rid of them [08:58] sorry :( [08:58] Pricey, i thought #u-irc-c was idleable though [08:59] Pricey: but thats the verything thats proposed, to remove the no idle policy [08:59] Pricey: #ubuntu-irc-council was supposed to be idleable [08:59] oh right k [08:59] jussi01: but they can be in -ops anyway. It appears to be so close in function that you gain very little? [09:00] Hobbsee, i agree, it seems like bureaucracy for bureaucracy sake [09:01] Yep I'm not sure about it then. [09:01] it would make sense to have a channel like the original proposal, to mirror the mailing list procedures [09:01] ok, if I can re outline the idea. the -irc-council channel is supposed to be for dispute resolution, not just between ops/users, but ops/ops also. [09:01] how would the person with the issue react to having an audience? [09:01] as in, moderate the lot. I can see how that hjas gain [09:01] -j [09:01] as they are likely in a "heated" state to start with [09:02] tsimpson: the same as if they knew the logs were publically viewable, i expect. [09:02] tsimpson: if the audience was not able to talk [09:02] Hobbsee, the logs would be publicly viewable [09:02] elky: precisely [09:02] the logs for -ops are already publicly viewable [09:03] indeed [09:03] is the council mailing list publicly viewable? [09:03] no [09:03] or i hope not [09:03] ops/ops? [09:03] tsimpson, no, people make confidential accusations [09:04] Pricey: is that used to resolve issues with 3rd parties though? [09:04] the idea of the proposal, is to gain a space where the resolution can take place, that has no "audience troll" and is separate from -ops. the need for this separateness is for the person to feel that they are getting to the right people, and moving up the line. [09:04] tsimpson: no. i'd imagine that would be where people would go for a completely private discussion, if they felt so strongly [09:04] if so, then I suspect there would be some who would rather use a "closed" system [09:05] The thing is, this need to be a transparent process, hence the proposal of idleable. [09:05] jussi01, that last sentance is why i feel it's bureaucracy for bureaucracy sake. we already have an ircc stop in the line in the form of the mailing list. why do we need two ircc stops? [09:05] IS dispute resolution over the council ML not acceptable? [09:06] apologies for the tardy arrival, just returned from hostpital [09:06] Because the ML is not open, therefore we need to have a open place also [09:06] that's up to the council as far as I'm concerned [09:06] jussi01, we need to have one, or the other. both is just stupid. [09:07] Pricey: there is also the fact of real time. sometimes its better to do things in real time, we are the IRC council after all... [09:07] elky: no, we need to have both! one open, one confidential. [09:07] More channels, more more more! [09:07] could someone clarify the point of ops/ops [09:08] maybe it should be an option for the person with the issue [09:08] bazhang: in what context? [09:08] bazhang, where i can take you to scold you for a bad decision. [09:08] elky: this is irc. I'd personally prefer an 'on irc' dispute resolution process [09:08] elky, rather than PM? seems excessive [09:08] nalioth, and i prefer an independant dispute resolution step. one where we are not "supreme rulers" [09:08] nalioth: +1, as it is about IRC, so the resolution should take place here too [09:09] bazhang, yes, well apparently people need to see us fighting. or something. [09:09] elky: who said anything about "supreme rulers"? think of it as "supreme court" [09:09] Pici, what jussi01 said above about user/ops and ops/ops resolution [09:09] bazhang: if it cant be resoved in pm, then it escalates... [09:09] bazhang: I realize that now, thanks ;) [09:10] nalioth, i'm talking about a resolution process where we cannot ban them from, as such. [09:10] elky: i would assume -irc-council would not be used unless dispute resolution failed at a lower level [09:10] bazhang: We have that mandate on our wiki page [09:10] nalioth, i'm talking about the people who refuse to talk to us on our turf because they're convinced by our lack of public fighting that we're going to bully them [09:11] elky: that makes sense [09:11] jussi01, I tend to stay shushed when shushed :) [09:11] elky: They should look at the -meeting logs then ;) [09:12] Pici, if only. [09:13] ok, back to the subjuect on hand. [09:13] i just think that channel to ops to ircc to ircc to ircc to cc is obfuscation by red tape. [09:14] that seems like a lot of steps [09:14] and no matter how much you dont want people to treat the ML and the irc channel seperately, they *will* [09:14] Imho, we need to have a channel for ircc operations where people can come talk to the ircc be it about dispute resolution or other ircc matters. how are we going to implement that? same as we have now? [09:15] irccc aka irc council court? [09:15] I don't like the court part though [09:16] or m like mediation [09:16] Maybe we should come back to this at a later date, as we're brainstorming here. [09:16] yes, and people are up at wee hours. [09:17] [topic] Removal of inactive operators from channel lists controlled by the IRC council [09:17] New Topic: Removal of inactive operators from channel lists controlled by the IRC council [09:17] Lately we have noticed we have large operator lists but have operators that have not been active on IRC for long periods. The idea is that if an operator has not been active in the said channel for a long period of time that he/she will be removed from the list. [09:18] goode idea [09:18] Mamarok: why? [09:18] as they never show up anyway when called [09:19] it also makes it more possible for people to find real active ops when they /cs access #channel list [09:19] +1 to both of those [09:19] I suggested this a long while ago and it didn't go well. iirc there were arguments such as "if they were useful then, they should be able to rejoin with little disruption, they should still be trusted" etc. [09:20] Do we keep developers on there etc. ? [09:20] well, they can be added easily if they come back and are willing to join in again [09:20] Mamarok: Nope, they think their not wanted anymore, annoyed, they don't come back. [09:20] as those people are already known, aren't they? [09:20] oh dear, this topic [09:21] I think this would be best handled on a case by case basis, and any suggested changes suggested individually. [09:21] how about we *gasp* contact them. and ask. [09:21] That's also a very good idea [09:21] elky: I was *just* typing that [09:21] elky: gasp! surely not! [09:21] Hobbsee, communication? the audacity [09:21] indeed [09:21] That's not what we're about though! [09:21] the access lists are a bit off a mess, those who have left the irc-ops team should not still have access IMHO [09:22] personally, i've found it useful to be able to keep ops everywhere even though i haven't been active in most channels for a while - means cross channel trolls can be booted out in most of their channels. [09:22] we can always put people back on if they become useful [09:22] so avoiding losing that would be good [09:22] if people on a list have not been into a channel in the past two years, then, well... [09:22] (for everyone, not just for me [09:22] ) [09:22] Sounds good. So someone interested can look through a list and decide what should be changed, then the council will contact those involved? [09:23] Hobbsee: for me it doesn't make sens to be ops in #u for example, as I never join there [09:23] Hobbsee: yes, but you are actually in those chans,even if you dont say anything [09:23] sense* [09:23] Mamarok: however, you will if you get !ops calls in -ops for there, and no one else is around, surely? [09:23] jussi01: er, some of them, anyway ;) [09:24] Hobbsee, depends; I am on #ubuntu-offtopic list but have no access there [09:24] bazhang: that sounds like a bug [09:24] Hobbsee: well, I didn't even know I was supposed to :) do I have ops rights there too or only in #k? [09:24] bazhang: /msg chanserv list? [09:24] i sympathise with the idea of culling down the lists, but to remove ops from people active on irc, even if not in that particular channel, can be problematic [09:24] Pricey: he means on the ops call list from ubottu i think [09:25] Pricey, sorry? I definitely dont have access there [09:25] I can imagine some people would not want to be contact people for #ubuntu [09:25] Mamarok: not sure, i've not looked it up [09:25] and i think that's the argument i've seen so far [09:25] Hobbsee, we're talking about removing the ones that are not useful, not 'every slightly inactive op' [09:25] elky: ok, good [09:25] jussi01: can you answer my question? [09:26] Mamarok: /msg nickserv listchans [09:26] elky: wasn't sure if that was per channel, or over freenode - the original proposal wasn't clear. Now that it is :) [09:26] Hobbsee, i'm pretty sure 'over freenode' is not within our scope. [09:26] would it not be a good start to clear up the !ops factoids in each channel, then filter down from there ? [09:26] elky: er, over freenode in ubuntu channels [09:26] was what i meant (but not what i said, alas) [09:27] Hobbsee, it's just housecleaning on a per-case basis. hoarding is silly. [09:27] right :) [09:30] So to sum up, someone will look at an access list and suggest changes to the council. If we agree, we'll attempt to contact that person before any changes. [09:31] Moving on if nothing else on this? [09:31] [agreed] So to sum up, someone will look at an access list and suggest changes to the council. If we agree, we'll attempt to contact that person before any changes. [09:31] AGREED received: So to sum up, someone will look at an access list and suggest changes to the council. If we agree, we'll attempt to contact that person before any changes. [09:31] Pricey: and that someone would be? [09:31] * Pricey learnt a new button [09:31] Mamarok: you :P [09:31] Mamarok: i'm sure we'll have volunteers, ops or cuncil. [09:31] council too [09:31] whoever looks at the list at any given time [09:32] Mamarok: doesn't matter who it is though, council will enact it [09:32] I can for #k and #k-ot [09:32] [topic] [09:32] New Topic: [09:32] We're not going to disregard it if its someone we didn't ask [09:32] [topic] #ubuntu proxy policy. Specifically, LjL plans to remove the +e feature of his FloodBots in support of mibbit. [09:32] New Topic: #ubuntu proxy policy. Specifically, LjL plans to remove the +e feature of his FloodBots in support of mibbit. [09:32] :) [09:32] This topic... [09:32] I assume LjL isn't able to attend so I'm happy to start this off. [09:33] Hes not online now so.... go ahead [09:33] I would like us to make policy. I don't want us to allow the Floodbots to make policy for us. [09:33] agreed [09:33] Currently, we ban all web/gateway from #ubuntu and allow freenode's webchat in using the floodbots. [09:34] on this, for what it's worth. I added the webchat support to the bots. first, I was working with the bots for #k, so had familiarised myself with them. I *added* webchat to the (currently 3) gateways the bots look for, mibbit was never removed [09:35] I added webchat because mibbit was no longer available for users and they were advised to use webchat [09:36] tsimpson: And we never condicered making a policy change for gateways at that time. [09:36] there was a 1 line edit, which I thought LjL would not have issue with, he was not around to check with at the time [09:36] Do we still want web/gateway blanket banned? [09:36] (forwarded to -proxy-users rather) [09:36] (though I admit, I should have checked with LjL) [09:36] help me understand this correctly... LjL is wanting to use the floodbots to protest the mibbit banning? [09:37] elky: tsimpson: Pici: Please can we decide what we want first. [09:37] elky: Unfortunately, yes. [09:37] Pricey, i'm not making decisions until i know the whole situation. [09:37] ditto. [09:37] 00:31:29 < LjL> I intended to remove gateway-exemption support from the floodbots. This is because, while that feature initially applied to Mibbit, Freenode unilaterally stopped Mibbit from accessing the network, and concomitantly created its own web gateway. [09:38] 00:31:34 < LjL> I consider this an unexplained abuse of a privileged position, and I do not think we should support it by explicitly supporting their gateway in #ubuntu by means of the bots. [09:38] 00:31:39 < LjL> I am not concerned about whether this should result in all gateways being disallowed, or all gateways being unbanned and allowed without any restrictions. [09:38] So LjL has an issue ith freenode and takes it out on us, because we adapt to freenodes policy? [09:38] i'm not comfortable with our channels being used as pawns in a protest. [09:38] 00:35:13 <+Pricey> LjL: and to clarify. Is this 'intention' going to happen, whatever we decide about our policy? [09:38] 00:35:33 < LjL> Pricey: yes [09:38] < LjL> Pricey: unless of course you convince me i shouldn't [09:38] well, since ljl isn't here . . . [09:39] there is, as far as I can see, no technical reason to remove webchat support from the floodbot's. so it's purely a politically motivated reason [09:39] Agreed. And I do not want a statement from 'Ubuntu' being made like this. [09:39] And theres no freenode supported way of banning people from a channel and also banning them from using gateways all in one shot. [09:39] i am really not comfortable with being put into a position where ubuntu irc users being messed around by a single person to protest a freenode decision [09:39] isn't the basic problem that the floodbots are not open source? [09:40] Mamarok, yes. [09:40] Mamarok: pretty much. [09:40] which to me seems doesn't give us much choice [09:40] would it be possible to approach LJL to buy the bots ? [09:40] buy?! [09:40] How complex are the flood bots? do we have resources/expertise to write our own? [09:40] ikonia: how? [09:40] ikonia: Using our canonical funds, great idea [09:41] Mamarok: Money is usually how that's done ;) [09:41] /sarcasm [09:41] Mamarok: ask him if he'd consider selling them as a comercial product [09:41] Pici: depending on the price it may be achievable from other methods [09:41] I would rather remove them than pay for them. [09:41] Pici: in my view it's worth asking [09:41] Pricey: they add a valuable function, asking a price is not unreasonable, I suspect the price will be, but asking should not a problem [09:41] we might also explore how difficult it is to write or have our own bots written, as an open source app [09:42] ikonia, and given he's using the power they give him to make our namespace say something we dont particuarlly agree with, i'm doubting he'd take it. [09:42] He's objecting to this for political reasons, money likely won't be worth anything [09:42] elky: I agree, however asking, ticking the box as "not an option" and binning it should be done [09:42] we could create our own, but I feel like we're being extorted [09:42] tsimpson, we are being extorted. [09:42] what is so special about those floodbots that devers to be paid unlike some hundred open source flood protection bot scripts ? [09:43] Not that you're aware of the situation, can we go back to the start and decide what we want? [09:43] elky: depending on the price I would use my company to sponsor it - thus problem solved, keep it closed source and just allow the trusted people to modify as required [09:43] it could be a quick short / sharp resolution [09:43] the problem is that we depend on his grace to be able to use the floodbots, not only in this istuation but in all other upcoming situations too [09:43] ikonia: I would not like that. [09:43] fair enough [09:43] situation* [09:43] Mamarok, it's an entirely hypocritical situation. [09:43] ikonia: I'm only one member of the council, but I am very against approaching LjL to buy them. [09:44] I've never been happy that the floodbots were not open source, and I dont like the idea of keeping them that way forever by paying for them. [09:44] Mamarok: that was why I suggested purchasing them and taking control [09:44] so we really should have our own bots eg. open source ones [09:44] Pici: no problem then, [09:44] 08:33:25 < Pricey> I would like us to make policy. I don't want us to allow the Floodbots to make policy for us. [09:44] the floodbots theotetically could be made open source at a new revision [09:44] ikonia: that will not solve the problem, he will not sell them because he uses it for political statements [09:44] it seems we will have 3 options, 1) accept LjL's rule over the bots and go with it, 2) accept LjL's rule over the bots an remove the ban on gateways, 3) reject the bots and make our own [09:44] Can we please go back to the start and decide what we want with proxy users, moving on to what we want the floodbots to do, rather than the other way around? [09:45] Pricey, and you're letting us have our say on 'whether the floodbots will dictate policy' [09:45] and i think it's pretty comprehensively 'no, floodbots will not dictate us' [09:45] tsimpson: 4) keep the ban on gateways [09:45] tsimpson: 4) keep the ban on gateways, exempting others as a whole [09:45]