19:01:26 #startmeeting community-working-group 19:01:26 Meeting started Wed Sep 7 19:01:26 2016 UTC. The chair is gregdek. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:26 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:01:26 The meeting name has been set to 'community-working-group' 19:01:36 #topic Roll Call 19:01:53 Agenda, as always: https://waffle.io/ansible/community 19:01:58 oh 19:02:01 * rbergeron wakes up 19:02:13 * rbergeron scowls at her lag 19:02:19 LOL 19:02:21 Hiya! 19:02:28 hey! 19:02:30 hello 19:03:01 * rbergeron counts herself as present for roll call 19:03:14 <_shaps_> hi 19:04:04 Hi linuxdynasty _shaps_ :) 19:04:07 And of course rbergeron 19:04:25 #topic Planning for Contributor Conference Brooklyn 19:04:34 https://github.com/ansible/community/issues/115 19:05:03 Looks like we got out our blog post and our emails to let people know what's happening. 19:05:12 Now we need to nail down the agenda, I imagine. 19:05:23 rbergeron: you've been doing some thinking about that? 19:05:41 We should prolly take some time to check out / update the etherpad... 19:06:04 gregdek: yeah, I think i have some things to add to the etherpad 19:06:16 along with folks i have reached out to that i will poke again 19:06:36 Want to grab some time to iterate over it in the next day or two? 19:06:52 yeah, let's do that... /me looks at schedule 19:07:15 I was going to ask when will people know if they have been chosen to speak ? 19:08:03 linuxdynasty: i am not sure on that front. we're mostly looking at the contributor summit portion (the day before ansiblefest) -- 19:08:16 * rbergeron doesn't seen notting in here to poke at 19:08:52 linuxdynasty: i know it's being reviewed so I would expect Real Soon Now, esp. since the event is fairly soon 19:09:12 Will ping Bill for that. 19:09:43 gregdek: anytime between 12:00 - 1:30, after 2pm your time is fine tomorrow if you want to get together 19:09:50 or we can ad-hoc and acdtually just remember to get together at some point 19:10:00 Let's do noon tomorrow for me. 19:10:43 okay! i will set a thing. 19:10:50 OK! 19:10:56 * gundalow waves 19:11:41 Hi gundalow :) 19:11:55 #topic contributor summit sf wrapup 19:12:06 https://github.com/ansible/community/issues/93 19:12:21 gundalow rbergeron anything left here? The final wrap-up blog is out, I think. 19:12:46 gregdek: all done 19:12:49 i think all done 19:13:14 ok, closing that one. 19:13:26 \o/ 19:13:29 :) 19:13:33 #topic Module Maintainer Guidelines 19:13:35 https://github.com/ansible/community/issues/81 19:13:58 i bet i was supposed to do something i didn't do, heh 19:13:59 * rbergeron sighs 19:14:41 I think it's just updating. 19:14:48 okay, i'll do that. i think i did some of it but not all :) 19:15:21 We can always finish that up in tomorrow's meeting and get a twofer! 19:15:33 i also note that we have some stuff on the contributor summit agenda / plan list to enhance some of this in the docs sprint 19:15:50 or at least "improve new module development docs" iirc 19:15:58 okay, i'll add that to our little meeting tomorrow 19:16:16 done 19:16:55 FYI Scot has some stuff in flight to update developing_modules, and as part of Testing Working Group we are updating notes on what we want to see from it 19:17:14 (docs scot) 19:17:19 * rbergeron nods 19:17:24 Oh, nice! 19:17:32 gundalow: awesome, thanks for the fyi 19:18:08 Testing notes https://public.etherpad-mozilla.org/p/ansible-testing-working-group 19:19:02 * gregdek looks 19:19:27 That's awesome :) 19:20:40 OK, moving on: 19:21:04 #topic Public Metrics 19:21:15 https://github.com/ansible/community/issues/38 19:21:21 jtanner: you around? 19:22:01 gregdek: yep 19:22:23 trying out weechat, so i'm not seeing notifications quickly 19:22:37 Ah, ok 19:22:53 Anything new to share on ^^^? I know you've been working on a bunch of stuff 19:23:25 not really ... i did make a chart for total comments per month 19:23:44 https://jctanner.github.io/ansible/stats/total_comments.png 19:24:13 i suppose contributors/stars/etc is something i should do next 19:24:28 been working on ansibullbot issue triage for ansible/ansible this week though 19:24:58 So. 19:25:06 What are we to make of these numbers? :) 19:25:36 charts and graphs, of course 19:25:37 :) 19:25:41 oh, that's *with* 19:25:44 well, for the comments, it's safe to say we have quadrupled the github traffic since 2013 19:26:55 True. 19:27:20 My real question is: what data do we have that tells us what we could do better? 19:28:10 my personal inclination from this data is that employees can't scale enough to handle the volume and we have to find more ways to source community 19:28:11 (are you looking for suggestions or actual concrete things that we are already keeping track of as data points?) 19:29:56 rbergeron: me or greg? 19:29:59 I just want to make sure we don't lose the purpose of keeping track of these numbers. Everyone agrees that "there's more users". 19:30:41 Just musing about what we want out of this. How do we present it? Do we do a regular blog post? 19:30:52 did you have something in mind? i don't really know the original purpose? 19:31:07 Yeah. That's what I'm realizing. :) 19:31:16 jtanner: asking greg, mostly, but you too 19:31:18 We've sort of played telephone with this one. 19:31:27 i think the purpose is ... multiple 19:31:27 i collect data to make myself feel better when i work on ansibot instead of triaging the issue queue by hand 19:31:49 #1: understand where our bottlenecks are 19:32:38 #2: set some goals to improve the bottlenecks, wheever they are (time from PR to merge, to first comment, whatever) 19:33:22 #3: general transparency / acknowledgement of throughput (if we want to improve any of these statistics as a community, we have to be able to point to something that shows we're actually committed to makingan effort, and shows people where the improvements can be made / how they can help, whatever) 19:33:26 2 is typical devops sort of concept but we have to keep in mind that when you improve a singular metric, you typically worsen others 19:33:51 I think in general, super general, having any sort of dashboard showing metrics for community is soft of a standard thing 19:34:17 i wish it were more standard, but github is fairly lacking in that dept 19:35:02 So. 19:35:15 our backlog is also increasing due to lower "quality" of issues being submitted 19:35:40 Then why aren't we closing those low-quality issues and demanding higher-quality issues? 19:35:41 we continually gain more users who are new to linux/automation/python etc and we have to hand hold 19:35:52 gregdek: maybe it's just a topic for us to chat about at the contributor summit -- find out what would actually help people 19:36:01 we don't have the data to properly classify "low" quality versus "high" 19:36:15 ...or providing easier tools / instructions / methods to obtain the quality information we actually need? 19:36:18 Is the templating helping in that rehard? 19:36:21 Regard, even? 19:36:36 i have thought about trying to build a corpus of ngrams that typically imply an issue is going to require code change and giving those issues a higher weight 19:36:42 and yes, this could be a good summit topic 19:36:48 but that's a whole project of research and discovery unto it's self 19:37:13 the templating is actually the best thing since sliced bread 19:37:28 imo 19:37:59 That's good. :) 19:38:02 would prefer real fields+components but template is getting us 90% there 19:38:30 Are we able to apply state to issues that tell us "this issue doesn't have enough info"? 19:39:01 <_shaps_> there is a label on github 'requires_info' 19:39:07 issue workflow includes a path to needs_info when an important subset of template requirements were not given 19:39:25 component name / ansible version / issue type 19:40:04 Maybe we could break that out in this report. How are you building these? Anything we could play with? 19:40:20 building what? 19:40:32 the graphs? 19:41:06 yeah 19:41:19 heavily modified fork of sivel's pr-trage: https://github.com/jctanner/pr-triage 19:41:31 has a few phases 19:41:44 Ah, yes. That's awesome. Lots of examples 19:42:08 Does it require running your own db? 19:42:30 1) fetch github issue objects and pickle them 2) serialize objects to json and enumerate some synthetic attributes 3) create stats from json with python pandas 19:42:51 the data is stored on disk rather than in a db 19:43:08 Excellent. 19:43:27 unless you intend to also run the flask dashboard, which does require mysql + elasticsearch 19:44:11 it may be easier to share the processed data via a public ipython notebook so people can play datascientist without having to duplicate the infra 19:44:32 something i had intended to do when time allowed 19:44:52 Now *that* sounds awesome. 19:46:35 Sorry for asking so many questions. 19:46:53 lol 19:47:55 And yes, i think in the end rbergeron you're right: this is a topic for the contributor summit. 19:48:07 thanks jtanner -- great stuff. 19:48:11 np 19:48:52 gregdek: i'll plop it on the etherpad and we can expound more tomorrow 19:48:58 kk 19:49:10 Next: 19:49:14 #topic Ansible Durham Meetup 19:49:23 My fault. Will have a date by next week. 19:49:46 https://github.com/ansible/community/issues/104 19:49:57 Have cleared the decks post-vacation. :) 19:50:04 containers containers containers 19:51:02 yes. 19:51:46 OK. 19:51:49 #topic Open Floor 19:51:50 containerize all the excitement 19:53:28 i heard through the grapevine that someone is putting vault into docker-container 19:53:39 ? 19:54:07 You mean ansible-container? 19:54:12 oops, yeah 19:54:17 which vault? 19:54:20 :) 19:54:23 I dunno. :) 19:54:33 lol 19:55:15 i only speak of the vault i originally wrote =) 19:56:00 *The* vault! 19:56:06 :) 19:57:42 ok. 19:57:45 And with that: 19:57:47 #endmeeting