15:01:12 #startmeeting Documentation Working Group aka DaWGs 15:01:12 Meeting started Tue Aug 31 15:01:12 2021 UTC. 15:01:12 This meeting is logged and archived in a public location. 15:01:12 The chair is acozine. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:12 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:12 The meeting name has been set to 'documentation_working_group_aka_dawgs' 15:01:12 wooo hooo!! 15:01:18 #topic opening chatter 15:01:22 #chair samccann 15:01:22 Current chairs: acozine samccann 15:01:28 o/ 15:01:30 who else is around? 15:01:33 #chair tadeboro 15:01:33 Current chairs: acozine samccann tadeboro 15:01:34 oh... we seldom use idea... must... experiment...!! 15:01:44 heh 15:01:52 I'd never even noticed it! 15:01:56 #idea ... what does the idea hashtag do in the meeting minutes??? 15:02:01 there... we can see later 15:02:45 abadger1999: andersson007_ dericcrago dmsimard gundalow ariordan briantist cyberpear felixfontein mrproper[m] Xaroth you folks chatting docs today? 15:02:53 lmodemal[m] has a conflict, I know 15:03:02 o/ 15:03:12 Yes 15:03:16 Yes 15:03:22 official agenda begins with https://github.com/ansible/community/issues/579#issuecomment-904852018 15:03:29 #chair briantist gundalow ariordan 15:03:29 Current chairs: acozine ariordan briantist gundalow samccann tadeboro 15:03:31 👋 15:03:35 #chair gwmngilfen-work 15:03:35 Current chairs: acozine ariordan briantist gundalow gwmngilfen-work samccann tadeboro 15:03:40 I'm around-ish 15:03:42 ooh, fancy emoji! 15:03:48 Xaroth: cool, do you want to be furniture? 15:03:49 need to have a resignation talk first though. 15:03:51 o/ 15:03:56 I'm always furniture. 15:03:57 #chair felixfontein 15:03:57 Current chairs: acozine ariordan briantist felixfontein gundalow gwmngilfen-work samccann tadeboro 15:04:00 heh 15:04:04 #chair Xaroth 15:04:04 Current chairs: Xaroth acozine ariordan briantist felixfontein gundalow gwmngilfen-work samccann tadeboro 15:04:43 as a reminder, I will be on vacation for the next two DaWGs meetings 15:05:02 enjoy your vacation! 15:05:09 when I return on Sept 21 I will be on the community side 15:05:21 thanks! 15:05:53 okay, our first agenda item may be a bit painful 15:05:59 #topic action item review 15:06:06 heh 15:06:37 recent action items: 15:07:03 Add `deciding how attributes should be displayed` to the agenda 15:07:05 done 15:07:41 Summarize in a HackMD the main questions, challenges, and solutions related to displaying attributes 15:07:54 here's how far I got: https://hackmd.io/Fy9kYQXrTHSE4ceLZph9ew 15:08:32 Open an issue on the ansible sphinx theme asking for expand/collapse 15:08:48 the box is checked . . . samccann do you have a link to hte issue? 15:09:14 I added more on the attributes to this hackmd - https://hackmd.io/R71WLQjPQOa-Ze0Cg97V7A 15:09:20 and linked to it from the issue 15:09:22 for expand/collapse, webknjaz listed some plugins: https://github.com/ansible-community/antsibull/pull/303#issuecomment-905391511 15:09:59 and for attributes, there's a compatibility PR for stable-2.11 (which can be backported further once merged): https://github.com/ansible/ansible/pull/75563 15:10:12 ooh, a PR and even some existing plugins! that's awesome 15:10:32 someone has to try how the existing plugins look with the theme 15:10:37 #info details on attributes - https://hackmd.io/R71WLQjPQOa-Ze0Cg97V7A and PR - https://github.com/ansible/ansible/pull/75563 15:11:05 #action samccann to test out https://github.com/ansible/ansible/pull/75563 to see how it looks 15:11:40 #info expand/collapse on the ansible theme has some suggestions at https://github.com/ansible-community/antsibull/pull/303#issuecomment-905391511 15:11:40 https://sphinx-design.readthedocs.io/en/furo-theme/dropdowns.html looks pretty nice; https://sphinx-toolbox.readthedocs.io/en/stable/extensions/collapse.html#directive-collapse would need some CSS 15:12:02 (if it should look different than a plain
) 15:12:40 I would vote for the one that doesn't require additional CCS - maintaining CCS gives me nightmares 15:12:45 :+1: 15:13:08 assuming it doesn't look like shit with our theme (which I don't think it will, but someone should try it out first) 15:13:28 yeah 15:13:58 what would it take to get a branch with that work that we could publish to the test site? 15:14:13 I think not much 15:14:33 basically create a branch, mention the plugin in requirements.txt and sphinx config, and use the directive somewhere 15:14:49 yeah what were we considering using the directive on? 15:14:56 looooooonnnnngggg pages 15:15:07 * acozine tries to remember a specific example 15:15:11 the filters page is huge 15:15:14 so not on like module docs, but some of the rst pages with long examples? 15:15:35 that's my recollection 15:15:47 * acozine looks for the minutes 15:15:55 heh yeah looking there as well 15:16:17 yeah, we were talking about creating the new "patternbook" of examples 15:16:31 and thinking it would be a very, very long page 15:16:55 ah ok yeah for the future examples pages. 15:17:02 specifically we were talking about expand/collapse for code examples 15:18:19 ok I can give these existing extensions a try and see what they look like 15:18:27 excellent 15:18:58 #action samccann to test out the expand/collapse extensions listed in https://github.com/ansible-community/antsibull/pull/303#issuecomment-905391511 to see how they display 15:19:37 we also had an action item for "create a topic issue for the community WG on community-contributed examples" 15:20:14 it's checked, samccann do you have a link handy? 15:20:17 yeah that was done and discussed... lemme dig up the issue 15:20:41 https://github.com/ansible-community/community-topics/issues/39 15:20:45 https://github.com/ansible-community/community-topics/issues/39#issuecomment-906133762 15:20:53 heh ok felixfontein's is better. 15:21:37 something that comes to mind - what kinds of examples are we looking for? 15:21:56 first-round request is for templating examples 15:22:21 preferable "self-contained" ones - so you can see the data inputs, the expressions, and the outputs 15:22:27 and see how it all fits together 15:23:10 that one example was a short playbook with a `vars:` section for the data, a task, and a `debug` statement 15:23:18 below that, the output 15:23:52 brb 15:24:15 woopsie, it's almost half past the hour 15:24:49 okay, last check-in on action items: "create a PR to update the Debian install instructions" is done - PR is https://github.com/ansible/ansible/pull/75571/files 15:25:03 I'll publish it to the testing site quickly, should be able to merge it today 15:25:10 ohhhh 15:25:16 one older one I do have an update on 15:25:24 Sphinx upgrades in CI 15:26:14 #info we were able to update CI to use Sphinx 3.5.4 but Sphinx 4.x generates errors 15:27:05 #info on Sphinx 4.x we get the `1 validation error for ModuleDocSchema\ndoc -> attributes\n extra fields not permitted ` warnings 15:27:53 hmm, how exactly do these warnings look? 15:28:03 those are triggered by the attributes work, I think 15:28:06 hum, is that from Sphinx, or ansible-test's validate modules? 15:28:16 sounds like antsibull 15:28:21 I'm wondering how this results in sphinx warnings 15:28:35 yeah, it's antisbull 15:28:51 because the current schema doesn't include the extra fields 15:29:08 https://www.irccloud.com/pastebin/eIT0SdYX/Sphinx%204%20error%20messages 15:29:31 but that should be a problem for either both sphinx versions, or none 15:29:50 back 15:29:56 the interesting error is the last line 15:31:14 * abadger1999 here. Sorry I'm late 15:31:25 #chair abadger1999 15:31:25 Current chairs: Xaroth abadger1999 acozine ariordan briantist felixfontein gundalow gwmngilfen-work samccann tadeboro 15:31:38 I have not tested it myself, but my guess is that 3.x categorizes it as a warning, not an error? 15:31:56 but 4.x calls it an error 15:31:58 but that's a guess 15:32:03 these warnings are not output by sphinx, but by antsibull before sphinx is run 15:32:08 abadger1999: hi, welcome! 15:32:10 or should be 15:32:16 hmmmm 15:32:22 line 9 is an actual error which (probably) breaks the build 15:32:39 that message comes from sphinx, and is a problem with the antsibull sphinx extension 15:32:44 which version of antsibull is that build using? 15:32:48 Yup, I was confused by it listed as a 4.x issue. Though I don't know the antusbull code that well 15:33:29 the error with testing_formatter also looks strange, but shouldn't be related to the sphinx version either 15:33:57 let me take a look 15:34:05 so should we open an issue on antsibull with the error output and let y'all take a look? 15:35:14 I would expect this to be the bug fixed in https://github.com/ansible-community/antsibull/pull/276, but that's already from May 15:36:09 I got this information from Matt Clay, but I don't have all the details 15:36:18 and i don't see a PR to work from 15:36:34 so maybe he hasn't finished updating the requirements 15:37:03 we should be using the latest version of antsibull, right? 15:37:36 yes, or a new enough version 15:37:53 okay, let me try again, and this time I'll test it locally also 15:38:43 #action acozine to test Sphinx upgrade in CI for the devel branch 15:39:55 and finally, here's the output of dericcrago's PR: http://docs.testing.ansible.com/ansible-core/devel/installation_guide/intro_installation.html#installing-ansible-on-debian 15:40:22 I'm amused by `MATCHING_UBUNTU_CODENAME_HERE` 15:40:34 overall, LGTM 15:40:55 cyb-clock-clone wakes up to say we are 40 min into the meeting and into action item review 15:41:01 heh 15:41:06 oh, I'm way behind 15:41:23 apparently we already merged the change to devel (the Debian install thing) and this is the backport to 2.11 15:41:31 yep 15:41:37 okay, I'll get that merged today 15:41:43 that 15:41:48 actually this is a 'test' issue 15:41:52 PR that is. 15:42:03 to see what it's like if I don't have merge rights for backports 15:42:19 presumably it will be merged on the next release, if not sooner 15:42:26 ahhh, so I shouldn't just merge it, I should let the process proceed 15:42:28 phew 15:42:40 yeah. I haven't pinged anyhone on core to merge it yet 15:42:58 but perhaps we can quickly discuss - how critical is it that backports get merged between releases? 15:42:59 Should samccann have merge rights? 15:43:10 samccann is not sure she wants merge rights 15:43:22 samccann could 'screw up a high mass' as her mum would say... 15:43:24 this is for backports only 15:43:31 she's got devel merge rights 15:43:45 Otherwise i think we wouldn't have anyone on docs who can merge backports 15:43:48 yeah so It's easy to ask for merge rights for backports. I'm just wondering how important it is to the community 15:43:57 and yes, that's the state we are talking about. 15:44:49 my worry is that frankly, with Alicia going, there is a ton of stuff I need to do/keep track of, etc. 15:45:04 (possibly relevant... Now that a different team is releasing ansible-core, I'm not sure who is merging backports there anymore) 15:45:06 So I thought - one less thing to track is minor releases and when the stable branch is frozen to merges. 15:45:28 I had a handful that I noticed weren 15:45:42 weren't merged, I asked core, and within an hour all were merged. 15:45:45 maybe there could be a workflow that samccann approves docs backports, and that team merges them before releases (or also inbetween) if samccann approved them 15:46:03 yeah that's what I was thinking felixfontein. 15:46:10 I don't know if that team touches backports 15:46:19 there are two docs backports open now: https://github.com/ansible/ansible/pulls?q=is%3Apr+is%3Aopen+label%3Adocs+label%3Abackport 15:46:32 Has anyone checked if that's okay of what they do? 15:46:47 I haven't asked core folks yet because I wanted to discuss 15:47:17 in the past I've merged backports of urgent fixes, ones where we really wanted the `latest` docs updated right away 15:47:22 if we feel I must have merge rights, I can ask for that. If we feel it's okay if backports linger for a week (or 3), then I can ask to implement what felixfontein said - 15:47:26 and left lower-priority ones for the RMs to merge 15:47:57 relrod: do you know if spredzy's team will be merging backports to ansible-core like you had been doing? 15:48:08 samccann: usually they can linger, except if there are potential conflicts - but that's also a problem for regular backports 15:48:37 Or is that responsibility going elsewhere? 15:50:26 We have 10 min left to the meeting. I can followup on this later 15:50:44 15:50:55 heh, it's one of those days 15:50:55 #action samccann to discuss docs backport merging with core folks 15:51:15 where we go over action items and then straight to the open floor 15:51:21 #topic open floor 15:51:33 all questions, comments, ideas, suggestions now welcome 15:51:50 from anyone, you don't have to be a #chair (though you are welcome to become one!) 15:52:30 we can talk about attributes if folks have ideas on that 15:53:36 quick one 15:53:42 (i've been in another mtg :P) 15:53:44 go for it gwmngilfen-work 15:53:55 matrix stuffs are going well 15:54:18 is it worth backporting what we have so far in the communication doc (beacuse its one file)? 15:54:32 or should it be all in one piece when we're done? 15:55:00 we can backport it PR by PR 15:55:26 Re: attributes, i was thinking maybe a list or table of the supported (full or partial) attributes on each plugin page (an empty list if no attributes are supported) with either a link to a page that describes all attributes or the definition of what that attribute means as part of the list. 15:56:12 i feel like last time we talked attributes one or more people wanted the definition with the attribute so they don't have to go look it up? 15:56:34 acozine: fair enough 15:56:36 heh, that might be another use case for the expand/collapse feature 15:56:43 i will keep going with my changes 15:56:51 and we can decide when its ready to backport ;) 15:56:57 i will link to devel for now ;) 15:56:59 I'm reluctant to expand/collapse on the module pages 15:57:12 fair enough 15:57:22 they have a very useful toc on the top of each page that gets the reader to the spot they want. I feel like it would annoy people to have to expand from there 15:57:49 gwmngilfen-work: i'm happy to open backports of the first two matrix docs PRs 15:58:00 or to merge them if you open them 15:58:20 samccann: yes, that's true 15:58:21 abadger1999: I think also no support should be mentioned, since there's an important distinction between 'none' and 'not specified'/unknown 15:58:23 One thing I'm not sure of is that attributes have several fields that may be interesting to users (description, type, i think I think one more). With a list, i suppose i'd be formatting that all into a single space. 15:58:41 acozine: ok 15:59:18 i can ask you/ samccann later for help with that :) 15:59:26 felixfontein: i don't know about that... The way it's coded in core, i think plugins which have standard attributes will have a ton of unsupported attributes along with them 16:00:07 so do we list all the attributes? That could get long 16:00:28 so a table might be helpful (attribute | state| description) 16:00:30 Or am i reading the code wrong? 16:01:22 hm, we could simply not display any attributes that have `not specified/unknown` as the value 16:01:22 abadger1999: by default a plugin will have no attributes, and if it has attributes, for these ones it has it has to specify the support (if it uses core's docs fragment, it will have a default 'support' value for all attributes in there) 16:02:08 plugins that don't use the docs fragment can for example have the attribute `diff mode` with support `none`, but not have the attribute `check mode`. then we know the plugin doesn't support diff mode, but we don't know whether it supports check mode 16:02:20 what does `support` mean in this context? 16:02:22 which is different from not knowing whether diff mode is supported or not 16:02:36 gwmngilfen-work: if you have the time and hte interest, you could test out our community instructions for backporting: https://docs.ansible.com/ansible/latest/community/development_process.html#backport-process 16:02:45 felixfontein: right. But if they do use the core docs fragment ( https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/doc_fragments/action_common_attributes.py ) then won't they get all of those attributes? 16:02:47 ok diff and check only make sense for modules :) 16:02:48 * gwmngilfen-work copies that link 16:03:41 samccann: it means that the plugin implements that 16:03:47 cool thanks 16:04:23 abadger1999: if they use the core docs fragment, they have to specify the support values which differ from the ones mentioned in there 16:04:34 abadger1999: (which also implies that that docs fragment can never be extended with new attributes) 16:05:28 is it possible that docs fragment is only useful to core (builtin) modules? 16:05:39 and that we shouldn't suppose any collection wants to use it? 16:05:52 that's a good question 16:06:03 or if they do they should copy it into their own repo so they can maintain it? 16:06:18 it would be great to document whether collections-based modules support check mode 16:06:19 it might actually be better, though I really don't like that either :) 16:06:44 okay, I need to head to my next meeting 16:07:04 probably it would be good if `support` has another possible value `unknown`, and that's the default 16:07:04 I'm going to end the official meeting, but the chat can go on 16:07:07 it just feels like a maintenance nightmare if a collection depends on this fragment but the fragment can be extended in the future 16:07:39 make notes in https://hackmd.io/R71WLQjPQOa-Ze0Cg97V7A 16:07:56 thanks acozine 16:07:59 felixfontein: Yes.... but my thinking is that we don't want plugins which use the action_common_attributes doc_fragment show all 20+ attributes since they won;t implement most of them. 16:08:24 thanks abadger1999 ariordan briantist felixfontein gundalow gwmngilfen-work samccann tadeboro! 16:08:31 #endmeeting