15:01:52 <langdon> #startmeeting modularity_wg
15:01:52 <zodbot> Meeting started Tue Jun 21 15:01:52 2016 UTC.  The chair is langdon. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:52 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:52 <zodbot> The meeting name has been set to 'modularity_wg'
15:01:57 <maxamillion> .hello maxamillion
15:01:57 <contyk> .hello psabata
15:01:58 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
15:02:01 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:02:02 <langdon> .hello langdpon
15:02:04 <zodbot> langdon: Sorry, but you don't exist
15:02:07 <tflink> .hello tflink
15:02:08 <contyk> ;)
15:02:08 <zodbot> tflink: tflink 'Tim Flink' <tflink@redhat.com>
15:02:11 <jkurik> .hello jkurik
15:02:12 <bconoboy> .hello blc
15:02:12 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com>
15:02:15 <zodbot> bconoboy: blc 'Brendan Conoboy' <blc@redhat.com>
15:02:17 <langdon> .hello langdon
15:02:17 <zodbot> langdon: langdon 'Langdon White' <langdon@fishjump.com>
15:02:27 <langdon> NOW I DO!
15:02:28 <langdon> #chair: dgilmore, cydrobolt, harald, jkurik, langdon, mikedep333, sct, tflink, threebean
15:02:29 <zodbot> Current chairs: : cydrobolt dgilmore harald jkurik langdon mikedep333 sct tflink threebean
15:02:41 <langdon> #topic Roll Call
15:03:10 <sct> .hello sct
15:03:11 <zodbot> sct: sct 'Stephen Tweedie' <sct@redhat.com>
15:03:25 <langdon> 30s to let others say hi
15:03:58 <jkaluza_> ,hi
15:04:00 <jkaluza_> .hi
15:04:07 <langdon> #topic Agenda
15:04:09 <langdon> ha
15:04:12 <jkaluza_> #hi
15:04:21 <langdon> #info modularity UX
15:04:23 <jkaluza_> memory.... :)
15:04:28 <jkaluza_> .hello jkaluza
15:04:28 <zodbot> jkaluza_: jkaluza 'Jan Kaluža' <jkaluza@redhat.com>
15:04:30 <langdon> #info orchestrator update
15:04:37 <langdon> any other agenda topics?
15:04:45 <contyk> just the one?
15:05:02 <langdon> contyk, 2
15:06:49 <langdon> hmm I don't see mary.. so maybe we start with orchestrator? and come back when she joins?
15:06:58 <langdon> i do see mizmo though.. thanks for coming!
15:07:36 * mizmo waves
15:07:44 <langdon> #topic Update on orchestrator (led by threebean & contyk)
15:07:52 <langdon> contyk, threebean can you give us an update?
15:07:57 <langdon> #chair contyk
15:07:57 <zodbot> Current chairs: : contyk cydrobolt dgilmore harald jkurik langdon mikedep333 sct tflink threebean
15:08:19 <contyk> there isn't much to say; we spent most of the week organizing the work, identifying the bits that need to be done and creating cards for them
15:08:59 <langdon> is there anything we need help with?
15:08:59 <contyk> we now have the first draft of the orchestrator api, since like an hour ago
15:09:14 <threebean> nice!  contyk can you link us to that (understanding that its not final yet)
15:09:23 <contyk> sure, one sec
15:09:42 <contyk> https://pagure.io/fm-orchestrator/blob/master/f/README.rst
15:09:59 <contyk> here you go; it's really simple for now but I'm not sure we even need more at this point
15:10:28 <langdon> contyk, will flo-rida also work as a path?
15:10:44 <contyk> not initially ;)
15:11:04 <langdon> :(
15:11:21 <langdon> any one have any feedback on the fast read of the api?
15:11:25 <contyk> we don't need anything from anyone right now
15:11:29 <langdon> ha!
15:11:37 * contyk listens
15:11:42 <threebean> we'll want lots of different ways to 'list' all module builds.. but we can wait on that for now
15:11:48 <threebean> .. and just add new query parameters later.
15:11:53 <contyk> yeah
15:11:55 <threebean> say, 'give me all the builds for the httpd module, but no others'
15:11:59 <threebean> 'give me all running builds'
15:12:06 <threebean> 'give me all failed builds between thursday and friday'
15:12:10 <threebean> .. etc.
15:12:14 <threebean> but, that can come later.
15:12:20 <threebean> oh - pagination, also.
15:12:41 <maxamillion> pagination?
15:12:42 <threebean> contyk: should I file tickets/cards for those, just to track them as separate things for another day?
15:12:44 <contyk> threebean: go ahead and create cards for these features :)
15:12:48 <contyk> threebean: even better, code them!
15:12:52 <maxamillion> (the term rings a bell but I can't remember what it means)
15:12:53 <threebean> ;)
15:13:09 <jkurik> maxamillion: it means we will have a lots of builds
15:13:15 <threebean> maxamillion: returning data in 'pages'.  only allow returning the first 100 results.  then you have to query again with page=2 to get the next 100.
15:13:25 <maxamillion> threebean: ah ok, like datagrepper
15:13:28 * threebean nods
15:13:49 <threebean> without that, every query can put undue load on the server when we accumulate lots of builds down the road.
15:14:00 <langdon> honestly.. should probably start with a cap.. but .. meh
15:14:14 <maxamillion> threebean: +1
15:14:39 <maxamillion> langdon: datagrepper seems to do fine without one and I don't think we'll have more builds than we have fedmsgs
15:15:04 <maxamillion> langdon: current fedmsg count -> 60,575,500
15:15:07 <threebean> contyk: nice work on the api.  it's a good starting point :)
15:15:08 <langdon> do we have a card for a "ui" for this? cause I was chatting with some people about copr front-ending .. or cloning copr and doing that as a front-end
15:15:25 <threebean> maxamillion: ah, it does have a cap of 100.  the ui you look at though uses JS to transparently fetch subsequent pages so it looks like you just get 'all' of them.
15:15:32 <langdon> maxamillion, sorry.. i meant.. it should start with pagination.. or a cap at 100 .. to avoid ddos
15:15:38 <maxamillion> langdon: oh, ok
15:15:53 <maxamillion> threebean: right, but there's no cap on getting more pages ... but it appears I misunderstood langdon
15:16:04 <maxamillion> sorry for the side track, didn't mean to derail
15:16:12 <threebean> langdon: we talked last week about intentionally not making a UI for now, to keep things simple and not get bogged down.
15:16:30 <contyk> we have that bpo service idea
15:16:36 <langdon> maxamillion, right.. often gets added later.. but sometimes it gets added because the server got knocked over :) my web-dev exp often says .. start expecting paging ;)
15:16:43 <threebean> contyk: yeah
15:16:43 <contyk> that should visualize state of all the services
15:16:57 <contyk> and ui work should happen there
15:17:19 <contyk> I've already talked to asamalik who was interested in working on that
15:17:25 <langdon> contyk, two different UIs .. one is the "state of modules" (which is like copr) .. one is "flow of a module through the pipeline" which is like... thinking.. blanking.. i meant the former
15:17:27 <mizmo> langdon, fwiw even if there isnt an intention to implement it yet having a design for a UI can help dictate technical direction
15:17:28 <contyk> we should have something in the near future
15:17:48 <contyk> I think the bpo could show both
15:18:03 <langdon> mizmo, i think they call that agile? ;)
15:18:31 <langdon> contyk, perhaps.. but they may be different priorities.. and cloning copr might be easy
15:18:43 <maxamillion> langdon: +1
15:19:35 <mizmo> langdon, not sure i get lost at the word 'scrum' :-p
15:19:40 <langdon> contyk, more comments? thoughts? and cards you could point anyone at?
15:19:46 <langdon> mizmo, lol :)
15:20:02 <contyk> weeeell, there are many :)
15:20:16 <contyk> I don't have a list
15:20:28 <langdon> arguably.. the UI here .. driving the requirement(s)... and therefore "user impact" .. is the api.. not nec. a web ux..
15:20:57 <langdon> contyk, ok.. well.. hopefully, in the next update we can point out some "independent" cards we can ask for help on
15:23:05 <contyk> I'll prepare a list for the next meeting :)
15:23:06 <langdon> ok.. one quick note.. we have been moving epics to a new taiga board... http://taiga.fedorainfracloud.org/project/modularity-roadmap which.. we just realized... is not open to all
15:23:23 <langdon> contyk, \o/ :P
15:23:30 <langdon> jkaluza_, help ^^ ?
15:23:35 <maxamillion> langdon: way to go!
15:23:41 <maxamillion> *jeez* ... >.>
15:23:45 <langdon> threebean, contyk any other comments? or move on?
15:23:50 <jkaluza_> langdon: wait, will check the admin tab there
15:23:51 <contyk> nothing from me
15:24:00 * langdon notes that was the "royal we"
15:24:09 <jkaluza_> langdon: it's public now
15:24:18 <langdon> jkaluza_, thanks
15:24:21 <jkaluza_> sry... I actually haven't tried it as unlogged user :)
15:24:30 <langdon> jkaluza_, yeah.. my problem too ;)
15:24:44 <langdon> ok.. lets move to the next topic
15:24:52 <langdon> #topic Modularity UX (led by mary)
15:24:59 <jkaluza_> langdon: I think we should try to populate that board with stuff scheduled for flock soon
15:25:06 <jkaluza_> I know you know about that, just reminding :)
15:25:11 <langdon> jkaluza_, +1
15:25:14 <jkaluza_> contyk: ^
15:25:16 <langdon> ughh.. work
15:25:36 <MaryC> for Modularity UX we are starting with fleshing out personas
15:25:41 <langdon> ok.. so .. as we have mentioned before.. we have been trying to bring in help to think about how the UX of working with modules will be the same/different from traditional packages
15:26:04 <langdon> just by way of intro :)
15:26:34 <langdon> i also invited mizmo for her to help weigh in on which personas we know/care about in fedora
15:26:50 <langdon> MaryC, can you elaborate on what a persona is and why we care about them?
15:26:54 <MaryC> yep, so we are starting with understanding who the users are that would be consuming modules as well as developing modules
15:27:30 <MaryC> sure, personas are fictional representations of user types that would interact with a product or part of a product in a certain way
15:28:15 <MaryC> leveraging personas can help the team share a common understanding of who the various users are and what is important to them
15:28:47 <langdon> so i know we have some in Fedora.. mizmo were you involved in those? for the editions? or did the WGs do them on their own?
15:29:41 <mizmo> langdon, we did a set for server, i've found a few for gnome but i dont think they are actually used.
15:29:47 <mizmo> langdon, these are the server ones: https://fedoraproject.org/wiki/Server/Personas
15:29:49 * langdon notes that each persona usually has a fictitious name that can then be referred to in the future.. like design patterns.. except less lame
15:30:15 <langdon> mizmo, ohh.. there are like "short ones" on the workstation page as well..
15:30:19 <mizmo> for server we focused on the sysadmin macguyver one a lot
15:30:27 <MaryC> thanks for the link mizmo; any other links to known personas would be useful
15:30:46 <contyk> ah, names... :)
15:30:51 <mizmo> i will say in practice i haven't had much luck with personas and have tried using them on a lot of diff projects
15:30:53 * langdon digs
15:31:16 <mizmo> but they have been useful in, for example, classifying usability test subjects and developing marketing material
15:31:20 <langdon> workstation mini-personas: https://fedoraproject.org/wiki/Workstation/Workstation_PRD
15:31:45 <mizmo> ah those are much better than the ones i found, those ar ereasonable
15:32:23 <langdon> mizmo, lol
15:32:45 <mizmo> https://wiki.gnome.org/Attic/UsabilityProject/Personas/Draft  <= literally has joe the plumber
15:32:54 <langdon> i think MaryC and i had discussed using them more as an "anchor" for workflows
15:33:12 <langdon> mizmo, wrong election year :)
15:33:41 <MaryC> yes, that is the goal.  I don't want to get too detailed, but provide a basic overview of goals and pain points
15:33:45 <mizmo> langdon, and they'd be for people installing modules, building modules, and inbetween or more end users?
15:33:53 <mizmo> MaryC^^
15:33:55 <MaryC> mizmo, hopefully no picture with joe the plumber :)
15:34:01 <maxamillion> heh
15:34:12 <langdon> mizmo, actually would like to concentrate on "end user" first.. because I think that informs a lot of the others..
15:34:18 <langdon> and has some of the hardest problems..
15:34:34 <mizmo> makes sense!
15:34:36 <MaryC> yeah, all of the above ..
15:34:45 <langdon> e.g. how do you let a user choose a firefox version by EOL.. aka LTS vs nightly
15:35:52 <langdon> i guess really what i wanted to have happen here is.. "we are thinking about ux" .. and "any ideas for how to best collaborate on it" .. e.g ml? slides? something else?
15:36:49 <langdon> don't all jump in at once! :)
15:36:51 <mizmo> maybe a git repo for mockups / design artifacts and a ticket system?
15:37:00 <mizmo> that's how we're managing it on the fedora hubs project
15:37:09 <mizmo> you could just make a pagure.io project, that gives you the git repo and the issue tracker
15:37:17 <MaryC> once personas are more solid, I plan on putting together end to end flows for the different sets of users --> consumers, builders, etc.
15:37:21 <mizmo> hook up the git repo via sparkleshare to make it easy to check in mockups / design artifacts
15:37:26 <mizmo> and manage work items via issues
15:37:40 <mizmo> you can tag issues in pagure too which has been helpful
15:37:49 <langdon> mizmo, is there a fedora "group" that should be directly plugged in to this kind of work? i get mildly confused about where the edges are..
15:38:05 <mizmo> (example: https://pagure.io/fedora-hubs/issue/91 )
15:38:13 <langdon> mizmo, pagure+sparkleshare works?
15:38:32 <mizmo> langdon, for UX stuff, would be the fedora design team, websites team a bit too but i think robyduck follows the design list
15:38:57 <mizmo> i would think tho, probably the workstation group too if youre thinking about end users installing modules for example
15:39:05 <mizmo> so - not a nice neat single group :-/
15:39:06 <langdon> mizmo, ok.. we should probably try to get on the "agenda" ..
15:40:03 <mizmo> langdon, we're having a meeting tomorrow (7 AM ET : ( )
15:40:04 <langdon> mizmo, i figured :) .. for workstation.. i still need to engage with them on modularity directly.. i think the UX part is probably a follow on.. like post conversation with design.. maybe?
15:40:14 <mizmo> next week should be 10 am ET on wednesday
15:40:18 <langdon> mizmo, ughh.. maybe after summit :)
15:40:37 <langdon> i can barely see straight as it is
15:40:37 <MaryC> after summit would be best :)
15:41:05 <langdon> mizmo, we can't use hubs for modularity yet, right??!?!? (so says threebean)
15:41:19 <mizmo> maybe although i will be honest with you, myself and ryanlerch are the only fulltime uxers on the team
15:41:31 <mizmo> and he's in brisbane, so getting time together is going to be difficult :(
15:41:43 <langdon> no lie
15:42:01 <langdon> he could have another kid.. then he could just work our hours
15:42:05 <mizmo> langdon, not yet :( we're working towards a prototype for flock that'll have 3 team hubs really fleshed out (l10n, design, mktg)
15:42:10 <mizmo> lol
15:42:33 <langdon> mizmo, cool! but :(
15:42:38 <mizmo> yeh... sorrys :(
15:42:42 <langdon> ok.. so.. I just wanted to give/get an update on the UX thinking ..
15:42:50 <langdon> any other qs? concerns? thoughts?
15:43:10 <mizmo> just excited that MaryC is on board :) UX \o/
15:43:17 <langdon> ha
15:43:25 <MaryC> thansk mizmo, me too :)!
15:43:33 <langdon> ok.. lets do an open floor if anyone has anything..
15:43:40 <langdon> #topic open floor
15:44:10 <langdon> i think we are in a bit of a lull.. like we know what we want to build for flock.. we (mostly) know how to build it.. and so we are building it
15:44:26 <langdon> anyone here have any qs? comments? etc?
15:44:47 <asamalik> hey guys, this is Adam from Copr team - I would like to join the modularity project and help with the UI
15:44:51 <langdon> anyone have any questions about what we are trying to ship for flock?
15:45:10 <langdon> asamalik, i asked you to join because we were discussing that a bit before..
15:45:23 <asamalik> I have was reading the discussion
15:45:32 <langdon> we would really love some help in thinking about the "bpo" in the bottom right of threebean's diagram
15:45:39 * langdon digs
15:46:00 <langdon> #link https://fedoraproject.org/wiki/File:Modularity_Systems.png
15:46:25 <langdon> implementation would be even cooler.. but i am not even sure we know what we want yet
15:46:40 <langdon> basically.. a way to visualize a module as it moves through the pipeline
15:46:41 <asamalik> I saw that diagram and if I understand it correctly, it would be something to track the "build process" of the modules, right?
15:46:52 <langdon> threebean, ^^
15:46:57 <contyk> short answer: yes
15:47:48 <contyk> not just the build, it would track the whole process from when the module was submitted for build to it being distributed
15:48:14 <langdon> contyk, i kinda would like to see it go even before that like "upstream update detected"..
15:48:17 <asamalik> contyk: yes, that's what I meant :)
15:49:42 <langdon> asamalik, should be based on fedmsg updates... like that should be the only "needed" input source..
15:49:48 <langdon> i think
15:49:49 <langdon> :)
15:49:57 <contyk> langdon: that would be fairly difficult to link together; I'll leave that to the ux people :)
15:50:16 <langdon> contyk, ha!
15:50:24 <langdon> any other topics?
15:51:08 <langdon> ok.. im gonna propose wrapping it up..
15:51:14 <langdon> going once
15:51:37 <langdon> going twice
15:52:00 <langdon> going three times..
15:52:13 <langdon> ok.. just a side note.. the agenda is already in the agenda etherpad for next week..
15:52:28 <langdon> sct has graciously offered to host as i will be jammed up at summit
15:52:28 <threebean> langdon++ thanks :)
15:52:31 <zodbot> threebean: Karma for langdon changed to 1 (for the f24 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:52:34 <langdon> please add agenda!
15:52:46 <langdon> #endmeeting