18:00:09 <felixfontein> #startmeeting Ansible Community Meeting
18:00:09 <zodbot> Meeting started Wed Nov 17 18:00:09 2021 UTC.
18:00:09 <zodbot> This meeting is logged and archived in a public location.
18:00:09 <zodbot> The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:00:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:09 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:10 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/539
18:00:10 <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:00:13 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/539 / Topics: https://github.com/ansible-community/community-topics
18:00:17 <briantist> o/
18:00:22 <tadeboro> o/
18:00:25 <felixfontein> #chair briantist jillr cybette tadeboro
18:00:25 <zodbot> Current chairs: briantist cybette felixfontein jillr tadeboro
18:00:33 <acozine> I felt like we ended that discussion at "lots of people don't care either way" and with inertia we didn't make a change in the UTC time. If those who DO care (folks in later time zones?) want to open the conversation again, it seems only fair.
18:00:43 <cyberpear> o/
18:00:53 <felixfontein> #chair acozine cyberpear
18:00:53 <zodbot> Current chairs: acozine briantist cyberpear cybette felixfontein jillr tadeboro
18:01:38 <felixfontein> I still hope that the person who voted to keep the current meeting time will eventually show up regularly for the meetings :)
18:01:42 <dmsimard> \o
18:02:21 <felixfontein> #chair dmsimard
18:02:21 <zodbot> Current chairs: acozine briantist cyberpear cybette dmsimard felixfontein jillr tadeboro
18:02:27 <felixfontein> #topic Updates
18:02:53 <dmsimard> ansible 5.0.0b2 is available for testing: https://groups.google.com/g/ansible-announce/c/_Z4JE5X-gZg
18:02:54 * dericcrago waves
18:03:06 <dmsimard> er
18:03:09 <dmsimard> #info ansible 5.0.0b2 is available for testing: https://groups.google.com/g/ansible-announce/c/_Z4JE5X-gZg
18:03:11 <felixfontein> #chair dericcrago
18:03:11 <zodbot> Current chairs: acozine briantist cyberpear cybette dericcrago dmsimard felixfontein jillr tadeboro
18:03:53 <cybette> o/
18:03:53 <samccann> o/
18:03:53 <acozine> #chair samccann
18:03:53 <zodbot> Current chairs: acozine briantist cyberpear cybette dericcrago dmsimard felixfontein jillr samccann tadeboro
18:04:12 <acozine> Carol you're already furniture
18:04:36 <felixfontein> I did chair some of the folks who wrote something like a minute before te meeting started :)
18:05:00 <briantist> #furniture-level enhance
18:05:35 <dmsimard> #info We are looking to start our monthly update/news/demo/presentation virtual meetups (think mini contributor summit) on december 14th and then on every second tuesday of each month. It's a great venue to come talk about what you're working on and discuss/share it with the community, reach out to dmsimard if you'd like to participate.
18:05:40 <sivel> #sofa sivel
18:05:43 <cybette> thanks acozine felixfontein :)
18:05:44 * jillr is a small credenza
18:06:04 <felixfontein> #chair sivel
18:06:04 <zodbot> Current chairs: acozine briantist cyberpear cybette dericcrago dmsimard felixfontein jillr samccann sivel tadeboro
18:06:05 <felixfontein> :)
18:06:08 <sivel> lol
18:06:35 <felixfontein> any more updates?
18:06:47 <dmsimard> nothing from me
18:07:15 <felixfontein> ok, then let's start!
18:07:15 <felixfontein> #topic Feature freeze for Ansible 5.0.0 b1/b2/rc1
18:07:30 <dmsimard> I'll take that one
18:07:35 <felixfontein> Background: feature freeze was supposed to start with Ansible 5.0.0b1
18:07:42 <felixfontein> ok, I'll stop typing then :)
18:07:46 <dmsimard> bah
18:08:14 <felixfontein> (then I can continue with eating dinner, instead of just looking at it ;) )
18:09:11 <dmsimard> It was expected that there'd be a feature freeze from 5.0.0b1 onwards meaning that collections would not have dot release updates until 5.1.0 but I.. hrm, forgot about it and so b2 was released with collection updates. If we were to freeze, we would actually roll back some collection verions back to b1
18:09:25 <dmsimard> the collections that would be impacted by a rollback are these ones: https://gist.githubusercontent.com/dmsimard/05017a08d857710255bcc4938b6f8c7c/raw/1438734af0b8437e760d4d180fea21e03c0ff9ab/gistfile1.txt
18:09:57 <dmsimard> I've looked at the actual updates and I didn't find anything critical and so I would suggest that we move forward and freeze from now on instead of reverting back to what should have been the right versions
18:10:11 <dmsimard> and then get it right the next time for ansible 6
18:10:12 <felixfontein> +1 to not reverting, but freezing from now on
18:11:12 <jillr> +1 move forward and freeze in the future
18:11:46 <felixfontein> (actually jillr and me are a bit biased since we maintain some of the accidentally included collections ;) )
18:12:08 <acozine> heh
18:12:09 <jillr> :) true, I would love to have those 2.1s in there
18:12:11 <dmsimard> biased in the right sense as you have knowledge of whether or not it is problematic so I don't see that as an issue
18:12:13 <tadeboro> Those version bumps would still happen in 5.1.0, right?
18:12:25 <jillr> for AWS they're not porblematic
18:12:26 <felixfontein> tadeboro: exactly
18:12:29 <jillr> *problematic
18:12:37 <dmsimard> tadeboro: right
18:12:50 <briantist> +1 to roll forward
18:13:20 <cybette> +1 move forward
18:13:20 <tadeboro> What is the point of locking them during the beta phase?
18:13:26 <acozine> +1 to rolling forward
18:13:39 <samccann> +1
18:13:40 <dmsimard> tadeboro: testing a single non-moving set of things together
18:13:51 <dmsimard> as we approach release candidate
18:14:11 <tadeboro> Do minor versions also have betas/rcs?
18:14:23 <dmsimard> not currently, no
18:14:25 <felixfontein> tadeboro: no, only the x.0.0 version
18:15:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:15:06 <tadeboro> Am obviously OK with rolling forward. I am wondering what is the reason for locking minor versions before a major release.
18:15:24 <dmsimard> that's not to say we can't change things and they can't be improved, the process was written before my arrival so I am working within the boundaries of what has already been written without putting everything into question (yet)
18:15:30 <tadeboro> But this discussion can wait since it is not strictly related to current issue.
18:16:19 <felixfontein> tadeboro: I *think* this is mainly useful for collections which don't really test well against the latest stable branch; for all other collections it shouldn't really make a big difference
18:16:21 <tadeboro> Do we need to vote on this one? If yes, I think we can do it now ;)
18:16:57 <dmsimard> I suppose people have already voted but we can call for a formal one if we feel it's necessary
18:17:02 <felixfontein> since noone said they don't like it, or asked for a vote, I think we can skip it
18:17:11 <dmsimard> yeah, no strong objections, let's go with that I think
18:17:16 <felixfontein> +1
18:17:20 <tadeboro> +1 on skipping the vote and moving on.
18:17:31 * felixfontein also finished his main course in time for the next topic ;)
18:17:38 <felixfontein> #topic Responsive documentation tables (plugin/module/role parameters and return values/facts)
18:17:41 <felixfontein> #info Implementation: https://github.com/ansible-community/antsibull/pull/335
18:17:46 <felixfontein> This is mostly an announcement / request for comments
18:18:19 <samccann> with a preference that you add comments to the PR itself so we can scan them all at once
18:18:37 <felixfontein> I've started a rewrite of the parameter and return values/facts tables in the generated docs on docs.ansible.com, so that they a) use less columns (which avoids horizontal scrolling in many situations), and b) has a responsive fallback to a more flat representation for narrow screen widths
18:19:15 <felixfontein> the PR has some links to examples before/after the PR
18:19:19 <dmsimard> I just wanna say that I've seen quite a bit of feedback on irc, the mailing lists and even reddit .. it's great to have people chime in, please keep it up :)
18:19:28 <felixfontein> (see the first three comments in it)
18:20:21 <felixfontein> and yet another docs topic:
18:20:23 <felixfontein> #topic Include semantic markup in plugin DOCUMENTATION strings
18:20:23 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/53
18:20:41 <felixfontein> This is something that started a looong time ago in the docs working group
18:21:17 <felixfontein> we want to raise more awareness, since this affects all docs consumers - that is ansible-doc text output, antsibull, ansible-navigator, galaxy-ng, the network team's docs renderer, and tadeboro's docs renderer
18:22:02 <bcoca> ansible-doc basically removes em (i have pr for nice formatting) for display, but keeps them when using --json/dump options for other tools
18:22:20 <felixfontein> the main goal is to have more semantic markup - O(option_name) instead of I(option_name), where O stands for option, while I is a specific formatting (italics)
18:22:55 <felixfontein> this will hopefully make formatting more uniform (right now especially C and I are sometimes confused, some people do it intentionally the other way around because they prefer it, ...)
18:23:19 <felixfontein> most of the other tools use `ansible-doc --json` as input, so they are all affected by this
18:23:31 <felixfontein> we have PRs for ansible-doc and antsibull
18:23:33 <samccann> it also allows us all to display in the best way for each of our tools. docs can do it one way, bcoca can do what he wants :-) Galaxy-ng/ansible-navigator etc
18:23:51 <felixfontein> (though the links in the antsibull PR currently do not work, since I've got the responsive PR's output on my docsite)
18:24:00 <bcoca> https://github.com/ansible/ansible/pull/75116 <= exmaple
18:24:01 <github-linkbot> https://github.com/ansible/ansible/pull/75116 | open, created 2021-06-25T17:48:31Z by bcoca: prettyfy ansible-doc [needs_revision,needs_rebase,module,ci_verified,stale_ci,support:community,support:core,feature,has_issue,affects_2.12] 
18:24:44 <felixfontein> and all tools can do it in a consistent way, assuming that collection authors use the new markup, instead of that the collection authors basically decide which formatting to use
18:25:19 <felixfontein> bcoca: I really like that PR (and it's not the first time I've seen it) :)
18:27:53 <felixfontein> any opinions on semantic markup?
18:28:47 <samccann> the open question for me is would we try to convert all plugins to use these, or just use them going forward and let collection owners decide if they want to go back and adjust existing I() etc
18:29:08 <felixfontein> I'm fine with using them going forward
18:29:21 <felixfontein> for the collections I'm maintaining, I'll probably convert a lot of them myself
18:29:36 <felixfontein> for c.g it will be more of a group effort though, since it's a huge collection :)
18:29:42 <tadeboro> I know a few maintainers will step up and do the conversion even if we do not ask them once things are ready.
18:30:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:30:04 <acozine> absolutely
18:30:35 <acozine> also, if we document "how to change this" well enough that the changes are easy, community members will submit PRs for this
18:31:54 <acozine> if we ever get to high levels of adoption, we might even add some kind of linting or testing for semantic markup use
18:32:59 <samccann> that's an interesting thought
18:33:39 <felixfontein> checking the syntax of P() and O() can be easily done, similar to the M() syntax checks that validate-modules currently has
18:34:20 <felixfontein> (checking whether the content in O() is valid is more complicated, since it can potentially refer to an option name of another module/plugin; it depends on the sentence around it...)
18:35:12 <bcoca> then have a O(name:option=value)
18:35:19 <bcoca> to signify external one
18:36:14 <felixfontein> bcoca: I guess more likely O(fqcn#type:option=value)?
18:36:37 <felixfontein> I guess we also need to define a syntax for referencing suboptions then, if we really want to validate the result
18:37:05 <samccann> should we balance validation vs how complicated we might be making this?
18:37:08 <felixfontein> I personally would use O(foo.bar=baz) for suboption `bar` of `foo`
18:37:15 <samccann> especially if we aren't mandating it...
18:37:37 <felixfontein> samccann: I'm fine with not making this complicated, but then we can't really validate, and we also cannot create automatic links
18:38:05 <samccann> ah automatic links might be worth the complexity
18:38:38 <bcoca> O(cisco.ios.stuff_that_is_long#module.top.sub.options={key:valluedict))
18:38:44 <acozine> sorry, I threw a red herring in - I don't think testing is realistic for several months or maybe years after we start implementing semantic markup, assuming we do
18:38:47 <samccann> easy for me to say of course since I'm not doing it
18:38:51 <acozine> testing can be a future discussion
18:38:55 <felixfontein> for automatic links, we would need the name of the plugin, the plugin type, and the full option name path
18:39:28 <felixfontein> if we don't plan for testing and linking at the beginning, it will likely never work
18:39:53 <samccann> well M() still has links.  so maybe O() with links is a bit further than we need?
18:40:16 <felixfontein> O() with links would make the docs easier to use in quite a few cases
18:40:31 <samccann> I like the idea of a collection owner being ABLE to validate if they so choose.
18:40:53 <felixfontein> like when the docs for `zzzz` says "Ignored if O(foo=bar)". if you have to scroll up 20 pages to get to `foo` it's nice if you can simply click on `foo` and get directly to `foo`'s docs
18:41:09 <acozine> yes, that would be nice
18:41:16 <felixfontein> if we want to link, we cannot make this optional
18:41:27 <samccann> maybe next step is to write up the markup that would be needed to both enable future testing and creating links
18:41:38 <felixfontein> and we have to validate right from the beginning, to avoid docs full of broken links
18:41:40 <samccann> and we can get feedback from some collection owners to see what they think?
18:42:07 <felixfontein> sounds good to me
18:42:23 <felixfontein> I can write something for it
18:42:26 <felixfontein> where should I do that?
18:42:54 <samccann> maybe add it as a comment to the proposal issue?
18:43:21 <felixfontein> do you mean https://github.com/ansible/ansible/issues/75054 ?
18:43:57 <samccann> i was thinking this one -https://github.com/ansible-community/community-topics/issues/53
18:44:10 <samccann> since that's the one I've been spamming people with of late ;-)
18:44:16 <felixfontein> ok. it's yet another PR/issue for this topic :)
18:44:22 <felixfontein> sounds good to me
18:44:34 <felixfontein> ok, a final topic for today (before open floor):
18:44:37 <felixfontein> #topic Repository instead of Changes impacting collection contributors & maintainers Issue
18:44:40 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/51
18:44:52 <samccann> yeah it's sort of the high level proposal. I'm hoping to get people to agree to that from the other tools teams (galaxy-ng etc)
18:45:02 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:46:15 <felixfontein> so basically we have three suggestions: 1) use issues in a new repo, 2) use files in a new repo, and use PRs as 'updates', 3) use discussions in a new repo
18:46:24 <felixfontein> (if I read this correctly)
18:46:57 <jillr> I actually think mu ideal would be an rss feed
18:47:03 <bcoca> imho its more like 'wiki page' or doc page ... closer to porting guide
18:47:09 <bcoca> or 'developer porting guide'
18:47:24 <felixfontein> that's true for some entries, but some others spawn into discussions, or people ask questions
18:47:36 <jillr> I dont love the idea of a repo I need to track issues in, because I'm thinking about the mail rules and inbox maintenance I'd end up with for yet another repo
18:47:41 <felixfontein> having some place where to do that without spamming everyone (or allowing others to ignore this particular discussion) would be helpful
18:47:59 <samccann> looking at that discussion, I'm like one of the commentors - I see changes because I'm subscribed to the current issue and it just shows up in my inbox.
18:48:30 <sivel> All you have to do is become a watcher of a repo, and you get the same benefit
18:48:34 <felixfontein> samccann: same here. all three proposals would also have that, if you subscribe to the repo
18:48:39 <jillr> samccann: same, with a mail rule that handles that issue specially
18:48:39 <sivel> of the repo is limited to that, it shouldn't be much extra noise
18:48:59 <sivel> I do agree that the current issue is terrible
18:49:02 <felixfontein> jillr: how much extra work is a repo vs. an issue?
18:49:05 <samccann> ok that's good
18:49:18 <felixfontein> jillr: because if we regularly rotate the issue, you'll have to change your mail config every time
18:49:20 <jillr> felixfontein: how much are those issues going to turn into discussion topics instead of announcements?
18:49:31 <felixfontein> jillr: I hope that most of them will not
18:49:33 <acozine> I agree that using issues in a repo could make it hard for a maintainer to find "new changes that might affect me since the last time I looked"
18:49:46 <felixfontein> but if some do and you don't care, you can go into the issue and click 'unsubscribe' :)
18:49:48 <samccann> my other question - how important is this info? Even in a repo a lot of it gets lost. How much of this really aught to be included in the docs somewhere on docs.ansible.com?
18:49:57 <sivel> Everytime I'm like how many # signs do I need for the proper header size :) and find myself scrolling forever to find an example.  And can never find the comment I need to edit if that is needed
18:50:15 <jillr> I actually don't hate the current format and find the info valuable
18:50:33 <sivel> yeah, the content is valuable, managing that issue and finding older info is impossible
18:50:37 <felixfontein> sivel: mostly likely because most comments are hidden, and it's a PITA to get the last few to show up without having to click 1000 times on 'show more'...
18:50:47 <sivel> felixfontein: exactly
18:51:10 <felixfontein> if GH would have a button that you can show more comments in the other direction, I wouldn't mind the current issue that much :)
18:51:20 <felixfontein> (except that searching is basically impossible)
18:51:55 <felixfontein> tadeboro: about your point, I think that most issues can simply be closed after a fixed amount of time
18:52:03 <sivel> I think it was mentioned, but right now we frown on people commenting to discuss things there too. So individual issues in a repo would make that possible
18:52:14 <samccann> wacky thought  could we do 'something' in a repo such that specifically tagged information could be pulled together as a weekly 'changelog' kind of thing
18:52:16 <felixfontein> with some useful labels and the search function it shoul be easy to find older ones of interest
18:52:16 <cyberpear> files in a repo seems best to me. easiest to find the final agreed state. discussion could be in PR or Issues
18:52:24 <sivel> also people always reference that single issue in PRs which cause it to close repeatedly
18:52:56 <felixfontein> cyberpear: usually the discussions are more like asking questions on details; it's not about determining what should actually happen
18:52:58 <sivel> cyberpear: we did try that with the proposals site, and it never quite worked out.  We used lables on issues instead
18:53:21 <jillr> are these updates meant to be announcements or proposals/discussions?  I've always viewed them as static announcements
18:53:33 <felixfontein> jillr: they are usually announcements
18:53:36 <sivel> announcements, but people often have questions, or want clarification
18:53:49 <felixfontein> jillr: but sometimes people ask questions, or want to add clarifications
18:53:51 <sivel> :)
18:53:57 <felixfontein> what sivel said ;)
18:54:07 <jillr> sivel that feels like something that folks should make topics for the appropriate community meetings then
18:54:27 <felixfontein> jillr: most things are not related to any meeting
18:54:49 <samccann> asynch ftw!
18:54:50 <sivel> at least from the core team, there aren't many who attend this meeting either.  So it's easier for async too
18:54:55 <felixfontein> and while people should do that, they usually don't :)
18:55:16 <jillr> I guess maybe I dont understand what the questions are, and that's ok
18:55:23 <felixfontein> when there is one issue / discussion / PR per topic, the pain that causes mostly goes away
18:55:24 <sivel> Could also use discussions ;)
18:55:37 <felixfontein> sivel: that's what zbr suggested
18:55:46 <felixfontein> instead of issues
18:56:08 <jillr> I seem to be the only person who wants a RO feed of announcements, so I will deal with whatever folks prefer then
18:56:23 <sivel> just need a proper category too.  But that doesn't solve the "I like one issue because of subscribing"
18:56:40 <felixfontein> jillr: right now you don't have that either, but right now you don't even have a way to tune out a discussion once it shows up :)
18:56:59 <samccann> jillr - I'm thinking some of the info needs to be saved as well. What happens if the developer doesn't pay attention for a month - where do they find out what they missed w/o scanning the repo?
18:57:02 <cybette> I usually try to check #45 for stuff to include in the bullhorn, and I'm fine with either the one issue or having a repo
18:57:16 <sivel> I think largely it will be just a feed of announcements, just easier for the people who report them to more easily manage the announcements
18:57:17 <jillr> felixfontein: right now the volume of info is good and useful.  tbh I will probably not consume an issue queue at all, but that's my own choice
18:57:48 <felixfontein> jillr: the expected volume for the issue queue is the same as comments for the current issue
18:57:48 <sivel> jillr: I don't really expect it to change in terms of volume
18:58:11 <jillr> sivel: I'm assuming that conversations will tick upward on issues
18:58:38 <jillr> since the GH convention is that issues can and should be used for conversations
18:58:42 <felixfontein> ok, time's almost up, let's do a quick open floor
18:58:49 <sivel> I feel like my brain and felixfonteins brain have some quantum entanglement going on
18:58:54 <felixfontein> please add your opinions to https://github.com/ansible-community/community-topics/issues/51
18:59:21 <felixfontein> sivel: I hope that doesn't extends to passwords and stuff like that ;)
18:59:25 <sivel> lol
18:59:28 <felixfontein> #topic open floor
18:59:55 <felixfontein> as always, please comment on issues in https://github.com/ansible-community/community-topics/issues, so we can have more asynchronicity :)
19:02:15 <dmsimard> asynchronicity++
19:03:02 <felixfontein> ok, if nobody has a topic for open floor, let's close the meeting
19:03:08 <felixfontein> and get back to work / more meetings ;)
19:03:13 <felixfontein> #endmeeting