16:00:45 #startmeeting Docs Working Group aka DaWGs 16:00:45 Meeting started Tue Feb 16 16:00:45 2021 UTC. 16:00:45 This meeting is logged and archived in a public location. 16:00:45 The chair is acozine. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:45 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:45 The meeting name has been set to 'docs_working_group_aka_dawgs' 16:00:51 #topic opening chatter 16:00:54 who's around? 16:01:06 hi! 16:01:12 hi felix! 16:01:15 #chair felixfontein 16:01:15 Current chairs: acozine felixfontein 16:01:17 Hey all! 16:01:24 hi lmodemal! 16:01:27 #chair lmodemal 16:01:27 Current chairs: acozine felixfontein lmodemal 16:02:42 Morning 16:02:43 o/ 16:02:50 #chair abadger1999 samccann 16:02:50 Current chairs: abadger1999 acozine felixfontein lmodemal samccann 16:03:13 andersson007_: bcoca dericcrago dmsimard gundalow samccann alongchamps baptistemm briantist cyberpear jmn madonius mrproper sommersoft tremble you folks chatting docs today? 16:03:28 hello 16:03:48 I'll just be lurking, have some meetings 16:04:15 alongchamps: okay, jump in if/when you can 16:04:19 hi dmsimard 16:04:23 #chair dmsimard 16:04:23 Current chairs: abadger1999 acozine dmsimard felixfontein lmodemal samccann 16:04:36 agenda begins with https://github.com/ansible/community/issues/579#issuecomment-776189919 16:05:15 o/ (dual meeting for me rn; i'll participate as i can) 16:05:27 hi sommersoft 16:05:28 thanks sommersoft! 16:05:33 * dericcrago waves 16:05:35 okay, I won't make you furniture 16:05:42 hi dericcrago 16:05:44 #chair dericcrago 16:05:44 Current chairs: abadger1999 acozine dericcrago dmsimard felixfontein lmodemal samccann 16:06:22 we'll get started, more folks can join us any time 16:06:34 #topic Ansible 3 release and docsite split 16:06:50 samccann: you want to take this one? 16:06:53 sure 16:07:07 this is the PR - https://github.com/ansible/ansible/pull/73616 and it's finally working! 16:07:22 * acozine dances a little jig 16:07:43 so we need feedback ASAP because we still need to merge this AND backport it AND test it all out so we are ready for I guess a Thursday Ansible 3 release date? 16:08:47 the PR has a test failure, any idea what's failing? 16:08:49 Yeah, that's what I'm planning on (Thu) 16:09:08 acozine - matt clay gave me the solution to that failure and it works locally 16:09:12 acozine: that's caused by the symlinks, see mattclay's comment 16:09:28 yeah and the cp instead of ln works... and I now know where to put a minor 'cleanup 16:09:29 ah, excellent 16:09:47 of the copy so it's not lingering when someone does a git add locally 16:10:29 this is the Ansible 3 docs in test BUT it's from /devel/ right now (until we backport) so the user guide etc are devel not 2.10 - http://docs.testing.ansible.com/ansible/3/index.html 16:11:12 and this is ansible core docs (note the url difference) - http://docs.testing.ansible.com/ansible-core/devel/ 16:11:48 so my question is - once I fix the CI problem - can we merge this this afternoon? Are there any other critical folks who need to review? 16:12:48 not critical, but: "Ansible releases a new major release of Ansible approximately three to four times per year." <--- better change that to twice per year as well :) 16:13:13 reviewers so far were webknjaz and mattclay ^ 16:13:40 felixfontein: good catch 16:13:41 thanks felixfontein -I'll add that as a comment to the PR so I don't forget. 16:15:03 IMO it can be merged once sanity tests pass. but then, I don't know the docs build process that well. I guess the main question is: should the nightly devel site build still work with this? 16:15:40 dmsimard: abadger1999 has also reviewed the approach, if not officially the PR 16:15:56 The nightly devel build will continue to work, but there is a separate discussion on that that I'd like to cover ...separately ;-) 16:16:25 felixfontein: yes, the devel nightly build should continue to work 16:16:28 We have build jobs now that will continue to work with the release process for ansible-core, and will allow manual build of Ansible 3 etc 16:16:29 I'm for merging (once sanity passes), it's the best way to find out what still works afterwards ;) 16:16:35 heh 16:16:49 hotfix in production? sure, why not . . . 16:16:55 * acozine is kidding 16:17:03 samccann: Yeah, I think the PR is sound. 16:17:03 well, it's not really production, it's testing so to say :) 16:17:13 yep 16:17:17 or to-be-production-in-more-than-a-month 16:17:41 all right, let's have a vote for the sake of posterity 16:17:42 for those who think the PR is good, can I hit you up for an approval later today before we merge? 16:17:43 the backport will be more critical, but that doesn't need to be merged to build the docsite I guess 16:17:43 samccann: I think the fix for the CI problem should be to add the files to the ignore list in the test, though. I can do that now-ish. 16:18:02 felixfontein - actually the backport is critical to Ansible 3 release on thurs 16:18:12 we have to build the docsite from stable-2.10 16:18:39 abadger1999 - I have that in my local branch so I can continue it and commit later 16:18:39 samccann: can't you also build the docsite from the backport [4~branch, rebased to the latest stable-2.10 branch? 16:18:40 hey folks, kinda lurking 16:18:50 samccann: I would expect that to yield exactly the same result 16:19:07 if we can get this merged to devel today, we can have a backport by end of day and should squeak in under the wire 16:19:11 felixfontein you mean build Ansible 3 from my private branch with the pr backported? 16:19:11 Hi briantist 16:19:13 briantist: hi! do you want to be furniture? 16:19:18 sure why not 16:19:24 #chair briantist 16:19:24 Current chairs: abadger1999 acozine briantist dericcrago dmsimard felixfontein lmodemal samccann 16:19:35 samccann: yep. not the best solution, especially not long-term, but if people are hesitant to merge the backport, it still works 16:19:50 acozine - I can't commit to a backport by end of day today. End of day tomorrow, sure. I still worry what might be lingering in stable-2.10 i've not thought of 16:19:58 samccann: of course getting it merged as well would be better :) 16:20:09 fyi, releases are on hold for now 16:20:10 samccann: I would be willing to give the backport a try today 16:20:19 bcoca: can you say more about that? 16:20:27 which releases? on hold for what? for how long? 16:20:28 #info if push come to shove, we can build Ansible 3 from a private branch w/ the pr backported to stable 2.10 (if we can't get reviews in time to merge into stable-2.10) 16:20:47 bad weather 16:20:49 #chair bcoca 16:20:49 Current chairs: abadger1999 acozine bcoca briantist dericcrago dmsimard felixfontein lmodemal samccann 16:20:52 ansible-base/core, cause RE is unavaialble (texas strom/power outage), idk, depends 16:21:13 (I first thought it was a joke when glancing at the mail, then re-read it...) 16:21:18 oof, that's terrible 16:21:29 Subject: [ansible-devel] Ansible releases delayed due to extreme weather 16:21:54 oh wow 16:22:11 ooch 16:22:22 all right, so the part we can control is merging into devel 16:22:51 #action - samccann to fix CI errors by using cp instead of ln and finish other feeback so pr can be merged to devel today 16:22:51 VOTE: merge PR 73616 as soon as CI is passing 16:23:02 +1 16:23:03 +1 16:23:04 oh haha forgot about the vote ...doh 16:23:06 +1 16:23:21 samccann: Err... I have a better way to fix the CI issue, I think. 16:23:28 +1 16:23:39 abadger1999 ok we can discuss offline or after the meeting 16:23:46 (luckily the vote doesn't depend on how the CI issues are fixed :) ) 16:23:51 heh true 16:24:00 +1 16:24:03 heh - framing the question is half the battle 16:24:37 +1 16:24:40 We should probably ask relrod if we can backport this while the stable-2.10 release is pending. 16:24:51 (I mean... merge the backport, not prepare the backport PR) 16:24:57 (when he gets back from ice-storm isolation) 16:25:28 #info - may not be able to merge the backport to stable-2.10 as it is frozen due to pending release 16:25:36 (and frozen in more ways than one, eh!) 16:25:38 okay, 6 in favor, none opposed 16:25:39 heh 16:25:47 He may have access to slack, I saw him reply to something earlier. But it could be transitory. 16:26:07 any other discussion about this PR, or about handing the split between /ansible/ docs and /ansible-core/ docs? 16:26:18 I think with Felix's idea, we can just publish from a branch if need be. I don't want to upset the ansible release applecart 16:26:36 We should discuss what /devel/ means and what the nightly jenkins job will produce as a new topic 16:26:53 #topic future of `devel` documentation 16:26:53 yep, it's probably better to only merge the backport after the next ansible-base 2.10.x release has been made 16:27:08 (now in single-meeting mode; feel free to chair me) 16:27:11 yes, these are special circumstances 16:27:13 I guess we will have /ansible-core/devel/ and /ansible/devel/ from now on? 16:27:17 #chair sommersoft 16:27:17 Current chairs: abadger1999 acozine bcoca briantist dericcrago dmsimard felixfontein lmodemal samccann sommersoft 16:27:44 my original thought was that `devel` only makes sense for the ansible-core docs 16:27:52 ok so let's start with core yeah 16:28:10 I guess /ansible-core/devel/ is pretty much the content of the devel branch of ansible/ansible 16:28:23 so we will have docs.ansible.com/ansible-core/devel but it's not the full content of devel 16:28:34 it will NOT have any of the scenario guides or the network guide 16:28:44 the core docs seem straightforward - we continue to publish from the devel branch, daily or more often, when there are changes to that branch 16:28:54 as in `make coredocs` is the new command for core, and it doesn't include those guides 16:28:58 samccann: I'd vote yes, the scenario guides should really be in collections 16:29:02 ok, let me rephrase, it is what will eventually be left in the devel branch once the collection-specific stuff found its new home 16:29:30 yeah just want to be sure folks realize this, as developers are the ones most likely to notice/care those guides aren't there 16:30:06 I guess /ansible/devel/ will still have them? 16:30:11 #info docs.ansible.com/ansible-core/devel/ will be what the current nightly build produces after the docsite split. It will not include scenario or network guides 16:30:23 that's the next discussion - what do we do w /ansible/devel? 16:30:29 felixfontein: that's where it gets murky 16:31:03 for now, I guess it should essentially stay the same, i.e. be what ansible/3/ looks like with no collections except ansible.builtin 16:31:06 so yes, we can easily produce docs off ansible/ansible devel branch and publish them 16:31:12 what should /ansible/devel/ contain? does it make sense, given that the list of included collections can change, and the versions of those collections can change? 16:31:22 and long term it would be nice if it includes the collections included in Ansible, with whatever version 16:31:28 if we want no collections, then we'd need a new/different jenkisn build 16:31:53 but rather than discuss what we could do - what do we think and Ansible the package 'devel' means? 16:32:01 if we could move the scenario & network guides today, would folks still want to publish /ansible/devel/ docs? 16:32:02 IMO it should include the collections from the latest Ansible release, but with their latest versions (instead of the versions / version restrictions from the latest Ansible release) 16:32:07 i mean no one can 'run it from source' so to speak, can they? 16:32:39 felixfontein: even though there's no easy way for users to install that set of collections? 16:32:40 acozine: move them to where? 16:32:46 felixfontein - so all the same collections in Ansible 3, but the collection version is the most recent in galaxy? 16:32:51 acozine: yes 16:32:52 move them to collections 16:32:53 samccann: yes 16:33:28 we had a discussion recently in #ansible-community with tadeboro that there are users that are confused that the collection documentation in /ansible/latest/ is not for the latest collection versions 16:33:50 okay, so how often would we publish? daily? weekly? we don't have an easy way (that I know of) to tell when a new version gets uploaded to Galaxy 16:33:53 felixfontein - here's my worry - we publish Ansible devel and it picks up THE MOST RECENT collection - say foo version 4.0.0. But we are already at an Ansible 4 freeze time, and at the freeze time, foo was at version 3.2.1. 16:34:02 if /ansible/devel/ would have the latest collection docs, I think it would be more helpful - then users can select between "collections included in the latest Ansible release" and "latest versions of the collections that are included in Ansible" 16:34:04 We now have a devel, before 4.0 release, that in fact has 5.0 content 16:34:40 samccann: yep, that's something that can unfortunately happen. though I think it's ok, if you don't assume that devel contains what the next release will contain 16:34:41 samccann: that sounds like the way `devel` docs have always functioned 16:34:50 samccann: Is that the same as the lead up to an ansible-core release , though? We fork off stable-2.11 for the release and at that point devel is actually for ansible-core-2.12. 16:34:54 yeah thinking the same after I typed it 16:34:58 :-) 16:35:06 the difference now is, folks can't get `devel` by installing from source the way they used to 16:35:12 resp. it's similar to ansible before: after feature freeze, when branching happened, devel might already have features that will not end up in the next major release from the frozen branch 16:35:13 so a friendly banner might solve that 16:35:14 at least, it's a lot more challenging to do it 16:35:36 Ansible as a Service 16:35:36 yeah I'm -1 for giving anyone the knowhow to build their own 'devel' Ansible package personally 16:35:45 acozine: tehy can get 'core' devel, just not 'ansible' pypi package equivalent .. can be simluated with the script i posted last week 16:36:16 they can also use antsibull to build their ansible 'devel' package 16:36:26 ok so it sounds to me like there is some consensus that /ansible/devel/ should happen, and should pick up the most recent versions in galaxy that are part of the 'latest Ansible' 16:36:32 it's not trivial, but also not THAT hard :) 16:36:55 https://github.com/bcoca/acd/blob/devel/generate_acd.yml <= can be made trivial 'run this playbook' 16:37:11 would just need to add 'ansible-galaxy install acd.tgz' at the end 16:37:13 also AFAIK antsibull has nightlies 16:37:53 are we at a point to vote on what we want Ansible/devel/ to be? and we can discuss offline how to make that happen perhaps post Ansible 3 release? 16:38:24 https://ansible-community.github.io/nightly-builds/ 16:38:30 (no idea whether they work though, never tried :) ) 16:39:15 VOTE: `/ansible/devel` (Ansible package "devel") docs should include the `devel` branch of core, plus the most recent versions of all collections known to be included in the next package release 16:39:20 #chair 16:39:20 Current chairs: abadger1999 acozine bcoca briantist dericcrago dmsimard felixfontein lmodemal samccann sommersoft 16:39:34 +1 16:39:53 +1 16:39:54 +1 16:39:55 hmm 16:40:01 i'm having problems w the wording there 16:40:02 +1 16:40:04 (whether we can do this, or how we do this, TBD) 16:40:16 samccann: ah, which parts? 16:40:17 'most recent version of collections known to be in the next package' 16:40:33 can we actually do that once the next package has a set of collections and versions assigned? 16:40:39 or should it be devel branch of thsoe collections? 16:40:55 or maybe there will be a 'data' file that is just collection names, no versions and that's what we use? 16:40:57 samccann: isn't that also a moving target? 16:41:00 bcoca: we can't do that, because we pull collections docs from Galaxy, not from git repos 16:41:05 getting into implementation I guess 16:41:14 bcoca: that's also possible, but somewhat more error-prone since they might be broken more often 16:41:32 yes, but that is nature of /devel/ 16:41:33 yeah I'd say 'most recent version in Galaxy' for sure 16:41:42 if it's not in galaxy, it 16:41:46 is not in our devel 16:41:47 otherwise i would not put collections in /devel/ since ethey will be 'stable versions' 16:42:27 I guess the biggest problem is that collection repositories have no common way to say which version they are 16:42:47 the version in galaxy.yml might not be there, might be the previous release, might be the next release, or something random 16:42:49 bcoca: yes, they will be stable, but they may be different from the versions included in the `latest` Ansible package 16:43:30 acozine: normally interest in devel is so people can contribute and/or see the code develop and handle expectations 16:43:31 right now, community.general on /ansible/latest/ is version 1.3.x, while on devel it would be 2.0.1 (and tomorrow 2.1.0) 16:43:56 bcoca: is that a -1 on the goal for /ansible/devel/ docs? 16:44:25 im mostly abstaining, just pointing out something that i dont think was brought up for consideration 16:44:46 my nickel - let's get the most recent Galaxy version working in our devel docs 16:44:52 gotcha, thanks bcoca 16:44:54 samccann: Yeah, as an example, I can create ansible-build-data/4/ansible.in right now. And then that could be the data source for building the /ansible/devel/ docs. (but need to some code to do the right thing) 16:44:59 abstain for me as well. i only have more questions to offer on this decision. :) 16:45:01 I guess we can also use prereleases from galaxy for devel - but I wouldn't use git repos, at least not in the beginning 16:45:02 then we can see who else is asking for the stuff that is in the github repos 16:45:54 git repos will not work. 16:46:09 collections may be hosted elsewhere (not on github), or even privately 16:46:18 collections docs need to come from Galaxy 16:46:34 should we info that? 16:46:39 acozine: we now require public SCMs (though not necessarily git) for collections included in Ansible 16:46:54 ah, TIL 16:47:03 time check - 45 minutes into the meeting 16:47:27 (though >99% will probably have regular public github repos) 16:47:38 theres's not a standard layout for the git repos so we won't have a standard way to figure out where the files we need are in there. The build steps to turn the git repo into a collection (intermediary before we turn them into docs) is also non-standard 16:47:51 should we agree on /devel/ docs will come from latest version in Galaxy for now and move on? 16:47:58 +1 16:48:02 +1 16:48:06 +1 16:48:08 technically, we're still voting 16:48:10 +1 16:48:13 latest version can explicitly include pre-releases 16:48:13 +1 16:48:22 +1 16:48:27 whatever is the latest on galaxy, yeah 16:49:28 #agreed goal for `/ansible/devel/` docs is to include the `devel` branch of ansible-core, plus the most recent versions in Galaxy of all included collections for the next ansible package release 16:49:44 woot! 16:49:53 just one warning: this will make the devel build process a lot less stable, since galaxy tends to have random timeouts/network errors (as every antsibull-build user knows...) 16:49:55 wont ansible-core/devel/ have the devel branch info? 16:49:59 of ansilbe-core? 16:50:06 bcoca: I think it will 16:50:06 #action - turn nightly build to core docs once PR is merged into devel 16:50:39 bcoca: yes, it will 16:50:46 should we move onto the docs folder within collections? 16:51:04 sure 16:51:10 #topic docs folder in collections 16:51:31 soo its going to duplicate the docs? 16:51:51 ^ fyi, having duplicate content normally incurrs in search engine penalties 16:51:54 bcoca: yes 16:51:56 bcoca - yes. lots of duplication here 16:52:12 we will have canonical urls to help with that and working w/ our internal SEO expert 16:52:43 the only reason we are publishing core docs separately is that the versions don't match 16:52:45 acozine - do you have an update on the folder proposal etc? 16:53:22 IIRC we talked last week about using a sub-folder for "things we will publish to docs.ansible.com" 16:53:43 was there a link for the proposal? I forget. doh. 16:54:03 because some developers want to use markdown instead of rst for their collection docs 16:54:18 non-plugin collections docs, I mean 16:54:36 yeah if feels like a clean separation - put stuff in this subfolder and we will bring it up to docs.ansible.com. 16:55:37 what are our next steps? 16:55:38 * acozine apparently didn't post last week's minutes 16:55:43 what about galaxy/ah ? thought we had plans to also display extended docs on those sites 16:55:55 gah! sorry. I'll go back and dig them up after this (meeting minutes) 16:56:13 bcoca: galaxy doesn't look like it will implement ANY new feature anytime soon 16:56:31 #action samccann - post last week's meeting minutes on the dawgs agenda 16:56:54 bcoca - that is part of an internal discussion we need to have, yes. 16:57:12 but they can also start pulling thedocs from this new subfolder. 16:57:29 bcoca: displaying docs on galaxy would be lovely, but I don't think it's on the short-term roadmap 16:58:07 fwiw the internal network team is happy to be the first test case for this. 16:58:09 thought it was on Ah map, i know galaxy/ng trails on that 16:58:29 bcoca - we will doublecheck on that, thanks for the reminder 16:58:42 bcoca: galaxy is not using galaxy-ng, and doesn't look like it will in the near future, so there won't be docs on galaxy 16:58:45 #action samccann acozine - find out where the /docs folder is in AH roadmap etc 16:59:18 time-check - at the 1 hr mark 16:59:26 AH renders all markdown files in docs folder already. But last time I checked, there were no plans on supporting rST. 16:59:49 sorry, I don't think we can make progress on this today beyond samccann's action item 16:59:52 tadeboro - if you stumble on an example of that, can you let us know? 16:59:52 felixfontein: there was plan to unify the codebases, as much as 'galaxy' itself wont be updated the point of ng was to migrate to unified base 17:00:25 bcoca: since galaxy-ng has no support for roles, it doesn't look like that will happen anytime soon 17:00:27 acozine - that's fine, at least we know what to do next (get the idea circulated, find out who has other plans for the folder etc) 17:00:34 yeah 17:00:42 samccann: Example of what? (Kids running around, focus bad ;)) 17:00:49 can we run a few minutes over today? 17:00:50 (also the amount of public communication on what will happen to roles on galaxy is essentially zero) 17:01:09 #chair 17:01:09 Current chairs: abadger1999 acozine bcoca briantist dericcrago dmsimard felixfontein lmodemal samccann sommersoft 17:01:11 tadeboro - if you find an AH example collection that is displaying docs on AH from the /docs folder, that would be great to see 17:01:27 iirc it supports README.md but not much more 17:01:29 if you need to head out, feel free . . . we're going to run a bit over the hour today 17:01:55 samccann: Sure. I will post a few screengrabs of you tell me where. 17:02:01 yeah I've seen readme.md. I knew they were 'thinking' about accepting any md in the /docs folder, but haven't seen it in action (haven't looked either) 17:02:20 tadeboro - you can post here or a private irc with the collection name. I can go look from there, thanks! 17:02:38 acozine - I can stay longer if we have another topic to move to etc 17:02:50 #topic PR/issue labels: https://github.com/ansible/ansibullbot/pull/1505 17:02:51 https://github.com/ansible/ansibullbot/pull/1505 | open, created 2021-02-06T14:45:20Z by sommersoft: [WIP] Classify/Label PRs That Are Docs Only 17:03:10 samccann: i still think just saying 'generate the html' and use whatever you want for source woudl be the simplest int he end (then styles/iframes become the fun part) 17:04:16 sommersoft opened a PR for the bot to apply the `docs` labels more consistently 17:04:27 oo fun! 17:05:30 indeed! :) 17:05:55 we currently have 3 labels: `docs`, `docsite`, and `docsite_pr`, and they are applied inconsistently at best 17:06:16 one of the pressing questions is highlighted by acozine's comment: what is the appropriate label to have ansibullbot apply. https://github.com/ansible/ansibullbot/pull/1505#issuecomment-776257938 17:06:41 yup, what labels do we want? and what should they mean? 17:06:55 is it useful to have one that means "the person who opened this used `Edit on GitHub`"? 17:07:23 is it useful to have one that means "this PR affects only files in the `docs/docsite/rst` folder"? 17:07:42 do we need a third one that means "this PR has both code and documentation"? 17:07:55 are there other labels that would be useful? 17:08:18 i like the 'edit on github' having its own label - those should be quick merges and helps us to understand how frequently people use that feature 17:08:46 and one that is `docs_only`. Those are the ones we as the writers should be able to keep on top of and merge. 17:09:00 theoretically we have that - `docsite_pr` is supposed to mean "opened with `Edit on GitHub`" but I don't know if it's applied consistently (or at all) 17:09:44 we should be able to test that by editing and seeing what labels the PR gets 17:10:14 true 17:10:36 for historical reasons, I don't want to get rid of the `docs` label 17:10:49 we've used it to track PR numbers for many years 17:10:51 we leave that for what is basically `docs` and code 17:11:08 i haven't dug into that one much; it's a bit outside of what i've been doing. should be easy enough to verify from a historical and programmatic standpoint 17:11:10 ah. So perhaps a docs only pr has both labels then? 17:11:18 yeah 17:11:50 ok thinking aloud here 17:12:04 so `docs` is anything to do with docs, and a subset of those gets `docsite` (ONLY docs), and `docsite_pr` (from Edit on GitHub) 17:12:22 so then a PR with `docs` but neither of the others is code-plus-docs 17:12:25 if the only reason to keep `docs` for all doc prs is historical - we continue with the stats by using a combination? 17:12:46 as in the same stats are the combination of all three labels going forward? 17:13:39 I'm guessing it will be easier to code "everything that touches /docs/ gets the `docs` label, stuff that meets these other criteria get other labels added" 17:13:48 i personally like the feeling of each label means something different... but .. ya know.. not the hill I'm gonna die on or anything :-) 17:13:58 note: current application of `docs` also involves the issue/pr templates. 17:14:01 ..nor am I doing any of the coding 17:14:18 sommersoft: good point 17:14:41 sommersoft ah so maybe the easier approach is to leave/let the `docs` label continue to do what it's doing, and add logic to detect 'oh by the way this is ONLY docs so add this new label? 17:15:44 * acozine looks again at PR 17:15:53 yeah. mkrizek recommended a `docs_only` label. i agree with that, unless one of the current labels' description is updated to mean the same. 17:15:57 we can use `docs_only` instead of `docsite` 17:16:13 yes, I think `docs_only` is much more readable 17:16:16 yeah if docsite has no meaning today, let's replace it with docs_only 17:16:27 +1 17:16:31 samccann: Docs rendered from https://github.com/cyberark/ansible-security-automation-collection/tree/master/docs https://usercontent.irccloud-cdn.com/file/wnCpNFvI/ah-cyberark-pas.png 17:16:50 tadeboro++ thanks! 17:17:44 #info - example of collection that has docs in docs folder - https://github.com/cyberark/ansible-security-automation-collection/tree/master/docs - this displays today on Automation Hub 17:18:14 I can update the labels themselves - remove `docsite`and add `docs_only`, or update the former to be the latter 17:18:48 sommersoft: I'll add a comment to the PR when that's done 17:19:02 removing `docsite` will likely upset ansibullbot without addressing how it interacts with that label. 17:19:04 cool 17:19:19 how it currently* 17:19:24 oh heh didn't mean cool about an angry ansibullbot 17:19:32 :) 17:19:45 angry bots are def not cool. haha 17:19:47 so add `docs_only` then wait until the PR is merged for next steps? 17:19:58 heh, do not make the bot angry 17:20:36 #agreed acozine to add a `docs_only` label 17:20:46 acozine: seems like a good approach. i'm on board to address deprecating `docsite` on the bot end. though, will likely drive discussions outside of my purview. 17:21:04 yeah, i don't know what happens to old PRs with a label that doesn't exist any more 17:21:13 I'll do some digging and see if I can find anything 17:21:26 maybe the old label lives on, with a deprecation in its description 17:21:52 anything else on labels or the bot? 17:22:04 (we're at 20 minutes past our usual time) 17:22:15 all right, thanks sommersoft 17:22:19 #topic open floor 17:22:39 all questions, comments, suggestions, ideas, critiques welcome now 17:22:49 if you have a PR or issue you'd like reviewed 17:23:12 or need information about contributing to the docs 17:23:18 or anything else you'd like to bring up 17:23:24 the floor is yours! 17:23:44 I have just a small PR that should be an easy merge :) https://github.com/ansible/ansible/pull/73615 17:23:45 https://github.com/ansible/ansible/pull/73615 | open, created 2021-02-15T17:09:20Z by dmsimard: Update 2.10 porting guide to include module index [affects_2.11,core_review,docs,needs_triage,small_patch,support:core] 17:24:19 Looks good, thanks dmsimard 17:25:00 merged! 17:25:51 anything else on folks' minds? 17:26:21 going once . . . 17:26:41 going twice . . . 17:27:10 thanks abadger1999 bcoca briantist dericcrago dmsimard felixfontein lmodemal samccann sommersoft! 17:27:15 see you next week 17:27:18 #endmeeting