=== Ursinha-afk is now known as Ursinha === jjohansen is now known as jj-afk === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === bilalakhtar_ is now known as cdbs === smoser` is now known as smoser === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk [19:59] o/ [19:59] o/ [19:59] * tsimpson uses a ctcp action to indicate he is here [20:00] very l33t! [20:00] very meta/ [20:00] * jussi waves tiredly [20:01] nhandler said he'll be late [20:01] topyli:shall we begin? [20:01] #startmeeting [20:01] Meeting started at 14:01. The chair is topyli. [20:01] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [20:01] [LINK] https://wiki.ubuntu.com/IRC/IrcCouncil/MeetingAgenda [20:01] LINK received: https://wiki.ubuntu.com/IRC/IrcCouncil/MeetingAgenda [20:01] [topic] Volunteering for duties and time management within the IRCC [20:01] New Topic: Volunteering for duties and time management within the IRCC [20:02] Seeker`: around? [20:02] I believe seeker wanted us to remmeber that if we don't have time to do a task that delegate it to our operators. [20:02] i'm not sure if this is even necessary, anyone in the team can volunteer, and should! :) [20:02] ie. rww is a priime example :) [20:03] * rww polishes halo [20:03] yeah, and others are doing a good job too [20:03] let's move on [20:03] [topic] Ubuntu IRC Council not responsible for all core channels [20:03] New Topic: Ubuntu IRC Council not responsible for all core channels [20:03] ikonia: around? [20:04] Hes in the states this weekend, I'm not sure if he was going to be able to make it to this meeting. [20:04] I think that we know what he was talking about right? [20:04] well we can discuss it still [20:04] yeah [20:05] we have nhandler's input, i could paste it here [20:06] For those of you who don't, it was referring to the control, or lack-thereof in channels such as #kubuntu and #ubuntu-devel [20:06] topyli: paste it [20:06] For ikonia's issue, as I mentioned, we have the authority from the CC and freenode to manage the Ubuntu project namespace on freenode. However, we also have the ability to delegate. We delegate authority to small team/LoCo channels to basically manage themselves (to an extent), we also have delegated some authority to people like the KC to add OPs. They can not override us on the IRC matters (they can appeal to the CC to have them override us [20:06] however). [20:07] that's him not me [20:07] That doesn't exactly address the entire issue though. What if we want to do something that they may not agree with. Do we have that authority? [20:07] on IRC, yes [20:08] if they disagree, that can escalate it (if we can't work things out inter-council first) [20:08] However, there needs to be consultation with them before we do stuff. [20:08] or switch to OFTC, was the impression I got [20:08] s/consultation/notification/ perhaps. [20:08] Or somewhere between the two. [20:08] Pici: to a point... [20:09] we are in a rather interesting position as a council in that we, by definition, need to work with other councils closely and often [20:09] I think if we do something that affects groups in large ways, we should be including these groups in the discussion [20:09] sometimes our points of view differ, but I don't know of a situation where we could not come to some sort of agreement [20:10] I want there to be as much respect between the councils as possible. I don't think that we should be stepping on each others toes, but I think we all should be respectful of where the lines of authority are drawn. [20:11] we are ultimately responsible. for example, i would love to delegate more of the loco channel policy to the loco council (if they want it), but i also have to be able to say that i can answer to the CC for what happens there. it's tricky [20:12] topyli: ++ [20:12] topyli: agreed [20:14] so i think we can't really advance this without first meeting the relevant councils (loco, kubuntu i suppose) and seeing what they want [20:15] I think this is good for a discussion on the inter-council list? [20:15] yes [20:15] I think thats a great idea [20:15] There's an inter-council list? huh. [20:15] Only councilmembers have access to it. [20:16] jussi: you're the council spokesman, would you like to take the action? [20:16] rww: so we can plot the world domination ;) [20:16] jussi: I'd be willing to help you draft something if you'd like. [20:16] we need smoky chambers! [20:16] You can't fight here! This is the war room! [20:16] topyli: I can go as number one on the action, but I have an incredibly busy week ahead, so some help would be good [20:17] Pici: yes please [20:17] Throw me up there then [20:17] Pici will help [20:17] plz 2 action [20:17] [ACTION] jussi and Pici to draft proposal for inter-council co-operation to maintain project channels [20:17] ACTION received: jussi and Pici to draft proposal for inter-council co-operation to maintain project channels [20:18] meh, i don't know if that's good but we'll get the idea [20:18] [topic] Give ubottu editing privileges to all who are operators in a core channel [20:18] New Topic: Give ubottu editing privileges to all who are operators in a core channel [20:18] rww: your item [20:18] you're [20:18] ! [20:18] :P [20:19] It's pretty much self-explanatory. Imho, we need more ubottu editors, because factoid submissions aren't being dealt with. We have a set of people who are entrusted with channel ops permissions, so give it to them ;) [20:20] i think it's just a technical issue really, bot access is handled separately [20:20] for example, i don't have access [20:20] I don't think the reason factoid edit requests aren't dealt with has much to do with the number of editors really [20:20] I don't think there's a reason it should be, really. [20:20] tsimpson: +++ [20:20] it's more that most people either don't see the requests or don't know if it's been done or not [20:20] rww: there isn't, it just happens to be this way [20:20] any bot admin can hand edit privileges [20:20] but that's a slightly different issue to this [20:20] and there are several admins [20:20] Is not a technical issue. [20:21] tsimpson: and if there were more editors, an editor would be more likely to see the requests. [20:21] Its an issue of whether this happens during the operator probationary period or after or other. [20:21] yeah, I was replying to topyli, a bit latew [20:21] rww: but not more likely to act [20:22] there are times where no one is active, and the request is somewhere in the scroll-back [20:22] even if everyone is an editor [20:22] Theres a FR in ubottu for caching of requested factoids, no? m4v have wwe actually put that in writing ofr just talked about it? [20:22] Maybe some of the people who are ops and not editors would pay attention to requests if they had access. [20:22] jussi: yeah, I tried to implement it in Encyclopedia, but it didn't turn out to be a trivial task [20:23] so I continued working in the new plugin [20:23] m4v: ok, are you planning it for the new encyclopedia? [20:23] yes, is in the TODO [20:23] I mean, surely I'm not the only one that reads -ops scrollback ... [20:23] excellent [20:23] rww: to make myself clear, I think having more editors is a different issue to just having edit requests dealt with [20:24] and I think that a) extending access would help with the problem, and b) that there's no reason I've yet heard of not to [20:24] I do think we need to have some way to say "yes, you should have edit rights now" [20:24] topyli: +1 [20:24] tsimpson: +1 [20:24] topyli: -1 [20:24] :P [20:25] heh [20:25] [15:58:50] m4v: the only isues I have with that are that its not always improvements, despite the best of intentions. Thing is, people consider factoids as "approved/trusted information" so if we have too many editors, it becomes a problem to keep it that way. I think the system we thought of that factoid edit requests get stored and are easily viewable is a much better way than adding millions of editors [20:25] I said that to m4v in a different convo, but its relevant [20:25] I think edit requests is a different issue to the one we are discussing now, related, but different [20:25] I don't think there is a thing as too many editors, as long as they are all trusted. [20:26] if there are many requests from one person, and is trustworthy, why don't give him/her rights? [20:26] tsimpson: is correct, there is no policy and needs to be [20:26] well basically we trust our ops, so there's no real reason for not giving access [20:26] Is there a sort on ubottu.com/factoids.cgi that for last changed? That way we can hand out editor access but still easily audit changes. [20:27] I don't think adding yet more approval procedure to a team that already has too much when there's a perfectly good set of people who are already trusted is a good idea. [20:27] we should also think about having some kind of style guidelines for factoids, so they are standardized [20:27] (again, another issue) [20:27] rww: I don't want it to be an approval procedure, but rather part of the probationary process. Just another thing that we look at while you're still fresh. [20:27] tsimpson: I suggested that a long time ago, but there was no suggestions on how the style should be... [20:27] o/ [20:28] hi nhandler [20:28] I don't like a policy where edit privileges are tight regulated.. [20:28] it should be more like a wiki [20:28] jussi: nothing too complex, just a general this is how you style a factoid... [20:28] m4v: we tried that long ago, it was wildly abused (somewhat like a wiki ;) [20:28] I think we should try to stick the issue at hand, we're getting sidetracked. [20:29] and I agree that some sort of submission queue would be an equally-good idea, but that's been in the works for a long, long time. adding more editors is relatively quicker. [20:29] tsimpson: well, if an admin hands over rights to somebody that abused the factoid db, the admin isn't qualified. [20:29] I think the simplest solution would be to just give our ops edit privileges at the end of probation [20:29] re: the issue. yes we might as well give factoid access to core channel ops [20:29] great [20:30] tsimpson: yes after probation [20:30] tsimpson: I was just thinking about that, but I'm not sure its the best idea. [20:30] tsimpson: ++ [20:30] Pici: why? [20:30] Pici: well, simple != best, but I'd rather not complicate things too much, we can always remove edit rights if we see abuse [20:30] Worst case: They come out of probation with no idea how to edit a factoid properly. [20:31] And then we have a bunch of unhelpful factoids to change. [20:31] tsimpson: That was basically what I suggested. I also thought that the ability to grant a slightly-restricted editor privilege where you can only submit corrections in -ops (instead of via PM) so other people could review it might also be helpful [20:31] Pici: do you have a different idea? [20:31] nhandler: that's technically difficult... [20:31] m4v: how feasible would it be to implement nhandlers suggestion? [20:31] m4v: what do you think ^ [20:31] Pici: edit factoids isn't a skill hard to learn... [20:32] I think we should encourage them to suggest factoid edits now. Even though they don't have the rights to add them. [20:32] Pici: that's a relevant point. we could just tell people to please not edit before they know how [20:32] m4v: Its not the techincal part that I'm worried about. [20:32] Give full factoid editing privs to ops out of probation now, implement correct-in--ops and give it to probationary ops when it's coded? [20:33] rww: I think thats a good idea. [20:33] i do see what Pici means. people rely on correct factoids [20:33] yes, me also [20:33] i like that [20:33] jussi: I don't see what's the difference than what we have now? [20:33] I'm not sure how easy it would be to implement that edit-in-ops thing, I'll have to do some poking around the code [20:34] the difference is that not all core ops have access now [20:34] ahh [20:34] tsimpson: You should be able to to use the ischannel() function to figure out whether they're talking in a channel or not. [20:34] you mean, you can edit a factoid if the edit is done in -ops? [20:34] Pici: yeah, but Encyclopedia is convoluted [20:35] m4v: Yeah, so other ops can review the change [20:35] tsimpson: I know ;) [20:35] m4v: The difference between what we have now is that the edit would actually be live, not just proposed [20:35] Pici: there's also the issue of separating out those who can edit _anywhere_ and those that can only in -ops [20:35] that's what I use with -es factoid bot, but as tsimpson said, Encyclopedia can make it hard to implemetn [20:35] tsimpson: Yes. [20:36] m4v: Its not a blocker for this process if its too hard to do. [20:36] I think just having our probates (I don't like that word) be okay with suggesting factoids is enough. [20:36] And encouraged to do so. [20:36] agreed [20:37] if somebody makes enough well made edit suggestions, can get edit privileges? [20:37] yep [20:37] but there's nothing anywhere that says that... [20:37] That is what we've done for individuals before. [20:37] s/somebody/an op/? [20:37] tsimpson: Maybe we should document how to get edit privileges [20:38] jussi: That is the question, should it be 100% restricted to core OPs? [20:38] or anyone? [20:38] No. Any operator. [20:38] m4v: there is no requirement on being an op to edit factoids, that where there was never any link between ops and editors [20:38] jussi: well, you have to have an account with ubottu, which is a bit hard to get if you aren't an op [20:38] are even all the current editors ops? [20:38] if we think you should have an account, we can add one :) [20:38] topyli: Probably not (I don't think we remove old ops for example) [20:38] topyli: most (probably) [20:38] I think we did. [20:39] But we still have a fair number of non probationed ops that don't have editor access. [20:39] we can see (who wants a mass ping?) [20:39] yay! [20:39] tsimpson: ubottu does, in private. [20:39] I personally see no reason why any person (ops and non-ops) should not be able to gain the privilege to edit factoids if they demonstrate they know what they are doing and submit many useful/correct ones for review first [20:39] topyli: you can see current editors with @user list --capability editfactoids in a query (i think) [20:39] Pici: but I wanted to mass ping everyone :( [20:40] heh [20:40] m4v: Yeah, but then we need to compare that to who is currently an operator ;) [20:40] m4v: we have the @editors command :) [20:40] I understand supybot more than I understand Encyclopedia ;P [20:41] I'd be willing to take a look at the code itself. [20:41] ok, shall we try to get editor rights to all core channel ops after probation? [20:41] but I think we should codify what we want exactly first. Perhaps a vote is in orer? [20:41] order too. [20:41] just trying to formulate a proposition to vote on [20:41] what are we voting on? [20:41] topyli: Thats what I mean [20:41] that's the question! :) [20:42] alright. [20:42] [vote] get editor rights to all core channel ops after probation [20:42] Please vote on: get editor rights to all core channel ops after probation. [20:42] 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 [20:42] E.g. /msg MootBot +1 #ubuntu-meeting [20:42] I say we give it to all non probated ops right now, we live the problems that might bring, if any, for a little bit. [20:43] How does the topic of restricting editing to -ops fit into this? [20:43] Pici: I like that [20:43] i think my proposal covers current ops [20:43] nhandler: if it's doable, we can do it [20:43] nhandler: That was only for probationed opreators. [20:43] opreators. nice. [20:43] Pici: ++ [20:43] gah [20:43] how do i retreat a voting item? :) [20:44] topyli: End it and start a new one [20:44] endvoet? [20:44] just end the vote [20:44] [endvote] [20:44] Final result is 0 for, 0 against. 0 abstained. Total: 0 [20:44] * Pici fail engish, thats unpossible [20:45] who wants to suggest a workable suggestion to vote on? i sort of know what we mean but i'm failing [20:46] Pici: ? [20:46] give all current ops in core channels factoid editing rights? [20:46] current ops, new ones after probation, in -ops only? [20:47] jussi: eh/ [20:47] What tsimpson said. [20:47] alright [20:47] Vote: Give all ops in core channels editing rights, with the exception of those on probation. [20:47] [vote] Give all ops in core channels editing rights, with the exception of those on probation. [20:47] Please vote on: Give all ops in core channels editing rights, with the exception of those on probation.. [20:47] 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 [20:47] E.g. /msg MootBot +1 #ubuntu-meeting [20:47] +1 [20:47] +1 received from Pici. 1 for, 0 against. 0 have abstained. Count is now 1 [20:47] thank you :) [20:47] +1 [20:48] +1 received from jussi. 2 for, 0 against. 0 have abstained. Count is now 2 [20:48] +1 [20:48] +1 received from topyli. 3 for, 0 against. 0 have abstained. Count is now 3 [20:48] +1 [20:48] +1 received from tsimpson. 4 for, 0 against. 0 have abstained. Count is now 4 [20:48] +1 [20:48] +1 received from nhandler. 5 for, 0 against. 0 have abstained. Count is now 5 [20:48] [endvote] [20:48] Final result is 5 for, 0 against. 0 abstained. Total: 5 [20:48] why don't just give rights to those ops that want it instead of all? (less commands to type) [20:48] oh i'm slow [20:48] maybe we can implement this so that they have to request access [20:48] because that's messy, and no one has really asked for it [20:48] Because we should be encouraging our ops to suggest factoids. [20:49] rww did ask for it [20:49] (with this meeting) [20:49] Not to say "Oh, I can't add factoids, so I'll be lazy instead" [20:49] :P [20:49] s/suggest/fix and add/ [20:49] and I think that'd only ask when they need to actually edit something [20:49] Or they didn't know they could ask. [20:49] m4v: the "really" in there covers that [20:49] kk, got it [20:49] alright [20:49] [topic] Add information on the recent increase of spam and that it should be ignored by users, to the #ubuntu topic [20:49] New Topic: Add information on the recent increase of spam and that it should be ignored by users, to the #ubuntu topic [20:50] to this, I'd just say "NO!" :) [20:50] Nobody reads the topic. [20:50] 1st reason ^ [20:50] bilal just /quit, he's not here [20:50] Are we still even getting that much spam? It's my impression that the FLoodBot changes have counted it rather effectively. [20:50] I read it :( [20:50] also, topics are a limited length, and are already rather full [20:50] the topic in #u is full enough all ready... [20:50] rww: They have. [20:50] * m4v is kidding anyway [20:50] i don't see spam increasing, it's always been like this [20:51] The dynamic +r setting is great. [20:51] Its been decreasing in our channel since we got that. [20:51] I would prefer not to go into much details in our /topic. It is an issue across the network. However, I see no issue in putting a shortened link to http://blog.freenode.net/2010/11/be-safe-out-there/ in there [20:51] there's also the issue that we don't want to be an advertising agency for these trolls [20:51] tsimpson: ++ [20:51] the best way to deal with them (once they are gone) is to ignore that it ever happened [20:51] yeah if we do something, i'd go with nhandler's idea [20:51] I think we should remind people to use our !feed the troll factoid, and maybe put that sort of link in there. [20:51] !feed the troll [20:51] Error: I am only a bot, please don't think I'm intelligent :) [20:51] :) [20:51] !feeding the troll [20:51] The above mess was caused by someone who thought it was funny (they're gone now). Please ignore it completely, since discussing it and making a fuss will only make them think they've reached their "fun" goal. [20:52] Or similar. [20:52] Pici: yes, that sounds sane [20:52] My only issue with the factoids is they tend to be rather noisy and give much more attention to the issue that it deserves [20:52] !-feeding the troll [20:52] feeding the troll aliases: feedthetroll, don't feed the troll, botattack - added by LjL on 2007-10-17 17:04:23 [20:52] maybe someone could make the floodbots do it, as they do for a netsplit? [20:52] nhandler: Its easier than telling 10 people that they shouldn't join #freenode to get an xmas cloak. [20:52] though, I still think that's a little much [20:53] can floodbots detect trolls? [20:53] my issue with factoids is the same that nhandler has with adding to the #ubuntu topic: they grow and become noisy and people start to ignore them [20:53] why do be have ops then :P [20:53] So education? [20:53] m4v: as you well know, bots are never perfect ;) [20:53] Instead of factoid spamming? [20:54] So were there any objections to having a simple link to that freenode blog post (shortened) in the /topic? It would only add a few characters, and would not require editing for each new type of attack [20:54] I don't think it's too much of an issue, most people go back to their support issues quickly after an "attack" [20:54] nhandler: if it still fits there, no [20:55] yeah, if we have room... [20:55] The more you put in /topic, the less people will read it. [20:55] yes that's the provlem [20:56] let's make ubottu /msg and /notice people the topic on-join [20:56] * tsimpson runs away [20:56] ha [20:56] tsimpson: That is what the entrymsg is for [20:56] and I don't think this is frequent enough that it needs to be in there :\ [20:56] nhandler: that wan't a serious suggestion [20:56] And we can easily make room in the /topic by shortening urls and removing the notice that maverick has been released [20:57] yes [20:57] I don't think so either. [20:57] We said a few minutes ago that this wasn't needed in the topic, what has changed? [20:58] we have so far established that it not needed but it's not harmful either :) [20:58] "The more you put in /topic, the less people will read it." <-- harmful [20:58] well except for rww's point of huge topics, but we can't fix it [20:59] rww: That isn't necessarily true either. And like I said, we can shorten the /topic rather easily [20:59] there's also the point that people aren't going to bother reading the topic, clicking on each link and reading each page when they join [20:59] most are there to ask a support question, they just don't care about the topic [20:59] nhandler: "we should take some of the stuff out of the existing topic" is a good point regardless of us adding new stuff to it. If someone else doesn't, I'll review it when I'm not at work. [21:00] specially if the urls are in tinyurl form [21:00] nhandler: if someone shortens all the urls in the topic and adds one more, i won't be against it :) [21:00] tinyurl form url is nice =) [21:00] Why not use a form that we can actually track how much they're clicked, like, goo.gl or bit.ly? [21:00] except that you don't know what it is until you click it? [21:00] tinyurl is one of the longer shorteners ;) We can get them even shorter. [21:00] is.gd ;) [21:00] bit.ly [21:01] That way we can see if people are actually reading through and clicking them? [21:01] m4v: We have the links labeled as well. 'i.e. release notes: foo.com/bar' is pretty clear [21:01] Pici: not a bad idea, could be useful information for many purposes [21:01] v.gd might be useful for that [21:02] nhandler: yeah, nevermind me [21:02] ok [21:02] So I guess we have two things to decidce. First, does anything need to be done at all by us? [21:02] Want me to do that? [21:03] Pici: I can do it as well if you want [21:03] [vote] add "ignore spam" info to #ubuntu topic [21:03] Please vote on: add "ignore spam" info to #ubuntu topic. [21:03] 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 [21:03] E.g. /msg MootBot +1 #ubuntu-meeting [21:03] we have to go on :) [21:03] I'm not sure if statistics on is.gd links can be viewed by everyone, I know goo.gl's can. [21:03] s/is.gd/bit.ly/ [21:04] Pici: That is why I suggested v.gd (same people as is.gd) [21:04] that's implementation details, let's decide on the issue [21:04] +1 (in shortened form) [21:04] +1 received from Pici. 1 for, 0 against. 0 have abstained. Count is now 1 [21:04] +1 [21:04] +1 [21:04] +1 received from topyli. 2 for, 0 against. 0 have abstained. Count is now 2 [21:04] +1 received from nhandler. 3 for, 0 against. 0 have abstained. Count is now 3 [21:04] +1 [21:04] +1 received from jussi. 4 for, 0 against. 0 have abstained. Count is now 4 [21:04] +1 for shortned form [21:04] +1 received from bittin. 5 for, 0 against. 0 have abstained. Count is now 5 [21:04] +0 [21:04] Abstention received from tsimpson. 5 for, 0 against. 1 have abstained. Count is now 5 [21:05] bittin: The vote is only for members of the council [21:05] [endvote] [21:05] Final result is 5 for, 0 against. 1 abstained. Total: 5 [21:05] heh [21:05] nhandler ah :( [21:05] Pici: So did you want the action, or should I take it [21:05] nhandler: I'll take it. [21:05] let's give the action item to bittin [21:05] i diden't know that how do i get to be a member? [21:05] bittin: Check out https://wiki.ubuntu.com/IRC/IrcCouncil/Charter [21:06] alright Pici, you volunteered first :) [21:06] bittin: but being a member doesn't entitle you to vote either, only the IRC Council can vote [21:06] You can state your opinion though :) [21:06] anything else? i haven't checked bugs to be honest [21:06] indeed-e-doodly [21:06] topyli: I don't think there have been any new ones (I am subscribed) [21:06] I threw something on there for the offtopic guidelines, but it can wait. [21:06] oh yes so am i [21:06] no new bugs, just the same old same old [21:07] Did we give that status update on the IRCC nomination process? [21:07] Pici: oh! [21:07] Pici: sorry, did i miss it? [21:07] refresh [21:07] oh yes [21:07] do we have time? i do [21:08] Just a quick status update, the extended period for IRCC nominations ended. The list of nominees has been sent to the CC along with feedback from the current IRCC. We are now waiting on the CC. [21:08] [action] pici to fix #ubuntu topic to include advice to ignore spam [21:08] ACTION received: pici to fix #ubuntu topic to include advice to ignore spam [21:10] jussi, nhandler, tsimpson, do you want to take on Pici's offtopic support item? [21:10] if you want [21:10] or shall we postpone? [21:10] Im tired, had a longday, need to sleep. [21:10] Okay, we can do this some other time. [21:10] Maybe bring it up on the ML to try and get some feedback before the next meeting [21:10] i guess it's not busy [21:10] nhandler: good idea [21:11]