15:02:08 #startmeeting hubs-devel 15:02:08 Meeting started Tue Jan 10 15:02:08 2017 UTC. The chair is mizmo. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:08 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:02:08 The meeting name has been set to 'hubs-devel' 15:02:42 .hello sayanchowdhury 15:02:43 sayan: sayanchowdhury 'Sayan Chowdhury' 15:02:45 .hello pfrields 15:02:46 stickster: pfrields 'Paul W. Frields' 15:02:47 .hello jcline 15:02:49 jcline: jcline 'Jeremy Cline' 15:02:53 .hello abompard 15:02:53 .hello wispfox 15:02:53 abompard: abompard 'Aurelien Bompard' 15:02:56 .hello devyani7 15:02:57 shillman: wispfox 'Suzanne Hillman' 15:02:57 .hello a2batic 15:02:59 devyani7: devyani7 'Devyani Kota' 15:03:01 .hello duffy 15:03:02 a2batic: a2batic 'Kanika Murarka' 15:03:05 mizmo: duffy 'Máirín Duffy' 15:03:06 .hello chawlanikhil24 15:03:11 chawlanikhil24: chawlanikhil24 'Nikhil Chawla' 15:03:57 #topic meeting agenda 15:04:02 hey so youve probably seen my note to the list? 15:04:07 lemme grab the link 15:04:17 https://lists.fedoraproject.org/archives/list/hubs-devel@lists.fedoraproject.org/thread/5AN2LIA6K4372LPW554R6N5MFBOZRTW2/ 15:04:32 yes 15:04:53 so the main thing is that we've kind of blown past our milestone and while we've been making progress (thank you for that!!!), we don't seem to be a whole lot closer to completing the milestone stuff 15:05:10 and just as a reference that milestone stuff is here: https://pagure.io/fedora-hubs/issues?status=Open&tags=milestone 15:05:26 it's 10 tickets... although some are quite deep, and some dependent on external stuff we dont have much control over - 15:06:00 although, i think for an app like hubs that basically aggregates data from a lot of different apps and doesnt originate much of its own data, working with external teams with different priorities is something we'll need a good solution for 15:06:21 Yeah, that seems like one of the major stumbling blocks -- iow, really great ideas, but they involve a lot of dependencies where we're getting "stuck in the mud," so to speak 15:06:38 sayan and i met last week and started going thru the chunks of work that correspond to the goals we set for the first milestone 15:06:48 mizmo++ sayan++ 15:06:48 stickster: Karma for duffy changed to 10 (for the f25 release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:06:48 i'm going to reiterate them here then give you the link to the full log there - 15:06:51 stickster: Karma for sayanchowdhury changed to 4 (for the f25 release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:06:56 COOKIE PARTY 15:06:57 1) zanata 15:06:57 2) waartaa 15:07:01 3) badges 15:07:04 https://meetbot.fedoraproject.org/meetbot/teams/hubs-devel/hubs-devel.2017-01-05-13.29.log.txt 15:07:08 4) release cycle widget 15:07:08 #link https://meetbot.fedoraproject.org/meetbot/teams/hubs-devel/hubs-devel.2017-01-05-13.29.log.txt 15:07:14 5) bookmarks bar 15:07:15 6) help widget / err bot 15:07:17 thanks sayan :) 15:07:39 so what we ended up doing - 15:08:00 we did a deep dive into what would be required for someone not familiar with the feature to start making progress on the zanata feature 15:08:21 i think we got pretty far on that right sayan? i think we pretty much got it to a level that it was the right amount of info for anybody to get started 15:08:24 Like, building out the list of TODO for that feature to work? 15:08:40 +100 15:08:47 mizmo: yes, but we only completed zanata 15:09:25 stickster: yeh diving down into small atomic chunks 15:09:29 have to start somewhere :-) 15:09:37 the meeting was quite in depth and also popped up a few more questions regarding the architecture 15:10:41 how can someone refer chunks of already existing code to build up the widget 15:10:46 right, the one architecture issue we talked about was our ability to load the pages quickly 15:11:42 mizmo: so one thing I was thinking of pushing hubs to production and people start using it? 15:11:48 and if our cache system is going to serve in this capacity at the level we need for the UX we want 15:11:58 sayan: i think it is way too premature for that, and i will tell you why 15:12:06 a long time ago we did an app called fedora community 15:12:34 and it was actually pretty feature complete for one specific workflow (the wrong one - packagers), and also was slow bc of external data dependencies 15:13:21 it kind of flopped bc people tried it, found out it didnt do anything they needed or didn't do anything new that made their lives better, and kind of forgot about it and never tried it again 15:13:24 and i dont want that to happen here - 15:13:47 the idea behind the milestones we set was to try to offer a *new* experience for specific fedora community members that they couldn't get anywhere else that would improve their workflow 15:14:11 we focused on 3 specific teams who often dont get these kinds of tools made for them - 15:14:20 design, commops, and globalization/localization 15:14:36 all of which are high-growth-potential teams 15:14:38 so thats where the current milestones come from 15:14:43 because easy entry for newbies 15:15:03 now if we had a milestone complete set of features for even just *one* of those teams, i'd say, hey, let's deploy to staging and try to get some individual members of that team trying it out and get their feedback 0 15:15:18 but i dont think we have enough done for any one team for that to be a useful exercise at this point :/ 15:15:20 mizmo: in that case deploy to staging 15:15:32 but the staging should be close, very close to the production 15:15:36 sayan: what would we get from that tho? 15:16:17 I think the point of staging is it's easier for current contributors to test and file issues 15:16:28 mizmo: right, feedback from the users 15:16:48 sayan: maybe s/users/current and potential contributors/ more likely? 15:16:48 we already have a devel deployment tho dont we? 15:17:06 mizmo: yes, we do have a devel instance 15:17:09 question: is the devel deployment hooked up to other required infra pieces? 15:17:19 But people don't use the devel instance 15:17:25 So we can see what the performance is like, wrt. fedmsg and other stuff? 15:17:25 Last I looked, the devel instance is really, really out of date 15:17:40 We want people to use the devel instance and get feedback from it 15:17:42 sayan: if people dont use devel would they use staging? 15:18:07 mizmo: I am considering devel=staging here 15:18:52 i think it would be useful to the designers we have working on hubs to have a non-local instance of hubs to play with - 15:18:54 having something in stg basically gives us a chance to hook it up to any other staging infrastructure piece, IIUC 15:19:27 but i dont think design is a blocker either 15:19:31 so that would be useful to designers, contributors, and even (if people start to get aware and interested) some users of initial milestone stuff 15:19:47 eg shillman and chhavi are working on regional and edu hubs respectively, those aren't milestone features 15:20:36 stickster, sayan: i dont know what kind of effort it would take to get a devel/staging instance up and updated regularly etc. and if it's worth doing vs applying effort towards getting the milestones more feature complete? 15:20:38 mizmo: since we are low on contributors we need to decide again on our milestones 15:21:20 mizmo: we to milestone releases to devel and tell people to use it 15:21:38 I do plan on pushing an update to fmn to staging in the next week to include the SSE server so you could hook the staging hubs instance up to that 15:21:53 jcline++ 15:21:53 sayan: Karma for jcline changed to 4 (for the f25 release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:21:57 i think to have a milestone release we should at least have a basic set of features for one of our initial target audience groups 15:22:14 jcline++ 15:22:14 mizmo: Karma for jcline changed to 5 (for the f25 release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:22:32 mizmo: I think it's a balance... maybe a combination of what we're talking about. So, focusing on *one* team, but also getting that team's Hub in an initial push to staging 15:22:37 jcline++ 15:22:37 stickster: Karma for jcline changed to 6 (for the f25 release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:22:59 * jcline feasts on cookies 15:23:09 mizmo: Being able to get more to "release early release often" means we need to get any deployment issues figured out, anyway 15:23:12 jcline, sayan: is SSE in FMN going to be new? or is there already some SSE component in place? 15:23:13 It might crash and burn, but it's good to know that early :) 15:23:19 (i'm wondering how big a deal this is :) ) 15:23:34 It's new 15:23:43 \o/ big deal! \o/ 15:23:49 jcline: what impact will it have? 15:23:52 You can configure it like any other notification system (email, irc, etc) 15:23:54 mizmo: yeah new, powers the stream 15:24:00 will it make getting data from fedmsg quicker? 15:24:17 From my understanding it's just what populates the stream 15:24:24 mizmo: something atelic and skrzepto worked on 15:24:48 but right now stream has dummy data, once we have fmn sse we can plugin real data 15:25:07 to the stream 15:25:19 ahhh okay awesome! 15:25:39 yeah, right on! 15:25:50 it currently only support individual's hub 15:25:50 okay so let's talk about whittling our milestone workitems now to something smaller we could deploy to devel/staging sooner - 15:26:00 we have g10n/l10n which is dependent on zanata which is external 15:26:03 for group hubs it will require some more hacking on fmn 15:26:14 we have commops, the help widget is dependent on errbot at the moment as a blockage 15:26:18 pingou: right 15:26:36 we have design, which i think is served already by the pagure ticket widget but, i think IRC is critical for that team 15:26:59 (i think irc less critical to l10n/g10n, probably critical for commops too) 15:27:37 so, one idea would be to try to focus on the design team for milestone 1 (full disclosure im totally biased here being on that team ;-) ), but that will involve a deep dive into IRC and really focusing on getting the IRC features working 15:27:59 irc work is going very slow :( 15:28:41 mizmo: I was talking to sayan earlier about g11n/l10n and he's going to be consulting with Alex Eng about zanata side, but I agree it might make sense not to block on that 15:29:10 mizmo: ^^ regarding the payload and the API pull 15:29:13 sayan: should we talk about what's got it going slow, and maybe we could get help? 15:29:42 since I am the only one working on it right now 15:30:00 so I do a very small chunk of task each week 15:30:11 #info jcline will be pushing fmn update int he next week to include SSE server which will enable personal data streams with real data, could be hooked up in stage 15:30:29 #info sayan working with aeng on payload and api pull for zanata 15:30:51 sayan: should we break down the IRC work the way we broke down the zanata work and use that to get more folks working on it? 15:31:41 mizmo: we already have the work broken down, I would love to see more folks working on it 15:32:11 sayan: mizmo: maybe we can get help from a couple other devs present? 15:32:45 sayan: great! is it in the github tickets? can you give sort of a brief overview of the codebases involved, and current status? 15:33:52 mizmo: https://trello.com/b/RetFEvn2/waartaa 15:34:05 The codebase is here: https://github.com/waartaa/waartaa/ 15:34:38 we are right now working on the branch v0.2 15:34:46 sayan: how do we get membership to the trello board? 15:34:46 https://github.com/waartaa/waartaa/tree/v0.2/waartaa 15:35:05 sayan: there is also ircb too, right? 15:35:25 mizmo: yes, ircb is pretty much complete 15:35:36 like it has the features needed for waartaa to use it 15:35:41 sayan: oh okay great! so the main codebase to focus on is waartaa 15:35:55 so the architecture is the waartaa is the web interface, the IRC client 15:36:05 and ircb is the IRC bouncer 15:36:14 does ircb do pms? 15:36:40 theres a few items tagged with ircb as todo on trello, wondering if they need to be updated or if some are still open 15:37:11 mizmo: yes, those need to be done 15:37:33 ircb does PM but there is an issues, the pms gets posted twice 15:37:40 :) 15:37:45 s/issues/issue 15:38:02 the rest are not crictical issues 15:38:17 Would it be helpful to have a clear tracker issue in the hubs that defines what needs to get done internally and externally (and what specific issues are blocking externally)? Looking at it right now leaves me a little lost. 15:38:21 sayan: if I look at that Trello, I can't tell what that problem in ircb is. 15:38:29 okay so maybe a few ircb issues to work on too but main focus is waartaa. 15:38:30 jcline: +1 15:38:34 https://pagure.io/fedora-hubs/issue/32 seems to be that issue, but there's not a lot to guide me on what to work on 15:38:39 yeh the trello user stories need to be filled out more 15:39:11 with links to the github issues/tickets ideally 15:39:32 we should break down the webui items too which are kind of broad 15:40:48 mizmo: so right now I am working on the signin page, both backend and frontend 15:40:59 now for that we have a major card for it 15:41:27 and then we broke down the issues into smaller issues, like for signup, I need to build up the signin form and then do redux integration 15:41:37 and similarily for signup 15:41:52 ^^ this is for the basic auth 15:42:19 ah okay so the trello cards are the high level user story and each may have multiple issues linked underneath, i see that on the sign up card here altho the issues aren't linked to github tix - https://trello.com/c/8bBtyah1/20-signup-basic-auth 15:42:52 do all of the cards with todo list items have the github tix already created, or only the inprogress ones? 15:43:07 mizmo: in progress ones have that 15:43:53 mizmo: becuase I am working on that I chalked that out 15:44:36 I'm confused by the use of both trello/github here, but since I'm not writing code, maybe that's not important 15:44:58 I am also confused by the use of both 15:45:01 * stickster doesn't care about systems, but does care that everyone knows how to find the next task to do, knows what it means, and can work on it easily 15:46:18 sayan: mizmo: Let's straighten out one process, I think this is where mizmo is trying to get clear, too... if jcline wants to help write some critical-path code right now, and doesn't know where to start, what would sayan expect him to do? Go to trello? To Github? other? 15:46:34 (I use jcline as an example here) 15:46:49 stickster: jcline: ok so you want to know the process 15:47:00 I think he would need to go to trello, pick off a chunk of work, and create issues for each of the todo list items under that chunk? 15:47:48 trello is setting goals to the project, we have different projects/stories/goals listed in the first card 15:48:10 sayan: that's the "Signup basic auth" card? 15:49:03 * stickster hopes he is not dragging this meeting away from purpose here 15:49:04 stickster: no the Stories/Goals/Projects 15:49:06 Say I want to do https://pagure.io/fedora-hubs/issue/32, what stories/issues are blocking it externally? 15:49:29 stickster: no this is what we need to do i think 15:49:43 mizmo: right 15:49:45 trello must have some github integration we could use to hook this stuff up? 15:50:20 sayan: so if we're going to use trello as a tool here to organize work i think everybody needs to have a trello account and be granted membership to this board. is that right? 15:50:51 mizmo: I don't know if we can make public 15:50:55 let me see it real quick 15:51:23 Is there something trello is offering here that github/pagure/etc issues wouldn't provide? 15:51:24 jcline: that is blocking externally on waartaa 15:52:04 now waartaa is the irc client that would come as a widget inside fedora hubs 15:52:36 now waartaa's main two pages are the Chat Page and the User Signup 15:52:55 Right now I am workin on the User Signup but nobody is on the Chat Page 15:54:26 So is that this issue? https://github.com/waartaa/waartaa/issues/220 15:54:57 jcline: yes, this is that issue 15:55:46 now Chat page is a very broad topic here and we need to divide it into small chunks 15:56:10 trello helps chunk related multiple issues together 15:56:43 you could do that in github or pagure say with tags but you cant set metadata in tags like you can on a trello card to help organize 15:56:53 ok, understood 15:57:03 now, our idea is that when we have divided into chunks and add it as sub-task 15:57:07 mizmo: long term planning: add this to pagure :-p 15:57:22 but if we cant get access to trello it's going to be hard to use it as a tool 15:57:33 pingou: or you could have pagure integrate with taiga? taiga does basically the same thing 15:57:40 The problem I'm having is everything is spread out across issue trackers and if I go to the hubs issue tracker I (or any new contributor) have these sweeping user stories with no technical details or indication of things to actually do. 15:57:50 jcline: that's the problem I'm having as ewll 15:57:51 *well 15:58:14 so how about this for an approach? 15:58:18 just a proposal: 15:58:20 - don't use trello 15:58:21 * stickster listens for suggestions 15:58:25 Really these are tasks to *plan* tasks 15:58:31 - use tickets in pagure under the hubs project as the high level chunks 15:58:49 jcline: the thing is diffrent projects uses diffrent issues trackers 15:58:49 - have the high level pagure/fedora-hubs chunk issues each have links out to the subtasks in waartaa's github issues 15:59:00 like zanata is using JIRA 15:59:29 rtnpro prefers trello 15:59:36 so he built up this one 15:59:38 then, if you're used to working in pagure/fedora-hubs, you'll still use that as the central organization for stuff to work on, but the individual subtasks will remain in the upstream waartaa tracker on github. and we'd still have the chunking / subtask organization 16:00:00 sayan: the issue, though, is that trello is a tool for Agile/kanban, and that *requires* that cards be more fully described, it's specifically *not* good for high-level 16:00:06 the main issue i see with trello besides not being floss is that we don't have access to it and it requires creating yet another account 16:00:40 mizmo: that too, although I think even if that problem was magically fixed, it's like trying to use a screwdriver on a nail 16:01:53 I could see trello still being useful but only for sayan and rtnpro 16:02:50 sayan, yeah, and that's okay. The problem is that going from a hubs issue (#32 for example), reading the issue it's not clear what project needs to get worked on, nor the issues within that project. I know now, but only because we've had this discussion. 16:03:45 this seems kind of a silly thing to get hung up on 16:03:56 sayan, rtnpro do you have an alternative proposal? 16:04:08 as long as (1) everyone here knows to send contributors to the Pagure issues for critical issues, and (2) those issues fully describe the problem to solve (and if needed, steps to take to solve it), things are good 16:04:39 (to be clear, I don't mind if other projects use a combination of issue trackers. I just want to know what to do when I look at a hubs issue) 16:04:41 mizmo: should github issue work well? tagging to github issues? 16:05:02 mizmo: sayan: would you say that (1) and (2) are true for critical-path issues right now? If so, that's awesome 16:05:31 If not, let's fix that so that e.g. jcline, abompard, others can jump in more easily. Because we need that to be true in order to attract other devs as well 16:05:42 stickster: i think that assumes we'd use pagure for the chunks (if just for hubs-devel purposes) which im not sure sayan and rtnpro are agreeding to 16:05:54 sayan: in pagure or trello? 16:06:45 mizmo: how do we plan to add this to pagure? 16:07:29 sayan: well i proposed above we copy the trello cards into individual pagure issues, and each pagure issue would have links to the upstream github issues in the ticket comments 16:07:42 so the code of waartaa is in Github, I move the trello board to github waartaa issues repo 16:08:45 and tag them with the component it is connected to 16:09:42 and in pagure we describe what needs to be done in waartaa to get the thing done 16:10:09 sayan: so why don't you and rtnpro keep using the trello board as you're using it, and we'll make a copy of it in pagure so fedora hubs contributors have a central place to go? 16:10:34 is that how it would work? 16:10:36 mizmo: Okay, works for me 16:10:52 So thinking about this from jcline perspective again (sorry to abuse you jcline) ;-) 16:11:00 Won't that get out of sync though? 16:11:30 yeah, jcline you just leapfrogged me (which is fine) 16:11:42 jcline: one thing that we need to do is update the the pagure fedora-hubs ticket 16:11:50 i dont know how you would move the trello board to github? 16:12:01 mizmo: github has kanban cards now just like trello. 16:12:22 so you can manage the project in one place 16:12:22 stickster: ohhhh i didnt realize that 16:12:36 I think keeping copies of data in two places is setting up for failure 16:12:47 I didn't intend to kick of a discussion of waartaa's issue/task tracking. What I wanted to highlight is that the milestones/tasks/issues for hubs need to be fleshed out. 16:13:04 jcline: understood -- I think these are symptoms of the same problem 16:14:18 example: https://github.com/fedora-infra/fas/projects/1 16:14:50 oh 16:14:54 sayan: mizmo: jcline: can I have a moment to describe what's happening for me, so I can see whether I need to just STFU? 16:15:03 when did github come up with this 16:15:07 sayan: Sept 2016 16:15:29 jcline: for example suppose you need to work on https://github.com/fedora-infra/fas/projects/1 16:15:33 oops wrong link :( 16:15:40 sayan: can you hold on for a moment 16:15:40 https://pagure.io/fedora-hubs/issue/32 16:15:46 stickster: sure 16:15:57 sayan: you're starting the same place I was going to, though, which is perfect :-) 16:16:06 So here's what I do in looking at hubs. 16:16:24 1. I start looking at most critical tasks: https://pagure.io/fedora-hubs/issues?status=Open&tags=milestone 16:16:42 2. I identify issue #32 on that list, https://pagure.io/fedora-hubs/issue/32 16:17:24 3. I read that issue, and it has great mockups describing how things should look when done 16:18:01 4. As I read through, I see that somehow this has to do with waartaa backend. The link points me to the trello board https://trello.com/b/RetFEvn2/waartaa 16:18:40 5. The trello board has no description of what the blocking issues are. I don't know what's needed, and the only way for me to write any code is to find sayan and/or rtnpro and get them to describe to me the situation. That doesn't scale. 16:18:56 jcline: Would you agree that is a good statement of the problem we're trying to solve? 16:19:14 stickster: +1 16:19:50 can I go ahead a probable solution? 16:19:53 sure 16:20:00 thanks for letting me regurgitate :-D 16:20:06 stickster, yeah. In addition, it's not clear how we're going to use waartaa to do this thing. Is it offering an API? What API? Is this all UI work? What major tasks need to get done in hubs itself? 16:20:22 jcline: agreed 16:20:37 The first thing that we do is remove that link, and rather link to a card in waartaa 16:20:53 s/waartaa/trello board/ 16:20:59 for this case it would be 16:21:25 https://trello.com/c/FGSWyW89/28-chat-page-rooms 16:21:41 github.issue.opened -- suzannehillman opened issue #226 on fedora-infra/fas: [RFE] More nuanced 'active' vs 'inactive' states https://github.com/fedora-infra/fas/issues/226 16:22:06 now, we write the complete solution to the problem as the IRC widget is powered by waartaa and how waartaa is powered by ircb 16:22:39 and then we can approach the solution to this problem 16:23:17 breaking them into chunks and listing them here 16:23:25 and also as sub-tasks to the card 16:23:31 i.e https://trello.com/c/FGSWyW89/28-chat-page-rooms 16:23:59 :thumbsup: 16:24:12 agreed 16:24:19 now the problem here is the person might work on a single sub task 16:24:38 so we collaborate that on the hubs issue tracker 16:24:39 In the past I've filed issues where the issue was "Write a detailed issue about " and the work was doing the research and writing a good story 16:24:53 *nod 16:25:11 and once it is done we edit the comment in hubs and strike that off 16:25:22 and we strike that off in the waartaa trello board 16:25:26 as done 16:26:23 does that sound okay? 16:27:02 sayan: I think that sounds reasonable, again as long as the sub tasks are well described 16:27:19 And as long as information isn't duplicated 16:27:38 jcline: agreed, pointers should go to one source of info about the task/story 16:27:50 The hubs issue tracker should describe in detail work needing to be done in waartaa, it should point to a waartaa issue/card that does that 16:27:59 shouldn't* 16:28:21 jcline: +1, keep it in the upstream project 16:28:43 project pagure tracker is great for mockups etc. and references to those upstream issues 16:29:00 because those are about Fedora implementations of Hubs, not waartaa specifically 16:29:06 right mizmo ? 16:30:17 oops did I lose everyone? 16:30:19 stickster: that explanation would be there in fedora hubs 16:30:32 sayan: yup, in pagure 16:31:40 Okay, then I'll do that 16:32:27 Should we end the end the meeting here? Need to catch a morning flight tomorrow :) 16:32:45 * mizmo a bit worried we're not getting anywhere? 16:32:46 Also, should we have another meeting to have things sorted? 16:33:00 sayan: mizmo: I know we got deep into solving this problem. But did we also settle the issue of tightening focus? 16:33:40 mizmo: yes, can we have another meeting scheduled tomorrow? 16:33:43 stickster: jcline ^^ 16:33:51 Works for me 16:34:30 the agenda would be to get things sorted and plan the next milestone 16:35:01 it feels like we needed to solve problem of "how can people help when they didn't understand tasks," and that seems on track to being solved. Now there's also making sure the plan for what tasks are critical, and what to focus on, and where to deploy, so everyone's on same page 16:35:09 ^^ mizmo would you agree with that? 16:35:11 by things I mean the issues here 16:36:21 personally I'm +1 to mizmo idea of focusing more specifically on a team, and making the tasks that affect that team's hub the critical milestone tasks 16:36:39 Yeah, that also makes sense to me 16:37:09 and then pushing to deploy a working solution to stg, so it can be tested not just for functionality, but also identify performance issues, connection issues, all those things that we can't yet predict that would affect production 16:37:10 Once we decide what team and issues, we can work on detailing those issues as we talked about here 16:37:17 Not sure we decided which team. It sounded like Design works less well because IRC complications, but unclear if other teams have similar blocks. 16:37:44 shillman: different teams have different blocks as mizmo mentioned 16:38:00 commops and design would be blocked heavily on IRC 16:38:19 whereas the i18n folks would be blocked on the zanata integration 16:38:30 We need to identify the block that we are most likely to be able to clear ourselves. For instance, if IRC complications, should we (including abompard) agree to move forward and *not* block on openstack folks, if that's the issue (I'm not 100% sure) 16:39:10 stickster: agreed. It's not cleat yet to me if there is a block that's easier or harder for us to get done. 16:39:33 +1 16:39:36 that seems like the best discussion to have tomorrow, if you guys agree 16:39:45 +1 16:39:50 i think my client died and i missed a lot :( 16:39:52 I think I can hack the widget to not require the changes in meetbot and find its info elsewhere (in hubs config) 16:39:53 oops 16:39:53 :( 16:40:01 mizmo__: We have a log fortunately :-) 16:40:05 \o/ 16:40:57 I know this first issue wasn't fun to go through, but we can't collaborate at any scale without solving it... i.e. no call for contributors would help us if they show up and can't figure out what to do :-) 16:41:10 There was a lot of trying to solve the problem ot two tools and making it easier for people to figure out what to do. And we were just discussing the idea of meeting tomorrow to try to figure out which team's block is the most tractable for us to handle. 16:41:20 shillman: great summary 16:41:23 shillman++ 16:41:23 stickster: Karma for shillman changed to 2 (for the f25 release cycle): https://badges.fedoraproject.org/tags/cookie/any 16:41:58 shillman, thanks!! "which team's block" <= what does this mean 16:42:17 IRC seems to block two of the three teams hubs being functional. 16:42:29 And Zanata the third. 16:42:40 mizmo: figuring out which team to focus on, based on the difficulty of hte particular blocking/critical items for each... how likely we can clear them ourselves 16:42:45 That/ 16:42:46 . 16:42:52 ohhh ok 16:42:57 yes 16:43:20 Time for tomorrow's powwow? 16:43:24 well i think maybe irc maybe makes the most sense in that we are closest to that upstream :) and it helps the most hubs 16:43:32 can we do the same battime that this one normally starts? 16:43:37 * stickster can do that 16:43:40 same time? 16:43:43 +1 16:43:45 +1 16:43:51 +1 16:43:51 #agreed meet tomorrow 16:43:54 oops 16:43:57 +1 16:44:00 #undo 16:44:00 #agreed meet tomorrow 16:44:03 ha 16:44:12 #undo 16:44:12 Removing item from minutes: AGREED by mizmo at 16:44:00 : meet tomorrow 16:44:20 #agreed meet tomorrow at the same time (1500 UTC) 16:44:20 #agreed meeting tomorrow 16:44:27 mizmo++ 16:44:40 cool see you tomorrow :) 16:44:45 gonna end meeting 16:44:48 #endmeeting