15:02:21 <sayan> #startmeeting hubs-devel
15:02:21 <zodbot> Meeting started Tue Mar 28 15:02:21 2017 UTC.  The chair is sayan. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:21 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:21 <zodbot> The meeting name has been set to 'hubs-devel'
15:02:28 <sayan> #topic Roll Call
15:02:32 <sayan> .hello sayanchowdhury
15:02:33 <zodbot> sayan: sayanchowdhury 'Sayan Chowdhury' <sayan.chowdhury2012@gmail.com>
15:02:51 <puiterwijk> .hello puiterwijk
15:02:52 <zodbot> puiterwijk: puiterwijk 'Patrick "マルタインアンドレアス" Uiterwijk' <puiterwijk@redhat.com>
15:03:27 <sayan> jcline: abompard meeting time
15:03:39 <mizmo> .hello duffy
15:03:40 <zodbot> mizmo: duffy 'Máirín Duffy' <fedora@linuxgrrl.com>
15:03:41 <jcline> .hello jcline
15:03:42 <zodbot> jcline: jcline 'Jeremy Cline' <jeremy@jcline.org>
15:04:44 <sayan> I have been out for a while for the FOSSASIA conference.
15:04:58 <sayan> #chair jcline puiterwijk mizmo
15:04:58 <zodbot> Current chairs: jcline mizmo puiterwijk sayan
15:05:04 <sayan> #topic IRC Widget
15:05:28 <sayan> jcline: what's the update on the rpm package of synapse?
15:05:58 <jcline> sayan, I've got it building, but I want to make sure I have the installation process documented
15:06:33 <jcline> It generates a bunch of keys on initial setup and I don't want to do that as a post-install step so it needs to be done by the user.
15:06:42 <abompard> .hello abompard
15:06:43 <zodbot> abompard: abompard 'Aurelien Bompard' <aurelien@bompard.org>
15:06:48 <sayan> #chair abompard
15:06:48 <zodbot> Current chairs: abompard jcline mizmo puiterwijk sayan
15:07:33 <sayan> jcline: same goes for matrix-appservice-irc
15:08:00 <sayan> I have packaged matrix-appservice-irc
15:08:48 <sayan> jcline: how are you documenting the installation process?
15:13:48 <sayan> I would be sending review request for the matrix-appservice-irc
15:15:19 <sayan> abompard: you want to discuss about authorization
15:15:21 <sayan> ?
15:15:47 <abompard> sure!
15:16:07 <abompard> So, the current state is that we only have authentication, not authorization.
15:16:17 <abompard> is everybody familiar with the distinction?
15:16:41 <mizmo> authentication = you are who you say you are, authorization = allowing you permission to do things?
15:16:42 <abompard> I reformulate my question: if you're not sure of the difference, please raise your hand :)
15:16:43 * puiterwijk is... obviously :)
15:17:22 <abompard> yeah, auth will tell the Hub framework you're mizmo, and that you're member of the group "designteam"
15:17:30 <sayan> yes
15:18:03 <abompard> but authorization is the system where you'll say that the designteam group is allowed membership access to the design-team hub
15:18:25 <abompard> it's also where you could say that user mizmo is the owner of the hub, if we have such a thing as "owners"
15:18:32 <abompard> and that's my first question
15:18:50 <mizmo> so the thought we had on the design side is owners == FAS group admins
15:18:51 <abompard> what are the different levels of permissions that we want ?
15:19:00 <mizmo> membership in the group == member of fas group
15:19:18 <mizmo> so the thought was it would be tied to fas as closely as possible
15:19:30 <abompard> puiterwijk: will OIDC tell me who is a group admin?
15:19:42 <puiterwijk> abompard: it will not.
15:19:48 <abompard> okay :)
15:20:03 <puiterwijk> But that's something I could add to CAIAPI.
15:20:24 <puiterwijk> (that's the backend-agnostic system I mentioned)
15:20:33 <abompard> Ah OK :)
15:21:09 <puiterwijk> Also, the fact that it isn't in OpenID Connect now doesn't mean I can't/won't add it if that's more ideal. So in short: we can get that data to you :)
15:21:32 <abompard> puiterwijk: cool, will it take the form of another group?
15:21:39 <abompard> or a group "property" maybe?
15:21:55 <puiterwijk> abompard: we'd/I'd need to figure that out :)
15:22:22 <abompard> puiterwijk: OK, let's talk about it later when I know the requirements better :)
15:22:28 <abompard> from a design point of view, what will hub owners be able to do that hub members can't ? mizmo?
15:22:32 <puiterwijk> abompard: +1 sounds good
15:23:08 <sayan> abompard: editing the hubs widgets I would say is one of them
15:23:26 <mizmo> abompard: hub owners are able to modify the hub (name, description, etc.), configure the widgets (add additional widgets, remove widgets, change individual widget config), set membership policy (same as in FAS, sponsor/approve new members, etc)
15:23:46 <abompard> Oh, membership policy
15:23:52 <mizmo> so mostly, same as fas group ownership, + widget config & metadata for the hub
15:23:57 <abompard> so the roles may be different from those in FAS?
15:24:11 <mizmo> abompard: i think it should be the same as fas
15:24:13 <sayan> abompard: they would be the same as FAS
15:24:19 <mizmo> (unless im not thinking of something)
15:24:38 <abompard> then I'm not sure I got what you mean by membership policy and sponsoring
15:25:48 <sayan> abompard: changing a member to sponsor, approve new member requests
15:26:14 <shillman> What is a sponsor? What do they do?
15:26:17 <abompard> sayan: does that happen in Hubs or in FAS ?
15:26:19 <sayan> afaik, FAS has three roles right? admin, sponsor and member?
15:26:42 <mizmo> sayan: i think that's right. sponsor is sort of an admin-lite
15:27:13 <mizmo> shillman: sponsors can mentor / approve new members applying to join the team. they are basically the same as admins. i'm unsure if there is much difference
15:27:31 <shillman> mizmo: ah, ok.
15:27:35 <sayan> shillman: I know sponsor can add/approve new members. But never been an admin so can't comment on that :)
15:27:41 <abompard> mizmo, sayan: ok, but that job is done in FAS, right, not in Hubs?
15:27:51 <sayan> abompard: Yes
15:27:55 <abompard> OK cool.
15:27:59 <mizmo> abompard: well we have a design for the hubs front end to let you do that
15:28:18 <mizmo> abompard: because if someone wants to join a hub ... they have to join the fas group
15:28:19 <sayan> abompard: you can control the request to FAS groups from Hubs
15:28:53 <abompard> sayan: OK, but that's Hubs telling FAS to do things, the canonical data is in FAS, correct?
15:29:08 <sayan> mizmo: a request in FAS group in FAS would show up in Hubs also?
15:29:30 <sayan> abompard: yes
15:29:45 <mizmo> sayan: if the request originated in FAS?
15:29:51 <sayan> mizmo: yes
15:30:05 <mizmo> sayan: i dont see why a FAS originated request should show up in hubs from a UX POV
15:31:08 <abompard> mizmo: if someone goes to FAS to ask to be a member of a hub, it may make sense to show it in hubs too, doesn't it?
15:31:14 <shillman> mizmo: depends on the request, no? If it's someone asking for membership in a group, for example, it might be good to let the admins in hubs know? Or maybe whatever mechanism FAS already uses is enough.
15:31:40 <mizmo> abompard: well, FAS doesn't actually have any refreences to hubs, and it's not intuitive to go to FAS directly to join a hub -
15:31:48 <abompard> mizmo: agreed
15:31:50 <mizmo> abompard: FAS does send emails to admins to let them know someone applied and needs approval
15:32:01 <shillman> So that's likely sufficient, really.
15:32:39 <mizmo> abompard: i think for the most part - having been admin for a popular fedora fas group for a long time now - most FAS group membership applications are confused! we usually add people manually from the admin... it's not an intuitive interface for someone to apply to a group
15:33:10 <abompard> so, if someones asks to be a member of a hub, this should be visible in hubs? this means that Hubs must track membership requests
15:33:25 <mizmo> eg when design-team was the 'artwork' group we got a lot of random applications from peopel and when we asked them why, they would say stuff like, "i added it because i like art" and they didn't know anything about the team or what we did
15:33:50 <mizmo> abompard: yep, it should be visible to the group owners who has applied
15:33:59 * mizmo looks up the mockups
15:34:10 <abompard> mizmo: okay, should group owners be able to accept the request?
15:34:30 <mizmo> abompard: yeh, they should be able to approve it or ignore it or delete it
15:34:36 <abompard> puiterwijk: see, there isn't only group members and group admins, there's also group sponsors, so there may be a need for a generic role model linked to groups in the API you're building.
15:34:59 <abompard> mizmo: OK, that's basically writing a new and better UI for FAS, right? ;-)
15:35:09 <mizmo> abompard: pretty much :)
15:35:10 * abompard is exagerating a bit
15:35:19 <puiterwijk> abompard: right.
15:35:32 <sayan> abompard: good to clear :)
15:35:33 <puiterwijk> So, I'm seeing a lot of things here that scare me and that we'll need to discuss.
15:35:40 <puiterwijk> But probably not now :)
15:35:42 <mizmo> well the idea being that FAS is disconnected from the activity of the group, so you dont get the context of the group from it, it's sort of this separate system
15:36:05 <mizmo> whereas hubs aggregates all the activity of the group, giving the potential applicant a much better idea of whether or not they want to apply / get involved
15:36:26 <mizmo> one of the 2 main drivers of hubs being, making it more inclusive / easy for new folks to get involved in fedora
15:37:01 <abompard> I'm not saying it's not a good idea, just making sure we're on the same page :)
15:37:20 <sayan> mizmo: would the vice-versa be true, applying in Hubs would reflect in FAS?
15:37:44 <abompard> sayan: that seems unavoidable since that's where the data actually is
15:37:52 <shillman> Pretty sure it has to be. That's where the data lives.
15:38:01 <mizmo> sayan: i thought i said before i didnt think that made sense (unless i answered a different question wrongly)
15:38:04 * abompard high fives shillman
15:38:13 * shillman grins.
15:38:18 <mizmo> sayan: ohh
15:38:23 <mizmo> yeh so if i apply to a group in hubs, it should be reflected in FAS
15:38:29 <sayan> mizmo: cool
15:38:34 <mizmo> but if i apply to the group in FAS, it should be reflected in Hubs as well
15:38:34 <mizmo> but
15:38:52 <mizmo> the admin workflow to approve my request, if i apply from FAS, will not be in hubs. i will have to approve in fas as admin.
15:38:59 <mizmo> if i apply in hubs, then the hubs admin workflow applies
15:39:02 <mizmo> sayan: (sorry i got tripped up)
15:39:28 <sayan> mizmo: right, was writing the same thing
15:40:00 <sayan> also since the data is synced if the member is approved in FAS, it would be reflected in Hubs also
15:40:50 <abompard> I'm a bit confused I think. If applications are "reflected" in each app, then approving from either app would give the same result, no?
15:41:06 <shillman> Approving would, yes. BUt the approval process would differ.
15:41:19 <sayan> shillman: +1
15:41:21 <shillman> And the information that someone asking would have access to would also differ.
15:41:46 <mizmo> http://i.imgur.com/qO1CWoe.png
15:42:04 <shillman> (as far as I can tell, ther's not a lot of info about teams out there right now, so even knowing you want to ask is hard)
15:42:18 <mizmo> ^ thats the mockups for the admin approval on the hubs side
15:43:20 <abompard> Okay!
15:44:08 <mizmo> (does that maek more sense?)
15:44:13 <abompard> yeah :)
15:44:31 <abompard> another question : how to you map hub names to FAS groups?
15:44:37 <abompard> are they the same thing?
15:45:55 <sayan> nope, we need to store the mapping in the database/configuration
15:46:09 <puiterwijk> I do want to point out that if any of this group membership is going to happen, there's going to be an obligatory security audit for the initial deployment and after that for every non-trivial update.
15:47:02 <sayan> puiterwijk: okay
15:47:36 <abompard> puiterwijk: because Hubs will be piloting FAS?
15:48:05 <puiterwijk> abompard: yes
15:48:19 <abompard> puiterwijk: makes sense
15:49:54 <abompard> So, another question (a bit similar). In FAS there's group members, sponsors & admins. Are we using all three to do different things in Hubs? Do we need a mapping?
15:50:49 <sayan> abompard: mizmo: admins should be able to change/edit widgets, accept membership
15:51:16 <sayan> sponsor to approve members
15:51:20 <sayan> mizmo: abompard ^^
15:51:37 <mizmo> i think we could say admins can do the hub metadata / widget config stuff PLUS handle the membership queue
15:51:42 <mizmo> whereas sponsors just handle the membership queue
15:51:48 <mizmo> does that seem fair?
15:52:04 <abompard> it does
15:52:39 <mizmo> i think we can always use more help sponsoring + mentoring new recruits, but too many cooks in the kitchen on the hub config can be problemataic
15:52:47 <mizmo> so limiting hub editing to the admins makes sense to me
15:53:05 <sayan> mizmo: yes
15:53:26 <abompard> So here's what I understood:
15:53:46 <abompard> FAS / OIDC will tell we which groups the logged in user is a member of
15:54:12 <abompard> and for each group, it will tell me (or give me a way to request) its role in that group (member / sponsor / admin)
15:55:21 <abompard> On the hubs side, the site admin(s) will be, upon creation or configuration of a hub, link it to the corresponding group in FAS / OIDC
15:56:02 <abompard> then, the connection will be established and the groups & roles coming from FAS will be used to limit actions in that hub
15:56:43 <abompard> (some words are missing... :-/)
15:57:20 <abompard> a hub can also be set "public", which means it's read-only for anybody, not only group members
15:57:45 <mizmo> yes
15:57:54 <mizmo> so one thing, the initial idea we had for hubs
15:58:09 <mizmo> is that fas group == hub, so when hubs is first 'turned on' a hub would be generated for each non-git, non-acl fas group
15:58:55 <mizmo> re a hub being set public, i think hubs should be public unless set private explicitly. the only fedora groups i can think of that have private stuff are maybe the council??
15:59:07 <abompard> mizmo: OK, do you want to keep creating hubs when new FAS groups are creating after the first deployment?
15:59:40 <shillman> When we say 'public' here, do we mean 'the general public' or 'people who are logged into hubs'?
15:59:46 <abompard> s/creating/created/
16:00:16 <abompard> shillman: up to you, I can do both :)
16:00:30 <sayan> abompard: :)
16:00:42 <mizmo> abompard: yeh i think so. every time a fas group is created, it also gets a hub
16:00:57 <mizmo> abompard: (again, non *-git, or ACL-oriented groups)
16:01:13 * sayan takes a note of that
16:01:14 <mizmo> (how we figure out if it's *-git i guess we can do based on name, for acl groups i dont know)
16:01:35 <abompard> mizmo: yeah I anticipate that this part will be a bit dirty ;-)
16:01:47 <shillman> I have no idea what's correct for teams and such. For regional hubs, I think that there needs to be a different view for general public than hubs members, simply because those are more likely to be local and in general I expect local things to have a higher chance of privacy issues.
16:01:48 <abompard> mizmo: and by that I mean regexp-based ;-)
16:01:54 <mizmo> abompard: heh
16:02:41 <abompard> shillman: it's however pretty simple to create an account, so that doesn't protect much
16:02:59 <mizmo> shillman: very true! we can hopefully handle that differently since they don't have FAS groups yet and are kind of a totally new thing.
16:03:14 <mizmo> i could see 3 privacy  modes?
16:03:28 <shillman> abompard: but that's a difference between automatically scrapeable and not. Right?
16:03:34 <shillman> Anyway.
16:03:35 <mizmo> public, private (members only can view), preview (public can see some select things, members can see all)
16:03:36 <abompard> shillman: true
16:03:55 <mizmo> so i'd see say the council-private group being private
16:03:57 <shillman> mizmo: works for me.
16:04:01 <mizmo> something like this team or design-team being public
16:04:05 <mizmo> and a local regional hub being 'preview'
16:04:32 <abompard> mizmo: sounds good, thanks for laying it out
16:04:54 <abompard> however...
16:05:12 <abompard> that means there must be a way to mark "things" are "public" for preview hubs
16:05:20 <abompard> which things? Widgets?
16:06:02 <sayan> Yeah. Widgets
16:06:36 <mizmo> widgets, and then items in the newsfeed
16:07:03 <shillman> And there may be a need to have things that are normally links in a widget not be?
16:07:07 <abompard> Haha I was just going to write "I'm not sure we can get more granular than widgets, for example newsfeed items"
16:07:16 <mizmo> so personal hubs / profiles have this too, they have a preview mode, where you can see the most recent 5 posts, but you have to be a friend to see all
16:07:21 <shillman> I can't think of any examples, though.
16:07:28 <mizmo> abompard: well for newsfeed im thinking you only see so many items, like 5-10
16:08:01 <shillman> And anything that involves someone saying they'll be somewhere at a specific time wouldn'
16:08:05 <shillman> t be public.
16:08:12 <mizmo> shillman: what kind of location data is sensitive to regional hubs? the roster of members?
16:08:26 <mizmo> shillman: if an event is a public event at XX location - its a public event, so it's not a problem for it to be shown?
16:08:39 <shillman> Agreed. In fact, that's intentionally something we want to show.
16:08:49 <mizmo> shillman: to what extent though? if someone is giving a talk at a public event - it has to be known they'll be there at that time
16:09:05 <mizmo> shillman: but an attendee, if they have noted they're going - that should be hidden?
16:09:25 <mizmo> shillman: also - hidden to people who aren't a member of the group? or hidden to ppl who arent logged into hubs?
16:09:35 <shillman> mizmo: Hmm. yeah, if it's someone talking or someone who is the spokeperson for a group, having that be public seems ok.
16:10:02 <shillman> And in general, I'd say hidden to people who aren't logged in.
16:10:05 <mizmo> shillman: could we front-load this, for when people say they'll attend something, they check off something to say they want to be anonymous
16:10:10 <mizmo> or its ok if ppl know they're going?
16:10:15 <shillman> Mmm! Yes. That works for me.
16:10:39 <mizmo> thats sort of how the FSF did it with talk recordings / broadcasts for speakers this weekend. you could opt out of having your talk recorded when you signed up
16:10:59 <sayan> Hmm
16:14:51 <abompard> as they say "well, that escaladed quickly" :-)
16:14:57 <shillman> *grin*
16:15:04 <fm-hubs> pagure.issue.comment.added -- wispfox commented on ticket fedora-hubs#285: "Many pages need a view for public consumption" https://pagure.io/fedora-hubs/issue/285#comment-433851
16:15:14 <sayan> abompard: haha, but we need to write it down in an issue
16:15:39 <shillman> Well, the part relating to regional hubs and public stuff I just copied to the issue that I updated.
16:15:45 <shillman> (just now)
16:16:36 <sayan> shillman: the discussion related to authorization
16:16:43 <shillman> *nod* True.
16:18:32 <sayan> abompard: can you write a writeup to the mail that you wrote to the hubs mailing list?
16:19:37 <abompard> sayan: I'll write what I have understood, so it may be a subset of what was discussed here
16:19:43 <abompard> but yeah
16:20:47 <sayan> shall we go over and end the meeting?
16:20:52 <abompard> It may not be possible to set permissions down to the last bit of information. But content-based permissions will probably be the job of widget writers to enforce, so I don't really have to think about it now
16:21:08 <abompard> yes
16:21:29 <sayan> abompard: yes
16:22:34 <sayan> Ending meeting in 3.
16:22:36 <sayan> 2.
16:22:37 <sayan> 1.
16:22:41 <sayan> #endmeeting