14:32:06 #startmeeting Docs Working Group aka DaWGs 14:32:06 Meeting started Tue Nov 17 14:32:06 2020 UTC. 14:32:06 This meeting is logged and archived in a public location. 14:32:06 The chair is acozine. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:32:06 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:32:06 The meeting name has been set to 'docs_working_group_aka_dawgs' 14:32:12 hi :) 14:32:14 #topic opening chatter 14:32:19 hi felixfontein! 14:32:20 I was wondering a bit what happened to the announcement :) 14:32:23 o/ 14:32:27 #chair lmodemal samccann felixfontein 14:32:27 Current chairs: acozine felixfontein lmodemal samccann 14:32:34 * tadeboro misses the DINGs ;) 14:32:42 we haven't adapted to the time change quite yet 14:32:47 heh. Tues. is grocery day so I don't get logged in now until right before the meeting 14:32:48 \o 14:33:01 tadeboro: just for you: DING DING DING 14:33:07 \o/ 14:33:09 #chair tadeboro dmsimard 14:33:09 Current chairs: acozine dmsimard felixfontein lmodemal samccann tadeboro 14:33:27 who else is around? 14:34:41 gundalow: alongchamps andersson007_ briantist cyberpear madonius mrproper persysted tremble I'm pinging you because you've joined the conversation before 14:34:47 talking docs today? 14:34:52 o/ 14:35:00 * dericcrago waves 14:35:14 * tremble lurks but doesn't need to become furniture 14:35:17 I'm only sort of here... in several meetings at once 14:35:18 I am not around today unfortunately, double-booked for 10 EST 14:35:26 for anyone who is watching this chat and thinking, "but they didn't ping me" . . . please join in any time! 14:35:54 hi and welcome cyberpear dericcrago tremble 14:35:57 alongchamps: bummer 14:36:02 #chair dericcrago 14:36:02 Current chairs: acozine dericcrago dmsimard felixfontein lmodemal samccann tadeboro 14:36:12 cyberpear: you want to be furniture? 14:36:36 no need, thanks! 14:36:49 .chair cyberpear 14:36:51 cyberpear is seated in a chair with a nice view of a placid lake, unsuspecting that another chair is about to be slammed into them. 14:37:30 heh 14:37:48 omgosh!!! 14:37:55 it's a COVID meeting - NO CHAIR-SLAMMING! 14:38:33 agenda ? :) 14:38:38 * gundalow waves 14:38:43 o/ 14:38:44 #chair gundalow 14:38:44 Current chairs: acozine dericcrago dmsimard felixfontein gundalow lmodemal samccann tadeboro 14:38:49 #chair gwmngilfen 14:38:49 Current chairs: acozine dericcrago dmsimard felixfontein gundalow gwmngilfen lmodemal samccann tadeboro 14:38:51 hey gundalow! 14:38:54 * gundalow sits 14:38:57 agenda begins with https://github.com/ansible/community/issues/521#issuecomment-724802607 14:38:59 !! 14:39:35 and i have a late-breaking addition as well ;-) 14:39:47 maybe we can get through a few items quickly? 14:40:01 let's try that! 14:40:02 shoot... I forgot to followup with abadger as someone who could attempt taking rst files out of the tarballs and estimate how hard/easy it is 14:40:22 hmmm, maybe roll that one over to next week, then? 14:40:36 I'll put them in the minutes though 14:40:43 #topic removing rst files from tarballs 14:40:50 #action samccann to followup with abadger on RST files out of the tarballs 14:40:59 at what point does the "source tarball" no longer represent the actual source code if we're not shipping all the things there? 14:41:28 hmm... interesting point 14:41:34 cyberpear: that's one of the questions we have to answer - is there a legal consequence to breaking "the source tarball" into a couple of files? 14:41:44 so for Ansible the package - I 'think' we already take some stuff out? 14:41:45 with my distribution packager hat on, it's typical to have separate packages for docs and tests 14:41:48 we would still provide the docs, it would just be a separate package 14:42:09 dmsimard: ah, good to know 14:42:59 #action samccann to again bug abadger to see if we already take anything out of the Ansible package that's part of the collections source 14:43:00 but the question is moot until we have a way to pull the docs out (a way we can implement in a reasonable timeframe) 14:43:02 cyberpear: Ansible is already a bit special since it includes collections from the galaxy, and there is no guarantee what those packages do (not) contain. 14:43:29 so for example in a fedora or rhel package you'd have python3-foo with the actual python code, foo-tests for unit/integration tests and then foo-docs 14:43:33 acozine, It would likely depend on the license that the code's released under 14:43:38 the collections make it complicated, yes. For -base, it's probably not too big a deal since the git repo is public, but I think generally the tarball should be an editable body of code if someone wanted to base a patch on it. 14:43:49 not all packages are that way, ultimately it's up to the packager 14:44:30 acozine, But it's not that uncommon to (for example) not package up test suites. 14:44:57 yeah, the conversation about licensing is complicated, and way outside of my area of expertise 14:45:03 #info some package tarballs contain everything - e.g. should be an editable body of code if someone wanted to base a patch on it 14:45:41 #info need to consider that as well as licensing/legal implications of removing docs etc from ansible tarballs 14:45:46 getting rid of the tests/ directories in the collections would save a lot of space. and removing docs/ as well (though a lot less than tests/). 14:46:06 but again, unless we can actually implement this change, we don't need to debate the legal side of things 14:46:27 can't we just ship a wheel and remove the tests/docs/whatever from there, but keep it in the source tarball? 14:46:40 (I know we don't ship a wheel today) 14:46:47 felixfontein: I wonder not just about the size difference but the install performance too -- even the latest 2.10 still installs far slower than 2.9 14:47:13 dmsimard: I think install performance is correlated to package size 14:47:38 #info size of tarball may also be slowing down installation times... 14:47:46 after removing all the coverage logs in the last release, package size reduced a lot and install got a lot faster 14:47:47 is it size or number of files? 14:48:00 ok I dunno what a wheel is, but for those who do - is this something we should bring to core/community to discuss? 14:48:04 dericcrago: little bit of column A and a little bit of column B ? 14:48:10 no idea. tests usually are both big and many files, so it does not matter too much what's the exact reason 14:48:23 samccann: wheel is more or less a pre-compiled package 14:48:25 either way, docs would contribute a lot (and so would tests) 14:48:58 might make sense to bring the wheel discussion t o core and/or community 14:48:59 acozine: I think docs are a lot less than tests, like 10% vs. 40%-50% of the size 14:49:13 felixfontein: ah, good to know 14:50:11 ansible can't produce wheels yet: https://github.com/ansible/ansible/issues/71992#issuecomment-700739135 14:50:41 dmsimard: that's ansible-base/ansible-core, not ansible 14:50:44 but if we're stripping things out like tests/docs, I think it should be done at the wheel level (which we don't ship/create yet)... if we're making a separate PyPI package for the tests or docs, that might be different, but we already saw the pain that comes from splitting PyPI packages w/ the base/ACD split 14:51:10 felixfontein: thank you for the distinction, that is what I meant, yes 14:51:11 dmsimard: though, I think ansible also has that code thanks to pip and the 2.9 -> 2.10 change (and soon 2.10 -> 2.11) 14:51:31 it'd be nice if he had more details in that comment... currently the setup.py checks that no older version of ansible is installed 14:52:10 cyberpear: the dynamic code (I know about) makes sure that installing ansible-base does not wreck ansible 2.9, and vice versa 14:52:15 Did we get legal sign off yet? 14:52:43 so removing the docs files is a complicated question, and one that is linked to many other concerns - I think we should explore the possibilities for implementing it (how long would it take, etc.) and then bring in the larger questions (legal, packaging, etc.) 14:53:51 even if ansible-base can't ship a wheel, ansible ACD probably can ship a wheel, unless we have setup.py dynamics there, too 14:54:02 cyberpear: as I said above, it has 14:54:14 sorry, the complicated terminology strikes again 14:54:24 I see "ansible" and still thing "ansible-base" 14:54:26 *think 14:54:29 so wheel solution isn't an option? 14:54:35 for either :-) 14:55:22 #info cannot use wheel option because ansible-core and thus Ansible have setup.py dynamics. See https://github.com/ansible/ansible/issues/71992#issuecomment-700739135 14:56:43 okay, I'm going to go rogue on our agenda 14:56:54 and introduce a totally new topic 14:57:07 #topic docs user survey 14:57:12 heh 14:57:52 :) 14:58:11 * gwmngilfen is totally not being a meerkat right now 14:58:26 2+ years ago I said we'd do a survey of docs users, and we're finally almost ready 14:59:26 this is part of the conversation about re-organizing documentation around personas and levels of experience 15:00:07 so things like "I'm a network admin" or "I'm just starting with Ansible because isn't working for my team" 15:00:48 of course I'd like to ask ALL THE QUESTIONS, but I know people won't actually fill in a survey of 150 questions . . . 15:01:29 so I've got a draft and am looking for ideas about what are the most important/helpful things to ask 15:02:02 * acozine realizes that her draft is invisible to the outside world 15:02:05 drat 15:02:09 hang on 15:03:49 * samccann hums hold music 15:05:05 okay, this looks awful, but it's a start: https://hackmd.io/JemYBo_8QbqqO9cULo3rJQ 15:05:30 can folks see it? 15:05:38 I can see it 15:06:24 me too 15:06:34 whoever is editing to make it look nice, thank you! 15:06:45 lol a secret cleaning crew! 15:06:59 I thought that was you acozine lol 15:07:08 that's me 15:07:11 just adding bullet points :p 15:07:18 thanks dmsimard, it needed it 15:07:18 on the second question: how about a 'looking up plugin options (reference)' option? 15:07:22 good job dmsimard! 15:07:37 that's what I'm doing a lot with the docs, and I guess other people are too 15:07:45 dmsimard++ 15:07:48 gwmngilfen: Karma for dmsimard changed to 2 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:08:32 felixfontein: good idea, added 15:08:48 #info draft docs survey for review - https://hackmd.io/JemYBo_8QbqqO9cULo3rJQ 15:09:22 What's the objective of `The last time you used the Ansible documentation, what was your goal?`? 15:09:39 for the first question I would defer to gwmngilfen but would a scale from 1 to 5 (or 1 to 10) work better ? 15:10:00 its the same thing 15:10:09 gundalow: you mean, what's the difference between `the last time` and `usually`? or what is the objective of `what was your goal` in general? 15:10:21 you can use numbers if you want, but the fact remains that you are measuring something non-linear :) 15:10:45 the employer section could use the option "my employer is not connected to redhat, also not as a customer, but I use ansible at work" 15:11:03 felixfontein: +1 15:11:18 +1 but, perhaps a bit shorter :P 15:11:29 yeah, sure :p 15:11:33 acozine: How will you use the answers to that question 15:11:47 felixfontein: I tried to roll the two answers into one, apparently not very successfully 15:12:04 maybe rephrase the first option 15:12:14 gundalow: it's the experience-based equivalent of "what kind of docs would you like to see more of?" 15:12:22 +1 to gundalow's question, I hadn't spotted that they were essentially the same Q 15:12:55 yeah, I think those two could be rolled into one, timeframe isn't important 15:13:10 but the question itself is to find out what type of docs will be most useful 15:13:20 keep the "usually" then 15:13:25 at least, that's what I was thinking about/hoping for 15:14:14 Should `Q3` be "Have you ever used the docs to ... (tick all that apply)". Which would help us identify which areas people use the most/least? 15:14:43 Or do we need a more direct question along the lines of "areas of documentation" vs "how well I rate them" 15:14:59 how is that different from using the adobe analytics to tell us what they use most/least? 15:15:09 gundalow: I think we might get a lot of "all of the above" 15:15:11 that could be quite a long list though, right? 15:15:48 perhaps a question like 'tell us the top 3 areas of docs you want to see improvement on" or something? 15:16:04 samccann: combing this with the AA stuff is a good point 15:16:32 but if you want to cross-reference this with, say, job role, then we have to ask it here 15:16:45 +1 samccann 15:17:03 also, we could then use the AA to weight the survey, if we wanted to get really fancy 15:17:18 samccann: that's a good question - I was hoping to tease out intent, which analytics can't give us 15:18:40 samccann: for "top 3 areas for improvement", would that be write-in? or pick-3 from a list? 15:19:10 i was thinking write in. it might give us stuff all over the map though. But I'm not sure I could pick which areas to add to a list 15:19:23 i the list is large, then write-in is probably better 15:19:26 *if 15:19:38 i can deal with it :) 15:20:49 write in gives them the option to be specific. 15:22:26 all right, thanks everybody for the ideas and feedback, I'll keep working on this - if you come up with other ideas, bring them to the chat any time 15:23:10 thanks for chugging through and creating the draft! 15:23:18 It's looking good, thanks for doing it 15:23:29 indeed! 15:24:11 I hope we can get some useful, actionable information out of it . . . 15:24:49 we've got a bunch of follow-up items on the agenda 15:25:05 #topic follow up on long-running items 15:26:29 these include: collection /docs folder uses, filter/test plugin docs, role argspec, Felixfontein's sphinx extension for module docs, bitflip process for Ansible release, redirect policy be post 2.10, and the new documentation fields proposal 15:26:38 the sphinx extension is now part of antsibull (not sure whether it's in a release yet though) 15:26:52 #info the sphinx extension is now part of antsibull 15:27:00 \o/ 15:27:35 besides that, nothing from my side 15:27:41 ohai! what would you like to know about role argspec? 15:28:02 #chair Shrews 15:28:02 Current chairs: Shrews acozine dericcrago dmsimard felixfontein gundalow gwmngilfen lmodemal samccann tadeboro 15:28:36 Shrews: do we have one? 15:28:50 and if so, is it documented already? 15:29:49 we are working towards the feature for 2.11. what we currently have of that feature is a PR to ansible-doc (https://github.com/ansible/ansible/pull/72120) to output the spec docs. We still need changes to core to actually _use_ the spec, but that is being worked on as we speak. 15:30:29 I think I'll merge 72120 today, but it might need changes as we go. 15:31:23 sounds like progress! 15:31:27 thanks Shrews 15:31:29 so still a lot of under development 15:31:41 But the spec itself is not yet publicly documented. We'll add that "real soon now" 15:31:42 Shrews: are there plans to have some validation of role argspecs in ansible-test? 15:31:56 felixfontein: not currently 15:33:07 shrews: - so does that mean the role docs will be generated from the role argspec? 15:33:14 or am I just dreamin :-) 15:33:44 @samccann well, yes, but only in text format (or optional json). just like the output currently supported for plugins 15:34:14 there is an example in that PR description 15:34:45 #info roleargspec PR - https://github.com/ansible/ansible/pull/72120 15:35:54 Shrews: do role args support deprecation? 15:36:19 Shrews: myself (or sivel) can explain how to write schema validation for argspec. I'd like to see that in before this is released, Happy to help 15:36:47 felixfontein: not in the current design. 15:37:16 gundalow: we'll be using the AnsibleModule validation code for this. It's currently being extracted into a common utility 15:37:17 the test output looks like we could send it through the docs pipeline, though we obviously can't publish docs for every role out there 15:37:51 https://github.com/ansible/ansible/pull/72120/files#diff-96c4675726c535de24f519c4d5f49737a9fb0d184e166786e02b7033ae8ca0b0 15:38:10 Shrews: ace 15:38:15 acozine: the docs pipeline would need to learn some specificalities of roles (like multiple entry-points), but it is doable :) 15:38:31 it's not as big of a stretch as I'd feared 15:39:06 Shrews: are there plans for a top-level description, besides having one per entry-point? 15:39:19 so perhaps we would bring role docs in for the collections in Ansible that have them? 15:39:34 does anyone know the roadmap for roles docs in AH/Galaxy? 15:39:40 felixfontein: no. descriptions are per entry point right now 15:40:14 Shrews: it would be nice to be able to document something top-level. I guess right now it's still possible to add that to the design 15:40:31 Shrews: (I'm also thinking of version_added for the changelog generator :) ) 15:40:47 yes, the overall "what does this role do / what is this role for" would be a good addition 15:41:09 samccann: yes, I think we could bring role docs in for certain collections . . . 15:41:10 Shrews: it would be annoying if `description`, `author`, `short_description`, `version_added`, ... would collide with entrypoints 15:41:32 samccann: no idea on the AH/Galaxy roadmap 15:43:10 Shrews: it could of course go into a separate file, but why load two files when one is enough? (also ansible-doc probably would have to load both then, because that's also stuff that should be shown by it) 15:44:56 sounds like the role argspec discussion will continue 15:44:59 If role argspec could contain roughly the things your usual README.md contains (short descritpion, variables and their purpose) that would be great. 15:45:30 (sorry, 2 concurrent meetings)... 15:45:34 tadeboro: agreed 15:45:36 Just something to clarify here, we're not shooting for the moon in the 2.11 release for argspec 15:45:50 it'll be MVP, and may not solve every problem everyone wants to see solved 15:45:51 sivel: you mean we can't have everything immediately??? 15:45:51 ^ yes that ( i was just typing similar ) 15:45:58 sivel: true, but if entrypoints stay at top level, it is next to impossible to fix that later 15:46:20 just saying, this meeting shouldn't devolve into a wish list for argspec 15:46:23 we can design the MVP with later enhancements in mind 15:46:27 sivel: gotcha 15:46:38 s/argspec/role argspec/ 15:46:40 :) 15:47:43 we've already `info`'d the PR for role argspec, right? 15:47:49 so folks can put comments there 15:48:03 yep 15:48:13 samccann: thanks! 15:48:24 all right, any other updates on our long-running topics? 15:48:29 sivel: Maybe completely ignoring the documentation needs during the design statge is not the best thing? ;) 15:49:25 I'm not against taking feedback, just want to make sure people understand the scope, and not to get too deep into the weeds with 100 different feature ideas to extend the MVP 15:50:32 sivel: thanks 15:51:04 sivel: Shrews leaving room for role-level documentation (as opposed to entry-point-level documentation) in the design would be really helpful 15:51:57 we can't implement it all now, but if we preserve the possibility of implementing it later without rewriting the spec entirely, that would be good 15:52:13 +1 15:52:20 +1 15:52:26 noted. we could always add a 'role_summary' special entrypoint or something for that. nothing about the current design prevents adding it later 15:52:40 I added the point about non-top-level entrypoints to the PR 15:52:57 Shrews: it prevents anyone from calling their entrypoint `role_summary` :) 15:53:27 heh 15:54:21 felixfontein: Like having a `"_comment"` keys in JSON you mean? 15:55:03 tadeboro: yep. that's just a terribly ugly hack that can sooner or later bite you 15:55:29 having a special-case entry point would work, but it's not the clearest solution . . . Future Me feels a bit squirrely about it 15:55:34 tadeboro: I've spent a lot of time in the last 7 years on $job on working around such limitations 15:56:50 okay, we've covered the sphinx extension and the role argspec 15:56:59 any other updates on our long-running items? 15:57:48 long-running items include: collection /docs folder uses, filter/test plugin docs, bitflip process for Ansible release, redirect policy be post 2.10, and the new documentation fields proposal 15:58:14 if not, we're already 30 minutes over our stated time 15:58:39 well, we're over time whether or not folks have other updates ;-) 15:58:39 No updates from my side 15:58:43 I have something for a quick open floor 15:58:45 collection /docs folder seems to be an item we have to resolve with The Powers That Be as there are conflicting uses/wishes for it 15:58:51 samccann: true 15:58:57 #topic open floor 15:59:28 anyone and everyone is welcome to bring up topics now! 15:59:46 since we're moving stuff out from community.general and community.network, I'd like some DaWGs feedback on changelog fragments for (a) announcing a new location for content (https://github.com/ansible-collections/community.general/pull/1303) and (b) removing the old content (https://github.com/ansible-collections/community.general/pull/1304) 16:00:18 I created two WIP PRs for the docker content in community.general, with the intention of them being kind of templates (at least for the changelog fragments) for all the similar PRs that need to be created 16:00:51 #info looking for docs feedback on c.g changes - (a) announcing a new location for content (https://github.com/ansible-collections/community.general/pull/1303) and (b) removing the old content (https://github.com/ansible-collections/community.general/pull/1304) 16:01:03 ah, yes, "content moved" PRs may be rather common for the next few months/years 16:02:04 yep. and if we have a good template for the changelog fragments, we avoid repeating the same mistakes every time ;) 16:02:22 +1 16:02:27 Where is the fun in that? ;) 16:02:36 heh 16:02:52 for creating a template and dropping in , , and 16:03:14 tadeboro: this is a new meaning of the word "fun" with which I am not familiar ;) 16:04:58 felixfontein: my main comment is that we could rewrite the sections to "speak to the user" - so instead of "users who X should" we say "If you do X, you should" 16:05:33 "If you run `ansible-core` and install collections manually, ." 16:05:58 I can turn that thought into suggestions on the PR 16:06:56 thanks for pulling this together! 16:07:04 acozine: sounds like a good idea. I'll rewrite it later. 16:08:40 time for weekly reminders 16:09:22 #info anyone can add an agenda item for this meeting by putting a comment on https://github.com/ansible/community/issues/521 16:09:51 I have on open floor item... 16:09:58 one even...sigh. 16:10:03 samccann: excellent! 16:10:34 if folks could take a look at the hack I did for a set of docs focusing on Ansible the package as a set of collections - http://docs.testing.ansible.com/ansible/devel/ 16:11:07 ooh, nice! 16:11:15 +1 acozine 16:11:24 it's a total hack so focus more on the left-hand nav and the fact that all the features of Ansible are actually `ansible-core` ... so the proposal would rename most of what we have today on docs.ansible.com/ansible as 'Ansible Core Documentation' 16:11:48 y'all can add comments here later as you get a chance to take a look and let me know what you think. 16:12:48 this is a nice transition to the second reminder, which is . . . 16:13:14 #info we currently have an additional meeting on Thursdays, starting one hour later than the regular DaWGs meeting, to focus on splitting out the `ansible-core` docs from the `Ansible` (package) docs 16:14:39 #info the split is necessary because next year we will have two things with version `2.11` - an `ansible` 2.11 package, and an `ansible-core` 2.11 version 16:15:29 anything else for open floor? 16:15:59 going once . . . 16:16:05 going twice . . . 16:16:54 all right, thanks everybody! 16:17:04 thanks everyone! 16:17:08 #endmeeting