15:02:31 <mizmo> #startmeeting hubs-devel
15:02:31 <zodbot> Meeting started Wed Jan 11 15:02:31 2017 UTC.  The chair is mizmo. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:31 <zodbot> The meeting name has been set to 'hubs-devel'
15:02:41 <mizmo> #topic roll call
15:02:48 <shillman> .hello wispfox
15:02:49 <zodbot> shillman: wispfox 'Suzanne Hillman' <wispfox@gmail.com>
15:02:51 <jcline> .hello jcline
15:02:52 <zodbot> jcline: jcline 'Jeremy Cline' <jeremy@jcline.org>
15:03:01 <mizmo> .hello duffy
15:03:02 <zodbot> mizmo: duffy 'Máirín Duffy' <fedora@linuxgrrl.com>
15:03:53 <abompard> .hello abompard
15:03:54 <zodbot> abompard: abompard 'Aurelien Bompard' <aurelien@bompard.org>
15:04:33 * bexelbie lurks
15:05:03 <mizmo> #topic agenda
15:05:15 <mizmo> okay so here is the summary of yesterday's meeting - https://lists.fedoraproject.org/archives/list/hubs-devel@lists.fedoraproject.org/message/RXP4F6TZZLYO72NFDZKMOV6G7O56KEZQ/
15:05:26 <mizmo> we left off talking about waartaa contributor workflow
15:05:33 <mizmo> i believe what we decided was the following:
15:05:58 <mizmo> * sayan is going to replace the general trello board links in irc-related hubs tickets with links to specific trello cards related to the hubs ticket
15:06:29 <mizmo> * we'll use hubs pagure for mockups for IRC features and descriptions of how to implement them, with links out to the appropriate trello cards
15:06:41 <mizmo> * the trello cards will be updated with links to the github issues that correspond to them (?)
15:06:50 <mizmo> sayan: does this seem right?
15:07:16 <sayan> mizmo: right
15:08:36 <mizmo> ok cool
15:09:09 <mizmo> so i think today the first thing we wanted to cover was which target audience commnity (l10n/g10n, design, commops) we wanted to focus on
15:09:15 <stickster> .hello pfrields
15:09:19 <zodbot> stickster: pfrields 'Paul W. Frields' <stickster@gmail.com>
15:09:19 <bexelbie> Do we know how much work the waarta stuff is, assuming someone sat down and tried to get the mvp parts ready?
15:09:21 <stickster> Sorry for being late, my call ran over
15:09:24 <mizmo> and then we could do a deep dive on the feature(s) needed for that team specifically kind of like what we did for zanata
15:09:25 <mizmo> sound good?
15:09:35 <sayan> mizmo: yes
15:09:42 <mizmo> #topic target audience decision
15:09:47 <mizmo> so we have 3 target audiences right now
15:10:02 <mizmo> g10n/l10n team => relies on external zanata community
15:10:18 <mizmo> comm ops => relies on openstack for the help widget, waartaa for chat
15:10:22 <mizmo> design => relies on waartaa for chat
15:10:40 <mizmo> my thinking is maybe since commops has 2 ext deps we drop that
15:11:10 <mizmo> and decide between g10n/l10n and design. for g10n/l10n we do have a lot of the details about how to work on the zanata stuff outlined now thanks to sayan
15:11:36 <mizmo> for design, the dependency is waartaa, although the bonus there is waartaa touches almost every team we'd have, so it'd be a good feature to get in early and test with a wide impact
15:11:51 <mizmo> zanata is more translator-focused so while it's an important feature it's not something used community-wide
15:12:28 <mizmo> my proposal is to focus on design for now, we already have some widgets that help that team (meeting and tickets), adding IRC into the mix would be a big win and would be a nice basic set of functionality to start testing with that team
15:12:33 <mizmo> any thoughts?
15:12:41 <shillman> This makes sense to me.
15:12:59 <sayan> mizmo: so will put the whole effort on IRC only?
15:13:15 <stickster> I feel that, while the waartaa/IRC issues are probably more effort than on zanata side, they're more global impact, like you said.
15:13:23 <stickster> i.e. bigger payoff
15:13:24 <mizmo> sayan: no, but it would be the main focus of our milestone
15:13:42 <mizmo> sayan: theres other stuff we have in the milestone we need to do (eg the bookmarks bar which is the primary nav element)
15:13:46 <mizmo> sayan: but the main focus would be irc for the first milestone
15:13:50 <jcline> That also sounds good to me
15:13:58 <sayan> mizmo: Ok, got it
15:14:03 <sayan> That's sounds good to me
15:14:04 <mizmo> fair to say #agreed?
15:14:10 <sayan> yes
15:14:52 <mizmo> #agreed we'll focus just on the design team for our milestone 1. this means the main development focus will be on IRC.
15:14:54 <mizmo> cool
15:15:17 <mizmo> so then let's get to a deep dive on what needs to be done in IRC and make sure our tickets / etc are in a good state given this new plan
15:15:19 <mizmo> #topic IRC feature deep dive
15:15:33 <stickster> +1
15:15:51 * mizmo looking up milestone link
15:16:06 <mizmo> https://pagure.io/fedora-hubs/issues?status=Open&tags=milestone
15:16:58 <sayan> This is the main issues here: https://pagure.io/fedora-hubs/issue/2
15:17:44 <sayan> s/issues/issue/
15:17:59 <mizmo> maybe what we could do is leave the milestone tag alone, and make a new 'milestone 1' tag and use milestone as a bucket of higher priority stuff?
15:18:12 <mizmo> eg tagged with milestone - we should do this soon it's one of our 3 target audience priorities.
15:18:17 <mizmo> tagged with milestone1 - we are actively working on it
15:18:21 <sayan> mizmo: +1
15:18:46 <mizmo> okay cool
15:18:58 <mizmo> okay so here is our first ticket for milestone1: https://pagure.io/fedora-hubs/issue/32
15:19:10 <mizmo> IRC mention notifications
15:19:35 <fm-hubs> pagure.issue.tag.added -- duffy tagged ticket fedora-hubs#32: milestone1 https://pagure.io/fedora-hubs/issue/32
15:20:27 <mizmo> this might not be a good one to start wth though since it builds on base functionality we don't have yet, so maybe we'll come back to it later?
15:20:48 <mizmo> let's start with IRC widget
15:20:49 <mizmo> https://pagure.io/fedora-hubs/issue/2
15:22:12 <mizmo> so maybe we could start with the IRC widget - what do we have done needed for it, what do we need done step by step to get this widget working?
15:22:36 <sayan> let's divide this into components
15:22:44 <mizmo> i will say there's a lot unsaid in the mockups in terms of getting the user logged in - the idea is that they wouldn't log in through a UI but it would happen automatically based on config
15:23:33 <sayan> mizmo: based on config as in?
15:24:16 <mizmo> sayan: so fedora accounts have an irc nick in FAS already
15:24:26 <sayan> so you mean to say if I land into design hub so I automatically log in to the #fedora-design channel with the IRC nick from FAS
15:24:49 <mizmo> sayan: since we have a proxy - you should be present in all the channels associated with the hubs you are a member of
15:24:50 <jcline> What if I've already got IRC set up with my own bouncer/client/etc?
15:24:58 <mizmo> whether or not you are on that hub page at the moment
15:25:10 <mizmo> jcline: by default, nobody gets logged in to irc, it's opt in
15:25:32 <mizmo> jcline: so by default the IRC widget should be greyed out with a little promo thing to get you to enablethe feature
15:25:44 <mizmo> i think for basic functionality, this is one path
15:26:08 <mizmo> we could, either now or later on depending on what we want to do, have some user-specific config to use an external proxy rather than hubs' ircb
15:26:46 <sayan> mizmo: what if the user does not want to be present in a particular channel?
15:27:22 <mizmo> sayan: they can go to the hub the channel is associated with and exit that channel from the widget
15:27:29 <sayan> so, it's should be a user-specific config
15:27:40 <mizmo> this is membership, mind you - not following
15:27:59 <mizmo> users who are members of the team in FAS, not just people who follow the hub
15:28:11 <mizmo> yeh i think so
15:28:36 <jcline> Okay, so one task is to have this setting added to the User database model and switch it on and off via the UI, right?
15:28:53 <sayan> I did not get this "this is membership, mind you - not following"
15:29:01 <mizmo> yes!
15:29:11 <mizmo> sayan: i rephrased it in the message below that
15:29:25 <mizmo> i didn't mean "not following" as in "not understanding" i meant, users who are not following the hub
15:29:49 <sayan> Ok
15:29:52 <mizmo> #info task: add setting of whether or not IRC is enable to the User database model and switch it on and off via the UI
15:30:33 <mizmo> #info task: add switch in UI to turn off a given channel in the irc widget so users aren't idling in it if they dont want to
15:30:35 <mizmo> what else?
15:31:39 <sayan> next is handling the login
15:32:12 <mizmo> that won't have a UI component
15:32:26 <mizmo> right?
15:32:29 <sayan> yes, but backend
15:32:37 <jcline> So I've toggled the button on. Hubs needs to then poke the bouncer (ircb) to log me into irc?
15:32:44 <sayan> so once you flip the switch it should start logging you
15:34:18 <jcline> If that's the case, what's the API? Is there an HTTP interface (I know literally nothing about ircb and waartaa)?
15:34:45 <mizmo> #info task: upon clicking on button to enable IRC feature, log user on
15:35:15 <sayan> now the thing is suppose jcline is already using is nick using ZNC
15:35:23 <mizmo> also, we coudl do users enter a channel as they enable irc for each individual hub (so they won't enter channels they dont want to be in), or we could enable it for all hubs channels in one go. maybe it's better to enable it on a hub by hub basis
15:35:29 <sayan> so ircb would log you in using jcline_
15:36:06 <mizmo> since we use freenode, there should probably be a way to put in your nickserv credentials?
15:36:15 <mizmo> then you could just do a recover (if person was registered)
15:36:59 <sayan> but then if he does recover in this widget, he gets logged out in ZNC or any other bouncer or client they are using
15:37:03 <jcline> I'm assuming the interaction with ircb happens on the hub server and not via javascript on the client? Or maybe not?
15:37:30 <sayan> jcline: the plan was rendering as an iframe
15:38:04 <jcline> Perhaps a simpler initial implementation would be to error and tell the user that username is unavailable and to hint they might be logged in elsewhere
15:38:38 <mizmo> so....
15:38:45 <mizmo> i think it's better to recover and ill tell you why
15:38:52 <mizmo> if you have a proxy set up elsewhere, you know what you are doing.
15:39:24 <mizmo> you opted in to the feature, and we can put a little warning when you opt in that it will disconnect your nick on any proxies / etc you may have running.
15:40:13 <sayan> if you don't want you cannot use the IRC widget feature, right?
15:40:14 <jcline> What happens when a new user has a name collision with someone on freenode? Won't that be confusing?
15:40:28 <mizmo> i think for the less savvy user, whom this feature is really targeted towards, they just want to be able to log in and to have it just work. not learn about the intricacies of how IRC works.
15:40:58 <mizmo> jcline: so they enter in a freenode user account in FAS so it's already a freenode nick
15:41:16 <mizmo> jcline: if they are new, and don't have one yet, they won't have anything in FAS
15:41:30 <mizmo> jcline: so this is a specal case we need to consider - we set them up with a nick on freenode and hopefuly register it for them
15:41:42 <mizmo> jcline: im not sure that having a nick that someone else has already registered would be a common case?
15:41:58 <mizmo> since it's either a nick they've already been using for a while, or they have none and we can set it up for them?
15:42:06 <sayan> mizmo: happens quite oftem
15:42:23 <sayan> if they are new
15:42:45 <mizmo> sayan: if they are new, we are the ones setting it up for them, so we can help them select a nick that doesn't clash, right?
15:42:50 <sayan> people who have common names try to log with their first name and have a conflict
15:43:08 <sayan> mizmo: oh ok then
15:43:08 <jcline> Okay, so another task is when I'm new and my account doesn't have an irc name field, direct the user to that page to fill out?
15:43:19 <mizmo> but if they are new and logging in with hubs for the first time, we have the opportunity to guide them to select a nick that works
15:43:23 <sayan> mizmo: If somebody already using IRC, that should not be the case
15:43:35 <jcline> Or does the setup happen in hubs?
15:43:35 <mizmo> jcline: yep! and that needs a mockup too
15:44:05 <mizmo> #info task: for users who do not have an IRC nick configed in FAS, we need to direct them to set one up
15:44:10 <mizmo> where do we want it to happen
15:44:15 <sayan> mizmo: and it link it up with the FAS account
15:44:17 <mizmo> can we handle this in hubs or do we need to implement in FAS?
15:44:26 <sayan> if that's possible
15:44:40 <mizmo> i was envisioning a little modal wizard in hubs to step them through it
15:44:44 <jcline> From a user perspective, it seems like setting it up in hubs would be best. Looking at the FAS account thing, it looks like I can set the irc nick to anything and it's not checked. It's been so long, is there some sort of confirmation process?
15:44:48 <sayan> mizmo: hubs I would say
15:44:51 <mizmo> and yeh it'd save out to FAS afterwards
15:45:15 <mizmo> #info task: mock up tool for helping new users set up their freenode nick and register it. should save out to FAS afterwards
15:45:44 <mizmo> jcline: i think there might be an email confirmation, lemme check
15:46:50 <mizmo> pon registering, you will receive an email with a verification command that you will need to run to complete the registration process. Failure to verify the account will cause it to be automatically dropped after about 24 hours.
15:46:59 <mizmo> http://freenode.net/kb/answer/registration
15:48:49 <mizmo> so we have to handle that case where the 24 hours passes and they havent verified
15:49:30 <sayan> mizmo: I guess if the confirmation is not done then it is treated as unconfirmed or unidentified
15:49:42 <jcline> Hmm. Okay. So we assume we've got this little checkbox enabled *and* we've got an account on freenode that works. ircb is told to connect and possibly identify the user. The user's browser uses waartaa to talk to ircb. Right?
15:49:54 <mizmo> sayan: even worse the nick is deregistered
15:50:10 <mizmo> #info task: figure out how to handle when user doesn't confirm email acct with freenode after 24 hrs of nick reg
15:50:16 <sayan> jcline: yes
15:50:42 <sayan> jcline: think of waartaa as just another IRC client and ircb is the bouncer setup
15:50:54 <jcline> sayan, yup
15:51:55 <sayan> suppose the user is successfully registered and logged in the next thing is to render the chat page
15:53:00 <sayan> remember hubs sents the data from the user-config on which all channels to connect
15:53:19 <shillman> If we are looking for accounts that are valid for new users, do we need the email confirmation thing? Or is it a terrible idea to skip that?
15:53:31 <shillman> (or can we?)
15:53:42 <jcline> So my inclination in terms of implementation priority is to handle the happy case first (I have an account that doesn't clash, I'm not logging in anywhere else, etc)
15:54:17 <sayan> shillman: this is on freenode nick registration side
15:54:32 <shillman> Gotcha. So no real choice abou tit.
15:55:09 <jcline> So right now someone could start on updating the the user model and adding a UI element to update the irc on/off setting, correct? It doesn't sound like anything is blocking that.
15:56:05 <sayan> jcline: Yep, that's not blocking
15:56:24 <sayan> btw, a question here: do we need login with FAS in waartaa?
15:56:51 <sayan> no, right. We can have a REST API accepting data and creating users in waartaa
15:57:27 <mizmo> sayan: id assume hubs would get the nick from fas and pass that on to waartaa?
15:58:17 <jcline> Maybe a better question is, of the tasks we've outline, what is blocked by a task in waartaa/ircb?
16:00:03 <stickster> ^ good question, so that we can direct some work there if needed to help sayan
16:00:45 <sayan> jcline: yes, I was going to tell that only
16:00:58 <sayan> mizmo: yes, that would be the easiest
16:02:13 <sayan> jcline: at the basic level, we would need a login mechanism and the chat page
16:02:47 <sayan> login mechanism would mostly be backend and that is handled by ircb REST API direclty
16:04:18 <sayan> but we need to create a login page also through which we log in the user from backend
16:05:17 <jcline> sayan, okay. So this login mechanism... Is this to log in to freenode? Triggered by enabling irc in the UI?
16:06:43 <sayan> jcline: both actually
16:06:52 <sayan> 1. Create user and logs in to freenode
16:07:15 <sayan> 2. Login via waartaa to generate the session cookies
16:08:23 <jcline> create the user where exactly? In ircb?
16:08:31 <sayan> jcline: yes
16:08:47 <jcline> Okay
16:09:08 <sayan> Now things left to do
16:09:36 <sayan> Login page is made, but I am working on redux integration of the data that is sent back from server
16:10:04 <sayan> waartaa is powered by aiohttp and react+redux
16:10:52 <jcline> okay, so waartaa provides the login page. Sorry for all the basic questions/statements, but I want to make sure I understand.
16:11:01 <sayan> jcline: yes
16:11:13 <sayan> let me dig out a link
16:12:40 <sayan> https://raw.githubusercontent.com/waartaa/mockups/543ff43bc93a032621661a1bd069fbbae2bd19c8/PNG/login_v3_existing.png
16:13:08 <mizmo> sayan: i dont think this UI should be in hubs though right?
16:13:37 <sayan> mizmo: no, this would not come in hubs, but we internally would pass the user through this page
16:13:41 <sayan> and log the user in
16:13:47 <sayan> and this is the chat page
16:13:50 <sayan> https://raw.githubusercontent.com/waartaa/mockups/master/PNG/chat_v1.png
16:14:08 <mizmo> ah ok
16:14:14 <sayan> unauthenticated users cannot see the chat page in waartaa
16:16:57 <sayan> should we discuss the chat page also?
16:17:56 <sayan> it's a single page and cannot be broken
16:18:07 <mizmo> so...
16:18:14 <mizmo> when i mocked that up the intention was for a standalone client
16:18:19 <jcline> When you say "we internally would pass the user through this page" what exactly do you mean by that (in terms of API interactions and who is talking to whom)?
16:18:21 <mizmo> but for a hubs widget it needs to look fundamentally different
16:19:44 <sayan> jcline: we log the user to waartaa
16:20:59 <sayan> mizmo: different like? My impression was the mobile version of the site would look like the widget
16:21:07 <sayan> and that would render inside the widget
16:21:19 <sayan> mizmo: as we are rendering as an iframe
16:21:40 <mizmo> sayan: yeh it should look like the widget. not like this: https://raw.githubusercontent.com/waartaa/mockups/master/PNG/chat_v1.png
16:21:49 <jcline> Is there any documentation for waartaa? I don't think it is what I think it is.
16:22:04 <sayan> jcline: nope
16:22:21 <mizmo> the widget mockup is in the ticket, it looks like this: https://pagure.io/fedora-hubs/issue/raw/files/169892f224708c95900184ea81aa4c51d20bd1b63165e022e73041c85687b48a-ircpm_5.png
16:22:48 * jcline sighs
16:22:53 <sayan> mizmo: yes, so this is something like the mobile view
16:23:28 <sayan> jcline: documentation for setting up?
16:24:01 <sayan> mizmo: so what would happen if the user is connected to multiple channels?
16:24:25 <sayan> mizmo: how would that be reflected in the widget?
16:24:28 <mizmo> sayan: the widget onyl shows one channel. if they want to go to another channel they go to the hub page for that channel
16:24:41 <mizmo> sayan: irc is really deeply integrated in the hubs design...
16:24:47 <jcline> Er, documentation on anything I suppose, but I had things like system diagrams, use cases, installation and setup, APIs (if any), etc in mind
16:25:24 <mizmo> each hub page deals with one topic/team. it wouldn't make any sense to change channels in that model - if i'm on the fedora packaging committee hub, there is no reason #fedora-design shuld ever be displayed
16:25:56 <shillman> jcline: https://www.howtoforge.com/tutorial/waartaa-irc-client-ubuntu-14.04/ might help. So might http://www.waartaa.com/blog/
16:26:26 <sayan> waartaa blog would be outdated
16:26:31 <shillman> Ah.
16:26:40 <sayan> jcline: you will find a few talks on building ircb
16:27:01 <shillman> http://www.rtnpro.com/tag/waartaa/ maybe? Didn't look closely.
16:27:18 <shillman> (not sure whose username that is)
16:27:53 <sayan> mizmo: oh ok then I was correct. I misinterpreted something you told in the beginning of the meeting
16:28:06 <mizmo> sayan: oh ok
16:28:19 <sayan> so I thought a hub can have multiple channels
16:28:45 <sayan> mizmo: just confirming, one hub would have only one channel, right
16:28:48 <sayan> ?
16:29:13 <mizmo> sayan: i would imagine in 99.9% of cases yes. in the case a hub would want a second channel, they'd need to configure a second IRC widget imho
16:29:41 <sayan> mizmo: ok, cool
16:30:11 <sayan> so our plan and what demoed in flock also
16:30:39 <sayan> we would have a URL as waartaa.com/channel/#fedora-hubs
16:31:36 <sayan> and that would take to the channel fedora-hubs channel and this URL is what will be rendered in the widget
16:34:20 <mizmo> so how would it display stuff that was hubs specific? like the user's hubs avatar? or a link to their hubs profile?
16:35:31 <mizmo> eg one thing i'd like to see is a on hover preview of their hub profile so you know mizmo = Máirín Duffy, gnokii = Sirko Kemter, etc
16:36:57 <sayan> mizmo: showing profile preview it on the hover would not work in that case
16:37:06 <mizmo> :-/
16:37:18 <sayan> then we need to do direct integration
16:37:23 <sayan> let me think
16:37:47 <mizmo> maybe on hover it could load from hubs so the html of the user profile details weren't in waartaa?
16:39:06 <sayan> then on hover data should be passed from waartaa to hubs
16:40:29 <jcline> So... waartaa is a service that is an irc client to ircb which is an irc bouncer. So waartaa is running on the hubs server. Yes? No? I was initially under the impression waartaa was some javascript irc client that would run on the client and connect to the bouncer or something.
16:40:55 <jcline> I think I would really benefit from a (simple) system diagram
16:41:21 <sayan> jcline: waartaa is a js irc client/ or better browser based IRC client
16:41:30 <sayan> and connects to bouncer
16:41:43 <jcline> Okay. And it runs on the client? In my browser, say?
16:42:12 <jcline> Because the website is using the word service
16:42:13 <sayan> jcline: nope, as a website
16:43:18 <sayan> jcline: something like this http://demo.shout-irc.com/
16:43:19 <jcline> So we're not going to run our own instance of this?
16:43:36 <sayan> jcline: that depends, we can run
16:43:49 <sayan> and chances are high we will
16:44:27 <sayan> but the problem here is that it will load inside the hubs widget as an iframe
16:48:03 <mizmo> so how to solve?
16:49:14 <sayan> mizmo: I am thinking to directly render the IRC widget
16:49:52 <sayan> but then we need to think of the data/chat transfer
16:50:16 <mizmo> by directly render, you mean not in an iframe?
16:50:22 <sayan> mizmo: yes
16:50:36 <mizmo> ah ok
16:51:55 <sayan> rtnpro is the better person who can answer this question. as I might not hit all the corner cases right now
16:53:08 <sayan> mizmo: I think we can by directly communicating with the ircb
16:53:10 <mizmo> okay
16:53:30 <sayan> but when rtnpro and threebean talk they planned on doing this through iframe
16:53:37 <mizmo> so we havent even gotten to PM but
16:53:53 <mizmo> we're getting on to 2 hours now, i think we need a break.
16:54:03 <jcline> +1
16:54:12 <sayan> mizmo: yes, my another meeting will start in another 6 mins
16:54:59 <mizmo> i am going to be at an off site event tomm at this time so i cant do tomm
16:55:29 <mizmo> but that doesnt mean you guys couldn't meet tomm if you wanted to continue then?
16:55:31 <shillman> +1
16:55:43 <sayan> mizmo: Ok, I am thinking to write a etherpad with the points discussed and then move to IRC
16:55:53 <sayan> mizmo: and I will discuss this thing with rtnpro
16:56:01 <sayan> s/IRC/hubs tickets/
16:56:37 <sayan> the etherpad will be a draft so the if somebody comes to the ticket, it's easy for them to understand
16:56:58 <sayan> so can we meet at an hour earlier?
16:57:09 <sayan> tommorow or the same time?
16:57:15 <mizmo> sayan: the etherpad will be a draft of the ticket info?
16:57:25 <mizmo> jcline: whats your availability tomm morning?
16:57:36 <jcline> I'm around, so whatever works for other people
16:57:42 <mizmo> i can't meet even if its an hour earlier, i have to drive up to westford (1 hr trip) then give a talk at a school there
16:58:50 <jcline> We could do Friday and use the time in between now and then to write up the tickets that aren't under discussion and maybe do some research
16:59:54 <sayan> the thing is the meeting starts at 8:30pm my time and since this meeting taking up long. It gets pretty late
16:59:56 <mizmo> i cant do friday
17:00:03 <mizmo> but again, no reason you guys cant meet wo me
17:00:13 <sayan> Friday same time should not be an issue
17:00:21 <mizmo> can you meet at friday at 9 am EST?
17:00:27 <mizmo> thatd be an hour earlier for sayan
17:00:54 <sayan> +1 for me
17:01:23 <jcline> Works for me
17:02:02 <sayan> we meet tommorow?
17:03:15 <jcline> I can do that, but I'd have more time to digest and research if we met on Friday
17:03:30 <shillman> I'm not around Friday due to Arisia, but I'm not sure that my presence is necessary.
17:03:42 <sayan> jcline: shillman: should we meet for just an hour maybe?
17:03:53 <shillman> sayan: can do tomorrow
17:04:45 <sayan> jcline: shillman: I will have a call with rtnpro tomorrow morning, so we can discuss upon that, iframe/direct/or some other way
17:04:53 <jcline> sayan, yeah. To be honest, it sounds like we need to think about the architecture and I can't provide much on that front until I learn more about waartaa/ircb so maybe we should just wait until next Tuesday
17:05:04 <sayan> jcline: I'll build that
17:05:25 <sayan> tommorow morning, that would be my first task
17:05:27 <sayan> :)
17:05:39 <sayan> I am slow and drawing DITAAAs :p
17:05:43 <sayan> s/and/at
17:06:00 <mizmo> okay so meeting on tuesday then?
17:06:05 <jcline> okay, so tomorrow at 15:00 UTC or 14:00 UTC?
17:06:22 <sayan> jcline: 15:00UTC but for an hour
17:06:37 <jcline> Okay.
17:06:37 <mizmo> #agreed meeting tomorrow 1500-1600 UTC (10-11 ET)
17:06:45 <mizmo> cool thanks :)
17:06:51 <mizmo> ill endmeeting now :)
17:06:52 <mizmo> #endmeeting