14:04:40 #startmeeting fedora-hubs 14:04:40 Meeting started Tue Apr 26 14:04:40 2016 UTC. The chair is pingou. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:04:40 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:04:40 The meeting name has been set to 'fedora-hubs' 14:04:52 #topic roll-call 14:04:55 * pingou is here 14:05:06 .hello devyani7 14:05:07 devyani7: devyani7 'Devyani Kota' 14:05:09 .Hello dhrish20 14:05:10 dhritishikhar: dhrish20 'Dhriti Shikhar' 14:05:32 .fas sayanchowdhury 14:05:32 sayan: sayanchowdhury 'Sayan Chowdhury' 14:06:30 #topic status 14:06:40 so there has been a few changes to fedora-hubs recently 14:06:51 ryanlerch: added a runserver script to run the dev server 14:07:10 he also splitted the templates, so that there is a master template that the hubs are using 14:07:21 he also ported to fedora-bootstrap 14:07:24 .hello pfrields 14:07:25 stickster: pfrields 'Paul W. Frields' 14:07:32 sorry, I missed roll call :-) 14:07:43 this allowed to drop the two bootstrap folders from the sources 14:08:06 fedora-bootstrap made things look quite pretty but broke a few things as well 14:08:20 like the ability to configure a widget, this has been restored today 14:08:24 * abompard is here 14:08:37 (which also brought back the ability to remove a widget from a hub) 14:08:51 today, I've been adding the logic to add a widget 14:09:16 so we should have all the bits and pieces in place to: add a widget, configure an existing widget, remove a widget 14:09:27 hub wide, we have the logic to re-order them 14:10:07 note: each widget now has a position argument, required, to determine if the widget should be only on the left column (for example feed), the right column (for example pagure's tickets) or present in both 14:10:28 both = span? 14:10:31 this allows presenting to the user a list of widgets available in the process of adding them 14:10:48 stickster: no a widget is always in one column, but some be can either on the left or on the right one 14:11:04 while others are restricted to be only in 1 column 14:11:09 Ah, I get it, thanks :-) 14:11:30 the logic to add widgets is only in my fork for the moment 14:11:50 but should be merged soon :) 14:12:00 pingou, +1 14:12:17 oh and thanks to Dimuthu, widgets can now have a footer :) 14:12:28 I think this cover my ends 14:12:31 pingou, footer? 14:12:38 hey 14:12:46 mizmo: hey :) 14:12:56 sorry im late, i forgot we moved to 10 14:13:06 pingou, what does that footer show? 14:13:31 dhritishikhar: as in https://pagure.io/fedora-hubs/issue/29#comment-599 14:13:44 the 'Request A New Meeting' button is in a footer there 14:13:48 hey mizmo :) 14:14:01 pingou, okay 14:14:11 anybody wants to jump in? 14:14:27 * sayan has a small update 14:14:35 pingou: question on the widget position (can discuss whenever appropriate) 14:15:00 mizmo: first (since it's the same topic) then sayan ? 14:15:13 * mizmo also wants to talk about a meeting decause, ryanlerch, sayan, and jflory7 had on thursday night (well, very early morning for sayan o_O) 14:15:14 sure :) 14:15:37 mizmo: what's your question on widget position? 14:15:43 pingou: does a both position mean it can go left OR right? 14:15:47 yes 14:15:49 ohhh okay 14:15:54 cool 14:16:00 sayan: your turn :) 14:16:06 mizmo: but could also be left AND right, if you put two widgets :-p 14:16:17 sayan: shoot :) 14:16:30 pingou: yeh i hadn't thought of that before, had some interesting ideas on how that might work, not sure if its super useful yet tho 14:17:29 on ircb, slick666 has been working on logging (he is one of the contributors to ircb) 14:18:10 and /me and rtnpro are spending time on reading reactjs 14:18:10 * pingou saw some of the commits passing by 14:18:32 sayan: did you see the thread I started on the infra list about JS framework for front-end work? 14:19:08 abompard: I had the same question for you actually :) 14:19:09 pingou: ah! yes, I forgot to reply there 14:19:44 sayan: might be nice if we kinda agree on one framework (looks like reactjs vs angular) before we get too deep into one :) 14:19:45 that's all from my side 14:19:51 pingou: +1 14:20:14 which on the other side would be a way to make a decision, but we have a poor trac record of following other's opinion ^^ 14:20:40 * mizmo needs to know which one to get training on :) 14:20:43 sayan: looks cool, let us know if you need something, coding of infra-wise 14:20:47 mizmo: +1 14:20:57 mizmo: so, you said you had a meeting last week? 14:21:02 pingou: sure 14:21:27 yes! it was very spur of the moment - basically i have been working through the UI ticket queue and came across a team badges widget ticket 14:21:29 s/of/or/ 14:21:31 pingou: sayan: is there an objective basis on which to decide which JS framework? 14:21:40 https://pagure.io/fedora-hubs/issue/17 14:21:44 pingou: saw it, following it with attention, but I don't have much to add 14:21:58 abompard: ok, I thought you had some experience w/ some 14:22:02 oops, sorry for backtracking mizmo, didn't type fast enough 14:22:02 and this idea of having 'paths' or tracks of badges to help onboard folks keeps coming up, both in hubs and in badges 14:22:07 it's all good i can wait too 14:22:31 pingou: not those, and my experience is getting old in this fast revolving world 14:22:31 im curious too how to decide which JS framework 14:22:40 abompard: ok thanks 14:23:21 stickster: for the moment, the first cut for me is a little at: do we have one that most people have experience with? 14:23:51 A lot of things can be considered, availlabilty of one resourses, which one works better, community etc 14:23:52 if there is a clear one, the choice will be easy, if there isn't a clear one (which seems to be our case), then it gets harder :) 14:25:05 * mizmo wonders if other FLOSS projects similar to us have a preferred one 14:25:23 these decisions are bad tho, turns into a bikeshed often :( 14:25:34 do any of our incoming interns have experience in one or the other? 14:25:41 good question :) 14:25:47 * mizmo looks up resumes 14:26:47 I touched angular, wrote a poem and then came back :P 14:27:00 eric has backbone.js experience 14:27:13 meteorjs, knockoutjs 14:27:14 I don't see either Angular2 or React mentioned -- but I see several on Eric's CV 14:27:27 So I imagine another wouldn't be a big deal... not that it helps decide :-) 14:28:05 The one thing that rtnpro mentioned was that Angular2 is easier for new developers 14:28:09 RH has an internal list called tech-list, we could ask on there just across RHers if there is one that is more or less suited to a project like ours 14:28:15 * mizmo likes easier :) 14:28:35 but rtnpro also said he prefers React :-D 14:28:42 so... not sure I helped there :-D 14:28:46 kinda does 14:29:07 if waartaa goes the react ways, there are two people close to us we can bother if we have problems with it :-p 14:29:33 :-) 14:29:55 anyway, the decision is not for today 14:30:16 but it's something we'll have to consider before or at the latest at flock I think 14:30:37 back on badges? 14:30:38 yeh 14:30:40 sure 14:30:48 okay so i have been slowly going thru needsmockup tickets 14:30:52 and i came across the badge ones 14:31:00 eg https://pagure.io/fedora-hubs/issue/17 14:31:08 the two overarching goals we have for hubs - 14:31:16 - make contributing to fedora way easier for existing contributors 14:31:32 - make contributing to fedora easier, welcoming, inclusive for new contributors 14:31:45 badges is a big priority in terms of getting newcomers bootstrapped onto teams/projects 14:32:00 so a big request for badges, and sometimes mentioned in hubs (like #17) is the concept of badge tracks 14:32:22 i knew decause and jflory7 had been working on defining some badge tracks for representative fedora teams 14:32:41 so i pinged them in irc, they had a video chat / hack session already scheduled for that night, so we took a couple hours of that and basically talked all about badges and hubs 14:33:13 so i think with hubs, to get to something by flock, across all features, we gotta take a layered approach right 14:33:22 basic functionality first, but leave room to expand for more awesomeness 14:33:31 mizmo++ 14:33:31 sayan: Karma for duffy changed to 18 (for the f23 release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:33:44 so i think for flock for august, there maybe isn't much to do for badges, i'll make mockups such that it should be clear what 'layer' they're intended for 14:33:58 i dont know how to name the layers, maybe layer 1, layer 2, layer 3 (from most basic to advanced) 14:34:10 so layer 1 for badges for flock - i think is simple, not complicated 14:34:20 mizmo: sounds to me like we need for each badge a: trac name and trac position 14:34:21 but for layers 2+, we need changes in the data model for badges 14:34:38 pingou: well that's where it gets interesting 14:34:44 okay so who here is not familiar with the final fantasy games 14:34:46 hehe 14:35:10 so my thinking about the badges feature - is maybe layer 2 thinking, but there's a layer 3 that might be quite interesting 14:35:38 layer 2 for badges, is that you can define a structure above badges - a badge track, and that badge track has ordering and member badges 14:36:00 so badge A is #1, badge B is #2, badge C is #3 - and if you achieve these badges in order you earn a badge track 14:36:12 earning a badge track may be a pre-requisite to joining a hub 14:36:29 nice 14:36:52 Ooo, I like that idea... 14:36:57 mizmo++ :) 14:36:57 devyani7: Karma for duffy changed to 19 (for the f23 release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:36:58 for example, you may need to earn the 'bootstrap track' to join any hub at all - this requires you set up a FAS account, maybe set an SSH key, earned the IRC badge (and remy has these defined) 14:37:10 we ALSO could have tracks that have no order 14:37:52 * pingou notes that w/o FAS account hubs is empty 14:38:02 so badge D, badge E, badge F - they make up a badge track. let's say it's voting for Fedora wallpaper. And maybe they don't have to be specific badges. If you earned any 3 voting for wallpaper badges, you earn the 'wallpaper critic' badge track (or something like that) 14:38:21 pingou: yeh i know :) just using that as an example, can't think of all the bootstrappy things remy had come up with (there are more tho) 14:38:25 okay 14:38:32 so that's just layer 2 right, for badges 14:38:34 mizmo: but I like the idea, def 14:38:41 * pingou curious about layer 3 14:38:53 layer 3 - a step up from that.... will also take a data model change for badges, so i think any changes to the data model should also support that since we don't wanna change the data model more than we have to 14:39:03 pingou: have you ever played a final fantasy game? 14:39:16 nope 14:39:21 my favorite is final fantasy 10, i can't think of the generic final fantasy term, but basically decause has envisioned a 'sphere grid' for badges 14:39:24 * mizmo grabs a link 14:40:03 hold on trying to find a non confusing one 14:40:14 * stickster never played FF either but awaits link 14:40:14 ok, I'm going to vote that we put decause off coffee until we manage to implement all his ideas, we'll never be able to catch up otherwise! 14:40:36 http://glacoras.net16.net/Images/SSGOSG.gif 14:40:51 badge path map? 14:40:55 so this is an annotated version of FF10's sphere grid 14:40:57 yes 14:41:02 so there's different flavors to it right 14:41:06 they're reprsented by the colors 14:41:18 eg purple / obnoxious pink is black mage 14:41:24 white is healer 14:41:36 dark blue is a warrior 14:41:42 fedora's equivalent is something like 14:41:47 the design/art flavor 14:41:51 the developer flavor 14:41:53 packager flavor 14:41:56 marketing / writer / contetn flavor 14:42:14 we have 5 badge 'flavors' right now i think, i dont recall them off the top of my head, something like, content, development, testing, that sort of thing 14:42:21 so we use those 14:42:28 okay 14:42:33 should make the code-color easy :) 14:42:35 then the little nodes in the graph, each one would be a badge 14:42:45 so it represents tracks i guess 14:43:05 if you're an artsy person, you have a path to follow to earn your 'design mage' ability or whatever 14:43:37 and this kind of representation would allow us to do these little graphs to represent any fedora contributors scope - their backgroudn/experience, the kinds of things they can help with 14:43:57 ON TOP OF giving folks a clear 'path' for developing their own skills 14:44:14 very, very awesome for beginners i think, bc a big weakness of FLOSS projects in general is that they are so self-directed 14:44:42 this stupid sphere grid system probably has wasted hours upon hours of my life lol, trying to get XP so i can earn a node 14:44:46 it's addictive 14:44:54 okay so anyway, that's layer 3 14:45:17 i think if we make data model changes for layer 2 they should include layer 3 things just so we don't make it harder to ever get to level 3. not that it's a super high priority 14:45:26 we can get away with layer 1 and it'd still be a huge improvement - 14:45:50 layer 1 is basically setting tags on badges, and then any individual hub when configuring the widget would list out the tags of badges they care about wrt that project/team, and it would display there 14:46:05 i don't know if we would want to have a 'pre-requisite' system in layer 1. maybe 14:46:22 but there's definitely badges that relate to a team that shouldn't be a pre-requisite for joining that team 14:46:38 sayan: am i forgetting anythign else we talked about? i'm taking a quick look thru the notes now 14:46:44 also decause also mentioned something like the radar chart - http://jsfiddle.net/fxs2n8s5/ to show which part of fedora a contributor actively participates in 14:46:49 * mizmo intends to blog all of this 14:46:55 sayan: ahh right, i couldn't remember what it was called 14:47:26 let me show you guys (you've seen this already i'm sure) the kind of thing i want us to aim for in hubs eventually 14:47:41 http://blog.linuxgrrl.com/wp-content/uploads/2013/08/user-profile.2.png 14:47:57 this is a hyperkitty idea, but it still applies to hubs 14:48:33 basically a way to get a feel for different folks' ability, personalities, and how to interact with them (eg TZ differences, when they tend to be active / around) so that newbies don't have to lurk for years to get a feel for a team they want to participate in 14:48:53 having a radar chart of their badge experience would be so super useful towards that goal 14:49:10 I like the idea of hubs as a dashboard for everyone 14:49:27 but I'm not sure I'm 100% confortable with hubs as a profile service 14:49:58 pingou: what are your concerns? 14:50:03 pingou: i dont want it to be like a social networking thing 14:50:10 i want it more to be like - 14:50:20 mizmo: basically, it screamed linkedin to me 14:50:22 - i need help with something, who is working on this? who is a skilled person i can ask? 14:50:36 like a profil, a place people would come to check you out 14:50:48 - i need to get in contact with someone but he/she is never on IRC, when can i best reach them? 14:51:15 well i think that is an important use case too, particularly for newbies. when you are a newbie, all names have equal weight, trolls and long-term reasonable contributors alike 14:51:32 but shouldn't FAS be the place then 14:51:34 ? 14:51:35 so having something where you can see if a person is a troll or an ally i think is important for newbies 14:51:37 mizmo: also... - has this person "leveled up" to the point where they seem interested to help on $TASK 14:51:49 well the idea we've talked about up until now on hubs is that hubs is actually the main front end for FAS3 14:52:01 and the FAS3 UI is directed at group admins, not individual group members 14:52:08 so a person's hubs profile would in effect be their FAS profile 14:52:41 specific non-goals: 14:52:43 - should not be creepy 14:52:46 - should not be stalker-y 14:53:03 (the radar graph seems a little too much for me) 14:53:23 kinda makes it too easy to "compare" profile 14:53:30 hmm 14:53:34 * mizmo wonders how to offset that 14:53:36 Actually I think the radar graph seems like a good way to identify skilled/interested people 14:53:43 that's what those graphs are for: comparison 14:53:50 well not just comparison, but recommendations 14:54:00 that's what you get from the comparison 14:54:01 If I'm trying to build up community around, say, docs... I want to find people who care about docs enough to have made it to a certain place in the graph 14:54:21 for example, i'm a new contributor, i have badge earnings in design and marketing, it might suggest based on other folks' profiles that i would be interested in working on this other area / project / team 14:54:31 stickster: that's info you can get from the level 3 of badges 14:54:52 you could have a thing where someone has been inactive in fedora for a while - maybe they didn't know what to work on. look at what they earned and suggest the next step 14:55:14 mizmo, is it like a recommendation system? 14:55:17 that could be suggested to them directly, or suggested to a project/team lead as a recruitment lead (oh this sounds like linkedin tho, lol, but would still be helpful) 14:55:27 dhritishikhar: not explicitly, but the data it provides could power one 14:55:46 i think if people view it as a comparison / ranking system that becomes problematic though 14:55:50 i dont want it to be a competitive thing 14:55:58 i want it more to be - i'm a black mage vs you are a healer 14:56:26 a warrior can heal, but not as well as a healer. a healer can kill a level 15 monster, but a warrior can do it in less hits 14:56:32 so maybe instead of showing areas in the radar, we can show projects 14:56:33 it's not better or worse, it's just different skills 14:56:48 projects that you are working on 14:57:10 but then, how do you quantify working on hubs vs working on pagure (say), # of commits? 14:57:13 that'd definitely be a useful widget, especially if it could be automated 14:57:30 you could do something simple like the last 5-10 projects contributed to 14:57:45 but project name doesn't necesarily tell you the skill set 14:57:48 then you end up showing what the person is working on, areas of interest 14:57:52 eg i make commits all the time, but they're svgs not code 14:58:00 or they're css not python 14:58:06 but everyone has a different graph (and not only the values, but also the axes) 14:58:19 mizmo: tells me you're involved in there 14:58:31 what would the axes be in that system 14:58:33 and if you're not the best person, you probably know who is :) 14:58:37 the projects 14:59:04 basically, if you and I have the same axes, say docs, design, dev, packaging, translation, ambassador 14:59:08 so the axes in the radar graph we were proposing would have been more general - content vs code vs marketing vs events / ambassadors 14:59:12 then we can compare our profile easily 14:59:26 is that a problem? 14:59:34 but if you have: design, wallpaper, hubs and I have pagure, hubs, pkgdb2 14:59:55 i guess the problem is that if there is no standard axes, the graphs aren't readable 15:00:07 someone would know what to contact us for and we're less into comparing 15:00:24 i guess i dont understand how comparing a black mage vs a healer vs a coder vs a docs writer is problematic 15:00:38 where i see problems is, you know, i had 550 commits but you only had 32, haha i'm better than you 15:00:42 mizmo: because I don't want hubs to become the place to be for head-hunters 15:00:48 pingou: ohhhhhh 15:00:51 hm 15:00:57 the place to check for someone who says they are from the Fedora community 15:01:08 but you need a fas account to get in 15:01:09 a linkedin for Fedora 15:01:16 mizmo: that's quite easy to get :) 15:01:17 well 15:01:28 meghan did design a privacy feature for profiles 15:01:36 so you get limited view of profiles unless a user gives you access 15:01:51 eg you only see the most recent 5 events, and only a few widgets. we could hide the radar graph widget 15:01:54 doesn't that make the graph less interesting? 15:01:57 unless you're a friend / co-member of a team 15:02:08 it wouldn't affect the content of the graph. 15:02:18 then I don't know what you work on and why I should contact you 15:02:32 so I have two things to point out here 15:02:38 there's a lot of different ways we could make it visible. could be fas +1, or fas + more, or if you'reboth members of the same team 15:03:04 the system meghan designed was you explicitly added each other, but we don't have to rely on that mechanism (i agree that'd make it hard to get the data to understand if you even want to friend them in the first place) 15:03:42 (1) there's a significant amount of info people can pick up through general archives, badges, wiki page profiles, etc. -- that someone can anonymously access now, whereas this Hubs idea would actually place that behind some barriers like FAS. 15:04:14 but hubs is centralized, so it makes finding this info (normally spread) much easier 15:04:41 yeh meghan's analogy was bike lock 15:04:44 * pingou waits for (2) :) 15:04:47 having it decentralized is like a bike lock 15:04:54 having it all easy to get in one go is like having an unlocked bike 15:04:57 more likely to be stolen 15:05:09 (2) Let's not forget that open source work is something many people *rely on* to help them with building a CV toward employment, and we don't want to make it harder for the majority of folks to show that information 15:05:57 I'm also having two thoughts: 15:05:58 that can be especially true in developing nations 15:06:19 a) widgets are configured by users, so those who like it can add it, those who don't, won't 15:06:41 +1 15:06:55 b) we can do both type of radar graph: one using badges to setup a 'standardized' profile and one presenting the most active projects of the contributor 15:07:08 * pingou looks at sayan and smile :) 15:07:45 https://fedoraproject.org/w/uploads/9/9a/FedoraRPG-mockup-startpage.png 15:07:51 just some random food for thought 15:08:08 with badge tracks we can do things like this (oh back then we called finishing a track == earning a trophy) 15:08:18 and we called the tracks "missions" 15:08:23 nice 15:08:29 wow 15:08:33 and there was a concept of campaigns 15:08:33 mizmo++ 15:08:33 stickster: Karma for duffy changed to 20 (for the f23 release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:08:43 so i could decide as design team admin, i want a campaign for people to close 5 design team tickets 15:08:44 mizmo++ as always :) 15:09:00 :) 15:09:10 * stickster has to turn his attention elsewhere -- but will stay camped here 15:09:14 but radar graph most active projects should all his axes as strong points. 15:09:17 pingou: so more to your idea about having radar maps for projects - 15:09:28 you could have widgets that show the person's progress in badge tracks / campaigns 15:09:34 then you know what projects the person is actively working on 15:09:36 s/should/would 15:09:43 people are most willing to help with what has their attention at the moment 15:10:00 sayan: we can make them relative to each others 15:10:05 so this would help people figure out - oh hey pingou is working on closing pagure tickets actively, hey, maybe he knows the answer to my pagure question 15:10:31 sayan: say you have 100 commits in pagure, that's you most active project, has the top level, hub has 40 commits, that's the second & so on 15:10:46 s/commits/fedmsg msg about/ 15:11:05 mizmo: that was also my thoughts 15:11:06 i dont know about the radar graph of projects, just because if there's 5 projects i'm working on, and they have my attention unequally, it'd probably be better to just have an ordered list with %'s to represent that data, i think a radar graph isn't the most usable way to present that data 15:11:19 which leads me to the conclusion: we need statscache 15:11:37 radar graphs are better suited to respresenting data that doesn't always hit all axes points (does that make sense?) 15:12:16 since you're putting projects the users are actually involved with - the graph is never going to hit one side more than the other unless you do it based on amount of time spent or whatnot, but, across projects particularly for folks not contributing code so you can't do based on # of commits - that falls apart 15:12:26 also what would be the axes for a new contributor, (maybe we hide the graph until he has not contributed much) 15:12:44 mizmo: I was thinking # of messages on fedmsg related to the project (and from that user) 15:13:11 sayan: I think the graph shouldn't be on the page by default but available as an option to add 15:13:23 like the linechard widget 15:14:10 pingou: it's not fairly comparable though, eg, translation activities generate less messages than say packaging (pacakging i think generates the most overall) 15:14:30 log transform? 15:14:39 so if i do a little bit of pacakging work, but a lot of design, ambassador, and translation wrok, the graph'll make it look like i'm a big time packager when im not 15:14:46 but I see your point 15:15:35 i think it could be done, but the bang for the buck is maybe a bit low there. it's like a layer 2 or 3 thing in my mind (hope that's fair) 15:15:47 but we probably want to focus on layer 1 stuff for flock 15:16:08 oh! 15:16:11 another thing that came up in the meeting 15:16:13 the radar graph is entirely 'wishful' for me now :) 15:16:19 because we have a number of interns coming on very soon 15:16:22 * pingou notes that we're 1h15 in the meeting 15:16:26 (this was remy's suggesting) 15:16:35 (this is just one quick point and i'm done, sorry to be a meeting hog) 15:16:41 3 interns, 1 GSoC ( devyani7 :)) 15:16:53 :) 15:16:56 we should figure out what we want done for flock, and step back week by week and try to set out some milestones for the interns 15:16:57 mizmo: no worries, I still have 10 minutes :) 15:17:07 mizmo: sounds good def 15:17:13 so they have a clear plan. I think devyani7 probably already has a proposed timeline bc of the GSoC application process, but the other interns won't have that 15:17:57 im going to try to come up with that intern plan for radhika (ux intern) this week 15:18:02 we should schedule something to discuss that, with devyani7 's proposal at hand 15:18:22 do you have this time tomorrow available? 15:18:56 I should have yes 15:19:04 mizmo: you mean 1400 UTC? 15:19:10 cool maybe we can talk intern plans then, devyani7 can you make it? 15:19:15 sayan: let me make sure :) 15:19:17 yes sure :) 15:19:24 1400 UTC , tomorrow 15:19:37 yes, I am free 15:19:37 yes 1400 UTC 15:19:38 ok 15:19:42 \o/ 15:19:46 #topic open-floor 15:19:49 devyani can you make UTC 1400 tomorrow? 15:19:53 devyani7: ^^ 15:20:01 mizmo: yes :) 15:20:05 cool :) 15:20:15 anything else? 15:20:26 we need to update the time on fedocal 15:20:32 it's done already :) 15:20:54 oh 15:21:20 I'm fairly sure I did it 15:21:33 * mizmo is adding a fedocal for meeting tomm 15:21:58 ok let's close 15:21:59 I got a mail today saying the email is tomorrow. 15:22:08 yes 15:22:10 sayan: indeed we should fix this, I was certain I had done it 15:22:13 will check later 15:22:24 #endmeeting