13:03:46 <sayan> #startmeeting hubs-devel
13:03:46 <zodbot> Meeting started Tue Nov 28 13:03:46 2017 UTC.  The chair is sayan. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:03:46 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:03:46 <zodbot> The meeting name has been set to 'hubs-devel'
13:04:24 <sayan> #topic Roll Call
13:04:31 <shaily> .hello
13:04:31 <zodbot> shaily: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
13:04:35 <mizmo> .hello duffy
13:04:36 <zodbot> mizmo: duffy 'Máirín Duffy' <fedora@linuxgrrl.com>
13:04:39 <sayan> .hello sayanchowdhury
13:04:40 <shaily> .hello shaily
13:04:40 <zodbot> sayan: sayanchowdhury 'Sayan Chowdhury' <sayan.chowdhury2012@gmail.com>
13:04:43 <zodbot> shaily: shaily 'None' <shaily15297@yahoo.com>
13:05:09 <mleonova> .hello mleonova
13:05:10 <zodbot> mleonova: mleonova 'Maria Leonova' <mleonova@redhat.com>
13:05:52 <sayan> mleonova: hey
13:05:56 <sayan> abompard: aroudn?
13:06:01 <mleonova> hi sayan
13:06:08 <fm-hubs> pagure.issue.comment.added -- ryanlerch commented on ticket fedora-hubs#469: "Subscriptions / Joining a Hub / Starring a Hub" https://pagure.io/fedora-hubs/issue/469#comment-481687
13:06:09 * sayan waits for abompard for some time
13:06:15 <ryanlerch> .hello ryanlerch
13:06:16 <zodbot> ryanlerch: ryanlerch 'Ryan Lerch' <rlerch@redhat.com>
13:06:18 <sayan> #chair shaily mizmo ryanlerch mleonova
13:06:18 <zodbot> Current chairs: mizmo mleonova ryanlerch sayan shaily
13:06:36 <abompard> .hello abompard
13:06:37 <zodbot> abompard: abompard 'Aurelien Bompard' <aurelien@bompard.org>
13:06:38 <abompard> sorry I'm late
13:06:56 <sayan> #topic Action items from last meeting
13:07:27 <sayan> * mizmo working on search designs for outreachy project
13:09:14 <mizmo> is that the only action? i dont have anything to report
13:09:24 <mizmo> shaily are you working on search right now?
13:09:43 <shaily> nope, i was working on adding messages to pagure
13:10:04 <shaily> the PR at pagure has been merged, i've to add support for those messages at fedmsg
13:10:05 <fm-hubs> pagure.issue.comment.edited -- ryanlerch edited a comment on ticket fedora-hubs#469: "Subscriptions / Joining a Hub / Starring a Hub" https://pagure.io
13:10:08 <sayan> mizmo: yes, that's the only action items
13:10:13 <shaily> and then use them in hubs
13:10:36 <mizmo> ok cool
13:10:45 <mizmo> shaily: so you're not blocking on search designs right?
13:11:05 <shaily> nope, i'll share my timeline with you. gimme a minute
13:12:00 <shaily> duffy at redhat, right?
13:12:37 <fm-hubs> pagure.issue.comment.added -- duffy commented on ticket fedora-hubs#469: "Subscriptions / Joining a Hub / Starring a Hub" https://pagure.io/fedora-hubs/issue/469#comment-481688
13:13:03 <mizmo> shaily: yep!
13:13:06 <mizmo> shaily: that would be super helpful, thanks!
13:13:35 <sayan> Moving onto the tickets then
13:13:39 <sayan> #topic Hub Bio & Rules / Contact always at top of the page https://pagure.io/fedora-hubs/issue/462
13:14:12 <sayan> mizmo: what's your input on this ticket?
13:14:43 <mizmo> sayan: i agree with ryan's suggestion as that was the original intention. the only thing im thinking about here when it's mandatory is to allow the user to shade these boxes to make more room to see widgets below
13:15:28 <mizmo> the gfx on the ticket are misisng the white bg though so i wouldn' tfollow the mockups from a vis design pov
13:16:03 <mizmo> https://pagure.io/fedora-hubs/issue/162
13:16:19 <ryanlerch> mizmo: whoops, sorry that was my bad
13:16:41 <mizmo> theres a sep one for groups
13:16:51 <mizmo> but im stlil looking for each
13:16:57 <mizmo> looking for it. each widget has a ticket
13:17:09 <mizmo> we were using some of the tickets as design specs
13:17:32 <ryanlerch> abompard: doing this would mean making the contact, rules, and bio not "widgets" as such, right?
13:17:48 <abompard> ryanlerch: correct
13:17:48 <mizmo> uhh... it looks like my pagure issue tags for specs are gone :(
13:18:45 <abompard> oh noes
13:20:29 <mizmo> here it is: https://pagure.io/fedora-hubs/issue/8
13:20:40 <mizmo> there used to be a ux-spec or ui-spec tag that made these easier to find hehe
13:21:33 <ryanlerch> abompard: one thing to consider here too especially with the contact box -- if we make it not a widget, you loose the ability for the widget visibility stuff (preview), etc
13:21:59 <mizmo> what if instead of making it not a widget make a different class of widget or subclass or whatever
13:22:59 <ryanlerch> mizmo: like making them fixed widgets that you can't re-arrange?
13:23:13 <mizmo> ryanlerch: yeh
13:23:20 <mizmo> i mean it's the same thing on the front end
13:23:43 <mizmo> but you shouldnt have to literally unwidget them if that makes sense?
13:24:22 <abompard> ryanlerch: well contact & rules is probably not something you want to hide on preview hubs, or do you?
13:24:41 <ryanlerch> abompard: maybe contact
13:24:53 <mizmo> no it should be visible in preview
13:25:02 <mizmo> the point of preview is to see what itll look like right
13:25:21 <fm-hubs> pagure.issue.comment.added -- duffy commented on ticket fedora-hubs#462: "Hub Bio & Rules / Contact always at top of the page " https://pagure.io/fedora-hubs/issue/462#comment-481692
13:25:36 <abompard> I don't know exactly ;-) My understanding is that preview hubs want to make some widgets public and some private
13:25:38 <ryanlerch> preview is one of the visibility modes that you can set a hub to
13:25:48 <ryanlerch> one of three
13:26:02 <mizmo> oh preview isnt what you see when you hit edit?
13:26:03 <mizmo> ohhh
13:26:10 <mizmo> you mean when you can only see a subset because you're not a member
13:26:11 <mizmo> got it
13:26:14 <abompard> yeah
13:26:43 <mizmo> so for a user's info widget thingy - i dont see hiding any of it, if it's available in FAS they made it public
13:26:45 <ryanlerch> yeah, that stuff is available on user hubs, but not really sure how that works since you cant be a member of a user hub
13:27:00 <mizmo> for instance if the user made their location in FAS private, then, it won't show up even if you are their friend
13:27:45 <abompard> mizmo: oh, I'm not sure I'm checking that.
13:27:45 <mizmo> fora  group hub, i dont think theres any reason to hide that stuff either
13:28:04 <ryanlerch> okies -- done! :)
13:28:08 <ryanlerch> agreed!
13:28:26 <mizmo> ryanlerch: there was a rule written out for how a user hub is private or visible to a given user, let me see if i can find it
13:28:39 <fm-hubs> pagure.issue.new -- abompard opened a new ticket fedora-hubs#472: "Contact widget: check that the location isn't displayed if it is set to private in FAS" https://pagure.io/fedora-hubs/issue/472
13:28:44 <fm-hubs> pagure.issue.edit -- abompard edited the priority fields of ticket fedora-hubs#472 https://pagure.io/fedora-hubs/issue/472
13:29:31 <ryanlerch> according to the descriptiopn in the config dialog, preview means you can select certain widgets that are only visible to logged in users
13:29:44 <ryanlerch> that that does make sense for user hubs i suppose
13:29:49 <abompard> ah, right, it's visible to logged-in users, not members
13:29:58 <mizmo> ohhh ok
13:30:03 <mizmo> thats a whole other facet
13:30:05 <ryanlerch> sorry, i was mistaken there
13:30:27 <mizmo> yeh some widgets make little sense if you're not logged in because we need a fas id to provide data for them
13:30:51 <abompard> mizmo: actually it's not the visitor's FAS ID that's used to display that info
13:31:00 <abompard> it's a "system account"
13:31:27 <abompard> so it was more of a privacy setting
13:31:44 <abompard> if I understand correctly
13:31:50 <mizmo> ah ok
13:32:04 <mizmo> i will say, the initial design for hubs was that if you weren't logged in you couldn't see anything
13:32:14 <mizmo> so i dont think there has been a lot of thinking about the not logged in case
13:32:38 <ryanlerch> mizmo: interesting
13:32:56 <ryanlerch> was it changed for a reason?
13:32:57 <mizmo> (from my end anyway :) )
13:33:06 <mizmo> the thinking being - you can't query FAS without being logged in
13:33:34 <shaily> that only holds for a user's own hub, right
13:34:14 <mizmo> ryanlerch no i think it just ended up getting implemented allowing for logged out viewing, i dont remember if it was an explicit decision or not, likely bc to start there was no log in system
13:34:25 <mizmo> shaily: what in particular?
13:34:59 <ryanlerch> mizmo: fair enough
13:35:02 <shaily> fetching data that is dependent on the viewer's FAS credentials
13:35:06 <abompard> mizmo: if it's the only technical reason then this reason isn't valid.
13:35:07 <abompard> because querying FAS is done on the backend
13:35:07 <abompard> and cached
13:35:30 <ryanlerch> is the hub visibility stuff something we want to get right / included in MVP?
13:35:40 <mizmo> shaily: im not suer that is the case - e.g. the group hub version of the badges widget lists the FAS user's rank respective to other team members
13:35:59 <mizmo> ryanlerch: as long as we're not committing any grave privacy ills i dont see it being particularly critical to MVP
13:36:48 <mizmo> abompard: no no the idea that it shouldn't be visible logged out wasn't because of technical issues - it was more the privacy thought, if you cant see FAS data not logged in, why are we making that public
13:37:13 <abompard> mizmo: yeah that's what I remember too
13:37:55 <mizmo> i mean we could (eventually) follow the twitter model where you go to the front page and you get a sign up prompt
13:38:01 <mizmo> but if someone gives you a direct link you can see it
13:38:06 <mizmo> a direct deep link
13:38:09 <mizmo> but maybe thats stupid
13:38:19 <shaily> mizmo: so a user can't see any FAS data (anyone's) without logging into FAS?
13:38:48 <mizmo> shaily: yep you cant see anything wo login see https://admin.fedoraproject.org/accounts/
13:39:02 <mizmo> i mean if we want to dive into logged in vs logged out viewing
13:39:33 <mizmo> logged in only viewing of data means more privacy, means anyone viewing the data has agreed to whatever legalese / codes of conduct / etc you must agree to when signing up, means they are human or run by a human, etc
13:40:02 <shaily> thanks, okay. so there are three modes - logged out, logged in, member. right?
13:40:05 <mizmo> however a con is that one of the 2 key goals of hubs is to help onboard new contributors. so it requires account creation as a barrier to entry to be able to 'shop around' the teams by viewing the team hubs and seeing what they are working on
13:40:41 <mizmo> creating a FAS account - how difficult is that to do? i dont know
13:40:55 <mizmo> i think it's been a significant barrier for certain types of potential contributors
13:41:07 <mleonova> pretty easy, if you ask me
13:41:10 <mizmo> vs logged out viewing
13:41:40 <mizmo> makes it easier to 'shop around' teams if you don't know what team you want to join or if it's even worth creating a FAS account
13:41:56 <mizmo> and, it makes private a lot of data that, ok it's public in other places, but aggregations of data particularly user activity across platforms in a really easy to use manner is kind of scary
13:42:09 <mleonova> true :)
13:42:16 <mizmo> shaily: member / not member is a different modality.
13:42:22 <mizmo> shaily: i could draw a tree. sec :)
13:43:48 <shaily> FAS account creation seems pretty straightforward to me, with the possible exception of that one math equation it asks you to solve for verification :P
13:44:03 <shaily> it needs your name, email and a security question
13:44:03 <ryanlerch> so currently you can view user hubs and group hubs without being logged in
13:45:20 <ryanlerch> https://hubs-dev.fedorainfracloud.org/ryanlerch/
13:48:31 <mizmo> https://i.imgur.com/Eum6qKp.png
13:48:54 <mizmo> shaily: we've had a lot of confusion and hand wringing over the captchas which can be excessively hard
13:49:48 <ryanlerch> mizmo: mutual subscribers?
13:50:26 <mizmo> ryanlerch: yeh so - not saying this model makes sense but - we've talked about in the past, if you request to subscribe to a user hub, the user has to also subscribe to you so you're 'friends' and see each other's stuff
13:50:44 <ryanlerch> also, in my testing, subscribing doenst actually do anything (yet)
13:50:46 <mizmo> alternatively could just be an approval process so you could have one way follows
13:50:52 <ryanlerch> my stream is always empty
13:51:03 <mizmo> my stream is always empty too, im not sure how to make it work
13:51:12 <mizmo> that seems like probably the most critical issue for MVP
13:51:15 <sayan> ryanlerch: yes, that is still in work
13:51:32 <sayan> #link https://pagure.io/fedora-hubs/issue/158
13:52:32 <shaily> is it like a filtered version of the Live Feed widget on the user hub?
13:53:09 <ryanlerch> currently too though, anyone can view all my fedmsgs on my feed widget too, right?
13:53:29 <sayan> ryanlerch: right!
13:54:18 <fm-hubs> pagure.issue.edit -- sayanchowdhury edited the close_status and status fields of ticket fedora-hubs#443 https://pagure.io/fedora-hubs/issue/443
13:54:18 <ryanlerch> just wondering how that fits in with the mutal subscriber idea
13:54:51 <fm-hubs> pagure.issue.edit -- sayanchowdhury edited the close_status and status fields of ticket fedora-hubs#442 https://pagure.io/fedora-hubs/issue/442
13:55:53 <fm-hubs> pagure.issue.comment.added -- sayanchowdhury commented on ticket fedora-hubs#436: "Hubs widget: implement as in the mockup" https://pagure.io/fedora-hubs/issue/436#comment-481705
13:56:26 <mizmo> ryanlerch: so 'my feedwidget' for ryanlerch != user profile for ryanlerch, so i dont think any other user should be able to see your feedwidget
13:56:29 <fm-hubs> pagure.issue.comment.added -- ryanlerch commented on ticket fedora-hubs#436: "Hubs widget: implement as in the mockup" https://pagure.io/fedora-hubs/issue/436#comment-481706
13:56:42 <fm-hubs> pagure.issue.edit -- ryanlerch edited the close_status and status fields of ticket fedora-hubs#436 https://pagure.io/fedora-hubs/issue/436
13:57:32 <mizmo> this is the comparison between the two https://pagure.io/fedora-hubs/issue/84
13:59:30 * sayan needs to run into another meeting
13:59:37 <sayan> And we are at time
13:59:57 <sayan> Should we end the meeting and continue the discussion, or do you want to continue and one possibly closing the meeting?
14:00:42 <sayan> mizmo: my feedwidget is the stream are you talking of?
14:00:57 <mizmo> sayan: yeh same thing
14:01:08 <sayan> mizmo: ok
14:01:33 <ryanlerch> mizmo: those mocks do have a stream widget on the profile view thought right?
14:01:51 <mizmo> ryanlerch: which one
14:01:55 <mizmo> which mockup
14:02:04 <ryanlerch> https://pagure.io/fedora-hubs/issue/84
14:02:08 <sayan> ryanlerch: mizmo: would you close the meeting, I need to run off to another meeting
14:02:10 <sayan> ?
14:02:23 <mizmo> sayan: sure
14:02:23 <ryanlerch> https://pagure.io/fedora-hubs/issue/raw/6beed7d9cf562725001abc14d5b341c8e689c295eaf81e23daa747003f53cfd0-profile-vs-stream_profile-someoneelse.png
14:02:27 <sayan> mizmo: thanks
14:02:48 <mizmo> ryanlerch: that mock is the user's profile. it does have a feed widget, yeh
14:02:56 <mizmo> theres a 'public' version of that mockup too
14:03:25 <mizmo> it basically only shows 5 items in the feedwidget and has a card at the bottom that says 'subcsribe to see more of $user's recent activity' [subscribe]
14:04:10 <shaily> mizmo: oh, so subscribing vs not subscribing only differentiates between the number of items you see on a user's feed?
14:04:21 <mizmo> shaily: no
14:04:41 <shaily> okay, five items respecting certain privacy constraints
14:04:42 <shaily> i guess
14:05:04 <mizmo> shaily: you have to subscribe to a user to see both their full feed widget on *their* page, and on your *my streams* page
14:05:18 <mizmo> shaily: but you can't see more than 5 items on their page and you cant follow them in your  my streams page unless they have approved your subscription req
14:06:02 <shaily> mizmo: thanks, one last thing. say i subscribe to your hub, but you don't subscribe to mine
14:06:03 <mizmo> shaily: yeh five items so you cant see their fully history or whatnot
14:06:16 <shaily> mizmo: what does that change for me
14:06:21 <ryanlerch> okies, this is all stuff we have to get implemented for MVP
14:06:39 <ryanlerch> none of these concepts exist in the code yet afaik
14:06:46 <mizmo> shaily: thats an open question. either we have a subscription approval process so i can approve your sub request and i dont necessarily subscribe to you, or we promote mutual subscriptoin by requiring it to see someone else's stuff
14:06:58 <ryanlerch> currently you can just subscribe to anyone's hub
14:07:29 <ryanlerch> and there is no approving their request or anything
14:07:39 <mizmo> ryanlerch: the effect of subscribing to someone's hub i guess is iminimal right now though, because the feed widget doesn't work
14:07:42 <mizmo> so you cant get a feel for what it even means
14:08:01 <ryanlerch> mizmo: the feed widget works for me
14:08:11 <mizmo> i mean we could tweak the idea if you could get the feel, do you know what i mean
14:08:12 <mizmo> it's kind of hard to make the call without real data from my pov
14:08:13 <ryanlerch> the my streams page is the one that doesnt work
14:08:34 <mizmo> ryanlerch: oh?
14:08:40 <mizmo> does it work on the dev instance
14:08:54 <ryanlerch> https://hubs-dev.fedorainfracloud.org/ryanlerch/
14:09:30 <mizmo> egon design team i see "Dummy  Lorem ipsum dolor" for feed widget
14:09:39 <mizmo> ahh ok
14:09:45 <mizmo> i wasn't following users so i didnt see that
14:10:21 <ryanlerch> https://hubs-dev.fedorainfracloud.org/designteam/
14:10:29 <ryanlerch> just added the feed widget there
14:10:35 <mizmo> ryanlerch: this requires log in to see though right?
14:10:42 <mizmo> ryanlerch: if you go to that URL ipsilon comes up
14:11:22 <ryanlerch> mizmo: nope -- it works not loggin
14:11:25 <ryanlerch> https://hubs-dev.fedorainfracloud.org/designteam/
14:11:42 <ryanlerch> good luck logging out ;)
14:11:54 * ryanlerch uses a private tab to test logged out stuff
14:12:16 <mizmo> that feels really invasive
14:12:25 <mizmo> that you can see all of that not logged in
14:13:26 <mizmo> i wonder how involved it would be to just require login for everything?
14:13:31 <mizmo> i feel like that would be good enough for MVP
14:14:08 <abompard> mizmo: we could do that
14:14:34 <mizmo> abompard: is it very involved to do?
14:14:50 <ryanlerch> mizmo: not really i dont think
14:14:54 <abompard> mizmo: not sure yet but I think not
14:15:11 <ryanlerch> we should make the all groups page public though
14:15:29 <ryanlerch> and maybe create a landing page at the front too
14:16:29 <ryanlerch> mizmo: tomorrow i'll try to write up a bug to encapsulate what needs to be done on the side of subscription approvals / mutual subscription
14:16:53 <ryanlerch> is that something that we want to still persue even if the whole site requires a FAS account?
14:18:31 <mizmo> ryanlerch: yeh i think we still want to do subscription approvals /mutual subscription for user hubs, but if those user hubs are behind FAS login, we won't need it for MVP though.
14:19:04 <ryanlerch> mizmo: ack!
14:20:32 <ryanlerch> https://pagure.io/fedora-hubs/issue/457
14:20:43 <ryanlerch> is also related to this on the group hub side
14:23:58 <mizmo> abompard: on ticket #457 - does fas 2 not have an api to trigger a membership request in FAS from hubs?
14:24:26 <abompard> mizmo: I don't know about that
14:24:29 <abompard> I'll have to ask
14:25:12 <mizmo> abompard: welli dont want to complicate things -
14:25:19 <mizmo> abompard: is there any link at all between hubs and fas groups right now?
14:25:43 <abompard> mizmo: only a script that imports fas groups and users and creates hubs
14:25:44 <mizmo> eg if you knew the name of the corresponding fas group, you could do exactly as you propose in the initial ticket text -
14:26:00 <mizmo> but give them a link to the admin panel in fas to add the requestor
14:26:18 <mizmo> abompard: can we create a variable on our side to store fas group name and sync it during the script?
14:26:46 <mizmo> in other words, if we knew the corresponding fas group name, and we know who is admin
14:26:55 <abompard> mizmo: sync it? you mean import users & members etc?
14:27:15 <abompard> we could, I guess, have a periodically running script that would do this sync
14:27:37 <mizmo> abompard: no i dont mean sync in that sense, i just mean, when the script is run and imports the fas groups, can it store the fas group name (if it doesn't already)
14:27:47 <mizmo> the end user workflow i'm thinking is
14:27:56 <abompard> I think it creates the hub with the same name as the fas group name
14:27:59 <mizmo> joe goes to the design-team hub and decides to put in a join request
14:28:45 <mizmo> mo, the deisgn team hub admin, gets an email / notification that FAS id 'joe' has requested to join the hub. the email has a link to http://admin.fedoraproject.org/accounts/whatevertheurlis so all mo has to do is click the link, put joe's name in the box, and hit add user
14:30:07 <mizmo> url would be something like https://admin.fedoraproject.org/accounts/group/invite/$fasgroupname so for this example https://admin.fedoraproject.org/accounts/group/invite/designteam
14:30:14 <mizmo> you'd build the url based on the fas group name
14:30:40 <mizmo> i dont know if invite is effective or if it has to be add
14:30:44 <mizmo> and once you add you have to sponsor i think
14:31:08 <abompard> yeah, doable. And then? Hubs must sync the members list from FAS I guess?
14:31:25 <mizmo> yeh it seems so :(
14:32:14 <abompard> yep. So there must be a way to disable the members edition tabs we currently have in hubs in favor of a sync from FAS
14:32:31 <mizmo> is that a show stopper?
14:34:00 <abompard> I don't know exactly what my FAS system account will be allowed to do, and I'm not very familiar with FAS' API
14:34:16 * sayan is back
14:34:46 * ryanlerch is going to have to go now though :(
14:34:48 <abompard> So I don't really know. I've build to authorization in hubs so we could switch to something remote-based such as FAS but I haven't tested it
14:34:58 <abompard> Oh yeah, good night ryanlerch
14:35:30 <mizmo> later
14:35:32 <mizmo> ill stop the meeting now i guess
14:35:33 <mizmo> #stopmeeting
14:36:16 <mizmo> hm
14:36:17 <mizmo> #endmeeting