15:31:01 <samccann> #startmeeting Documentation Working Group supplemental meeting
15:31:01 <zodbot> Meeting started Thu Jan  7 15:31:01 2021 UTC.
15:31:01 <zodbot> This meeting is logged and archived in a public location.
15:31:01 <zodbot> The chair is samccann. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:31:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:31:01 <zodbot> The meeting name has been set to 'documentation_working_group_supplemental_meeting'
15:31:15 <samccann> #topic opening chatter
15:31:19 <samccann> who's around?
15:31:24 <samccann> #chair gundalow
15:31:24 <zodbot> Current chairs: gundalow samccann
15:32:42 <samccann> tadeboro felixfontein abadger1999 dericcrago dmsimard ? Around to talk about splitting up the docsite?
15:35:54 <samccann> ooookay.  Gonna be a  quiet talk... or a deep dive w/ me and gundalow today!
15:35:59 <dmsimard> on a phone call, apologies
15:36:06 <samccann> #topic status update
15:36:18 <samccann> #info problem statement - the ansible PyPI package called version 3.0.0 will beta at start of Feb 2021 timeframe and some time after that, the ansible-core PyPI package called version 2.11 will release. We need a way for docs to reflect the two “streams” of versions. Ansible 3.0.0 docs need to reference back to ansible-base 2.10 docs for all Ansible features that are not collections.
15:36:32 <samccann> #info proposal  docs.ansible.com/ansible becomes Ansible the Package documentation. docs.ansible.com/ansible-core becomes the core only documentation.
15:36:50 <samccann> #info current status Reviewing internally to get full buyin from management later this week
15:36:50 <samccann> - getting feedback from SEO expert on how to handle duplicated guides on both sites using canonical url on only one of them.
15:37:14 <samccann> #info Today's meeting goals - implementation - assuming we get approval, how can we accomplish all this in 3 weeks and 2 days (to have a docsite for 3.0.0 beta)
15:37:36 <samccann> #info agenda - https://github.com/ansible/community/issues/579#issuecomment-750471248
15:37:43 <samccann> ok after that link/info fest...
15:38:00 <samccann> #topic what must we accomplish by Feb 2 and what can we push off to a later date
15:38:12 <acozine> o/
15:38:17 <samccann> #chair acozine
15:38:17 <zodbot> Current chairs: acozine gundalow samccann
15:38:34 <gundalow> #info proposal https://hackmd.io/TQmzyhCUSSKa22iFR_079A?both
15:38:53 <samccann> so I'll start with what I think is a given - by Feb, we MUST have a docsite that reflects Ansible 3.0.0 without ruining the docsite for prior releases.
15:39:08 * dericcrago waves
15:39:11 <samccann> AND we MUST have a /devel/ that continues to show the progress of ansible-core
15:39:19 <samccann> Do we agree on that much so far?
15:39:32 <gundalow> #chair dericcrago
15:39:33 <zodbot> Current chairs: acozine dericcrago gundalow samccann
15:39:55 <gundalow> samccann: +1
15:40:18 <samccann> ok
15:40:36 <acozine> yep
15:41:24 <samccann> #agreed we need a docsite that reflects Ansible 3.0.0, that doesn't mess up older releases, and that has /devel/ for ansible-core
15:41:43 <samccann> ok now we discuss what we can potentially punt to after Feb.  The list is:
15:42:52 <samccann> 1 . splitting off unversioned docs such as community and developer guide
15:42:52 <samccann> 2. moving scenario guides out of ansible/ansible to 'someplace else'
15:42:52 <samccann> 3. One Ansible package - different core releases installed
15:43:18 <samccann> Is  there a low hanging fruit there that we can all say 'yes definitely, let's handle that one later'?
15:44:15 <acozine> I'd vote for punting on unversioned docs, I think we can do that at any time
15:44:24 <gundalow> 1. Maybe we can talk about this later, though I'm wondering if "make new place, don't move old content yet" might help
15:44:24 <gundalow> 2. leaving scenario guides were there currently are could be OK
15:45:16 <acozine> gundalow: so the 3.0 docs would be on their own, with no connection to earlier versions?
15:45:46 <samccann> so I'm also +1 for not doing unversioned docs yet
15:46:54 <gundalow> acozine: different thing. I'm wondering if we make docs.ansible.com/community for brand new docs. And avoid moving anything from d.a.c/ansible/community for the moment
15:47:44 <dericcrago> in terms of short term, I think 'One Ansible package - different core releases installed' is probably the most important or just something to really help with any versioning confusion once 3.0.0 comes out
15:48:08 <samccann> ok let's try a vote
15:48:11 <acozine> so what would be included in the "brand new docs"?
15:48:29 <samccann> VOTE - we will not try to unversion any existing docs (aka community/developer guide) by Feb 2.
15:48:54 <acozine> +1
15:49:00 <samccann> +1
15:49:14 <lmodemal> +1
15:49:21 <samccann> #chair lmodemal
15:49:21 <zodbot> Current chairs: acozine dericcrago gundalow lmodemal samccann
15:51:32 <samccann> hmm... well the writers are in favor but not getting feedback from anyone else -
15:51:51 <gundalow> (sorry was on phone)
15:51:58 * samccann ponders the morality of silence is approval
15:52:18 <gundalow> We currently don't have any unversioned docs. So although this is something we generally want, this isn't a regression
15:52:19 <gundalow> so
15:52:20 <gundalow> +1
15:52:32 * acozine shudders at the historical reference to the Silent Majority
15:53:43 <samccann> #agreed we will not try to unversion any existing docs (aka community/developer guide) by Feb 2.
15:53:44 <gundalow> acozine: brand new docs would include "guides for collection owners"
15:54:02 <samccann> ok I think that should be the next topic gundalow
15:54:09 <acozine> ah, okay
15:54:29 <samccann> I don't think we can rule out moving scenario guides if we also want to create a new place for guides
15:54:43 <acozine> so we develop those guidelines (the checklist and so on) into a Collection Owners' Guide
15:54:48 <samccann> but first, let's finish with the list  - Ansible vs multiple core versions
15:55:01 <samccann> please hold that for the next topic (what's in new guides)
15:55:04 <acozine> sorry samccann , carry on
15:55:47 <samccann> So at one point, there was confusion (probably in my head) that if someone installs say Ansible 3.0.0 AFTER ansible-core-2.11 releases, they would actually install core 2.11, NOT base-2.10
15:56:17 <samccann> I seem to think someone clarified my confusion, and Ansible 3.x would only include ansible-base 2.10.x if installed via pip
15:56:26 <samccann> does that sound correct to others?
15:57:07 <bcoca> isn't same true for ppa?
15:57:32 <samccann> #chair bcoca
15:57:32 <zodbot> Current chairs: acozine bcoca dericcrago gundalow lmodemal samccann
15:57:39 <lmodemal> sorry, what is ppa?
15:57:40 <acozine> As I understand it, Ansible 3.0.0 will have a dependency on base/core. That dependency will be expressed as `>=2.10.x`.
15:57:44 <samccann> could be, I'm barely understanding the pip side of things
15:58:03 <acozine> So if I install Ansible 3.0.0 on day one, I will get the minimum defined version.
15:58:08 <samccann> ok acozine's memory matches mine then
15:58:16 <samccann> oh wait
15:58:20 <bcoca> dependencies work basically teh same across package managers, must be referenced and installed first .. giving the illusion of 'included'
15:58:21 <acozine> But as new versions of base/core are released, I can update my base/core.
15:58:30 * samccann lets others finish typing...sits on hands
15:58:56 <samccann> acozine - i'm not talking right now about someone manually updating core
15:59:00 <gundalow> dericcrago: dmsimard abadger1999 Is the plan that `ansible==3.0.0` will depend on `ansible-base 2.10.x`
15:59:22 <samccann> what I want to know is - if I am installing Ansible the package, is there any scenario wherein I get 2.11 instead of 2.10
15:59:30 <acozine> I think so.
15:59:32 <dmsimard> back from phone call
15:59:41 <dmsimard> gundalow: yes according to https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw?view
15:59:42 <tadeboro> IIRC, ansible 3.0.0 will depend on latest stable thing at the time of release.
15:59:58 <acozine> I think if I stick with 2.9 until, say, June, then install 3.0.x, I will get ansible-core-2.11.
16:00:22 <acozine> Assuming 2.11 is released in April/May.
16:00:23 <dericcrago> https://docs.ansible.com/ansible/devel/roadmap/COLLECTIONS_3_0.html that seems to refer to 2.11
16:01:05 <acozine> Because pip will install the latest available version that matches the dependency.
16:01:11 <dmsimard> technically there will never be an ansible-base 2.11 so at one point we will need to change the requirement from ansible-base >=2.10 to ansible-core >=2 .11
16:01:17 * lmodemal Dropping off for another meeting.
16:01:19 <tadeboro> acozine: I would assume that ansible will not change its dependencies in between major versions. So ansible 3.x.y will always depends on ansible-base
16:01:29 <dericcrago> "Ansible 3.x.x minor releases will occur approximately every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-base-2.10.x. Ansible 3.x.x minor releases may contain new features but not backwards incompatibilities."
16:02:13 <acozine> Okay, so the dependency will be `>=2.10 and <=2.11`
16:02:28 <acozine> 2.10.0, that is
16:02:45 <acozine> I guess by June we should be onto Ansible 4.0
16:02:45 <dericcrago> the current release (2.10.5) specifies this: 'ansible-base>=2.10.4,<2.11'
16:03:32 <dmsimard> pinning ansible-base to <2.11 is somewhat useless
16:03:36 <dmsimard> there won't be a 2.11 ansible-base
16:03:37 <samccann> so.. is that agreement that no 3.x install would automatically grab core 2.11?
16:03:50 <dericcrago> so if ansible-base 2.10.5 came out tomorrow and then you pip installed ansible, you'd get 2.10.5, whereas if you installed it today, you'd get 2.10.4
16:03:53 <samccann> or is that only an artifact of it changing from base to core in 2.11
16:04:26 <samccann> the docs only reflect 2.10.x vs 2.11.x  so the patch changes aren't important for  the docs discussion
16:05:11 <acozine> as long as we define an upper bound for the version of base or core, we clarify things for docs
16:05:20 <acozine> it sounds like we are doing that now, and plan to continue doing that
16:06:12 <samccann> ok without abadger1999 here, I don't know if we can say 100% that no Ansible 3.x will install core 2.11 (but let's assume that's true for now).
16:06:21 <acozine> samccann: so users will not be able to install 3.x with core 2.11
16:06:33 <abadger1999> Sorry, /me shows up and reads back
16:06:51 <abadger1999> What's the immediate question?
16:06:51 <samccann> oh cool. Let's give him a minute or two to catch up
16:07:00 <dmsimard> ansible-core 2.11 won't be out by the time ansible 3.0 releases so I would expect the requirement to change for Ansible 4.0
16:07:09 <samccann> If I install Ansible 3.x, will it every install 2.11 core
16:07:12 <gundalow> #chair abadger1999 dericcrago dmsimard
16:07:12 <zodbot> Current chairs: abadger1999 acozine bcoca dericcrago dmsimard gundalow lmodemal samccann
16:07:16 <dmsimard> samccann: it won't
16:07:21 <abadger1999> @samccann No, it won't
16:07:32 <tadeboro> In python world, you cannot specify "I depend on ansible-base or ansible-core". This is why I would assume ansible 3.x.y will always install ansible-base.
16:07:41 <samccann> #info If a user installs Ansible 3.x it will never install ansible=core 2.11
16:07:42 <dmsimard> tadeboro: that is my understanding as well
16:07:57 <samccann> ok let's for a moment push this out in time.
16:08:01 <acozine> more generally, though, moving forward, will we define upper bounds on the versions?
16:08:11 <samccann> Ansible 4.x - will bring in ansible-core 2.11 right?
16:08:25 <acozine> ^^^
16:08:30 <samccann> So will Ansible 4.x ever install ansible-core-2.12
16:08:35 <acozine> but not 2.12
16:08:39 <acozine> ???
16:08:41 <abadger1999> Right.  And additionally, ansible-core-2.11 doesn 't guarantee backwards compat with ansible-base-2.10, so we wouldn't want to upgrade that for the ansible dependency without also bumping the anislbe major version number.
16:08:52 <abadger1999> acozine: yes
16:08:56 <acozine> good
16:09:12 <samccann> #info Ansible 4.x would never install core-2.12 either
16:09:19 <samccann> ok good. thanks for clarifying that
16:09:21 <samccann> next question
16:09:28 <abadger1999> sorry I was late to the party.
16:09:39 <dericcrago> I think each major version of ansible will pin to latest ansible-core minor version at the time of release
16:10:09 <samccann> IF as a user, I have Ansible X.Y, and I manually upgrade ansible-core on my own to some future version - will that work? do we support that? (ans in running core 2.12 on Ansible 4.x)
16:10:17 * acozine AFK five, sorry
16:10:19 <abadger1999> Yep, where minor is the Y in ansible-core-X.Y.Z
16:11:15 <abadger1999> samccann: It will be strange but the user probably can because pip doesn't check the dependencies of the whole system.  It only checks the dependencies in the pakcages that it actively has to work with in that request.
16:11:40 <samccann> abadger1999 - but is that considered a supported scenario (from the community perspective)?
16:11:52 <abadger1999> "support" is iffy here since ansible is volnteer/community maintained and run.
16:11:54 <samccann> or is that 'you've done something silly, back it out'
16:12:22 <abadger1999> I think it would definitely be appropriate to say, some things might not work if you mismatch versions.
16:12:41 <dmsimard> the risk by updating ansible-core out of sync of the ansible package would be incompatibilities for collections that shipped in the version shipped by the ansible package
16:12:47 <samccann> Ok what I'm leading to  is - our docs do NOT have to have a smooth/easy way to find docs if you've done something like this
16:13:24 <samccann> As in, docs reflect what is installed with Ansible the package, not what someone might do after that
16:13:30 <abadger1999> But I think it will probably ultimately be up to people who are answering questions on mailing lists and irc channels and so forth whether they want to say right off the bat "if your versions don't match what we recommend, then we won't answer your questions"
16:14:37 <abadger1999> I would prefer someone who is not paid by red hat to weigh in on that but I think it's fine as a starting point.
16:14:53 <samccann> #info Docs will reflect what is in Ansible the package and not attempt to match what a user may manually upgrade after that
16:15:18 <bcoca> that is what ansible-doc is for, it should always match 'what you have'
16:15:21 <samccann> Ok of the three items of what can we punt for now, we've covered two of them
16:15:49 <samccann> So I'd like to move the topic onto gundalow's idea of a new place for new docs as I think it impacts the item we didn't cover yet (scenario guides)
16:15:55 <abadger1999> If community people a year from now say, "Hey, we answer these five questions about mismatched versions all the time and the answer is easy.  Here's a doc update that answers those questions for docs.ansible.com", I think we should consider adding those answers.
16:16:14 <samccann> yeah that's fine
16:16:39 <samccann> #topic new repo for new community guides etc
16:16:50 <abadger1999> Cool :-)
16:16:51 <samccann> gundalow: do you want to summarize your idea?
16:17:04 <gundalow> Thanks
16:18:39 <gundalow> #info We know there are various gaps in the community documentation, especially around how to look after (maintain, own, manage) Collection & Collection repos. We have a lot of brand new docs to write. Currently we've been using https://github.com/ansible-collections/overview to host some RST. Though this was always viewed as a short term solution
16:19:28 <gundalow> #info I wonder if we could start a new top level docsite for these brand new docs (docs.ansible.com/community)
16:19:45 <gundalow> #info Example index page https://hackmd.io/uKhHRhFUStG_bVNhY10cLQ#New-Index-structure
16:20:45 <samccann> at the highest level, i'm +1 on a docs.ansible.com/community
16:21:48 <acozine> that sounds good to me
16:21:49 <samccann> I like the idea of new community contributor docs starting out on a new repo and being published to a new url
16:22:11 <acozine> over time we could migrate existing community content to that section
16:22:15 <samccann> then over time, we can move/remove the rest of the older community rst pages
16:22:20 <samccann> JINX
16:22:27 <samccann> u owe me a soda :-)
16:22:34 <acozine> heh, okay
16:23:33 <samccann> anyone seeing a drawback to new community info being in another repo and published when ready to a new url?
16:24:07 <gundalow> I think the steps would be something like
16:24:07 <gundalow> 1. Agree we want to do this
16:24:07 <gundalow> 2. Define the structure (top level index) - something like https://hackmd.io/uKhHRhFUStG_bVNhY10cLQ#New-Index-structure
16:24:07 <gundalow> 3. Create new repo, initially with just `index.rst` with top level titles (no actually links)
16:24:07 <gundalow> 4. Individual PRs that add specific bits of content (ie PR to detail how to use GitHub Actions for CI) - Smallest PRs possible, ie update index + add new page. Anything larger is just painful
16:24:07 <gundalow> 5. Maybe add some back links from existing d.a.c/ansible/community to $newplace
16:24:07 <gundalow> 6. Future: Migrate content from d.a.c/ansible/community to $newplace as you mentioned
16:24:28 <acozine> short-term we'll have issues with the community docs being in two different places, but we can solve that over time
16:24:30 <gundalow> oh, and Jenkins docs build foo as as `3b`
16:24:44 <gundalow> acozine: yup, two community places, though no duplicated content
16:25:16 <abadger1999> Only thing I can think of is there may be a need for an index  below "Index of all of the ansible ecosysterm" that lists both the community and the existing documentation.
16:25:27 <abadger1999> But I think that can be solved later.
16:25:35 <gundalow> abadger1999: Is this d.a.c root page
16:25:41 <abadger1999> (Maybe once we also spin out scenario guides)
16:25:56 <acozine> which repo will the rst pages for the new section live in?
16:26:06 <gundalow> acozine: I think brand new repo
16:26:58 <samccann> hmm
16:27:12 <samccann> one of the things we benefit from is having docs in a repo where code changes happen
16:27:28 <samccann> I guess you can say community pages have no underlying code?
16:27:41 <abadger1999> gundalow: There may be a need for a deeper hierarchy... d.a.c/index.html (click)=> d.a.c/ansible/index.html (click) => d.a.c/ansible/community or d.a.c/ansible/latest/ or d.a.c/ansible/managing_aws/
16:27:42 <gundalow> samccann: yup, though most of this content isn't `ansible` or `ansible-core` version specific
16:27:58 <abadger1999> (But like I say... we can figure that out once there's more content)
16:28:39 <samccann> gundalow: reading that index, it does have code dependencies (anything to do with collection structure, galaxy init commands etc)
16:28:39 <gundalow> abadger1999: in my mind I see `community` as a top level (first class) entry
16:29:22 <abadger1999> samccann: yeah... there would be some sync issues but it wouldn't be too different than now. (for instance, some policies are encoded into ansible-build-data and the antsibull repositories).
16:29:24 <samccann> as an example - when someone changes ansible galaxy * commands, they usually change some of the docs to match.
16:30:03 <abadger1999> gundalow: yeah... but we'd also want to make clear that ansible-core is also open source and can be contributed to by the community.
16:30:09 <samccann> gundalow - yes community is top level... but where I get confused is the separation between community and developer.  So 'how do i create a collection' imo is developer not community
16:30:46 <abadger1999> (gundalow also... if community is toplevel, why doesn't it include contributing to tower and galaxy? yadda yadda)
16:30:55 <samccann> we don't have a clock person keeping us in line but we are at the 1 hr mark
16:31:12 <gundalow> In that example, i'd expect d.a.c/community/FOO/Authenticating against galaxy with github to create a collection to maybe have an overview then intersphinx link to the main Galaxy docs
16:31:33 <acozine> Can we distill this discussion into a GitHub issue or proposal or something?
16:31:43 <acozine> And then call it enough for today?
16:31:47 <gundalow> abadger1999: I think longer term contributing to AWX, ansible-lint, etc should be on d.a.c/community
16:31:53 <gundalow> acozine: Sure, I'll do that
16:32:40 <samccann> so that still leaves scenario guides.  My nickel - we don't move them until we figure out the Grand Plan of what gundalow is proposing and what we can or cannot put into an individual collection /docs folder
16:32:51 <gundalow> 1. How do we get there (6 points from above)
16:32:52 <gundalow> 2. What about links between different docs sites
16:32:52 <gundalow> 3. Should AWX, ansible-lint contributor docs be moved (or at least linked)
16:32:52 <gundalow> what else should be in the proposal
16:32:54 <samccann> (aka not by feb 2).  Any thoughts/disagreements?
16:33:08 <abadger1999> gundalow: I do to.  (But haven't bounced that off of the awx or galaxy teams ;-)
16:33:16 <acozine> Sounds like a good plan, samccann
16:33:36 <samccann> gundalow - the entire set of information needs an information architecture analysis - community vs developer vs galaxy
16:34:22 <felixfontein> sorry, won't be around today :/
16:34:45 <abadger1999> samccann: For your example of galaxy... note that half of galaxy is in a different repo right now (the serverside)
16:34:49 <samccann> so i'm caught between liking the idea, and dreading recreating the community vs developer problem we have today
16:35:02 <samccann> abadger1999 yep, and they are not in sync
16:35:03 <zbr> the docs were moved out because the publishing pipelines were bit shaky, not because we love having lots of websites for each tool
16:35:20 <abadger1999> samccann: yep.
16:35:34 <abadger1999> they're not always in sync between galaxy repo and ansib le/ansible repo
16:35:36 <samccann> but let's let gundalow create the proposal and we can dig into it more at that point
16:35:59 <samccann> That leaves us with...
16:36:02 <abadger1999> BTW, I think that community is mostly a subset of developer.
16:36:06 <samccann> #topic next steps
16:36:14 <abadger1999> but it's not an exact subset.
16:36:26 <samccann> so as I panick-said earlier - 3 weeks and 2 days til 3.0.0 beta
16:37:27 <samccann> So I think one of my biggest worries is 'how do we publish 3.0.0 with some pieces coming from ansible/ansible devel and some from ansible/ansible stable-2.10'
16:37:54 <samccann> and the lesser worry - how do we create a makefile that will only build a subset of existing docs
16:38:07 <samccann> I might be able to hack my way on that second one
16:38:15 <abadger1999> can you define the pieces in each of those?
16:38:21 <samccann> but not a clue how to do the first. Is this something someone can test out by next week?
16:38:31 <abadger1999> I can estimate how easy it would be to do if I know what the pieces are.
16:39:01 <samccann> abadger1999 - so it would match this docsite http://docs.testing.ansible.com/ansible/3.x/index.html
16:39:34 <samccann> But the user guide would come from stable-2.10
16:39:57 <samccann> i 'think' the rest would come from devel, and the collection index, from 3.x
16:40:24 <abadger1999> samccann: I have to admit that I don't know the docsite well enough as a document to be read that I know what's missing or coming from different versions... are you able to circle things in red for me?
16:41:13 <samccann> abadger1999 - yes I can do that offline. But for a rough estimate, just imagine 'build everything from devel, except /user_guide/* comes from stable-2.10
16:41:36 <samccann> there are only a handful of files that would need to be removed after that
16:42:22 <abadger1999> Cool, and user_guide is already a separate directory in there.
16:42:45 <samccann> so am I hearing a volunteer from the audience on testing this out? ;-)
16:43:01 <abadger1999> I think the easiest way to do that would be to create a different sphinx doc for the user guide.
16:43:20 <abadger1999> well.... least hacky way
16:43:48 <abadger1999> easiest might be to build the docsite twice from the two branches and then copy files around
16:44:01 <samccann> ok  we are nearly 15 min over.  So maybe you and I can continue this discussion here later today?
16:44:13 <samccann> as our next step so to speak... so we can close out this meeting in a few?
16:44:24 <abadger1999> yes, that sounds good.
16:44:52 <samccann> #action samccann abadger1999 to continue discussing how to build this 3.x docsite from some 2.10 rst files later today
16:44:59 <samccann> #topic Open Floor
16:45:00 <abadger1999> Why does 3.0 build from devel?
16:45:12 <samccann> Anyone else have anything to bring up for this discussion?
16:45:52 <samccann> 3.0 builds from devel because ansible/ansible repo is controled by core and the next stable will be 2.11 for core. Though if you know some branching magic we can discuss that later today as well
16:46:45 <abadger1999> Okay.... but ansible-3.0 won't be based on devel.
16:47:21 <acozine> we should be able to build 3.0 the way we currently build 2.10
16:47:37 <acozine> off the stable-2.10 branch with a list of included collections
16:47:40 <abadger1999> Maybe what I'm asking is what's the criteria that we're using to say user_guide should reflect stable-2.0 and not the reference guide (as an example)
16:47:54 <samccann> ok so as a concrete example - the scenario guides MUST be tied to 3.x.. today they live in ansible/ansible devel
16:48:17 <abadger1999> okay, so they're also tied to stable-2.10?
16:48:55 <samccann> so the scenario guides in stable-2.10 reflect Ansible 2.10
16:49:12 <samccann> the scenario guides for Ansible 3.x... are in devel
16:49:38 <abadger1999> okay.  so the scenario guides in devel do not reflect ansible-core-2.11 ?
16:49:50 <acozine> yes, the scenario guides need to move, so we can update and maintain them in synch with collections
16:50:03 <samccann> well, in general, who knows who's updating what on the scenario guides
16:50:09 <abadger1999> Heh :-)
16:50:16 <acozine> I think they aren't getting much attention
16:50:25 <samccann> but networking specifically - the guides are being updated to reflect the collections
16:51:06 <acozine> agreed that content like that really belongs in collections
16:51:30 <acozine> it documents the capabilities of collections and changes with the collection, not with ansible-core
16:51:31 <samccann> So if we say the Ansible 3.x docset - 'everything' could come from stable-2.10 except the collection index, the scenario guides, and the porting/release/maint/ and roadmap pages... does that help envision things?
16:51:36 <abadger1999> Okay.  I guess when we talk after the meeting, we can write a short criteria and then we can make assumptions about where things fall based on the criteria and later, other people can ask us to adjust because they don't think our assumptions were correct.
16:51:48 <samccann> :-)
16:52:12 <abadger1999> samccann: yeah :-)
16:52:25 <abadger1999> Cool.
16:52:55 <abadger1999> Clear as mud now (but now I know where the mud is so I'll be able to navigate it :-)
16:52:58 <abadger1999> Thanks :-)
16:53:02 <samccann> ok before we close out - do you have a good time to meet later today in case anyone else wants to pop in for our informal chat?  I have meetings til 3pm ET
16:54:00 <abadger1999> I have a team meeting coming up and then I think I'll be free until End of day Pacific time
16:54:20 <abadger1999> So if you want to meet at 3pm ET, that's fine with me.
16:54:44 <abadger1999> If you want to have a break before meeting with me and are willing to risk going after 5PM ET, that's also fine with me.
16:55:26 <samccann> heh ok let's pop back here at 3pm ET. all are welcome but it won't be an official meeting... just open brainstorming chat
16:55:34 <samccann> Thanks everyone!
16:55:38 <abadger1999> Excellent.
16:55:39 <abadger1999> Thanks :-)
16:55:44 <acozine> thanks samccann for keeping us banging away on this problem
16:55:52 <samccann> #endmeeting