18:00:47 #startmeeting Ansible Community Meeting 18:00:47 Meeting started Wed Sep 2 18:00:47 2020 UTC. 18:00:47 This meeting is logged and archived in a public location. 18:00:47 The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:47 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:47 The meeting name has been set to 'ansible_community_meeting' 18:00:56 who's around? 18:00:59 #chair dmsimard 18:00:59 Current chairs: dmsimard felixfontein 18:01:02 o/ 18:01:05 #chair samccann 18:01:05 Current chairs: dmsimard felixfontein samccann 18:01:08 o/ 18:01:18 * gundalow waves 18:01:20 #topic agenda: https://github.com/ansible/community/issues/539#issuecomment-681006031 18:01:21 o/ 18:01:25 #chair cyberpear gundalow andersson007_ 18:01:25 Current chairs: andersson007_ cyberpear dmsimard felixfontein gundalow samccann 18:01:53 abadger1999: gwmngilfen: acozine: geerlingguy: gregdek: are you around? 18:02:22 Hello :-) 18:02:40 #chair abadger1999 18:02:40 Current chairs: abadger1999 andersson007_ cyberpear dmsimard felixfontein gundalow samccann 18:02:43 hello there 18:02:47 #chair geerlingguy 18:02:47 Current chairs: abadger1999 andersson007_ cyberpear dmsimard felixfontein geerlingguy gundalow samccann 18:02:53 lots of people today :) 18:02:58 Oh, is it going ahead after all? I thought anderson couldn't make it, so I'm doing kids bedtime 18:03:08 #chair gwmngilfen 18:03:08 Current chairs: abadger1999 andersson007_ cyberpear dmsimard felixfontein geerlingguy gundalow gwmngilfen samccann 18:03:22 gwmngilfen: don't worry, no rush 18:03:26 gwmngilfen: we can talk about other tings first :) 18:03:33 heh, bedtime later! (just kidding) 18:03:41 so many chairs... maybe we need some sofas 18:03:41 Kinda need some notice for 7pm meetings :) 18:03:55 Sofas++ 18:04:00 hehe :) 18:04:20 is there anything that's urgent that we need to discuss first? 18:04:48 #topic Updates 18:05:03 #info Ansible 2.10.0b1 has been released - features are now frozen for 2.10.0 18:05:07 #ingo Not sure if others saw, though we have 3,000+ people that are interested in attending Contributors Summit (which is an increase from the ~150) 18:05:16 #info Not sure if others saw, though we have 3,000+ people that are interested in attending Contributors Summit (which is an increase from the ~150) 18:05:27 I'll be back in 30 min or so 18:05:30 that's a really astonishingly high number! 18:05:55 I'd count on 10-20% actually attending :P 18:06:05 (still a big number) 18:06:09 geerlingguy: even 10% is still double previous years 18:06:25 wow... that's... a lot of contributors to wrangle! 18:07:33 was it announced differently this time? or has anyone an idea why there are so many more this time? 18:07:39 #info We are planning for two days of Contributors Summit. Monday will mostly be pre-recorded videos with Q&A. Thursday will be possibly more interactive 18:08:01 felixfontein: I think partly as AnsibleFest itself has many more people registered due to it being virtual 18:08:21 I guess that's the trouble with Free Virtual events? lots of people sign up and don't show? 18:08:22 #info Please register for AnsibleFest https://www.ansible.com/ansiblefest 18:08:27 cyberpear: yup, also that 18:08:35 I've no idea how many people will attend 18:09:01 even if 10 % it will be cool 18:09:08 i wanna say when RH did Summit virtual, they had a TON more people actually show up (combination of free and can attend from anywhere) 18:09:10 ~300 18:10:07 What usually is lacking (especially if it's all pre-recorded) is any kind of engagement 18:10:17 does AnsibleFest attendance cost money? 18:10:17 QUESTION: What type of introduction videos walkthoughts do people think maybe useful to new(ish) contributors 18:10:25 felixfontein: free as it's virtual 18:10:29 at least Q&A and live chat could be live, but I've really been missing that aspect in all the online conferences I've attended 18:11:14 geerlingguy: yup, we plan (say) 20minute video, during which people can chat and add stuff in the Q&A. Then at the end we will go through the Q&A and anything else that seems interesting from the general chat 18:11:20 gundalow: cool! 18:11:42 gundalow: I've wondered (tho have no proof) if git itself is a barrier? 18:11:49 for new folks 18:11:50 One thing—maybe a video/session showing people how to sign up for / set up IRCcloud or something similar 18:12:12 since new folks most likely have either never used IRC or only touched it once or twice, and getting IRC to be more like Slack is a big win for them 18:12:28 geerlingguy: great idea! 18:12:54 samccann: maybe also a demo of how to edit docs via GitHub's web UI then? It's a good stepping stone. 18:13:12 Would also be nice to have 'edit on github' links in the docs — those were present once long ago weren't they? 18:13:19 heh edit docs on github - ansible's 'gateway' drug 18:13:22 (docs are often the best stepping stone) 18:13:28 geerlingguy: they will be returning, though not for a while 18:13:42 Should IRC include how to register? 18:14:00 yes 18:14:01 gundalow: might be better, in case we need to add +r to more channels 18:14:03 geeerlingguy - edit on github links still there for .rst files... not for docstring content as that broke w the collection move. Might be possible to bring it back someday 18:15:10 #action Fest Video: 1) Brand new GitHub (no fork of collection), click `Edit on GitHub` 2) Fix typo 3) Create PR 4) Wait for CI 5 ) 6) Success 18:15:13 Basically "How to get involved with IRC (in a way more familiar with current slack users) if you've never been on IRC, with a guide to some of the popular #ansible- rooms 18:15:38 (I know I'd probably learn a few things from that too!) 18:16:14 a tutorial on how to create a bugfix PR and/or new feature PR for a module is probably also a nice idea 18:16:17 #action Fest Video: Overview of IRC (maybe show via Matrix.im) 1) How to register (or does Matrix do this for you) 2) #ansible (user) #ansible-devel & #ansible-community 3) Don't `ping` Just ask the question 18:16:27 including finding where the module lives, and creating a changelog fragment :) 18:16:42 hehe 18:16:49 :-) 18:17:22 #action samccann - open a docs issue for a 'getting started developing in ansible' guide 18:17:24 hum, would that be a good example for `git` commandline (checkout your fork), create feature branch, do work, add changelog, push PR 18:17:36 we have tidbits for users, but nothing afaik for just getting started for developers 18:17:37 anything else need to go in that? 18:18:07 gundalow: look at CI results and fix issues CI reports ;) 18:18:07 I also very quickly hacked https://www.katacoda.com/gundalow/scenarios/testing-collections together (click the command to run them) 18:18:30 source for the above: https://raw.githubusercontent.com/gundalow/katacoda-scenarios/master/testing-collections/step1.md 18:18:33 felixfontein: +1 18:18:37 :) 18:18:48 If that looks sensible it would be broken down into multiple steps with a lot more explanation 18:19:21 samccann: having a couple of how-tos tailored to the most frequent contributions (fixing a bug, adding a new option) would be great! 18:19:27 I just did a video bit on training developers to clone collections and run them locally. More focused on roles and what my team does, but it was received very well 18:19:38 #chair GHellings 18:19:38 Current chairs: GHellings abadger1999 andersson007_ cyberpear dmsimard felixfontein geerlingguy gundalow gwmngilfen samccann 18:19:50 Definitely vital to new contributors, even if they're familiar with Ansible itself 18:19:56 Regarding the large number of "interested" in Contributor Summit, it's from AnsibleFest registration- there's a question: 18:19:56 indeed! 18:20:01 Are you interested in attending the Ansible Contributor Summit on October 12?* 18:20:01 (By selecting “Yes,” you agree to be contacted by the Ansible Contributor Summit team for additional event information) 18:20:06 samccann: also keeping your PR current for newer versions of the upstream repo deserves a section/page 18:20:07 GHellings: Is that something that could be shared? 18:20:12 More than half selected yes 18:20:30 gundalow, The video is internal to Red Hat, just because of how I presented it. But I can redo it in a public format 18:20:52 abadger1999: yep! that's not trivial for beginners, and often leads to problems (people end up with merge commits, and the bot starts shouting at them) 18:21:13 (git remote add ; git fetch ; git merge --ff-only to devel ; git checkout feature-branch ; git rebase devel ) 18:21:19 gundalow, The demo walk through already lives on Github 18:21:23 That's a big set of concepts and steps :-/ 18:21:55 (darn I missed a bus trying to type those messages. I think I'll just read the logs tomorrow) 18:22:24 abadger1999: yep. it would be great if GitHub's UI would have a button "update this branch from the upstream where this was forked from" if fast-forward is possible 18:22:25 GHellings: Got a link? 18:22:28 cybette: woops, sorry 18:23:10 cybette: thanks for writing them, and I hope you don't have to wait long for the next one! 18:23:13 gundalow, https://github.com/greg-hellings/ansible_collection_demo 18:23:22 b/2 18:23:41 Uses a Vagrant box to bring you from bare Fedora to developing new or adding to existing collections 18:25:23 "gundalow" (https://matrix.to/#/@freenode_gundalow:matrix.org) "felixfontein" (https://matrix.to/#/@freenode_felixfontein:matrix.org) no worries, I'm on the next bus now thanks :) 18:26:31 right, i'm back 18:26:43 * resmo waves 18:27:05 should we switch to the topic of 'inactive collection maintainers' then? 18:27:08 #chair resmo 18:27:08 Current chairs: GHellings abadger1999 andersson007_ cyberpear dmsimard felixfontein geerlingguy gundalow gwmngilfen resmo samccann 18:27:25 since not much has been written in the last few minutes, I guess it's ok 18:27:32 * resmo reading +3000 contributors summt... wait what? 18:27:45 #topic What to do with/about inactive (collection) maintainers? https://github.com/ansible/community/issues/539#issuecomment-669849223 18:27:58 let's discuss first if should we track collections under ansible-collections that haven't been released for some time and if not, should we release them ouselves 18:28:32 * gwmngilfen loads up the GH releases api 18:28:41 I guess it only makes sense to release them ourselves if there are actually things to update :) 18:28:50 sure 18:29:06 what does the community team think about this (i.e. gundalow abadger1999 who else?)? 18:29:11 did all collections initially have maintainers? 18:29:28 Something we always struggled with regarding orphaing when I worked on Fedora was having some sort of quality metric that made sense. 18:29:28 cyberpear: not really 18:29:29 does this translate to trying to identify maintained-but-stable things vs unmaintained things? 18:29:46 i think initial maintainers are people who initiated moving stuff 18:29:49 foo hasn't been released in three years but it Just Works(TM). 18:29:49 most have I think, but for example community.network and skydive.skydive (now community.skydive) and community.azure are pretty ... unmaintained 18:29:53 because thats come up for me before, and i have half-baked thoughts :P 18:30:09 I think yes ^ — I know there are sometimes roles or modules which might be feature complete and barely ever need to be touched. Others need feeding and care weekly. 18:30:10 gwmngilfen: I think so 18:30:22 bar hasn't been released in four months but it has 70 new bug reports and no one has answered them. 18:30:38 Sad thing is CI integration testing can help weed that out but most of the 'bad' unmaintained collections ain't going to have good CI anyways 18:30:44 so i spent a bit of time thinking about this, and I think it comes down to (a) number of open issues, and (b) time-to-close on issues/PRs 18:30:49 abadger1999: that's usually a good indication of that something is not good. or also lots of unmerged PRs, whose number increases 18:30:56 Is this a problem that exists today? 18:30:59 for a stable, maintained piece of software, those should both be low 18:31:12 (we integrated a stale bot to close things after 90 days unless marked as frozen/important in community.kubernetes 18:31:15 but for unmaintained things, they would increase over time 18:31:18 Following lead of K8s prow bots 18:31:41 (so that could skew results for your benchmark of maintained since bot could be doing the only maintenance :D ) 18:31:47 felixfontein: +1 unmerged/unreviewed PRs are a huge indicator of a problem.... that we might be able to do something about (empower the PR submitters to make needed changes and releases) 18:31:47 mmm, thats fine though, you'd want a close time of less than 90 days for maintained things 18:32:18 gundalow: speaking of which, is it possible to get ansibullbot for community.network? 18:32:23 One good benchmark is "how many issues have had zero responses in [x] days" 18:32:23 right, so this leads into my topic on what we'd like to see on some kind of collections dashboard 18:32:40 we at least try to respond with a follow-up question for any issue or PR, or with a label comment 18:32:44 time-to-close and time-to-first comment are already on the list 18:32:50 felixfontein: yes, once jillr has done her bot updates I can get it running there 18:32:58 gundalow: that would be awesome! 18:33:26 but are there other things that make sense folks would like to see? even if it's just basic collation of open/closed issues/prs, etc 18:33:35 "time-to-first comment": comments from authors are counted? 18:33:43 or from bots? 18:33:48 nope to both 18:33:52 ok 18:34:00 assuming I can tell its a bot, not always obvious 18:34:08 not count also comments from felixfontein and me:) 18:34:10 lol 18:34:15 lol 18:34:25 depends on the comments :) 18:34:36 "add changelog fragment" 18:34:46 that implies there were changes :) 18:34:52 and thus coding is happening 18:34:59 time from last maintainer (for some repos == committers. For c.g, would have to find out from the bot) comment is a good metric. 18:35:32 abadger1999: indeed. for c.g/c.n it's a bit harder to do as you said, but for most other repos it should be pretty easy 18:35:36 yeah, but as you say, could be tricky. happy to put that on phase two :) 18:35:57 should we count tags as release indicators? if possible 18:36:03 yeah, for other repos, GH reports the Author_Association status, which can be "maintainer" 18:36:11 andersson007_, I would say so 18:36:20 andersson007_: I'd count galaxy releases 18:36:25 (thats a field on the api response for any comment) 18:36:33 It seems like we also have two things we're looking for: maintainer activeness, and collection "well-maintainedness". 18:36:37 felixfontein: if it's possible, would be good 18:37:02 You hope that the first leads to the second but it might not be true. 18:37:07 abadger1999: seems right. the former seems doable, measuring the latter seems harder 18:37:16 Would we only orphan depending on the first one? 18:37:22 so when we talk about releases, are we talking about GH or Galaxy? 18:37:39 galaxy because gh is not set 18:37:43 could be anythign right? 18:37:47 Time since last CI passed? 18:38:03 If the CI can be determined 18:38:13 would be great to count releases on Galaxy, if not possible (no api, etc.), count tags 18:38:22 galaxy does have an api 18:38:23 as in.... I'm really active on commenting on new issues and PRs to my collection but horrid at getting any work done on it. do we orphan that collection? 18:38:33 gwmngilfen: great 18:38:46 how usable it is for this remains to be seen :) 18:38:58 To be honest, how many modules in ansible/ansible were never deprecated even after 4-5 years of nobody touching them at all :D 18:39:01 * resmo afk for 5, kids bed 18:39:07 it's been like a year since I last looked at it, but I can always poke the galaxy team a bit 18:39:12 Question is do we want our status quo to be better than that with collections 18:39:16 galaxy can tell you when all lof the releases on galaxy were uplloaded. 18:39:30 geerlingguy: quite a lot. the question is whether they still actually work fine, or whether they really need to get deprecated 18:39:30 geerlingguy: i'm sure we *want* it, its a question of doing it 18:39:30 abadger1999: gregdek 's topic about orphaned modules should definitely be expanded for collections as well 18:39:47 andersson007_: yeah. 18:39:53 andersson007_: +1 18:40:20 * gwmngilfen pokes about in galaxy a bit 18:40:54 also... policy wise, orphan can be independent of in-the-ansible-package-not-in-the-ansible-package. 18:42:50 for docs, it would be good to have a logo or something calling out orphaned collections or modules 18:42:58 https://galaxy.ansible.com/api/v2/collections/community/grafana/ seems ok, I see a "latest version" field 18:42:58 #cair acozine 18:43:02 #chair acozine 18:43:02 Current chairs: GHellings abadger1999 acozine andersson007_ cyberpear dmsimard felixfontein geerlingguy gundalow gwmngilfen resmo samccann 18:43:09 * geerlingguy has to run, lunch time 18:43:15 gwmngilfen: oooh, another thought for your time to close metrics.... a collection which has a single coherent project behind it will be different from c.g..... the single coherent projects, we'd be thinking of "should this collection be in the ansible package? should this collection be orphaned?" For c.g we'd be thinking of "should this module be in community.general? Should this moudle be orphaned?" 18:43:15 so people can see "oh, this isn't actively maintained" and make decisions accordingly 18:43:34 gwmngilfen: https://galaxy.ansible.com/api/v2/collections/community/grafana/versions/ 18:43:36 oh nuts, that api has no dates on it 18:43:41 would be better perhaps to have an 'active' logo - something for collection maintainers to strive for 18:43:43 you cant see when they were uploaded 18:44:08 gwmngilfen: I don't see a timestamp though 18:44:08 acozine: gregdek suggested a new bool field called `orphaned` 18:44:15 abadger1999: detecting when things should move to their own collection is absolutely something I keep discussing with gundalow :) 18:44:17 acozine: for modules 18:44:33 would also be nice to be able to link to "here's how you can take over this orphaned [thing]" 18:44:47 with steps like "create your own collection, copy the module code over to your collection, etc." 18:44:53 gwmngilfen: Doh! I was tricked by this: https://galaxy.ansible.com/api/v2/collections/community/grafana/ 18:45:15 I know in Drupal community, there's a process for actually transferring ownership of a given project... but with collections it's more complicated (especially if talking like community.general) 18:45:17 gwmngilfen: they're keeping the info (it's on the web ui) so I guess we have to ask them to provide it via the api. 18:45:42 yeah, that would be nice. which of us should get a poking stick? 18:46:01 One of the reasons community collections are under github.com/ansible-collections/ is so we can add other maintainers if the existing ones leave 18:46:11 gundalow: is that a thing you and I should bring up with chouse at the internal ansible project meeting? 18:46:24 https://gist.github.com/gregdek/52e6669421d3f65cded51862e16ad0e9 18:46:44 there's a section about orphaned stuff 18:46:47 gwmngilfen: https://galaxy.ansible.com/api/internal/ui/repo-or-collection-detail/?namespace=community&name=general seems to contain everything - though it's an internal API 18:46:57 we discussed the topic a little bit there 18:47:11 andersson007_: a boolean field sounds great; it would be even better if the docs build used that to change the look/feel of those pages 18:47:17 re 18:47:18 felixfontein: good find! but yes, if we can get it in the offical api that'd be better 18:47:28 acozine: sounds good 18:47:34 gwmngilfen: I looked in the Network tab in the dev tools to see where it gets the info from ;) 18:47:40 ahaha 18:47:45 consle tools are the best 18:47:48 yeah 18:48:06 especially for such webapps which do all the work client-side 18:48:27 so anyway, we have release data. so, we can look at releases - but that still leaves us with the problem of telling apart stable vs dead things 18:48:32 abadger1999: can just be raised in #ansible-galaxy 18:48:32 acozine: and an "I'd like to take maintenance" button? (maybe.... link to a github issue template to request that or something) 18:48:58 Cool, then gwmngilfen Maybe you want to take the action item? 18:49:04 we have time-to-close, time-to-comment, and time-to-release - i guess it'll be a combination of all three 18:49:07 gwmngilfen: if there are things you'd like just raise an issue and then mention it in ask in #ansible-galaxy 18:49:08 abadger1999: sounds also good 18:49:14 abadger1999: oh, that would be awesome 18:49:20 gundalow: raise where? 18:49:26 acozine - ah reading that doc (above) - makes more sense now to have orphaned vs retired etc visible on the docsite so users know (and some kind of warning if it shows up in a playbook execution etc?) 18:49:34 gwmngilfen: gh/ansible/galaxy 18:49:44 k 18:50:10 putting it on my todo - but with the url from felix I could build something right away and then switch to whatever official things comes along later :) 18:50:18 abadger1999 maybe a link to a docs page on 'what is orphaned/retired' that includes how to take this over in your own collection etc 18:50:46 abadger1999: acozine samccann would be great if you participate in the discussion in gregdek 's gist. 18:51:01 didn't we have a document for new maintainers somewhere? 18:51:21 I guess it might need some updating for the collection world, and could be mentioned more prominently (especially for orphaned stuff) 18:51:46 #action samccann acozine to review / participate in orphan discussion - https://gist.github.com/gregdek/52e6669421d3f65cded51862e16ad0e9 18:51:49 so, if I aim for an initial "thing" where we can look at these time-to-X metrics for a given collection, and then put together some kind of "ranking" based on all three. that would be a good piece of tooling for folks? 18:51:54 samccann: Or both? A docs page can give the end user a lot of useful information. An existing contributor would be ready to fill out the template. 18:52:05 @andersson007_ will do, thanks for the pointer 18:52:21 i can easily build an API on it too, if we want to query it from other tools 18:52:23 abadger1999 true 18:52:25 felixfontein: this page comes to mind, not sure if it's what you meant: https://docs.ansible.com/ansible/devel/community/maintainers.html 18:52:46 I'm not that concerned about collections without maintainers right now, hopefully we can last a few months 18:52:54 acozine: yw! 18:53:05 acozine: I think we had something more extensive 18:53:08 gwmngilfen: yeah. people will probably have more ideas of metrics to add to it once they see some initial data too :-) 18:53:16 (if I don't misremember) 18:53:54 for sure. i'm kinda shying away from simple "you have this many issues" things because theres about 900 versions of that already - but it can always be added if needed :) 18:54:30 the "gold standard" would be a curated list of examples, 50/50 split between stable things and dead things. but we're never going to get that :) 18:54:35 felixfontein - maybe it's in one of the github repos. There's a lot of doc info scattered right now 18:55:01 so, I think I'm going to aim for a list of "flag candidates" that gundalow or whoever can review from time to time 18:55:42 let me log some issues 18:55:44 samccann: I think it was either in ansible/ansible, or on the docsite where I read it 18:55:56 hmmm 18:56:13 maybe https://docs.ansible.com/ansible/devel/community/contributing_maintained_collections.html? 18:56:31 felixfontein: ^^^ 18:57:00 felixfontein: or https://docs.ansible.com/ansible/devel/community/committer_guidelines.html 18:57:17 ah I think it *was* https://docs.ansible.com/ansible/devel/community/maintainers.html - but it used to be a lot longer in the past :) 18:58:05 * cyberpear steps away for another meeting 18:58:22 https://docs.ansible.com/ansible/2.9/community/maintainers.html 18:58:55 yeah, I trimmed it down not too long ago because most of the info focused on ansible/ansible PRs and so on 18:58:57 https://github.com/ansible/ansible/pull/70488/files 18:59:02 gundalow: that page is seriously outdated :) 18:59:17 (the People part) 18:59:32 felixfontein: I think just about everything on that page is wrong 19:00:03 felixfontein: I added `Each collection community can set its own rules and workflow for managing pull requests, bug reports, documentation issues, and feature requests, as well as adding and replacing maintainers.` Is that actually true? 19:00:14 If not, we can put more detail in there again. 19:00:21 acozine: that's true 19:00:31 acozine: and that makes it hard to write more about it :) 19:00:41 yeah, that's why I took all that detail out 19:00:53 cyberpear: bye! 19:01:04 bye cyberpear! 19:02:26 so on the "time to first comment from a maintainer" thing - we've said it's tricky for community.general, but what if it was "time to first comment from a previous committer"? 19:02:44 does that help? 19:03:26 gwmngilfen: that's probably a good enough substitute in most cases! 19:03:27 ideally it'd be commiters to that part of the repo, but that could get messy 19:04:06 in theory it would mean a committer to one module in c.g would count when commenting on another module - but that's probably not so common? 19:04:10 acozine: Although process may vary it is basically 19:04:10 Raise PR -> Loop (Fix CI, Address review comments) -> enough reviews -> merge 19:04:11 For community.general, the problem is that the maintainer::code isn't mapped by anything about committers. But I'm not sure if that will be a problem or not.... have to look at raw data to find out. 19:05:06 Like..... if one of us here comments on any issues that aren't seeing updates to prompt the actual maintainers to respond... that will throw your metrics off since we're committers. 19:05:18 yeah i know 19:05:33 gundalow: do we want to add a general overview section to https://docs.ansible.com/ansible/devel/community/contributing_maintained_collections.html, above the `Requirements to merge your PR ` section? 19:05:39 it's possible that I could restrict the list of commits by filepath 19:05:52 gwmngilfen: we can probably get the information from the bot. 19:05:55 gwmngilfen: i often put something as the first comment like "dear maintainers, could you please take a look":) 19:06:11 acozine: That could be useful, thanks 19:06:13 that actually works now, but my current scraper is about to die, and the new one doesn't have that feature (yet) :P 19:06:19 It's just a thing that would have to be done separate from the code you already have for reading the same type of infor from github apis. 19:06:31 (it should be mapped i nthe bot's config file) 19:06:55 right, but you still have to know something about the PR to get the right thing from the bot, yes? 19:07:04 BOTMETA.yml 19:07:17 Yeah, you'd have to know about filepaths. 19:07:26 welll actually.... 19:07:29 i.e. if i stat with a list of PRs from c.g, what else do I need to figure the maintainer? I'm guessing it's the files touched 19:07:30 yeah 19:07:38 i was afraid of that 19:07:51 the bot knows who the committers are and does X to the issue/PR for that. 19:07:52 is any other collection handled with botmeta? 19:07:58 s/committers/maintainers/ 19:08:18 it's not like we're likely to declare c.g. abandoned, i'm inclined to treat it as special and not have it on the table :) 19:08:19 gwmngilfen: community.network, and maybe also the aws ones 19:08:36 well there goes that idea then 19:08:58 if the bot labels them all, then you can use the label to map to botmeta. If the bot just cc's the maintainers, you could try looking for that special comment adding the cc list. 19:09:17 gwmngilfen: BOTMETA is used by anywhere we use the bot, so general, network, amazon, vmware (and possibly windows) 19:09:31 gwmngilfen: Potentially any collections using the bot (which I think is what felixfontein just listed) 19:09:50 and these presumably all have multiple collections in, similiar to c.g 19:10:00 If we need to hack the bot to add a hidden comment with meta data that you could scrape we can do that 19:10:32 mmm, i will think about it 19:10:40 Possibly :-) Right, I think all of those do but that doesn't mean that a collection might not both use the bot for some things and choose to do merge/commit differently. 19:10:43 I think the bot does not CC people who already replied before the bot first posts 19:10:48 *Right now, I think all of those do 19:10:59 my gut feeling is that anything using the bot is likely to be always active, which makes it less of a priority for tracking these things 19:11:54 not to say we hould ignore it, but implementing the time-to-first-comment using author_association from GitHub will be a good first step, and covers anything not using the bot 19:11:55 then I can refactor more complex stuff after that 19:12:49 would be great to use a similar approach(es) for all collections under ansible-collections 19:13:51 yeah, but I always want a prototype done by Fest :) 19:13:56 s/always/also 19:15:22 i mean if the bot works not in all collections, the approach with botmeta doesn't feel fair 19:16:20 oh i see. i'm talking about blending them - use author_association where it works, query botmeta for the more complex repos. in either case, we should get a valid time-to-first-comment metric 19:16:36 how much to folk want to see trends? is it useful/valuable to see your time-to-X over the last few months? 19:16:56 (basically this translates to me use cron to storie the data in some simple db every week) 19:18:02 seeing it over a few months would be helpful I think 19:18:21 for detecting orphaned repos, it might be useful to even have it over years, to see how it used to be in the past :) 19:18:48 if im storing it at all, it might as well be for a while :) 19:18:58 ok, logging an issue for that 19:19:17 Heh, I could see tons of useful-but-out-of-initial-scope things to do with historical data. 19:19:27 gwmngilfen: don't forget to regular back up your database;) 19:19:30 heh, instead of canning food, you're doing data prepping, gwmngilfen? 19:19:31 feel free to log them :) 19:19:44 https://github.com/ansible-community/stats-collections/issues/7 19:19:46 regularly 19:19:53 andersson007_: indeed! 19:20:02 * gwmngilfen was a sysadmin, once. backups are underappreciated 19:20:06 Like, "Should we schedule X during hte holidays because more people from the community are available to work on it or not because less employe4es are avaiable?" 19:20:22 hehe :) 19:20:29 depends on the community-employee ratio ;) 19:20:33 ah, that involves solving the identity problem first. good luck :) 19:21:06 gwmngilfen: All we'd really need to answer it is "Did work increase or decrease every year in this time period" 19:21:34 it moots the identity issue ;-) 19:21:57 I need to drop shortly, will catch up tomorrow 19:21:59 heh, true i guess. but thats not what time-to-event metrics will tell you. for that you probably want to look at the time series of issues/prs/commits 19:22:09 gundalow: btw, since you know someone at github, github seems to have problems in the UI: if I reload https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/porting_guides/porting_guide_2.10.rst or https://github.com/ansible/ansible/blob/stable-2.10/docs/docsite/rst/porting_guides/porting_guide_2.10.rst, the "Latest commit" is changing sometimes, and the history is sometimes wrong 19:22:15 as well. it seems to confuse branches. 19:22:27 gundalow: that was already happening this morning, and I just saw that it is still happening 19:22:56 * gundalow looks 19:23:33 oh, that's funky. I'll report that tomorrow 19:24:07 thanks! 19:24:18 i gotta run too. thanks for the input folks. I hope I'll have some things to get feedback on before fest :) 19:24:21 feel free to log further thoughts on the repo 19:24:35 we're overtime anyway :) 19:24:39 thanks gwmngilfen and bye! 19:24:59 #topic open floor 19:25:05 anything else for today? 19:25:27 Done a quick hack for an interactive lab https://www.katacoda.com/gundalow/scenarios/testing-collections 19:25:44 It would be multiple steps with a lot more details of the what/why 19:25:59 Source is https://github.com/gundalow/katacoda-scenarios/blob/master/testing-collections/step1.md 19:26:27 Do people think something like this might be useful? 19:26:44 You can see a good example of what a finished Ansible *user* lab is here: https://www.katacoda.com/rhel-labs/scenarios/ansible-introduction 19:27:59 katacoda scenarii are great tool 19:29:14 hrm, I havne't signed up for katacoda 19:29:27 but in general that sounds like a great resource 19:29:34 are (new) developers likely to use a scenario walkthrough? 19:29:37 baptistemm: ++ for `scenarii` 19:29:51 heh was about to do that as well baptistemm++ 19:30:39 living next to Italia 19:30:42 gundalow: meaning, are they more likely to go through a presumably short scenario with everything set up for them, or want the instructions to do it themselves on a laptop? 19:31:34 gundalow: want would be the scope of this scenario ? debugging collections ? 19:37:37 samccann: that's something I'm unsure about 19:38:53 gundalow: - my nickel - make it short, see how frequently it gets used and then decide if it's worth expanding 19:39:03 (or adding more) 19:39:13 Sounds good 19:39:49 I guess same steps could be used for someone to use on their laptop 19:42:01 Thanks 19:42:18 maybe do a "drop-in" session at Fest for devs who want to try it out? 19:42:27 or promote it during Fest some other way? 19:42:37