15:02:31 #startmeeting hubs-devel 15:02:31 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:02:31 The meeting name has been set to 'hubs-devel' 15:02:41 #topic roll call 15:02:48 .hello wispfox 15:02:49 shillman: wispfox 'Suzanne Hillman' 15:02:51 .hello jcline 15:02:52 jcline: jcline 'Jeremy Cline' 15:03:01 .hello duffy 15:03:02 mizmo: duffy 'Máirín Duffy' 15:03:53 .hello abompard 15:03:54 abompard: abompard 'Aurelien Bompard' 15:04:33 * bexelbie lurks 15:05:03 #topic agenda 15:05:15 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 we left off talking about waartaa contributor workflow 15:05:33 i believe what we decided was the following: 15:05:58 * 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 * 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 * the trello cards will be updated with links to the github issues that correspond to them (?) 15:06:50 sayan: does this seem right? 15:07:16 mizmo: right 15:08:36 ok cool 15:09:09 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 .hello pfrields 15:09:19 stickster: pfrields 'Paul W. Frields' 15:09:19 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 Sorry for being late, my call ran over 15:09:24 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 sound good? 15:09:35 mizmo: yes 15:09:42 #topic target audience decision 15:09:47 so we have 3 target audiences right now 15:10:02 g10n/l10n team => relies on external zanata community 15:10:18 comm ops => relies on openstack for the help widget, waartaa for chat 15:10:22 design => relies on waartaa for chat 15:10:40 my thinking is maybe since commops has 2 ext deps we drop that 15:11:10 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 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 zanata is more translator-focused so while it's an important feature it's not something used community-wide 15:12:28 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 any thoughts? 15:12:41 This makes sense to me. 15:12:59 mizmo: so will put the whole effort on IRC only? 15:13:15 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 i.e. bigger payoff 15:13:24 sayan: no, but it would be the main focus of our milestone 15:13:42 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 sayan: but the main focus would be irc for the first milestone 15:13:50 That also sounds good to me 15:13:58 mizmo: Ok, got it 15:14:03 That's sounds good to me 15:14:04 fair to say #agreed? 15:14:10 yes 15:14:52 #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 cool 15:15:17 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 #topic IRC feature deep dive 15:15:33 +1 15:15:51 * mizmo looking up milestone link 15:16:06 https://pagure.io/fedora-hubs/issues?status=Open&tags=milestone 15:16:58 This is the main issues here: https://pagure.io/fedora-hubs/issue/2 15:17:44 s/issues/issue/ 15:17:59 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 eg tagged with milestone - we should do this soon it's one of our 3 target audience priorities. 15:18:17 tagged with milestone1 - we are actively working on it 15:18:21 mizmo: +1 15:18:46 okay cool 15:18:58 okay so here is our first ticket for milestone1: https://pagure.io/fedora-hubs/issue/32 15:19:10 IRC mention notifications 15:19:35 pagure.issue.tag.added -- duffy tagged ticket fedora-hubs#32: milestone1 https://pagure.io/fedora-hubs/issue/32 15:20:27 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 let's start with IRC widget 15:20:49 https://pagure.io/fedora-hubs/issue/2 15:22:12 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 let's divide this into components 15:22:44 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 mizmo: based on config as in? 15:24:16 sayan: so fedora accounts have an irc nick in FAS already 15:24:26 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 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 What if I've already got IRC set up with my own bouncer/client/etc? 15:24:58 whether or not you are on that hub page at the moment 15:25:10 jcline: by default, nobody gets logged in to irc, it's opt in 15:25:32 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 i think for basic functionality, this is one path 15:26:08 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 mizmo: what if the user does not want to be present in a particular channel? 15:27:22 sayan: they can go to the hub the channel is associated with and exit that channel from the widget 15:27:29 so, it's should be a user-specific config 15:27:40 this is membership, mind you - not following 15:27:59 users who are members of the team in FAS, not just people who follow the hub 15:28:11 yeh i think so 15:28:36 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 I did not get this "this is membership, mind you - not following" 15:29:01 yes! 15:29:11 sayan: i rephrased it in the message below that 15:29:25 i didn't mean "not following" as in "not understanding" i meant, users who are not following the hub 15:29:49 Ok 15:29:52 #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 #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 what else? 15:31:39 next is handling the login 15:32:12 that won't have a UI component 15:32:26 right? 15:32:29 yes, but backend 15:32:37 So I've toggled the button on. Hubs needs to then poke the bouncer (ircb) to log me into irc? 15:32:44 so once you flip the switch it should start logging you 15:34:18 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 #info task: upon clicking on button to enable IRC feature, log user on 15:35:15 now the thing is suppose jcline is already using is nick using ZNC 15:35:23 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 so ircb would log you in using jcline_ 15:36:06 since we use freenode, there should probably be a way to put in your nickserv credentials? 15:36:15 then you could just do a recover (if person was registered) 15:36:59 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 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 jcline: the plan was rendering as an iframe 15:38:04 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 so.... 15:38:45 i think it's better to recover and ill tell you why 15:38:52 if you have a proxy set up elsewhere, you know what you are doing. 15:39:24 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 if you don't want you cannot use the IRC widget feature, right? 15:40:14 What happens when a new user has a name collision with someone on freenode? Won't that be confusing? 15:40:28 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 jcline: so they enter in a freenode user account in FAS so it's already a freenode nick 15:41:16 jcline: if they are new, and don't have one yet, they won't have anything in FAS 15:41:30 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 jcline: im not sure that having a nick that someone else has already registered would be a common case? 15:41:58 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 mizmo: happens quite oftem 15:42:23 if they are new 15:42:45 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 people who have common names try to log with their first name and have a conflict 15:43:08 mizmo: oh ok then 15:43:08 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 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 mizmo: If somebody already using IRC, that should not be the case 15:43:35 Or does the setup happen in hubs? 15:43:35 jcline: yep! and that needs a mockup too 15:44:05 #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 where do we want it to happen 15:44:15 mizmo: and it link it up with the FAS account 15:44:17 can we handle this in hubs or do we need to implement in FAS? 15:44:26 if that's possible 15:44:40 i was envisioning a little modal wizard in hubs to step them through it 15:44:44 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 mizmo: hubs I would say 15:44:51 and yeh it'd save out to FAS afterwards 15:45:15 #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 jcline: i think there might be an email confirmation, lemme check 15:46:50 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 http://freenode.net/kb/answer/registration 15:48:49 so we have to handle that case where the 24 hours passes and they havent verified 15:49:30 mizmo: I guess if the confirmation is not done then it is treated as unconfirmed or unidentified 15:49:42 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 sayan: even worse the nick is deregistered 15:50:10 #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 jcline: yes 15:50:42 jcline: think of waartaa as just another IRC client and ircb is the bouncer setup 15:50:54 sayan, yup 15:51:55 suppose the user is successfully registered and logged in the next thing is to render the chat page 15:53:00 remember hubs sents the data from the user-config on which all channels to connect 15:53:19 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 (or can we?) 15:53:42 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 shillman: this is on freenode nick registration side 15:54:32 Gotcha. So no real choice abou tit. 15:55:09 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 jcline: Yep, that's not blocking 15:56:24 btw, a question here: do we need login with FAS in waartaa? 15:56:51 no, right. We can have a REST API accepting data and creating users in waartaa 15:57:27 sayan: id assume hubs would get the nick from fas and pass that on to waartaa? 15:58:17 Maybe a better question is, of the tasks we've outline, what is blocked by a task in waartaa/ircb? 16:00:03 ^ good question, so that we can direct some work there if needed to help sayan 16:00:45 jcline: yes, I was going to tell that only 16:00:58 mizmo: yes, that would be the easiest 16:02:13 jcline: at the basic level, we would need a login mechanism and the chat page 16:02:47 login mechanism would mostly be backend and that is handled by ircb REST API direclty 16:04:18 but we need to create a login page also through which we log in the user from backend 16:05:17 sayan, okay. So this login mechanism... Is this to log in to freenode? Triggered by enabling irc in the UI? 16:06:43 jcline: both actually 16:06:52 1. Create user and logs in to freenode 16:07:15 2. Login via waartaa to generate the session cookies 16:08:23 create the user where exactly? In ircb? 16:08:31 jcline: yes 16:08:47 Okay 16:09:08 Now things left to do 16:09:36 Login page is made, but I am working on redux integration of the data that is sent back from server 16:10:04 waartaa is powered by aiohttp and react+redux 16:10:52 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 jcline: yes 16:11:13 let me dig out a link 16:12:40 https://raw.githubusercontent.com/waartaa/mockups/543ff43bc93a032621661a1bd069fbbae2bd19c8/PNG/login_v3_existing.png 16:13:08 sayan: i dont think this UI should be in hubs though right? 16:13:37 mizmo: no, this would not come in hubs, but we internally would pass the user through this page 16:13:41 and log the user in 16:13:47 and this is the chat page 16:13:50 https://raw.githubusercontent.com/waartaa/mockups/master/PNG/chat_v1.png 16:14:08 ah ok 16:14:14 unauthenticated users cannot see the chat page in waartaa 16:16:57 should we discuss the chat page also? 16:17:56 it's a single page and cannot be broken 16:18:07 so... 16:18:14 when i mocked that up the intention was for a standalone client 16:18:19 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 but for a hubs widget it needs to look fundamentally different 16:19:44 jcline: we log the user to waartaa 16:20:59 mizmo: different like? My impression was the mobile version of the site would look like the widget 16:21:07 and that would render inside the widget 16:21:19 mizmo: as we are rendering as an iframe 16:21:40 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 Is there any documentation for waartaa? I don't think it is what I think it is. 16:22:04 jcline: nope 16:22:21 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 mizmo: yes, so this is something like the mobile view 16:23:28 jcline: documentation for setting up? 16:24:01 mizmo: so what would happen if the user is connected to multiple channels? 16:24:25 mizmo: how would that be reflected in the widget? 16:24:28 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 sayan: irc is really deeply integrated in the hubs design... 16:24:47 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 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 jcline: https://www.howtoforge.com/tutorial/waartaa-irc-client-ubuntu-14.04/ might help. So might http://www.waartaa.com/blog/ 16:26:26 waartaa blog would be outdated 16:26:31 Ah. 16:26:40 jcline: you will find a few talks on building ircb 16:27:01 http://www.rtnpro.com/tag/waartaa/ maybe? Didn't look closely. 16:27:18 (not sure whose username that is) 16:27:53 mizmo: oh ok then I was correct. I misinterpreted something you told in the beginning of the meeting 16:28:06 sayan: oh ok 16:28:19 so I thought a hub can have multiple channels 16:28:45 mizmo: just confirming, one hub would have only one channel, right 16:28:48 ? 16:29:13 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 mizmo: ok, cool 16:30:11 so our plan and what demoed in flock also 16:30:39 we would have a URL as waartaa.com/channel/#fedora-hubs 16:31:36 and that would take to the channel fedora-hubs channel and this URL is what will be rendered in the widget 16:34:20 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 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 mizmo: showing profile preview it on the hover would not work in that case 16:37:06 :-/ 16:37:18 then we need to do direct integration 16:37:23 let me think 16:37:47 maybe on hover it could load from hubs so the html of the user profile details weren't in waartaa? 16:39:06 then on hover data should be passed from waartaa to hubs 16:40:29 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 I think I would really benefit from a (simple) system diagram 16:41:21 jcline: waartaa is a js irc client/ or better browser based IRC client 16:41:30 and connects to bouncer 16:41:43 Okay. And it runs on the client? In my browser, say? 16:42:12 Because the website is using the word service 16:42:13 jcline: nope, as a website 16:43:18 jcline: something like this http://demo.shout-irc.com/ 16:43:19 So we're not going to run our own instance of this? 16:43:36 jcline: that depends, we can run 16:43:49 and chances are high we will 16:44:27 but the problem here is that it will load inside the hubs widget as an iframe 16:48:03 so how to solve? 16:49:14 mizmo: I am thinking to directly render the IRC widget 16:49:52 but then we need to think of the data/chat transfer 16:50:16 by directly render, you mean not in an iframe? 16:50:22 mizmo: yes 16:50:36 ah ok 16:51:55 rtnpro is the better person who can answer this question. as I might not hit all the corner cases right now 16:53:08 mizmo: I think we can by directly communicating with the ircb 16:53:10 okay 16:53:30 but when rtnpro and threebean talk they planned on doing this through iframe 16:53:37 so we havent even gotten to PM but 16:53:53 we're getting on to 2 hours now, i think we need a break. 16:54:03 +1 16:54:12 mizmo: yes, my another meeting will start in another 6 mins 16:54:59 i am going to be at an off site event tomm at this time so i cant do tomm 16:55:29 but that doesnt mean you guys couldn't meet tomm if you wanted to continue then? 16:55:31 +1 16:55:43 mizmo: Ok, I am thinking to write a etherpad with the points discussed and then move to IRC 16:55:53 mizmo: and I will discuss this thing with rtnpro 16:56:01 s/IRC/hubs tickets/ 16:56:37 the etherpad will be a draft so the if somebody comes to the ticket, it's easy for them to understand 16:56:58 so can we meet at an hour earlier? 16:57:09 tommorow or the same time? 16:57:15 sayan: the etherpad will be a draft of the ticket info? 16:57:25 jcline: whats your availability tomm morning? 16:57:36 I'm around, so whatever works for other people 16:57:42 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 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 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 i cant do friday 17:00:03 but again, no reason you guys cant meet wo me 17:00:13 Friday same time should not be an issue 17:00:21 can you meet at friday at 9 am EST? 17:00:27 thatd be an hour earlier for sayan 17:00:54 +1 for me 17:01:23 Works for me 17:02:02 we meet tommorow? 17:03:15 I can do that, but I'd have more time to digest and research if we met on Friday 17:03:30 I'm not around Friday due to Arisia, but I'm not sure that my presence is necessary. 17:03:42 jcline: shillman: should we meet for just an hour maybe? 17:03:53 sayan: can do tomorrow 17:04:45 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 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 jcline: I'll build that 17:05:25 tommorow morning, that would be my first task 17:05:27 :) 17:05:39 I am slow and drawing DITAAAs :p 17:05:43 s/and/at 17:06:00 okay so meeting on tuesday then? 17:06:05 okay, so tomorrow at 15:00 UTC or 14:00 UTC? 17:06:22 jcline: 15:00UTC but for an hour 17:06:37 Okay. 17:06:37 #agreed meeting tomorrow 1500-1600 UTC (10-11 ET) 17:06:45 cool thanks :) 17:06:51 ill endmeeting now :) 17:06:52 #endmeeting