13:05:43 #startmeeting hubs-devel 13:05:43 Meeting started Tue Dec 19 13:05:43 2017 UTC. The chair is abompard. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:05:43 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:05:43 The meeting name has been set to 'hubs-devel' 13:05:49 #topic Roll Call (Wait for 2 minutes for the Roll Call) 13:06:36 .hello duffy 13:06:37 mizmo: duffy 'Máirín Duffy' 13:06:48 .hello2 13:06:49 shaily: shaily 'None' 13:06:52 .hello2 13:06:53 abompard: abompard 'Aurelien Bompard' 13:07:19 #chair duffy shaily 13:07:19 Current chairs: abompard duffy shaily 13:07:45 #chair mizmo 13:07:45 Current chairs: abompard duffy mizmo shaily 13:08:48 I think ryanlerch is off for the holidays 13:09:00 so I guess that's all of us. 13:09:12 #topic Action items from last meeting 13:09:30 no actions from last meeting 13:09:39 #topic Status Updates 13:09:43 who wants to start? 13:10:04 * mizmo doesn't have any updates 13:10:28 shaily? 13:10:34 yeah sure 13:10:49 i'll just give you guys a link of the user issues widget i made 13:10:51 so we can talk about it 13:11:47 https://i.imgur.com/MMk8QwW.png 13:12:03 i picked up the UI from the PR widget 13:12:28 any changes i should make in it? 13:12:42 also, what do we do about issues created / issues assigned 13:13:01 do we want tabs in the widget, or like a checkbox 13:14:11 shaily: what is the sorting order here 13:14:33 umm last updated 13:14:42 there's an option in the github API 13:14:59 for the rest, i'll check once or sort using the data returned 13:15:03 #link shaily's user issues widget: https://i.imgur.com/MMk8QwW.png 13:15:48 just for some context because i dont have it - is this the bugs widget, or something new? 13:15:57 yes, the bugs widget 13:16:08 ah ok, let me explain the design, not saying it has to go that way - 13:17:15 so rather than have tabs (which may be a good idea), the design idea was to have a config in the widget, where it's either "tickets waiting on me" or "tickets i filed" 13:17:49 tickets waiting on me, is tickets assigned to me, or needinfo to me (I dont know if pagure / github / etc have a needinfo concept tho) 13:18:01 ohhh, from anar's PR i had the idea that we want the user to be able to look at issues filed by anybody 13:18:07 sort order would be last updated 13:18:09 because it has three inputs 13:18:19 shaily: is this the individual version of the widget or the team version 13:18:27 okay, i didn't there were two versions 13:18:40 didn't know* 13:18:47 yeh a lot of widgets have two versions, team vs person 13:18:59 the three inputs - pagure, github, bugzilla? 13:19:09 usernames you want to monitor 13:19:17 like i used abompard's here 13:19:18 oh hm 13:19:42 there isnt a design for that concept 13:20:09 abompard: on the backend, the two versions are two different widgets right 13:20:12 but, honestly, it could be a config box in the widget config and still the exsting designs for individual bugs would work 13:21:14 okay so one widget 13:21:40 wait we dont have their github/pagure/bugzilla in FAS right 13:21:44 so they would have to input it either way 13:22:36 shaily: we're not sure about that yet. Probably. 13:23:06 they could be fields in the config portion of the widget although probably better to centralize? 13:23:39 yeah i guess we should put it in the user hub config (if there isn't one yet) 13:23:45 .hello ryanlerch 13:23:46 ryanlerch: ryanlerch 'Ryan Lerch' 13:23:47 since we need them for the PRs widget too 13:23:51 * ryanlerch is sorry for being late! 13:23:59 mizmo: I was thinking about that too. 13:24:53 needing that means following another user is a bit more difficult too, i would stay to start maybe just cover the individual's data and not worry about other users to follow yet 13:25:12 i mean the concept of hubs higher level is you can follow other users via their hubs, rather than via individual widgets 13:25:28 mizmo: makes sense 13:26:45 abompard: is there a provision for a "hub-wide" config? 13:27:05 shaily: yeah, this has just been merged yesterday IIRC 13:27:09 i remember something of that sort being discussed for team hubs in the last meeting 13:27:37 on a user hub, you probably only want to ever show your own issues, right? 13:28:10 but on a your stream "hub" you might want to show from other users? 13:30:03 ryanlerch: honestly i dont see a huge case for that beyond a mentor checking in on a mentee's progress? 13:30:33 one thing i want to be conscious of is not enabling stalkers.... so if you follow someone via their hub page, that person controls what shows up on their hub page, so you can't follow what they havent put out there 13:30:55 (and obviously all this data is public via fedmsg but aggregation of data in a super usable format can be bad) 13:31:01 mizmo: sounds good to me! 13:31:16 not enabling stalking that is 13:31:26 not stalking 13:31:32 :) 13:31:37 but i think mentor/mentee is a special relationship, although we now have designs for a mentor to track a mentee is a specialized widget so we probably dont need to account for that across every widget 13:33:37 this makes this widget easier to implement too, from a config UI point of view too -- so +1 frome! 13:33:43 *from me 13:35:40 OK! 13:35:40 shaily: ^^ does this make sense then? the suggestion moving forward would be to drop the follow anyone feature 13:36:09 shaily: the way id mocked up this widget too - i sorted the tickets by latest update, across systems. so they weren't segmented by pagure vs github vs bz 13:36:16 lemme see if i can pull up the mockup for you, sec 13:36:47 shaily: https://pagure.io/fedora-hubs/issue/1#comment-2046 13:37:24 oh that's cool 13:37:31 those icons to indicate what platform the ticket is on 13:37:48 so i'll look into the hub config system 13:37:57 and get this up asap 13:38:14 one question, where does View More take you? 13:38:17 from the mockup 13:39:05 shaily: ideally a query page on the ticket system itself showing the full set of tickets assigned to you or tickets you opened 13:39:29 there are three ticket systems here, right 13:39:36 i guess if we have three ticket systems mixed in we'd have to have a link per system which is a bummer 13:39:36 yeh 13:40:18 i mean for a while i had the idea that each widget could have a page on hubs that had fuller info but we always had this argument against storing data in hubs which would mean that wouldn't work 13:40:47 we could just leave out the 'view more' and let users configure in the config screen how many tickets to see 13:41:03 or, clicking view more could retrieve more to display in the widget 13:41:06 in chunks of 5 or something 13:41:25 okay 13:41:36 "tickets waiting on me" and "tickets i filed" 13:41:39 the main user context the 'view more' tries to address is, ok i saw those, are there more i need to worry about beyond these {5} 13:42:01 are those two configurations of the same widget, two different widgets or one widget with two tabs 13:42:03 mizmo: maybe just something like "42 other tickets" 13:42:35 abompard: maybe but its kind of a tease to say, "and there's 42 more! but i won't show them to you, and you can't see them, nyah!" 13:42:45 hehe 13:42:54 having an idea of the full number though, if we can get that == very good 13:43:07 maybe the view more button could show a dropdown with links to the different TS 13:44:03 I think the ticket systems APIs gives you the total count when you make a query anyway. I kind of remember seing that in the bugzilla API at least 13:44:37 ah i like the dropdown idea! 13:44:41 if we could list per system too in the dropdown 13:44:42 eg 13:45:02 "View more on Pagure (24)" "View more on Bugzilla (15)" etc etc 13:45:07 yep 13:45:28 that's a cool idea 13:45:36 great idea! 13:46:17 also, assigned vs authored - how are we dealing with that 13:47:21 assigned tickets go in the 'waiting on me' version, authored goes in the 'tickets i filed' version 13:47:31 (unless i'm misunderstanding) 13:47:39 okay, so two different widgets 13:47:48 or two different configurations? 13:47:55 of the same widget 13:49:17 two different configs of the same widget i think 13:49:28 although i think configuration is not really the best idea here since doing that requires editing Hub layout 13:49:48 and waiting on me / i filed are something you would want to switch between frequently 13:50:07 im not sure about that - 13:50:18 shaily: you can have more than one of the same widget in a hub 13:50:48 i.e. you could set up 2 different configs of the issues widget, one with assigned, one with filed 13:50:55 but maybe my experience is a weird case, many of my 'i filed' tickets are against projects / systems that aren't waht i actually worked on. so tickets 'i filed' are maybe 80% my curiosity / checking up on things i asked for rather than part of my usual workflow 13:51:15 yeh exactly, you'd just configure 2x of the widget to get both on screen if thats what you wanted 13:51:23 okay, that sounds cool 13:54:49 so that's the issues widget 13:54:52 about search now 13:55:37 shaily: so far, then, to recap - i would say drop the follow others feature, have a drop down in the config widget to choose between tickets i filed adn tickets waiting on me, have the 'view more' pop up a drop down with links for each ticket system and a count per system, and do a flat sort across ticket systems like in the mockup rather than segregating htem by system 13:55:43 cool lets move on to search 13:56:56 okay so in the cache, we have key value pairs 13:57:10 the keys being widget IDs 13:57:20 widget instance IDs* 13:57:48 and the value is the data that is being cached 13:58:00 so we could gather all the data across all widgets 13:58:09 search through that for the query 13:58:21 and return the appropriate widget's URL in the results 13:58:52 across all widgets - respecting the scope of the search of course 13:59:49 if that sounds good, i'll implement it in vanilla python first and then see how to bring in the search engine libraries i've been trying out 13:59:58 yeah that sounds good 14:00:12 you can use Whoosh in Python 14:00:14 if you want 14:00:19 it's very basic 14:00:37 but it's closer to the bigger libraries in spirit 14:01:15 yes, that's the first task (trying whoosh) i had in my timeline :D 14:01:42 cool then, i'll complete the issues widget and implement search in whoosh 14:02:30 cool! 14:02:59 any other questions or reports shaily? 14:03:21 I realize we're over 14:03:35 overtime 14:03:38 nope that's all :) my first blog post is up, i'll write a second one this week 14:04:21 ryanlerch: if you have time and want to report your status quickly, you may do so now, but if anyone must go now then feel free to 14:04:32 sorry for letting the meeting slip 14:04:50 abompard: nothing super-pressing to report for me TBH! 14:04:52 * mizmo has time to stay however long 14:05:03 * ryanlerch is happy to wrap! 14:05:04 alright! 14:05:14 closing then. 14:05:29 if you want my status report then go to Pagure and look at the PRs ;-) 14:05:34 :) 14:05:48 #endmeeting