18:00:15 #startmeeting Community Working Group 18:00:15 Meeting started Wed Jul 27 18:00:15 2022 UTC. 18:00:15 This meeting is logged and archived in a public location. 18:00:15 The chair is samccann. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 18:00:15 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:15 The meeting name has been set to 'community_working_group' 18:00:31 @room Meeting time! Who is here to talk about the community? 18:00:45 Raise your ascii hand (o/) to say hi or any other way you want to let us know you are here. And Welcome to any new folks! 18:01:36 o/ 18:02:14 briantist: cyberpear geerlingguy__ ikhan @jill jtanner misc resmo tadeboro zbr0 ping! 18:02:21 #chair mariolenz 18:02:21 Current chairs: mariolenz samccann 18:02:23 hi 18:02:27 o/ 18:02:38 #chair jtanner acozine 18:02:38 Current chairs: acozine jtanner mariolenz samccann 18:02:53 #topic Agenda https://github.com/ansible/community/issues/645 18:03:04 #info Agenda: https://github.com/ansible/community/issues/645 / Topics: https://github.com/ansible-community/community-topics 18:03:15 o/ 18:03:28 #chair andersson007_ 18:03:28 Current chairs: acozine andersson007_ jtanner mariolenz samccann 18:04:00 #topic Updates 18:04:08 hunleyd: ah, clear, thanks 18:04:24 #info VOTE ENDS 08-03 - on adding rules on collection dependencies: https://github.com/ansible-community/community-topics/discussions/119 18:04:43 #info VOTE ENDS 08-03 - removing google.cloud from Ansible 8 - https://github.com/ansible-community/community-topics/discussions/121 18:04:51 #info VOTE ENDS-08-03 on normalize booleans in documentation, ansible-lint, ansible-doc, ... https://github.com/ansible-community/community-topics/discussions/120 18:04:59 * samccann thinks 08/03 is a magical day 18:05:12 :) 18:05:23 #info AnsibleFest registration is open! The event will be at Sheraton Grand Chicago Riverwalk on October 18-19, 2022. Check out the details and register at https://www.ansible.com/ansiblefest 18:05:29 i already mixed it up with today yesterday 18:05:37 the date i mean 18:05:38 heh 18:05:39 #info Ansible Contributor Summit will be the day before AnsibleFest (Oct 17, 2022) at the same location. Due to the focus of the event, space is limited and you'll pre-register to be on the "invite" list (so when you register for Fest you can add on Contributor Summit as an option) https://ansiblecs202210.eventbrite.com/?aff=matrix 18:05:48 #info For those attending Contributor Summit virtually you can also register on Eventbrite and select the "Online" option 18:05:52 "mariolenz: do milestones send..." <- I don't think so, but I'm not sure. But I think they're the usual way to group things to be done for a release. WE would have to actively check what's still open, though. 18:06:13 Any other updates? 18:07:49 ok folks can add in at any time 18:07:49 mariolenz[m]: if you add your suggestion about milestones to https://github.com/ansible-community/community-topics/issues/122, it'd be great:) 18:07:51 #topic Ansible Roadmap and Tracking 18:08:02 heh 18:08:11 #info new community topic on how to better track deliverables and ensure they are completed on time for future Ansible package releases - https://github.com/ansible-community/community-topics/issues/122 18:08:34 #info we have Ansible roadmaps but they are date-focuse and do not include 'planned work' like the core roadmap has - https://docs.ansible.com/ansible/devel/roadmap/ROADMAP_2_14.html#planned-work 18:08:44 #info how can we best decide what we plan for Ansible 7, 8, etc as well as track to be sure we are on target to deliver (or update Planned work for whatever gets delayed as core does)? 18:09:33 could we use a GitHub Project for tracking? 18:09:53 Hm, I don't see Projects on the community-topics repo 18:10:53 interesting. I wonder if there's a way to 'turn it on' 18:11:12 First i came up with something that will automatically force a release engineer to take a look, say, at non-empty special file but it can be too late 18:11:14 There's a few things going on here: 18:11:23 I have no idea, I expected it to be there 18:11:36 1. getting people to vote (especially Steering Committee) so we can finalize decisions 18:11:47 2. Implementing those decisions 18:12:14 3. Coordinating/tracking work for future release (like when a collection is deprecated in Ansible 7, we need to remember to remove it in Ansible 8 etc) 18:12:59 i can enable Projects there in settings if we decide to follow that way 18:13:51 ah, that's great andersson007_ 18:13:52 I'm especially interested in p. 3, though all of them are important of course 18:14:06 automate it? 18:14:31 if all (or most) of the underlying tasks are documented as issues, then GH Projects seems like a reasonable starting point 18:14:34 for tracking it all 18:15:01 @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting 18:15:18 acozine: right now they aren't issues (point 3 specifically). Pt 1 are issues, but the implementations of them are not tracked in separate /linked issues all the time 18:15:54 ah, okay, does that suggest we should look at other tools/processes then? 18:16:02 i've just turned it on if someone wants to take a look 18:16:15 how about milestones as mariolenz[m] suggested? 18:17:07 issues can be added to milestones, say, called Ansible 7, Ansible 8, etc. 18:17:10 can you explain milestones a bit? is this like core, where I think they pull a milestone branch at fixed points during the devel cycle or something else? 18:17:28 or is this a github milestone feature ? 18:17:33 yes 18:17:40 github milestone feature 18:18:00 https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/about-milestones 18:18:09 for anyone who wants a quick look 18:18:34 So that shows promise for sure. We'd need to turn community-topic decisions into a series of issues and then assign milestones 18:18:35 but it will require some effort from a release engineer to recall that they exist:) 18:18:44 #info we could use github milestones https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/about-milestones 18:18:59 that looks like a good option 18:19:01 yeah that was my aforementioned need for a nagger :-) 18:19:24 :) 18:19:29 But if we add it to this meeting's agenda as a standard review item, that might cover it 18:19:44 like topic milestone review and take a look at.. erm.. whatever github shows 18:20:24 We'd also need a planning phase to say for the August milestone, we hope to do x, y, and Z. And then post August, move what wasn't completed (cuz things always slip) 18:21:12 so I think we have two problems to solve: 18:21:12 1 - how to track things better 18:21:18 2 - who gonna nag 18:21:38 well, 2 is more like 0- who will turn what we want to track into issues, add to milestones, nag about milestones, update milestones etc 18:23:40 yeah, there needs to be a release manager 18:23:49 to turn decisions made into issues will generate a lot of noise and it'll get harder to find something in community-topics 18:23:52 aka a Head Nag 18:24:34 I think projects have a more loosely defined scope. You can have a project to implement something within the current major release, but you can also have a project (for example cleaning up the documentation) that could span several releases. They're not necessarily tied to the next major release... also you could define it like that, if you want to. 18:25:06 andersson007_: good point. We may need a different 'repo' for that so it doesn't add noise to community-topics. That said, how many of those implementations are actually part of that repo? I'd think very fuew 18:25:09 few even 18:25:28 So the issues would be opened in other repos, but added to the general Ansible 8 Release Github board 'somewheres' 18:25:58 mariolenz: yep good point. 18:27:21 maybe we could create issues which are associated with releases (and corresponding milestones) in ansible-build-data ? 18:28:10 i don't have we have something else bounded to certain dates 18:28:25 "i don't think" 18:28:31 :) 18:30:02 * andersson007_ andersson's not-native-english brain generates bizarre things at this late time 18:30:03 @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting 18:30:27 heh 18:30:57 heh, my native-english brain does that often enough too 18:31:04 :) 18:32:09 so how about ansible-build-data repo where all stuff related to releases happens? 18:32:14 be sure to add your thoughts to the community-topic as well https://github.com/ansible-community/community-topics/issues/122 18:33:00 I do like the idea of something 'failing' the build if it wasn't implemented, but can you walk me through it a bit? Say we forget to remove foo.bar collection, how hard is it to remove after the build fails? 18:33:23 is it just a line item in the build data file the needs to be snipped and you rerun the build? 18:36:13 "Say we forget to remove foo.bar collection, how hard is it to remove after the build fails?" good question, as I mentioned it can be (maybe) not too late but can delay things, I think 18:37:05 to remove a collection from a build is not hard but there can be other cases 18:37:42 "so how about ansible-build-..." <- I'm not sure if we could add things from ansible-community/community-topics to an ansible-build-data milestone. We might need to have "implement ansible-community/community-topics discussion XYZ" issues in ansible-build-data. I'm not against this, just wanted to mention it. 18:37:42 and even removing implies some work made long before 18:38:40 mariolenz[m]: yes, it's what i was talking about 18:38:44 mariolenz: so milestones are single-repo only? 18:39:29 It might help thin in that community topic if you can walk through all the steps that have to happen to 'remove foo.bar' from Ansible 8 as a walkthrough example. And roughly when each step has to happen 18:39:48 not a lot of detail but enough for those of us not involved to understand and help with ideas on how to keep it on track etc 18:39:56 acozine: I'm fine with creating issues in ansible-build-data. anyway solved topics would be marked as completed in a milestone 18:40:34 that wasn't an objection at all, just curious about the scope of the Milestone feature 18:40:35 but, yeah, let's think more:) 18:41:32 I have to drop now, thanks for the nice conversation folks! Please put your thoughts in the topic https://github.com/ansible-community/community-topics/issues/122 18:41:58 have a great rest of the day 18:42:27 bye andersson007_ ! 18:42:33 thanks andersson007_ ! 18:42:45 ok we have a few minutes left so... 18:42:50 #topic Open Floor 18:43:02 Anyone have any other topic they want to chat about today? 18:44:20 not that I can think of . . . 18:45:00 @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting 18:46:08 "mariolenz: so milestones are..." <- I'm not 100% sure. But if you think about it, a milestone is a way to track the stuff you want / have to implement. Another repo is kind of an organizational boundary. 18:46:47 Well github projects definitely allow you to breach that organization boundary. But we can probably create a test of this somewheres 18:46:57 samccann: Nothing much, but FYI: We've had a dependency problem with community.mongodb. This looks fixed now: https://github.com/ansible-collections/community.mongodb/issues/482 18:47:10 yeah, it would make sense to focus a milestone on a single repo, but in some circumstances it's useful to pull in issues or PRs from related repos 18:47:45 #info dependency issue with community.mongodb is fixed now - https://github.com/ansible-collections/community.mongodb/issues/482 18:47:55 hooray 18:49:00 ok that seems about it for today 18:49:03 #endmeeting