18:01:00 <dmsimard> #startmeeting Ansible Community Meeting
18:01:00 <zodbot> Meeting started Wed Dec  1 18:01:00 2021 UTC.
18:01:00 <zodbot> This meeting is logged and archived in a public location.
18:01:00 <zodbot> The chair is dmsimard. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:01:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:01:00 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:01:09 <dmsimard> #topic Agenda https://github.com/ansible/community/issues/539
18:01:19 <felixfontein> o/
18:01:30 <berkhan> o/
18:01:43 <dmsimard> #chair felixfontein berkhan
18:01:43 <zodbot> Current chairs: berkhan dmsimard felixfontein
18:01:46 <cybette> o/
18:01:52 <jillr> o/
18:01:56 <felixfontein> #chair cybette jillr
18:01:56 <zodbot> Current chairs: berkhan cybette dmsimard felixfontein jillr
18:02:16 <cyberpear> o/
18:02:19 <felixfontein> #topic Updates
18:02:24 <felixfontein> #chair cyberpear
18:02:24 <zodbot> Current chairs: berkhan cyberpear cybette dmsimard felixfontein jillr
18:02:30 * dericcrago waves
18:02:31 <felixfontein> #info Ansible 5.0.0 has been released
18:02:44 <dmsimard> #undo
18:02:44 <zodbot> Removing item from minutes: INFO by felixfontein at 18:02:31 : Ansible 5.0.0 has been released
18:02:48 <samccann> o/
18:02:48 <dmsimard> #info Ansible 5.0.0 has been released: https://groups.google.com/g/ansible-announce/c/t0JoB6evpt8
18:02:54 <felixfontein> #chair dericcrago samccann
18:02:54 <zodbot> Current chairs: berkhan cyberpear cybette dericcrago dmsimard felixfontein jillr samccann
18:04:17 <dmsimard> #info Monthly virtual community meetups delayed until January
18:04:48 <dmsimard> ^ I had not gone into the details but I did mention that in passing, I would've liked to start it in december but we'll delay a little bit
18:04:58 <cidrblock[m]> o/ !
18:05:25 <dmsimard> #chair cidrblock[m]
18:05:25 <zodbot> Current chairs: berkhan cidrblock[m] cyberpear cybette dericcrago dmsimard felixfontein jillr samccann
18:05:29 <dmsimard> any other updates ?
18:06:12 <felixfontein> not from my side
18:06:27 <dmsimard> I was hoping for higher attendance due to the sensitivity of the ansible 5 py38 topic but we can start with that I guess
18:07:00 <felixfontein> acozine andersson007_ baptistemm bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal misc nitzmahone resmo samccann tadeboro cidrblock thaumos zbr: ping!
18:07:06 <felixfontein> (sorry for also pinging the ones already chaired :) )
18:07:33 <cyberpear> my vote is for "Lower the Ansible 5 ansible-core requirement down to >=2.11 and keep the python requirement intact (until we decide to raise it, i.e, Ansible 6 or 7)"
18:07:40 <samccann> acozine is likely out today. Got her booster shot and was feeling ill earlier
18:08:06 <dmsimard> #topic Ansible 5: raise python requirement from >=2.7 to >=3.8 https://github.com/ansible-community/community-topics/issues/54
18:08:10 <felixfontein> cyberpear: I strongly disagree :)
18:08:16 <andersson007_[m]> i'm also out ...after visiting a dantist
18:08:24 <andersson007_[m]> though i can read and vote
18:08:45 <felixfontein> andersson007_[m]: I'm glad this isn't a phone or video conference, where you'd have to speak :)
18:08:47 <andersson007_[m]> #chair: andersson007_
18:09:04 <andersson007_> felixfontein: yeah:)
18:09:05 <dmsimard> For context: installing ansible=5.0.0 with anything lower than python3.8 results in a failure because ansible-core requires python 3.8 since 2.12: https://github.com/ansible/ansible/issues/76414
18:09:05 <bcoca> for collections/modules/;plugins you've always had those that required specific python versions, but for core .. you should really never update python requirements and core versions out of lockstep
18:09:43 <bcoca> i would argue you either keep maintaing those in parallel or defer to core docs for 'supported python versions'
18:09:56 <bcoca> the latter saves headaches in the long run
18:10:02 <dmsimard> Two options have been suggested so far, being:
18:10:07 <dmsimard> 1) Keep Ansible 5 requirement on ansible-core>=2.12 and raise the python requirement to >=3.8 (up from >=2.7)
18:10:13 <dmsimard> 2) Lower the Ansible 5 ansible-core requirement down to >=2.11 and keep the python requirement intact (until we decide to raise it, i.e, Ansible 6 or 7)
18:10:30 <cybette_> #chair andersson007_
18:10:34 <dmsimard> before we discuss these into more details, are there other options we should be thinking about ?
18:10:41 <andersson007_> thanks cybette_ !
18:10:52 <cybette> #chair andersson007_
18:10:52 <zodbot> Current chairs: andersson007_ berkhan cidrblock[m] cyberpear cybette dericcrago dmsimard felixfontein jillr samccann
18:10:55 <berkhan> Which distributions don't include Python 3.8? Debian Bullseye (stable) ships Python 3.9 (https://wiki.debian.org/Python#Supported_Python_Versions)
18:11:14 <dmsimard> berkhan: I had gone through that exercise when the bump to 3.8 was originally proposed a while back, let me find it
18:11:30 <felixfontein> berkhan: debian buster (10) :)
18:11:32 <bcoca> berkhan: dont think of 'current' distro but existing installations, ... many are stuck on centos7 and similar numbers in other distros
18:11:58 <berkhan> dmsimard: Buster (oldstable) will not recieve any *security* updates 5-6 months later
18:12:34 <dmsimard> The table I had drafted at the time: https://github.com/ansible/ansible/issues/72668#issuecomment-733068389
18:12:50 <berkhan> bcoca: you are right but at the same time how many CentOS or RHEL users upgrade their Ansible scripts? I am still on Debian Bullseye with Ansible 2.7 for example
18:13:25 <cyberpear> mainly CentOS 7 is the big whale
18:13:27 <dmsimard> bcoca: I will remind you that there are still requirements on py27 in spite of "current" distros and py27 been EOL for almost 2 years already
18:13:33 <bcoca> berkhan: mixed bag,  while there might be many, i would doubt they hit 5% of the user base
18:14:24 <gundalow> Not around, though I'm +1 for the async proposal
18:14:30 <bcoca> dmsimard: no need to remind me ...painfully aware of that, at least for target. but ansible-core will be much more aggressive on python versions when it comes to controller going forward (also python itself has become more agressive on version publish/retireing cycles)
18:15:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:15:01 <jillr> my concern is just not surprising people. I do think we should rapidly move to 3.8, but users should have some notice that it's coming
18:15:02 <bcoca> for those using ansible-pull this is also a big change
18:15:18 <berkhan> bcoca: I am not saying the user base doesn't exist :)
18:15:31 <bcoca> jillr: core has put this on roadmap and publicily discussed for more than a year
18:15:40 <apollo13> jillr: the notice has been out there for a while
18:15:49 <dmsimard> jillr: py38 is already required for ansible-core 2.12, best we can do to delay the "surprise" is to lower the requirement down to 2.11
18:16:21 <jillr> bcoca: I admit I havent followed user notices as closely cause I run on devel  ;)  that probably works for me then
18:17:07 <jillr> dmsimard: right, I was mainly thinking should 5.0 have a porting guide or something to say "ready ready for 6 y'all, it'll require 3.8"
18:17:09 <bcoca> <= also runs on devel .. why i pushed that we notice long ago .. .cannot wait to get rid of py2.7 on my system
18:17:24 <felixfontein> I think the correct solution is to declare ansible 5 as Python 3.8+ (on controller), instead of reverting our decision to base ansible on the latest ansible-base/-core release available on that ansible release (https://meetbot.fedoraproject.org/ansible-community/2020-07-01/community_working_group_meeting.2020-07-01-18.04.html)
18:17:57 <dmsimard> felixfontein: thanks for hunting that down, I was wondering if it had been written down somewhere
18:18:05 <jillr> if we feel confident users have had a notification period then I'm ok with that, felixfontein
18:18:05 <bcoca> i would just suggest that the process of selecting core version includes/mandates updating requirements
18:18:52 <cidrblock[m]> Have we previously stated major releases of the ansible pkg will require the latest version of ansible-core available as a minimum?
18:19:00 <felixfontein> we can also publish more Ansible 4.x.0 releases if we want to have a more up-to-date Ansible release that supports Python 2.7+ on the controller
18:19:13 <cidrblock[m]> (if only to avoid the situation again)
18:19:14 <dmsimard> cidrblock[m]: it was implied, felixfontein just linked where the decision had been taken back in 2020
18:19:42 <bcoca> https://github.com/ansible/ansible/issues/76414 <= FYI, the 'pip' error when using a older python is not really good, just shows the version as not in 'available list', not that you need newer python for it
18:19:48 <dmsimard> felixfontein: this would be a third option -- that this serves as an incentive to continue maintenance for 4.x
18:19:57 <felixfontein> the porting guide for Ansible 4 already mentions that 3.8 will be a hard requirement for ansible-core 2.12: https://docs.ansible.com/ansible/devel/porting_guides/porting_guide_4.html#other
18:20:01 <apollo13> bcoca: that said an up2date pip will properly install ansible 4 instead of 5
18:20:29 <apollo13> (even in the current released form on pypi)
18:20:40 <jillr> felixfontein: awesome, thanks
18:20:44 <bcoca> apollo13: seeing that many distros still come with ancient pip by default ...
18:20:47 <felixfontein> and we can make not too old pip's happy by adding a Python requirement to the package, releasing 5.0.1 with it, and yanking 5.0.0
18:20:51 * bcoca stares at rhel8
18:21:05 <apollo13> bcoca: sure but those people are probably used to venvs anyways?
18:21:11 <bcoca> iwouldhope
18:21:18 <felixfontein> I don't know how old pip has to be that it ignores the Python requirements of a package
18:21:27 <apollo13> I mean those people can a) use system packages of ansible or b) update pip in a venv because otherwise you'd probably have manylinux wheel issues
18:21:38 <bcoca> felixfontein: iirc, < 18.0
18:22:03 <bcoca> but again, 9.x  was still default till very recently
18:22:06 <apollo13> and somewhen between 20 and 21 pip learned to download ansible 5 first and then when install subseuqently fails it downgrades
18:22:25 <dmsimard> felixfontein: my argument in favor of #2 is that collections should already be testing against both 2.11 and 2.12 so it should "just work" and would benefit users of <py38 by getting updated collections with 2.11 for a while longer. I believe this would be less work for us than to continue maintenance releases of 4.x.
18:22:32 <felixfontein> bcoca: meh...
18:22:44 <bcoca> the issue is 'milage will vary' .. so at least an FAQ with several cases might be in order
18:22:57 <felixfontein> dmsimard: my main argument against #2 is that it breaks the assumption that if you install the latest ansible package, you will also get the latest ansible-core version
18:23:17 <felixfontein> (well, latest that was around when the latest ansible package was built)
18:23:29 <bcoca> felixfontein: that is not always a good assumption, since the releases are not in sync
18:23:33 <dmsimard> lots of assumptions will be broken when people try to install ansible with their python versions and it won't work :/
18:23:35 <samccann> I'm not sure the docs impact of #2 off the top of my head.
18:23:43 <bcoca> there will always be a period that the latest core is not installed by latest community
18:24:02 <berkhan> does ansible-core or awx gather information such as Python version?
18:24:07 <dmsimard> bcoca: shouldn't happen, for example it's >=2.11.6 for ansible 4
18:24:16 <samccann> I 'think' we could produce Ansible 5 docs off a stable-2.11 core base, but I haven't tried it. When we decided to move to Ansible package always having the most recent ansible-core, we changed the build docs to match that decision
18:24:16 <felixfontein> bcoca: yes, but that period is usually < 3 weeks (except when there's a new 'major' release, then a bit longer)
18:24:22 <dmsimard> so even if I install ansible 4 a year from now, it should get latest 2.11
18:24:24 <bcoca> dmsimard: but 2.12 was released while 4 was 'latest'
18:24:31 <dmsimard> bcoca: ah, sure.
18:24:59 <dmsimard> berkhan: there's an ansible fact for it but I'm not sure what you are hinting at
18:25:00 <felixfontein> dmsimard: the interesting things happen when you already have some version of ansible-core installed :)
18:25:11 <bcoca> samccann: wont docs build then reflect the correct requirements and roadmap?
18:25:28 <felixfontein> like when you have 4.0.0 installed (with some ansible-core 2.11.x, x small), and you install 4.9.0
18:25:34 <bcoca> so docs for 5 alraedy should state correct python reqs .. is this then just an issue with the package itself in pypi?
18:25:55 <berkhan> dmsimard: nope. not that one. similar to Steam Hardware & Software Survey (https://store.steampowered.com/hwsurvey)
18:25:59 <samccann> @bcoca What I'm saying is - if we have to build docs for Ansible that have 2.11 core, then I have to test and see if that works
18:26:25 <bcoca> samccann: understood, just infering that current docs for 5 then match teh 'correct' requirements for 2.12?
18:26:27 <dmsimard> berkhan: there is no built-in telemetry that I am aware of, the closest might be https://pypistats.org/packages/ansible
18:26:29 <felixfontein> berkhan: ansible-core does not collect telemetry (to my knowledge), and I hope awx doesn't either (never used it though). no idea about tower.
18:26:30 <samccann> If we are saying the docs should still say core-2.12, then things are fine ;-)
18:26:54 <samccann> bcoca: yes, current docs for5 will have the correct 2.12 core docs to match
18:26:55 <felixfontein> basically our porting guide and changelog will also be wrong if we relax the dependency on ansible-core
18:27:03 <bcoca> felixfontein: no telemetry is collected by any of those, only if you have sattelite /insights .. which are specifically meant to do so
18:27:28 <felixfontein> resp. we would have to remove the ansible-core part from both of them, and just link to the ansible-core changelog and porting guide
18:27:36 <felixfontein> also the docsite will have wrong information on ansible.builtin
18:28:13 <bcoca> so 'simplest' solution seems to update the package .. for long term ensure package matches reqs from core package
18:28:37 <berkhan> i know built-in telemetry sounds scary but that way its hard to tell who support. Thanks dmsimard for reminding PyPI Stats
18:28:49 <dmsimard> bcoca: I identified the issue as a gap in our integration testing, we should have caught that prior and we'll improve it to ideally avoid the issue in the future
18:28:57 <apollo13> and it would "match" the communicated requirements that ansible-core requires 3.8 (most people would expect -core and ansible to be in lockstep)
18:29:27 <felixfontein> telemetry in software that doesn't need to talk with the producer's server is the best way to ruin your reputation
18:29:29 <apollo13> (the …and is in addition to brian's comment)
18:29:35 <felixfontein> *automatically enabled telemetry, I mean :)
18:29:36 <dmsimard> berkhan: built-in telemetry in open source software is very controversial, not to go off topic here but do some research about audacity
18:29:52 <apollo13> or django, we discussed telemtry a lot
18:30:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:30:26 <felixfontein> telemetry for AWS's boto is easy, they just have to look at the user agent strings in the server log for the AWS API...
18:30:36 <bcoca> awx team wanted an opt in, even that was deemed too 'creepy' .. while it would have been very useful to see which modules/tasks/os we shoudl put our efforts on, no one likes to have to report data 'just cause'
18:31:06 <berkhan> dmsimard: i will take a look at it. thanks!
18:31:24 <randall> There are "popcon" stats in Debian, which can tell you how many people have the ansible package installed at which version. No info on pip installed ansible instances, though.
18:31:48 <apollo13> I guess for me the main question is: how many people actually know the difference between ansible and ansible-core. For most people this is a meaningless distinction
18:31:52 <berkhan> randall: in the setup, you are asked about installing popcon. No is default
18:32:02 <felixfontein> randall: the answer for popcon is usually "extremely old versions of ansible" ;)
18:32:09 <apollo13> those wanting more control over their env install ansible-core + select collection. The rest just wants an "ansible experience"
18:32:19 <bcoca> thsoe are opt in also, which is already a subset of a distro (which in itself is a subset) .. i do use popcorn data as guide someetimes, but requries a lot of supposition for 'full picture'
18:32:22 <felixfontein> (since debian usually offers extremely old versions)
18:32:35 <dmsimard> We've already spent a lot of time on the topic -- I think there is some level of agreement that #1 is the easiest way forward, though in all likelihood it will not be the most popular option for users. If we go ahead with it, can we think of a potential workaround we can suggest for the use case where someone wants to have updated collections from
18:32:35 <dmsimard> Ansible 5 while running 2.11 ?
18:33:13 <apollo13> provide a meta collection that pulls in the others at the 5. version?
18:33:13 <cyberpear> with RHEL 9 shipping just ansible-core, many will learn the difference
18:33:17 <apollo13> (if this is possible)
18:33:17 <bcoca> dmsimard: tehy can manually install 2.11 and then ansible-galaxy install <list of collections from 5> ... i have a play that does this already
18:33:21 <felixfontein> you can always do what people suggest: use `ansible-galaxy collection install` :)
18:33:42 <felixfontein> or if we want to make such people happy we could also release newer versions of Ansible 4
18:33:45 <bcoca> play builds meta collection from collection list of the ansible package
18:33:47 <dmsimard> bcoca: that's actually not a bad idea, in fact we already compute a galaxy requirements.yml based on the collections in the package but we don't currently do anything with it: https://demo.recordsansible.org/results/689573.html#stdout
18:34:10 <bcoca> https://github.com/bcoca/acd/
18:34:19 <apollo13> can " <list of collections from 5>" be even replaced with a single collection that pulls the other?
18:34:33 <felixfontein> apollo13: almost, if you ignore ansible.builtin
18:34:36 <apollo13> or is that not possible (I am a little behind on collections)
18:34:40 <berkhan> felixfontein: Bullseye (oldstable) provides 2.7 and Bullseye backports provides 2.10
18:34:46 <bcoca> generate_acd.yml is a play that downloads the build script and extracts the collections and sets them as requirements, so ansible-galaxy install acd .tgz wil 'just work'tm
18:34:46 <apollo13> felixfontein: but ansible.builtin is shipped with core anyways no?
18:34:48 <dmsimard> apollo13: not sure about a meta collection but we can provide a galaxy requirements.yml file like the one I linked above
18:35:13 <dmsimard> bcoca: will look, thanks for sharing
18:35:14 <felixfontein> berkhan: 2.7 is extremely old. and 2.10 is EOL next spring as well
18:35:16 <bcoca> ^ play already prompts for version/branch
18:35:31 <apollo13> dmsimard: I'd prefer a meta collection if possible because one wouldn't have to download the requirements.yml file then (or can ansible-galaxy install that from urls as well)
18:35:31 <bcoca> i 'll update defaults, have not used in a while
18:35:48 <bcoca> apollo13: that play generates the meta collection
18:35:50 <berkhan> felixfontein: Sorry Bullseye (stable) provides 2.10. Backport is 2.9.16. However, experimental provides 4.6 :)
18:36:09 <berkhan> felixfontein: I know it's old but still has its user (like me :D)
18:36:47 <felixfontein> should we vote?
18:36:52 <dmsimard> Yes, let's have a formal vote (-1/0/+1) before moving on so we have it on the record, please
18:36:56 <dmsimard> VOTE: Keep Ansible 5 requirement on ansible-core>=2.12 and raise the python requirement to >=3.8 (up from >=2.7)
18:36:56 <apollo13> bcoca: sure but it would still be nice to be able to easily pull it from the official galaxy servers without much extra work
18:36:57 <felixfontein> so we have something to do?
18:37:01 <felixfontein> +1
18:37:13 <jillr> +1
18:37:14 <bcoca> apollo13: just need to publish it and generate on CI ...
18:37:14 <cidrblock[m]> +1
18:37:17 <andersson007_> +1
18:37:17 <dericcrago> +1
18:37:20 <dmsimard> +1
18:37:33 <apollo13> bcoca: yes, that is easy for you and me, but you and me can just use python 3.8 as well…
18:37:34 <cybette> +1
18:37:42 <berkhan> +1
18:37:52 <apollo13> oh you mean you would publish it on galaxy, makes sense -- sorry
18:37:55 <bcoca> apollo13: once done, its easy for all
18:37:58 <felixfontein> #chair
18:37:58 <zodbot> Current chairs: andersson007_ berkhan cidrblock[m] cyberpear cybette dericcrago dmsimard felixfontein jillr samccann
18:38:06 <berkhan> since i believe Ansible is moving fast
18:38:06 <bcoca> they just 'ansible-galaxy install bcoca.acd'
18:38:18 <bcoca> ^ or new name that makes more sense and is not my personal test
18:38:23 <dmsimard> Any objections to the proposal ? If not, there is no need to vote on the second option which is to lower the ansible-core requirement
18:38:32 <apollo13> bcoca: yeah I assumed you ment everyone should run their own ci for that etc…
18:38:34 <felixfontein> ansible.not_bcocas_acd? :)
18:38:40 <bcoca> ah, no, just 1
18:39:04 <dmsimard> going once
18:39:04 <bcoca> felixfontein: i would suggest, community.ansible
18:39:16 <dmsimard> going twice
18:39:30 <cyberpear> -0
18:39:31 <samccann> +1
18:39:56 <dmsimard> #agreed Keep Ansible 5 requirement on ansible-core>=2.12 and raise the python requirement to >=3.8 (up from >=2.7)
18:39:57 <dericcrago> what's the requirement for collections documenting their minimum python requirement? could we run into a situation where the collection is assuming python >= 3.8 now and thus not documenting the requirement?
18:40:14 <dmsimard> dericcrago: we actually had a topic about that not too long ago
18:40:22 <felixfontein> strictly speaking we have not enough votes by steering committee members
18:40:38 <berkhan> dericcrago: you wouldn't install ansible-core?
18:40:46 <dmsimard> felixfontein: fair, I will post the results in the issue and solicit additional feedback
18:41:05 <felixfontein> dmsimard: we should still prepare for this solution :)
18:41:12 <bcoca> felixfontein: but same would be said of overturning using 'latest core' ... so either get quorum or #1 is closer to previous 'quormized' decision
18:42:00 <dericcrago> dmsimard - yeah, I was trying to remember the outcome from it without looking it up :P
18:42:08 <dmsimard> berkhan: there is a distinction between the requirements for installing and running ansible on the controller vs modules that are executed on the targets which still supports py2.7
18:42:34 <dmsimard> felixfontein: yes, let's chat about it after the meeting
18:42:41 <berkhan> dmsimard: didn't think about the modules that we are running on nodes :D
18:43:09 <felixfontein> since we don't have much time left, I don't think we can properly discuss either of the two other topics for today
18:43:14 <dmsimard> berkhan: basically: the node you are running ansible from should be fairly recent but you can use it to manage ollllddddd stuff
18:43:24 <felixfontein> let's do a quick look at both, if that's ok for everyone, and defer them to next week :)
18:43:29 <berkhan> so, built-in modules will be py38 then right?
18:43:29 <apollo13> right, but for instance lookup plugins might get incompatible?
18:43:44 <apollo13> berkhan: no, they also need to run on 27 targets
18:44:16 <felixfontein> I was just wondering, how do you know there are twentyseven different targets, until I realized what you mean? :D
18:44:30 <felixfontein> -?
18:44:37 <apollo13> my bad
18:44:47 <felixfontein> #topic How to make meeting / discussion process more inclusive and asynchronous?
18:44:52 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/38
18:45:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:45:03 <bcoca> no, buildint modules still support 2.7, builting PLUGINS that run on controller are 3.8 though
18:45:14 <felixfontein> #info Proposal: https://github.com/ansible-community/community-topics/issues/38#issuecomment-982456681
18:46:02 <felixfontein> so far feedback has been positive, it looks to me like the main question is whether there should be 'office hours' (like this meeting) or not
18:46:14 <berkhan> felixfontein: can I think of as a forum?
18:46:36 <felixfontein> berkhan: what do you mean?
18:47:43 <berkhan> when i first read async discussions it remind me e-mail conversations
18:47:52 <dmsimard> The trap about recurring scheduled meetings is that people consciously (or not) wait for the meetings to talk about stuff. The intent is to break that habit because it is not inclusive of people from the community that cannot attend the meetings (due to timezone differences or otherwise)
18:47:57 <bcoca> those are async ...
18:48:06 <felixfontein> I like the idea of still having some times where to discuss, and I don't mind them moving around. once things are more async, it's easier to miss these meetings, and less of a problem when fewer people are around
18:48:22 <bcoca> dmsimard: for core meetings  i require topics to be in agenda and ping peopole to read them ahead of time
18:48:44 <bcoca> for small topics people can bring adhoc to meetings, but anything lenghty i will push to next/future meetings for 'digestion time'
18:48:55 <bcoca> so you can have both, but you need strong moderation
18:49:11 <gundalow> For the moment this meeting will still exists and this time. Though it will be more general discussion, ie what's causing problems today. What ideas do people have. Zero voting in meetings
18:49:36 <andersson007_> +1
18:49:37 <dmsimard> berkhan: in our case we don't have a mailing list (we do, but not particularly for the community workgroup) so the proposal is to use github issues/discussions instead
18:50:16 <gundalow> berkhan: GitHub issue is sort of pork a single thread email list.
18:50:32 <gundalow> s/pork/like/
18:50:36 <samccann> +1 for moving decisions to async
18:50:51 <dmsimard> gundalow: I was truly wondering what was the meaning of pork there :P
18:50:58 <felixfontein> gundalow: when will we change and stop voting here? should we have a vote on this, say, next week? :)
18:50:58 <samccann> +1 for also keeping this and similar meetings 'in some form' for brainstorming etc before an idea is up for proposal
18:51:00 <tadeboro> Hi all. o/
18:51:00 <jtanner> that is quite the typo
18:51:06 <felixfontein> hi tadeboro!
18:51:09 <felixfontein> #chair tadeboro
18:51:09 <zodbot> Current chairs: andersson007_ berkhan cidrblock[m] cyberpear cybette dericcrago dmsimard felixfontein jillr samccann tadeboro
18:51:20 <felixfontein> jtanner: indeed :)
18:51:40 <dmsimard> jtanner: that looks like one key off for each letter, happens to me sometimes
18:51:47 <gundalow> felixfontein: not sure if that's a serious question or not.
18:52:11 <gundalow> I'm on my mobile, just finishing dinner, apologies for inability to type
18:52:14 <andersson007_> tadeboro is just in time:)))
18:52:34 <felixfontein> gundalow: it's half serious, half not. we'll need to vote on this, but there's no reason we have to do it in a meeting :)
18:52:37 <samccann> What's not clear to me in the async proposal (tho I've only skimmed it) - how to find out what is actively being discussed vs an issue that is stale etc? With irc/matrix meeting minutes, I can scan them to see what's active. Maybe that's obvious in the new proposal and I've just missed it
18:52:55 <gundalow> samccann: project board,
18:52:59 <dmsimard> gundalow: ^ would samccann's question be answered by the project board ?
18:53:11 <felixfontein> a project board would be a good idea
18:53:27 <samccann> is that what 'fresh' meant on that project board someone shared as an idea a few days ago?
18:53:33 <gundalow> https://github.com/orgs/ansible-community/projects/2/views/1
18:53:34 <tadeboro> samccann: Also, IIRC, the current async proposal sets some deadlines which should help reduce the backlog.
18:53:36 <berkhan> TIL GitHub has spreadsheet :O
18:53:45 <felixfontein> berkhan: me too
18:53:53 <dmsimard> the new project board format is very new to my understanding
18:54:03 <bcoca> not for all :-( , cannot use in my projects
18:54:41 <cyberpear> Fedora FESCo votes mostly in tickets but still has weekly meetings where additional votes are placed. I think they generally allow a week for each voting item that isn't urgent. each gets its own issue in Pagure.
18:54:44 <felixfontein> bcoca: it's a beta feature, no idea what you have to do to get access
18:54:52 <samccann> cool thanks. makes sense. I still feel a meeting time for brainstorming is helpful. Think how fast we are all talking/covering this idea right now, vs how slow it would be if we didn't have this at all
18:54:56 <samccann> (this meeting)
18:55:26 <felixfontein> cyberpear: what do you mean with 'additional votes'?
18:55:42 <berkhan> samccann: i second to that but this meeting will be available in the same day and time
18:55:49 <tadeboro> samccann: This is why I would like to have some slots for discussing things but force people to go comment in the ticket when done. So no voting in meetings.
18:55:52 <cyberpear> if not enough voted in the ticket, they can vote in the meeting or vice versa
18:56:06 <cyberpear> (similar to what we've done here informally)
18:56:23 <dmsimard> I think we want to encourage voting in the issues (thus, async) but that doesn't mean we can't discuss the topics elsewhere
18:56:26 <samccann> so my 2 cents - equal time/decisionmaking for both async and sync.  Final vote is on async, but we can add the sync 'vote count' to async proposal so it's not lost (along with a link to the meeting minutes and log)
18:56:43 <felixfontein> cyberpear: ah ok, thanks!
18:56:45 <cyberpear> samccann++
18:57:23 <felixfontein> tadeboro: disallowing voting in this meeting sounds ok to me. I'm not 100% sure whether I love it, but I like it enough :)
18:57:28 <tadeboro> I do not like the sync and async are equal because it does not seem fair to people whose timezone is bad.
18:57:48 <samccann> we could keep all voting async, discuss during a meeting and if people want to vote DURING the meeting, they go over and 'cast'  their vote on the issue.
18:57:58 <felixfontein> samccann: +1
18:58:03 <dmsimard> samccann: right
18:58:05 <andersson007_> +1
18:58:17 <tadeboro> Just like having meetings where half of the people are in the office while the other hald connects via zoom.
18:58:45 <jillr> I have a hard stop here, but I will follow up in the github issue if there is anything to vote on there  ;)
18:59:04 <samccann> heh jillr the trendsetter
18:59:07 <tadeboro> So I would say tht votes need to be in the ticket with all of the relevant discussions.
18:59:08 <jillr> tadeboro: +1 being a remote / timezone different person in an office/single timezone heavy group sucks
18:59:22 <felixfontein> I think it would be great if we could finalize a proposal until next week or the week thereafter and then vote on it (in the issue) :)
18:59:53 <cybette> felixfontein: +1 :)
19:00:12 <tadeboro> It would be nice if this would be the first async decision we make ;)
19:00:24 <tadeboro> And the timeline seems reasonable.
19:00:28 <felixfontein> maybe we should define the meeting time by random generator (at least a couple of weeks in advance), then everyone should get their favorite meeting time at least once every 24 weeks ;)
19:01:11 <felixfontein> #topic open floor
19:01:29 <felixfontein> before we close, does anyone have something quick for the open floor?
19:01:34 <dmsimard> nothing for open floor for me but wanted to thank apollo13 and berkhan for joining us today :)
19:01:41 <felixfontein> you can always create an issue for the next meeting if you have a topic
19:01:50 <samccann> heh
19:02:02 <berkhan> dmsimard: doing my best to join as many Ansible meetings as possible :)
19:02:19 <felixfontein> berkhan: you've already have been around multiple times IIRC, +1 to that!
19:02:38 <felixfontein> #endmeeting