14:32:28 <acozine> #startmeeting Docs Working Group aka DaWGs
14:32:28 <zodbot> Meeting started Tue Jul 21 14:32:28 2020 UTC.
14:32:28 <zodbot> This meeting is logged and archived in a public location.
14:32:28 <zodbot> The chair is acozine. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:32:28 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:32:28 <zodbot> The meeting name has been set to 'docs_working_group_aka_dawgs'
14:32:34 <acozine> #topic opening chatter
14:32:41 <acozine> who's around?
14:32:47 <samccann> Me
14:32:50 <baptistemm> Me
14:32:53 <acozine> #chair baptistemm felixfontein samccann
14:32:53 <zodbot> Current chairs: acozine baptistemm felixfontein samccann
14:33:10 <felixfontein> acozine: baptistemm: https://github.com/ansible/ansible/pull/70529/files#diff-2eeaed663bd0d25b7e608891384b7298R80 gives instructions when it detects installing it wrongly
14:33:29 <acozine> today's official agenda: https://github.com/ansible/community/issues/521#issuecomment-658334278
14:33:33 <baptistemm> felixfontein knows everything
14:33:45 <felixfontein> no, I just tracked the links on github :)
14:33:58 <felixfontein> your PR mentions an issue, and in that issue sivel linked that PR
14:34:01 <acozine> heh
14:34:06 <acozine> it looks like that PR was merged
14:34:43 <acozine> so maybe add `Cannot install ansible-base with a pre-existing ansible installation.` to the text of your PR baptistemm ?
14:35:02 <samccann> #topic how to install ansible
14:35:20 <bcoca> hire bcoca.. done
14:35:43 <acozine> #chair bcoca
14:35:43 <zodbot> Current chairs: acozine baptistemm bcoca felixfontein samccann
14:35:45 <felixfontein> it doesn't matter if you install ansible or ansible-base after removing ansible, both should work (and both install ansible-base)
14:36:07 <bcoca> use acd or it gets confusing which ansible you ansibalize about
14:36:33 <bcoca> or specify the 'ansbile 2.10 pip package'
14:36:38 <acozine> bcoca: if it's pip, then it will be `ansible` for ACD, right?
14:36:42 <samccann> #info there are details in the code https://github.com/ansible/ansible/pull/70529/files#diff-2eeaed663bd0d25b7e608891384b7298R80
14:36:52 <bcoca> acozine: but version matters here, cause 2.9 is not the same
14:37:15 <felixfontein> ACD == ansible according to marketing IIRC ;)
14:37:17 <acozine> I think the PR is specific enough: https://github.com/ansible/ansible/pull/70768/files
14:37:18 <bcoca> we have to be very clear to users, since this is confusing to begin with
14:37:48 <bcoca> felixfontein: no, marketing uses 'ansible' or 'automation platform' .. acd was internal name, dont think it will be anything else
14:38:10 <bcoca> but for discussion it seems easier to use that (or other, im open) to distinguish ansible <=2.9  vs >=2.10
14:38:10 <felixfontein> we could of course add another paragraph mentioning that after removing ansible, you can also install ansible-base, and install the needed collections manually (and mention that this is not called ansible anymore)
14:38:49 <samccann> Dunno if we want to document that option
14:39:18 <samccann> I thought we expected vast majority to just use ansible
14:39:28 <bcoca> https://github.com/bcoca/acd <= you can generate and install this
14:39:45 <samccann> Or we document it in the developer guide only
14:39:57 <bcoca> samccann: not everyone has access to pip, so we'll have to provide alternatives
14:41:12 <samccann> So there is no way to install ansible w/o pip?
14:41:16 <acozine> bcoca: I think we will need to revise and probably expand the Installation guide, more than just this PR . . . but I also think this PR is a good start. Iterative improvement.
14:41:26 <bcoca> no doubt
14:41:31 <baptistemm> samccann: you can use native disoro packaging
14:41:35 <baptistemm> dsitro
14:41:39 <baptistemm> damn
14:41:48 <bcoca> OS package manager
14:41:52 <acozine> heh, I like `disoro`
14:41:52 <bcoca> ;-p
14:42:11 <felixfontein> you could also use easy_install I guess
14:42:14 <acozine> sounds like a tasty beverage
14:42:25 <bcoca> baptistemm: that works for some, still there will be those w/o access to such things *cough* OS X *cough*
14:42:31 <felixfontein> or manually download the .tar.gz and extract it to the correct location, and things like that
14:42:47 <samccann> I think there is an install page that goes through all the sisters
14:43:04 <samccann> Distros
14:43:08 <samccann> Yeesh
14:43:09 <acozine> heh
14:43:09 <zbr|rover> acozine: i made a request to enable "release-drafter" github app on ansible-lint repo, org admin should have received the email by now.
14:43:55 <acozine> #chair zbr|rover
14:43:55 <zodbot> Current chairs: acozine baptistemm bcoca felixfontein samccann zbr|rover
14:43:56 <zbr|rover> same up is used by many repos under ansible-community org, but for ansible it needs to be enabled per repo.
14:44:17 <acozine> zbr|rover: sounds good
14:44:27 <acozine> he, we have a full agenda as usual
14:44:53 <acozine> baptistemm: your PR is a good improvement, if you can put part of the error text in it, I'll merge it today
14:45:16 <baptistemm> acozine: ok, I'm finishing my day work and will do that
14:45:27 <acozine> #topic docs pipeline refinements
14:45:47 <acozine> first part of this topic is about the effects of umask settings on the new pipeline
14:46:03 <acozine> samccann: you want to add a quick update on that?
14:46:38 <samccann> Sure
14:47:27 <samccann> #info reinstall the docs requirements.txt to pick up antsibull-doc
14:47:56 <felixfontein> or manually do `pip install --upgrade antsibull` :)
14:48:07 <samccann> #info check umask to be sure it is 022 by default
14:48:39 <samccann> Or really the rst directory has to be 022
14:49:01 <acozine> so the default umask on RHEL is 002, and that breaks the pipeline, right?
14:49:12 <samccann> And there are a bunch of build warnings we will want to clean up
14:49:24 <samccann> Fedora default is 002
14:49:33 <acozine> ah, sorry, fedora not RHEL
14:49:35 <samccann> And yes it breaks
14:50:12 <acozine> felixfontein: baptistemm zbr|rover bcoca have any of you tried building the collections docs locally?
14:50:15 <felixfontein> how does it break the pipeline? (out of curiosity, and just in case you know)
14:50:17 <samccann> And tells you that dir has to be writable only by you or something
14:50:35 <zbr|rover> acozine: yes i did, not very happy
14:50:36 <felixfontein> acozine: I did, to some degree
14:50:50 <baptistemm> acozine: nope
14:50:59 <bcoca> acozine: yes , but didnt get far
14:51:04 <samccann> To the educated masses the error is likely clear. I needed abadgers help
14:51:18 <zbr|rover> 1st issue: the current stable (2.9) does not even have ability to ignore files when building, is present only on 2.10
14:51:48 <zbr|rover> second issue is that it does not verify what it builds and only way to findout is to upload, which cannot be undone
14:51:53 <felixfontein> zbr|rover: are you talking about building collections with `ansible-galaxy collection`, or are you talking about building collections *docs* with `antsibull-docs`?
14:52:21 <zbr|rover> to discover that your foo-bar role is rejected due to bad name, you much try to upload.
14:52:25 <zbr|rover> must
14:52:41 <zbr|rover> building collections in general
14:53:01 <acozine> zbr|rover: ah, that's good feedback, though not specific to docs
14:54:05 <acozine> we just merged the new docs pipeline for the collections ecosystem
14:54:43 <felixfontein> acozine: is the result already uploaded somewhere?
14:54:54 <felixfontein> like at docs.testing.ansible.com?
14:55:04 <acozine> for the build-my-collection utilities, I don't know how much will be backported to 2.9
14:55:05 <samccann> I can try 2.10 later today as a local build
14:55:16 <acozine> felixfontein: yes, I published 2.10 last night
14:55:19 <acozine> to test
14:55:48 <acozine> http://docs.testing.ansible.com/ansible/2.10/collections/index.html
14:56:05 <felixfontein> cool, thanks!
14:56:14 <acozine> also devel, though those pages only include the ansible.builtin collection
14:56:27 <acozine> http://docs.testing.ansible.com/ansible/devel/collections/index.html
14:56:44 <felixfontein> btw, is there a reason docs.testing.ansible.com has no https?
14:56:51 <acozine> I'm really happy that the pipeline has been merged to both 2.11/devel and to 2.10
14:57:08 <felixfontein> yep!
14:57:49 <acozine> felixfontein: I think it's a combination of lack of resources on our web team and general inertia
14:58:12 <acozine> it might be a good thing, actually
14:58:36 <acozine> because it may help prevent people from hitting the test docs by mistake
14:59:01 <acozine> it is annoying, though
14:59:26 <felixfontein> the best way to prevent people hitting the test docs is adding a simple HTTP auth, like user `ansible`, password `testing`
14:59:40 <acozine> oh, that would be good
14:59:56 <acozine> I will ask the web team if they can do that
15:00:00 <baptistemm> updating robots.txt also
15:00:22 <baptistemm> if there is one
15:00:28 <acozine> baptistemm: we did update robots.txt for testing
15:00:41 <acozine> after we had a few google results leading there . . .
15:01:10 <acozine> so I hope we're not seeing a lot of traffic from search engines to the testing site
15:01:42 <baptistemm> there is no robots.txt on https://docs.ansible.com/ btw
15:02:59 <acozine> baptistemm: ah, interesting - we do want search engines to index that site . . . I don't know how to use robots.txt other than "don't index this"
15:04:21 <acozine> baptistemm: if you have suggestions, please pass them along
15:04:24 <baptistemm> sure
15:04:49 <acozine> meanwhile, please test out the new docs pipeline
15:05:28 <acozine> on the `devel` branch and on `stable-2.10` it should build collections docs locally - install the `requirements.txt`, check your umask settings, then run `make webdocs`
15:05:39 <samccann> #info please test out the docs pipeline on http://docs.testing.ansible.com/ansible/devel/collections/index.html
15:06:07 <acozine> we already have some refinements in mind (like passing a list of collections to build / not build)
15:06:13 <samccann> #info and build locally with the aforementioned steps
15:06:21 <acozine> feedback and ideas welcome!
15:06:45 <baptistemm> samccann: acozine: it there a doc /proc to build the collections doc ?
15:07:05 * baptistemm was in meeting
15:07:21 <acozine> baptistemm: what do you mean by /proc?
15:07:38 <samccann> What acozine said above
15:07:44 <baptistemm> sorry proc was procedure (/me is production guy)
15:07:53 <acozine> procedure in the documentation itself, describing how to build the collections docs?
15:07:56 <acozine> heh
15:07:58 <samccann> It’s part of make webdocs now
15:08:05 <baptistemm> ok
15:08:39 <acozine> just plain `make webdocs` builds the full `ansible` PyPI package docs, collections included, on `stable-2.10`
15:09:01 <acozine> and `make webdocs` builds the rST files plus `ansible.builtin` on `devel`
15:09:34 <acozine> we definitely need to update the how-to-build-docs documentation soon
15:09:38 <acozine> but we haven't done it yet
15:10:21 <acozine> I think I'll feel more comfortable when a few more folks have tried it out, on different systems and so on
15:11:36 <acozine> we ran into an issue on macOS
15:11:43 * acozine digs back to find the details
15:12:50 <acozine> ah, it was `ulimit`
15:13:19 <acozine> #info on macOS you may need to set `ulimit -n 1024` before running the collections docs build
15:13:54 <acozine> #info on Fedora you may need to set the `umask` to 022 before running the collections docs build
15:14:14 <acozine> woops, 15 minutes left
15:14:28 <acozine> #topic changelogs in collections
15:14:36 <acozine> https://github.com/ansible/community/issues/521#issuecomment-657219778
15:14:48 <acozine> felixfontein: you want to start the conversation?
15:15:14 <felixfontein> sure
15:15:49 <felixfontein> so, now that we have ansible-base, and separately of that, ansible, we need to discuss how the porting guides of these two relate to each other :)
15:16:06 <felixfontein> that the porting guide of ansible-base should be a subset of the one of ansible is clear I think
15:16:20 <felixfontein> but that's it, pretty much
15:16:48 <acozine> current porting guides section: https://docs.ansible.com/ansible/latest/porting_guides/porting_guides.html
15:16:48 <felixfontein> right now, the porting guide for ansible <= 2.9, and ansible-base 2.10, is at https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/porting_guides/porting_guide_2.XXX.rst
15:18:05 <felixfontein> so I have two questions: 1) where should the ansible-base porting guide be stored (and under which name), and 2) where the ansible porting guide?
15:18:16 <acozine> good questions
15:18:28 <acozine> we could have one (very, very long) page for both
15:18:31 <baptistemm> talking about porting guide, it was not clear to me who are the target ? because there is a mix for end-user and ansible module developers
15:18:33 <felixfontein> sooner or later (when ansible-base and ansible versions diverge) this becomes a much bigger problem, but for 2.10 this is probably the main question :)
15:19:04 <acozine> it probably makes more sense to separate the ansible-base entries from the collections entries
15:19:16 <felixfontein> how about having both a `Ansible-base 2.10 porting guide` and a `Ansible 2.10 porting guide` in the list on https://docs.ansible.com/ansible/latest/porting_guides/porting_guides.html ?
15:19:29 <felixfontein> the collection entries should have been moved to the collections anyway
15:19:30 <acozine> baptistemm: I think the collections porting guide is aimed at users more than developers
15:20:15 <felixfontein> acozine: baptistemm: it is, though also users could have small plugins/modules locally that need updating, so there is no clear distinction
15:20:33 <acozine> felixfontein: that's a good idea, it gives us the flexibility to move the actual content in future and just leave a link on the Porting Guides index page
15:21:12 <samccann> do we repeat the `ansible-base` porting guide content in the `ansible` porting guide?
15:21:47 <felixfontein> samccann: I think that would be good, so that ansible users don't have to look at two porting guides
15:21:58 <samccann> +1
15:22:20 <samccann> and because `ansible-base` should be an 'unknown' to most ansible users
15:22:32 <samccann> is it time... for... a... POLL!!!???
15:22:37 <acozine> so the `ansible` porting guide would focus narrowly on the PyPI package
15:23:02 <samccann> except it would also include the ansible-base porting guide content
15:23:05 <felixfontein> here's an example of how the combined porting guide could look like: https://gist.github.com/felixfontein/7d5efcc70c8a25c218d9e8082f5ee92f#file-porting_guide_2-10-rst currently it simply adds stuff after the ansible(-base) porting guide from the changelogs of the collections
15:23:40 <acozine> samccann: well, the `ansible` PyPI package includes a specific version of `ansible-base` within it, right?
15:24:10 <felixfontein> it refers to a minimum version of ansible-base
15:24:17 <felixfontein> users can have a newer version installed
15:24:39 <felixfontein> (for the latest ansible package, there should be no newer, or at most one if it was released before the next ansible package was released)
15:24:51 <samccann> yeah I guess my point is - if there are porting guide entries specific to say developers  in the `ansible-base` porting guide content, that will show up in the `ansible` porting guide as well.
15:25:05 <samccann> blurring that user vs developer target audience (still)
15:25:21 <acozine> felixfontein: ah, so the `ansible` PyPI package is ONLY the collections? or it includes a minimum `ansible-base` which users can upgrade with `pip install ansible-base=my.ver`?
15:25:45 <samccann> maybe we can fix that 'down the road' by having developer-specific note/sections that we can remove from the `ansible` porting guide
15:25:55 <felixfontein> acozine: the ansible pypi package has a dependency on `ansible-base >= 2.10.xxx`
15:26:08 <acozine> ah, okay, thanks felixfontein
15:26:24 <samccann> so as a user, if I install ansible, it's going to go grab ansible-base for me as well, right?
15:26:28 <felixfontein> samccann: should it really be removed? I mean, people can also use the ansible package to develop collections/plugins/modules
15:26:35 <felixfontein> samccann: yes
15:26:56 <samccann> felixfontein: down the road we need a clearer distinction between developer and end-user
15:26:59 <felixfontein> samccann: but say if in a year, you have ansible-base 2.11.0 installed, and you install ansible==2.10.0, you will keep ansible-base==2.11.0
15:27:02 <samccann> not where we are at today for sure.
15:27:22 <samccann> felixfontein - you just hurt my brain!  :-P
15:27:23 <felixfontein> true :)
15:27:43 <samccann> me no likey that install ansible==2.10 would not bring me back to 2.10
15:28:03 <samccann> but I think we are straying offtopic.
15:28:20 <felixfontein> samccann: that's a topic for the #ansible-community meeting, and for abadger1999 :)
15:28:22 <samccann> we have 2 minutes... can we agree on something for the porting guide(s)?  the location?
15:28:50 <samccann> and/or if the ansible porting guide contains the ansible-base porting guide content?
15:28:56 * abadger1999 woke up late... tries to catch up
15:29:16 <felixfontein> how should the ansible-base porting guide be called? and do you want the base subset of the porting guide as its own section in the porting guide, or should it be as in my mockup?
15:29:33 <felixfontein> porting_guide_base_2.10.rst?
15:29:34 <samccann> so many questions
15:30:01 <samccann> POLL - should we call the ansible-base porting guide... the ansible-base porting guide?
15:30:09 <acozine> for 2.10, I'd vote for: a) put the collections porting guide as a separate page linked from https://docs.ansible.com/ansible/2.10/porting_guides/porting_guides.html, b) call the two pages `ansible-base 2.10 porting guide` and `ansible collections 2.10 porting guide`
15:30:14 <felixfontein> so porting_guide_base_2.10.rst would be manually created, and porting_guide_2.10.rst would be automatically generated by antsibull, and it would use porting_guide_2.10.rst, the collection changelogs, and maybe some hardcoded info
15:30:40 <samccann> there is no ansible collections porting guide.
15:30:42 <samccann> it's ansible
15:30:58 <felixfontein> it could be "ansible 2.10 collections porting guide" :)
15:31:03 <samccann> disagree
15:31:16 <samccann> we are creating a new 'thing' by calling it ansible collections
15:31:18 <samccann> it's ansible
15:31:28 <samccann> it's already confusing enough to have ansible and ansible-base
15:32:04 <felixfontein> <nod>
15:32:15 <acozine> yeah, we need to agree on a consistent naming scheme . . . and that's not just for docs
15:32:58 <samccann> wasn't that already decided?
15:33:02 * abadger1999 is getting rid of internal references to acd in the antsibull tool this week.
15:33:54 <acozine> samccann: you're suggesting a) put two pages on the porting guides index and b) call the two pages `ansible-base 2.10 porting guide` and `ansible 2.10 porting guide` and c) include all base and collections info in the second page
15:34:07 <acozine> is ^^^ accurate samccann ?
15:34:54 <samccann> yes
15:35:10 <samccann> tho I'm fine w/ voting on each individual piece but that's the direction I was suggesting, yes
15:35:25 <acozine> felixfontein: can we print a dry run of samccann's idea to the testing site?
15:35:27 <felixfontein> I'm fine with that
15:35:44 <felixfontein> acozine: I think so, I can create a PR for that
15:35:49 <acozine> s/print/publish/g
15:35:56 <samccann> and as a final piece, I'm happy w the sections felixfontein has today
15:35:57 <felixfontein> btw, what about the collection things mentioned in the current ansible-base porting guide?
15:36:07 * baptistemm cannot vote on something he's not sure he can contribute
15:36:12 <felixfontein> I don't like that they are in the ansible-base porting guide, they don't belong there
15:36:18 <samccann> yeah saw that stuff.
15:36:31 <felixfontein> but if the collections do not put that info in their changelogs, we'd have to put it in manually
15:36:37 <felixfontein> so how about having a
15:36:41 <samccann> yep
15:36:48 <felixfontein> "manual" section that's specific for the ansible porting guide?
15:37:02 <samccann> I think in general we have to allow for a manual section, yep
15:37:20 <felixfontein> I'd move these entries into antsibull's porting guide creation, so that they are no longer in the ansible/ansible repo
15:37:26 <samccann> the question becomes then - how does it fit into the overall sections
15:37:42 <felixfontein> that's a good question :)
15:37:54 <samccann> or do we create a 'general notes' section that is the manual notes area?
15:38:20 <samccann> maybe at the end. and collection maintainers can 'do what they want' in that area?
15:38:34 <samccann> and for 2.10, we dump the section from the base porting guide there?
15:38:35 <felixfontein> I would avoid that :)
15:38:51 <felixfontein> (that collection maintainers can do "what they want")
15:38:58 <acozine> putting the manual section at the end is an incentive for collection maintainers to use the changelog system
15:39:02 <felixfontein> they should use the changelog
15:39:13 <samccann> yep. that's why I wanted just a dumping ground at the end
15:39:20 <acozine> "use the changelog or we bury your info at the very bottom . . . you have been warned"
15:39:25 <samccann> eggzactly
15:39:43 <samccann> we can put guidelines up on how to use that section and that it's a
15:39:46 <samccann> last resort
15:40:07 <felixfontein> that section is manually managed by us, so we should prevent any unnecessary edits
15:40:16 <samccann> and even come up with a template for how to add their stuff there... like put it under a collection title, etc etc
15:40:43 <samccann> if we control that section via PRs, can't we manage it that way?
15:40:49 <acozine> yep, the ansible-base porting guide is also manually managed, so we can prevent/redirect entries there too
15:40:51 <felixfontein> they could just add a proper changelog to their collection
15:40:56 <felixfontein> it would be A LOT of less work for us
15:40:59 <samccann> and the first comment on the PR would be 'why can't you put this in a changelog fragment'
15:41:12 <samccann> agreed felixfontein
15:41:22 <samccann> ok lemme take a step back here
15:41:41 <samccann> other than the mess we have tdday with ansible-base porting guide content having stuff that doesn't belong
15:41:49 <samccann> do we foresee needing that manual section ever again?
15:42:00 <samccann> forsee? foresee? four seas?
15:42:12 <felixfontein> IMO we would only need it for things that affect ansible itself (and not ansible-base), and not individual collections
15:42:58 <samccann> ok I think I'm coming over to your way of thinking felixfontein
15:43:17 <felixfontein> :)
15:43:22 <samccann> we have a 'hidden' manual section that only we can control. And we don't allow 'oh sorry I forgot a changelog entry for xxx can you add it manually please'
15:43:39 <samccann> they have to rev their collection to bring it in
15:44:07 <felixfontein> yes
15:44:12 <acozine> yep, with this many collections we need some regimentation
15:44:43 <felixfontein> otherwise the manual section becomes the "easy way out" (next to "just don't document it, we know what's happened, that's enough")
15:44:53 <samccann> so are we agreed?? only a handful of us can edit a manual section in the ansible porting guide and it is not for missing changelog fragments from collections?
15:45:03 <acozine> +1
15:45:04 <felixfontein> +1
15:45:12 <samccann> #chair
15:45:12 <zodbot> Current chairs: acozine baptistemm bcoca felixfontein samccann zbr|rover
15:45:22 <acozine> #chair abadger1999
15:45:22 <zodbot> Current chairs: abadger1999 acozine baptistemm bcoca felixfontein samccann zbr|rover
15:45:35 <felixfontein> they don't even have to use antsibull-changelog, they can manually create changelogs/changelog.yaml with the correct entry(es)
15:46:09 <samccann> ok gonna call this vote - 3 in favor, rest abstained
15:46:16 <acozine> hooray!
15:47:03 <acozine> great stuff today
15:47:14 <acozine> we went 15 minutes over, but it's in a good cause!
15:47:17 <samccann> #agreed only a handful of people can edit a manual section in the ansible porting guide and it is not for missing changelog fragments for a collection
15:47:41 <felixfontein> acozine: indeed!
15:47:41 <samccann> #agreed we will have two porting guides - ansible-base and ansible. The ansible-base content will also be in the ansible porting guide
15:47:54 <acozine> quick open floor
15:47:54 <felixfontein> #action felixfontein create a PR which shows how it would look like
15:48:33 <acozine> felixfontein: when that is ready, let me know and I'll figure out how to publish it to docs.testing.ansible.com
15:48:59 <baptistemm> #action baptistemm open a PR to discuss about the left column on the doc website
15:49:08 <felixfontein> acozine: cool!
15:49:12 <samccann> oooo
15:49:22 <samccann> ping me on that one when you have it baptistemm !
15:49:28 <felixfontein> I'll probably create a PR for stable-2.10 first, since that's most pressing
15:49:28 <acozine> baptistemm: ooh, yes, the last part of the User Guide changes is updating the TOC
15:49:31 <baptistemm> it's just a mess when you arrive on docs
15:50:11 <felixfontein> wihch kind of leads to the second part of my second question "into which branches (just stable-2.10, or also devel)?"
15:50:13 <acozine> we have info on the top most-visited pages, we should incorporate that too baptistemm
15:50:17 <baptistemm> Reference & Appendices is full of different topic that we could put under a good category
15:50:27 <felixfontein> which is somewhat coupled to "how do the docsites for ansible and ansible-base relate in the future?"
15:50:55 <acozine> felixfontein: let's get 2.10 done as a proof of concept
15:51:21 <acozine> longer-term, my bet is that the rhythm for publishing docs will change
15:51:48 <acozine> we'll publish some things in response to ansible-base updates and some in response to ansible (PyPI) updates
15:51:50 <samccann> baptistemm : I forget your timezone, but did you want to set a time we can meet here to discuss the left-hand nav in more dept?
15:51:53 <samccann> depth even
15:52:25 <samccann> I can dig up the most visited pages stats if that would help. or you can talk about your ideas, focus areas to fix etc
15:52:39 <samccann> and yeah, that appendix is a dumping ground for sure and needs help to simplify it
15:53:10 <acozine> count me in, as well
15:53:23 <samccann> baptistemm: one thing to keep in mind is we can't rename/move rst files without also adding http redirects (doable, but an added complexity to consider)
15:53:34 <acozine> oops, I never updated the topic
15:53:37 <acozine> #topic open floor
15:53:49 <acozine> samccann: but we can change the TOC without changing the rst filenames
15:53:51 <baptistemm> samccann: I need to set my mind up and clarify what I like to fix first
15:53:57 <acozine> like we did with the Style Guide
15:54:18 <baptistemm> I'm in France so it's currently 5:54
15:54:23 <samccann> baptistemm: sounds good. We're here to chat about it when you are ready.  Obviously there's a level of excitement that someone wants to tackle it :-)
15:54:26 <acozine> those pages live in one section but show up in the TOC of a diffrent one
15:55:00 <acozine> so we can change the nav a lot without redirects, if we do it carefully
15:55:46 <acozine> it will be great to streamline that stuff!
15:55:52 <acozine> all right . . . .
15:56:02 <acozine> I have yet another meeting at the top of the hour
15:56:26 <acozine> any other topics for open floor?
15:56:36 <acozine> anybody out there who was too shy to speak up before?
15:57:05 <samccann> or just polite and waiting for the open floor?
15:57:51 <acozine> #info agenda items are welcome for next week's meeting at https://github.com/ansible/community/issues/521
15:59:44 <acozine> okay, thanks abadger1999 bcoca baptistemm felixfontein samccann zbr|rover
16:00:03 <acozine> see you here in chat through the week, and next week at the DaWGs meeting!
16:00:09 <acozine> #endmeeting