18:07:01 <samccann> #startmeeting Community Working Group
18:07:01 <zodbot> Meeting started Wed Jun 14 18:07:01 2023 UTC.
18:07:01 <zodbot> This meeting is logged and archived in a public location.
18:07:01 <zodbot> The chair is samccann. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:07:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:07:01 <zodbot> The meeting name has been set to 'community_working_group'
18:07:20 <samccann> @room Meeting time!
18:07:20 <mariolenz[m]> o/
18:07:27 <mariolenz[m]> o/
18:07:31 <samccann> 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:07:40 <samccann> #chair mariolenz briantist
18:07:40 <zodbot> Current chairs: briantist mariolenz samccann
18:07:48 <samccann> #info Agenda: https://github.com/ansible/community/issues/679
18:07:51 <anwesha[m]> Hello
18:08:13 <briantist> o/
18:08:21 <samccann> #chair anwesha
18:08:21 <zodbot> Current chairs: anwesha briantist mariolenz samccann
18:08:29 <samccann> Topics: https://github.com/ansible-community/community-topics
18:08:48 <samccann> #topic Updates
18:08:55 <Leo[m]> hi all!
18:09:03 <samccann> #chair Leo
18:09:03 <zodbot> Current chairs: Leo anwesha briantist mariolenz samccann
18:09:32 <mariolenz[m]> Anything someone wants to discuss?
18:09:40 <samccann> #topic making community docs a separate project from ansible/ansible
18:10:02 <samccann> #info we're moving docs out of ansible/ansible - https://github.com/ansible-community/community-topics/issues/243
18:10:31 <samccann> #info goal is to eventually get docs under community control. This first step allows us to iterate/experiment w/o being tied to core
18:11:01 <samccann> #info we'll merge docs prs and publish from the new repo (ansible/ansible-documentation) for a two week period to see how it goes
18:12:26 <samccann> Anyone have thoughts etc on that one before we move on?
18:13:38 * bcoca crosses fingers
18:13:44 <mariolenz[m]> That is, docs minus ansible-core docs, right? The ansible-core-docs will stay under the control of the core team? Sounds like a good idea to me.
18:13:46 <samccann> heh
18:14:11 <samccann> so all the docs move, core and community. Core will maintain technical stewardship of the core-specific docs
18:14:38 <Landrash[m]> Only one comment, the period is during the western hemispheres summer and there's a natural slow down of pr during this period I would guess. Is the test period long enough?
18:14:55 <samccann> Over time, we will likely spit the docs core vs community but not in this first step. Right now we're just leaving ansible/ansible repo
18:15:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:15:43 <samccann> Landrash: good point. We'll see how many PRs etc we get and decide. Right now the test only impacts devel docs, but if anyone uses Edit on Github today, it will edit what is in the new `ansible/ansible-documentation` repo
18:16:37 <samccann> #info a related topic on the overall longer term strategy - https://github.com/ansible-community/community-topics/issues/240
18:16:56 <samccann> #info Other updates
18:17:21 <samccann> #info still looking for examples of ansible CLI commands with useful flags to add to docs  - https://github.com/ansible-community/community-topics/issues/240
18:17:43 <samccann> This is the list of topics that have the next meeting label - https://github.com/ansible-community/community-topics/issues?q=is%3Aopen+is%3Aissue+label%3Anext_meeting
18:17:52 <samccann> Anything there folks want to talk about?
18:18:07 <briantist> I was hoping to see if there were any updates on https://github.com/ansible-community/community-topics/issues/237
18:18:33 <briantist> but might need to wait on cybette_  if there's anything that can be shared yet
18:19:12 <samccann> ah yeah. I haven't heard status on that yet myself. I think folks are still digging details on costs etc
18:19:32 <briantist> ok np
18:21:22 <samccann> #topic Open Floor
18:21:23 <samccann> Anyone have anything to bring up?
18:21:23 <mariolenz[m]> Well if nobody has anything else I think I'd like to mention something... just give me a minute to type
18:21:23 <samccann> cool
18:25:29 <samccann> berline1999: I think you can try after mariolenz brings up their topic
18:25:29 <mariolenz[m]> I know we've talked this over and over again, but there are a lot of requests to include new collections into the community package. Some things we require for inclusion are really hard to check, meaning there's a lot of manual work. It would be great if we could define the requirements in a way that could be tested more or less automatically. I think there are already issues about this, but I can't find them at the moment.
18:25:29 <mariolenz[m]> Just wanted to remind you.
18:26:16 <briantist> I do think we should work off the existing issue(s) that discuss this, because I think the same points will be brought up
18:26:25 <samccann> #info collection inclusion requests still require a lot of manual work. Need to define requirements in a way that could be  tested automatically
18:27:51 <gotmax> In Fedora, we have a tool called fedora-review that automates package reviews
18:28:21 <samccann> I tried to find a related issue in community-topics but don't see anything obvious
18:28:22 <gotmax> It generates a text file with a checklist that has the things it can see automatically checked and then blanks for the things that require manual checks
18:28:44 <jtanner> you either accept them all or you become the "mean people who don't let us contribute" like the core team used to be
18:28:55 <jtanner> or you accept none
18:29:53 <briantist> I don't think the current situation is any of those things, it is a lot of work to review though
18:30:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:30:03 <Leo[m]> mariolenz[m]: we have the inclusion criteria, maybe it can be matched to a list to see _what_ can actually be automated and what requires manual review
18:30:33 <briantist> the previous discussions are probably here: https://github.com/ansible-collections/ansible-inclusion/pulls?q=is%3Apr+is%3Aclosed
18:30:35 <gotmax> ++
18:30:39 <Leo[m]> as part of the proposal to automate it
18:32:15 <mariolenz[m]> I don't think we'll find a solution in this meeting, just wanted to remind you that we have a problem there ;-P
18:32:26 <gotmax> Yeah
18:32:32 <gotmax> We should create an issue to discuss further
18:32:34 <samccann> #link https://github.com/ansible-collections/ansible-inclusion/pulls?q=is%3Apr+is%3Aclosed
18:32:39 <briantist> I am all for automating anything that can be, but a lot of the things in the requirements do not lend themselves well to automation. And I think we should not go down the road of removing requirements if they can't be automated: a requirement should be evaluated independently based on its usefulness and importance as it relates to adding something to the package.
18:32:57 <briantist> agreed, it should be discussed async
18:32:59 <Leo[m]> mariolenz[m]: +1 automate all the things  mariolenz! :D
18:33:50 <gotmax> Definitely. There's nothing comparable to a thorough human review, but automation can at least prevent the reviewer from spending a lot of time on the trivial stuff.
18:34:07 <gotmax> Is there anything else to discuss re. community docs?
18:34:07 <mariolenz[m]> <briantist> "I do think we should work off..." <- Would it help to tag those issues with `collection_inclusion_problems` or similar? This might make it easier to find them.
18:34:09 <Leo[m]> briantist: above was a joke, just in case, there is always some manual review and I don't think something like inclusion can be totally automated, lot's of subjective details
18:34:54 <mariolenz[m]> I don't want to create a new tag without your consent, though.
18:35:11 <briantist> oh I know that, I'm just saying it's tempting to start looking at "automatability" as a metric for evaluating inclusion rules, and I think that might be an antipattern
18:36:04 <gotmax> mariolenz[m]: I'm not sure what would fall under that tag
18:36:16 <briantist> mariolenz[m]: it looks like "issues" are disabled on this repo, and "discussions" are used primarily for inclusion requests, and PRs are for changes to the repo content... so I'm not actually sure where to have discussions about this 😅
18:36:29 <gotmax> community-topics probably
18:36:39 <samccann> gotmax: I haven't heard much else on community docs other than the steps we're taking this week to move out of ansible/ansible so we can experiment etc before finding an eventual home for community portions of those docs (aka non-core)
18:37:42 <gotmax> Right. I was wondering whether there were any plans beyond the ansible/ansible-documentation repo, but I guess not.
18:38:44 <samccann> ah the plans are still rough but in the hackmd
18:39:00 <samccann> https://hackmd.io/Ejh1G6hjSO2DFiJXyUpUsw
18:39:24 <samccann> Don's not available today but that I think has some ideas in it for what happens after we move to the new repo
18:41:09 <gotmax> Ack
18:42:24 <gotmax> Speaking of docs, I'd like to call attention to
18:42:28 <gotmax> #link https://github.com/ansible-community/ansible-build-data/pull/227
18:42:36 <gotmax> I'm still waiting for a review on that one
18:42:44 <samccann> um didn't see a link?
18:42:52 <mariolenz[m]> nope
18:43:06 * gotmax23 curses at the IRC bridge
18:43:07 <briantist> link worked for me?
18:43:08 <gotmax23> #link https://github.com/ansible-community/ansible-build-data/pull/227
18:43:12 <samccann> berline1999: meanwhile go ahead and ask your question
18:43:19 <mariolenz[m]> now
18:43:23 <samccann> #info looking for reviews ^^
18:43:59 <samccann> anwesha: that PR is lookign for your review pls
18:44:37 <briantist> if there was a message from `berline1999` I didn't see it... I guess a bridge thing
18:45:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:47:10 <berline1999[m]> Brian already gave suggestions, but looking for some more for this :  What would be the best practise you can suggest to move from older version of an API from new version of API, given the api schema is completely changes but the feature remains same. Will you create a new module and remove older one or keep both.  As ansible playbook doesn't allow two version of plugin in one playbook.
18:47:29 <berline1999[m]> s/from/to/
18:48:25 <berline1999[m]> Have anyone seen this kind of migration in any plugin before.
18:50:26 <samccann> ok not specific to the meeting so I'll go ahea and end that
18:50:30 <samccann> #endmeeting