15:30:43 <samccann> #startmeeting Documentation Working Group Supplemental
15:30:43 <zodbot> Meeting started Thu Nov 12 15:30:43 2020 UTC.
15:30:43 <zodbot> This meeting is logged and archived in a public location.
15:30:43 <zodbot> The chair is samccann. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:30:43 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:30:43 <zodbot> The meeting name has been set to 'documentation_working_group_supplemental'
15:30:55 <acozine> o/
15:30:56 <samccann> #topic openning chatter
15:30:59 <felixfontein> is 'julien' a verb?
15:31:07 <samccann> #chair acozine felixfontein gundalow
15:31:07 <zodbot> Current chairs: acozine felixfontein gundalow samccann
15:31:12 <samccann> I probably spelled it wrong
15:31:14 <acozine> think it's spelled julienne
15:31:16 <dericcrago> \o
15:31:26 <samccann> #chair dericcrago
15:31:26 <zodbot> Current chairs: acozine dericcrago felixfontein gundalow samccann
15:31:39 <acozine> it's what French chefs do to carrots and things
15:31:43 <felixfontein> `to julienne sth.` found that in a dictionary :)
15:32:03 <acozine> not sure how it's different from "chopping" but it sure sounds French!
15:32:17 * gundalow waves
15:32:22 <dmsimard> o/
15:32:23 <samccann> who else might be around? andersson007_  aminvakil alongchamps cyberpear geerlingguy ?
15:32:28 <gwmngilfen> It's a lot finer, iirc
15:32:37 <felixfontein> interesting, never heard that name. to me it sounds like a female first name, and that didn't make sense in that sentence :)
15:32:44 <cyberpear> o/ half way here
15:32:45 <samccann> #chair dmsimard
15:32:45 <zodbot> Current chairs: acozine dericcrago dmsimard felixfontein gundalow samccann
15:32:52 <lmodemal> o/
15:32:54 <gwmngilfen> I'm decent with a knife, but not that good :)
15:33:02 <samccann> #chair cyberpear lmodemal gwmngilfen
15:33:02 <zodbot> Current chairs: acozine cyberpear dericcrago dmsimard felixfontein gundalow gwmngilfen lmodemal samccann
15:33:24 <geerlingguy> can't be around this morning, sorry :(
15:33:32 <felixfontein> hmm, looks like that name is also common in german, at least in the gourmet/cooking scene
15:33:38 <geerlingguy> But I still wish collection docs were available on Galaxy, would make a lot of this moot
15:33:39 <samccann> ok no worries, thanks geerlinggguy
15:33:47 <samccann> AAAH  too many g's
15:33:50 <geerlingguy> lol
15:34:03 <geerlingguy> you're welcome samcccann ;)
15:34:09 <samccann> AAHAHAH touche
15:34:13 <gwmngilfen> I'm mostly lurking since I'm working with acozine on docs stats, but I'm here for uninformed opinions too :)
15:34:15 <felixfontein> hehe
15:34:27 <samccann> ok let's jump right into it then
15:34:36 <samccann> #topic Personas
15:34:52 <samccann> So this is what can help drive the discussion of 'who needs what kind of docs'.
15:35:14 <samccann> I took what gundalow had in a separate doc and tried to summarize - https://etherpad.opendev.org/p/ansible-documentation-split
15:35:27 <samccann> #info first thoughts on personas - https://etherpad.opendev.org/p/ansible-documentation-split
15:36:33 <dmsimard> I think the personas split makes sense (user, creator, developer, partner)
15:36:49 <samccann> scroll down til it changes color in the Personas section.  But to summarize - We have:
15:36:49 <samccann> 1. users (don't create playbooks etc, just use what others have created)
15:36:49 <samccann> 2. creators (playbooks, roles, inventories) - no python coding
15:36:49 <samccann> 3. developers (create modules, collections, etc - coders)
15:36:49 <samccann> 4. parterns (certification peeps)
15:37:01 <samccann> s/parterns/partners/
15:38:02 <samccann> What I couldn't figure out - if the user isn't writing playbooks, just using  them etc - do they create their own inventories? I was thinking no... but they may need to understand how to execute the playbooks based on inventory groups... maybe even variable definitions?
15:38:29 <felixfontein> do we include collection maintainers in the developers group?
15:38:32 <gundalow> I think creators needs to be split in two
15:38:52 <abadger1999> I think users and creators have a shifting overlap...
15:38:58 <felixfontein> especially if we plan to make creating (and thus maintaining) collections so much easier, I think that's also a group of interest
15:39:11 <dericcrago> I think users probably are creating playbooks / inventories unless they're awx / tower users
15:39:14 <samccann> felixfontein: yes... though as gundalow is suggesting. some of these personas may be split even more... so general module developer vs collection maintainer
15:39:15 <gundalow> I personally don't like `creators` (without a prefix)
15:39:31 <abadger1999> (They're both in our traditional end-users category)
15:39:54 <acozine> hmm
15:40:05 <gwmngilfen> is the plan to have entirely separate pages per persona, or is this more of a "tags" concept for a given page?
15:40:13 * samccann ... bites nails when acozine sez hmmm
15:40:22 <gwmngilfen> the latter would allow for overlapping categories
15:40:44 <acozine> if we look at the descriptions instead of the standalone terms . . . how do the categories fit?
15:41:04 <samccann> gwmngilfen - TBD.  I think the Grand Strategy for a full docsite revamp (say 2 yrs out before completed) might have separate areas for users vs the creators vs developers for example.
15:41:25 <samccann> acozine what cagegories?
15:41:41 <abadger1999> (My comment was directed at samccann's question about whether "users" would create their own inventory)  Some will, some won't
15:41:59 <gwmngilfen> so content appropriate for 2 personas would be duplicated? or are personas more a way of signposting people to content?
15:42:07 <samccann> abadger1999: good to know.
15:42:19 <dmsimard> to use ansible, you need an inventory (unless using only localhost? I guess) and likely need to set variables too
15:42:40 <samccann> gwmngilfen: depends on how we handle it. we could 'duplicate' the html pages for example, but single-source the rst file. (write once, publish in two areas)
15:42:41 <felixfontein> I think if we have separate content, we will repeat a LOT of things
15:42:51 <acozine> I mean, instead of "users/creators/developers/partners" if we talk about "people who run roles and playbooks but may not know even YAML/people who write playbooks and roles but may not know python/people who code in python/people who need to understand the certification rules"
15:42:53 <gundalow> gwmngilfen: I *think* we'd have index for each persona, though two personas-index pages may link to the same page for details
15:43:24 <samccann> yeah so acozine has the correct separation I was trying to capture with persona names
15:43:35 <acozine> if we can agree on the categories, we can debate names later
15:44:17 <gundalow> +1
15:44:25 <gwmngilfen> gundalow: i see. essentially, if there's any form of content re-use, via tags, index pages, or single-source-multiple-url, then the categories can overlap, I think.
15:44:26 <dericcrago> if you're a new user who just discovered ansible, you'll need to create inventories / playbooks, right?
15:44:37 <acozine> gwmngilfen: yes, personas give us a way to organize pathways through the content; they may also help us identify missing content
15:45:02 <abadger1999> dmsimard: Yeah... but some sites might create an ansible playbook + inventory and say "Hey manager, to get the stats on which employees have logged in from home this week, run ansible-playbook -i bastion-hosts gather-remotee-stats.yml"
15:45:33 <gundalow> acozine: samccann What would you like to achieve for this topic? (I know there is a lot of stuff here, so want to make sure we keep on track)
15:45:38 <samccann> abadger1999: yeah that's what I was trying to capture with the basic 'user'
15:45:48 <gwmngilfen> yes. implementation might affect what stats I can do for you though - I like samccann's point about single-source to multiple URLs, as that would have unique stats per persona
15:45:50 <acozine> dericcrago: possibly - you might also be someone who just took a job a company that runs Tower and you need to understand the pre-existing infrastructure, how to read Ansible output, etc.
15:46:05 <gwmngilfen> but I digress, +1 to personas in general :)
15:46:26 <samccann> gundalow: my thought is - do we take a stab at defining the personas of the future and thus those index'd pathways, as we split `ansible-core` docs from Ansible docs
15:46:38 <gwmngilfen> (because then they become a variable in my data - i.e we can try to say which personas are performing well)
15:47:08 <samccann> I thought it would help drive those decisions.  Maybe I'm going to far into the future though and we should just scratchpad splitting out core from Ansible?
15:47:41 <dmsimard> abadger1999: makes sense
15:47:58 <samccann> whatI worry is - we'll take a hope to two docsites (core and Ansible)... and then 6-8 months later, take another hop as we start to flesh out the persona-based docs that the product team is looking for.
15:48:03 <gundalow> samccann: Do you think splitting content changes personas or what should be under each of them?
15:48:33 <samccann> gundalow: I think splitting content changes the urls now... and splitting based on personas say 9 months from now changes urls again
15:48:58 <abadger1999> It's not a clear boundary, though, because a site could also just write a playbook and say "Hey release team, here's a playbook to deploy the web app.  To integrate it into production, write an inventory file that includes a group for database server, app servers, and load balancers" (which then requires the release team to write an inventory file)
15:49:05 <samccann> was hoping to avoid one set of http redirects to go from what we have today to core/Ansible...and then another set of redirects once we have personas
15:49:05 <acozine> yeah, what samccann said - since we have two big changes in mind for the next year (persona-based navigation and Core vs. Package), if we can find ways to dovetail them it will be a win
15:50:03 <gundalow> ah, OK. I guess intersphinx works for the links, but not the old URLs
15:50:22 <samccann> abadger1999: yeah, good point.  Maybe we solve this by the 'Beginner's Guide to Ansible'  and cover the basics of modules/collections/playbooks, and inventory files.  Then all the nitty gritty details go into the 'creators of playbooks etc' section
15:50:59 <dmsimard> abadger1999: the reality probably looks like a venn diagram where you have user/creator/partner with dev meeting in the middle https://i.imgur.com/LGJTjAP.png
15:51:12 <samccann> #info not a clear boundary between 'users' and 'creators' in this sense.  some places will hand a user a playbook and tell them to write their own inventory.  Other places the user is the creator as well.
15:51:43 <samccann> dmsimard omgosh how did you create that so fast!
15:51:57 <dmsimard> dunno, picked the first venn diagram creator from google :p
15:52:15 <acozine> we've also been talking about making the developer guide pages (which basically correspond to one persona - "docs for folks who write Python") into single-version documentation (in other words, removing those pages from the stable branches)
15:52:33 <felixfontein> maybe user and creator should be kept as one set, similar to what we have today (if you ignore the parts on roles, collections, and the dev guide)?
15:53:39 <dmsimard> samccann: for the record: https://www.canva.com/graphs/venn-diagrams/
15:53:48 <samccann> heh thanks dmsimard
15:53:53 <felixfontein> acozine: depends on how stable the interface plugin/module developers talk to are
15:55:08 <acozine> felixfontein: ah, good point
15:55:16 <samccann> ok so we have at least THREE things coming in here at once:
15:55:16 <samccann> 1. ansible-core split from Ansible
15:55:16 <samccann> 2. Personas
15:55:16 <samccann> 3. versioned docs vs release-independent (aka devel only) docs
15:55:39 <felixfontein> but even if the interfaces change over time, it's good to have it all in one place (for all versions) since people who don't work on ansible-core (which is almost everyone) has to support multiple ansible versions, and finding out the differences by using the version selector sucks
15:55:49 <dmsimard> ansible-core is just a rename from ansible-base, right ? or is there more to it than that ?
15:55:54 <felixfontein> dmsimard: yes
15:56:01 <felixfontein> (first question)
15:56:03 <samccann> And as I think about it, we (as in those of us here) have only so much control over personas... I feel like the ultimate persona experience might be defined by someone higherup in the foodchain
15:56:35 <felixfontein> samccann: I guess you could make suggestions, and hope they simply eat (i.e. accept) them :)
15:57:03 <acozine> we'd also like to get the survey out to docs users
15:57:19 * gwmngilfen wakes back up
15:57:20 <samccann> #info one option for 'release independent' developer guides - put all the version-specific information in one guide. So 'in ansible-base...do this... in ansible-core.2.11, do this other thing, etc.
15:57:55 <acozine> it might give us a basis for making decisions about personas
15:58:00 <samccann> Anyway, I'm starting to second-guess our attempt at personas this early in the game. We have a hard deadline for the core vs Ansible plit
15:58:07 <samccann> SPLIT
15:58:12 <acozine> heh
15:58:44 <samccann> so we could just solve for that.  Solve for that AND release independent developer content.
15:58:54 <samccann> OR solve for both of them AND our first stab at personas.
15:58:58 <felixfontein> samccann: most of the time, it will be more like small `The xxx option / yyy method was added in ansible-core 2.12` additions
15:59:21 <felixfontein> most of the things should be identical for most ansible versions. hopefully :)
15:59:31 <samccann> felixfontein: yep, I've written my fair share of release-independent docs.  When the changes between releases are relatively minor, it works out well.
16:00:03 <gundalow> Community guide is version independent
16:00:17 <samccann> should we do a POLL to find out what we should try to accomplish by the Jan/Feb deadline?
16:00:18 <gundalow> dev_guide is collection independent, and mostly ansible-core independent
16:00:23 <acozine> gundalow: it certainly could be - we currently publish it for all versions
16:00:44 <acozine> and there are differences from one version to another, because we didn't backport all changes
16:00:45 <samccann> #info Community guide and much of the developer guide content could be release-independent
16:01:01 <felixfontein> gundalow: there are some chunks of the dev guide which are core-specific, especially some of the testing parts
16:01:23 <felixfontein> (though I think they are also mostly version-indepdendent)
16:01:38 <gundalow> yup, though my gut thinks 80%+ version independent
16:01:40 <samccann> #info testing info in the dev guide might be core-specific and we'd need a separate testing section for collection developers etc
16:02:21 <samccann> #topic release dependent vs independent docs
16:02:30 <samccann> since that's what we've been talking about ;-)
16:02:36 <gwmngilfen> i'd be happy to help with survey design if you'd like
16:03:26 <acozine> For Jan/Feb, we know we will have docs.ansible.com/ansible/2.11 which will cover the `ansible` 2.11 PyPI package, and we know that a few months after that, we will need separate/different docs for `ansible-core` 2.11 - how do we explain the difference to users?
16:03:46 <felixfontein> hmm, I wonder how much of the docs are actually pretty much version-independent and could live well with '(In ansible-core 2.xx, this option was added / this was modified / ...)'
16:03:53 <samccann> so we can pull out the community guide pages for sure.  I think we can pull out the dev guide pages as release independent... and then add sections for 'in ansible 2.11... blablala' as needed.
16:04:21 <dmsimard> are release independant docs rendered straight from devel ?
16:04:23 <samccann> felixfontein: I feel like we can do that with dev guide for sure. I'm less sure about user guide/creator stuff.
16:04:35 <samccann> dmsimard - good question.
16:04:43 <acozine> dmsimard: currently we don't have many release-independent pages
16:05:20 <felixfontein> samccann: good question. you're probably right about the user guide/creator stuff.
16:05:46 <acozine> we recently removed the Porting Guides section from the stable branches, stubbing in a link to the devel docs, and the full content is rendered straight from the `devel` branch
16:05:48 <samccann> dmsimard acozine : it becomes an issue because someone will add docs for say `ansible-base 2.12` in devel, cuz that is what devel would be after ansible-core 2.11' releases
16:05:58 <samccann> and then we'd publish
16:06:04 <dmsimard> I ask because I've seen notes like this one to go to devel https://docs.ansible.com/ansible/latest/reference_appendices/release_and_maintenance.html
16:06:06 <gundalow> currently every area under docs.ansible.com/{ansible,ansible-tower,galaxy} is build from a different Git repo
16:06:22 <samccann> though if they are careful with the 'added in 2.12' that's probably fine.
16:06:47 <acozine> dmsimard: ah, yes, release and maintenance is the other place where we do that
16:07:28 <acozine> because we wanted older versions of the docs to be clear about "this version is not maintained, for heaven's sake upgrade"
16:08:05 <samccann> #info we have started maintaining some pages only in devel and stubbing out the info in older versions. release and maintenance, porting guides..
16:08:17 <acozine> and that meant we either had to backport the most recent changes to all the old branches, or we had to remove that page from the old branches
16:08:27 <dmsimard> yeah, makes sense
16:09:01 <samccann> so are we at the warm fuzzy point of saying, yes - let's take a stab at making the developer docs release-independent for 2.11 (Ansible and `ansible-core`)?
16:09:24 <acozine> I think so . . .
16:09:52 <samccann> POLL - Should we make developer docs release independent for 2.11 (Ansible and core).  please vote
16:09:55 <samccann> #chair
16:09:55 <zodbot> Current chairs: acozine cyberpear dericcrago dmsimard felixfontein gundalow gwmngilfen lmodemal samccann
16:10:07 <dmsimard> can you define developer docs ?
16:10:09 <acozine> should we take advantage of that change to move the developer docs more radically?
16:10:20 <acozine> as in, do we want `dev-docs.ansible.com`?
16:10:43 <gundalow> https://docs.ansible.com/ansible/devel/dev_guide/ (https://github.com/ansible/ansible/tree/devel/docs/docsite/rst/dev_guide)
16:10:49 <dmsimard> gundalow: thanks
16:11:17 <cyberpear> I think it'd still be useful to have historical versions; at least a snapshot per (major version of ansible-base or major version of ansible)
16:12:04 <samccann> cyberpeear - that would mean versioned docs. which is what we have today.
16:12:42 <abadger1999> acozine: I'd keep it on the same domain but a different sub-url might be appropriate.
16:13:38 <dmsimard> taking a brief glance at the dev guide, it looks like reasonably release independant stuff .. is some of it pulled from collections ? like ovirt/vmware/openstack things
16:13:39 <acozine> abadger1999: so, docs.ansible.com/ansible-core or maybe docs.ansible.com/developers
16:13:54 <abadger1999> acozine: yep
16:14:12 <gundalow> docs.ansible.com/developers (which 95% would be about ansible-core & collections)
16:14:37 <dmsimard> answering my own question, it's not pulled from collections -- it's here https://github.com/ansible/ansible/tree/devel/docs/docsite/rst/dev_guide/platforms
16:14:38 <samccann> would depend on how we split things
16:14:39 <felixfontein> +1
16:15:02 <samccann> docs.ansible.com/ansible/developers and docs.ansible.com/ansible-core/developers for example, if we need that granularity
16:15:22 <gundalow> docs.ansible.com/community - Different types of community, how to get involved, how to contribute (to the various projects), again, initially mostly around ansible-core & collections
16:15:28 <felixfontein> I don't think it makes sense to separate ansible-core and ansible for developer docs
16:15:38 <felixfontein> resp. the ansible developer docs will be essentially empty
16:15:59 <samccann> gundalow: and yes, that is exactly what makes this all so very hard. We are talking about say moving OUR community guide to docs.ansible.com/ansible/community
16:16:01 <acozine> dmsimard: nothing in the dev guide comes from collections, and we want to move collections-specific content into collections as/when we can (for example, the Scenario Guides section)
16:16:15 <samccann> whereas you may be envisioning ONE community guide for ansible, tower, lint.blablabla
16:16:33 <acozine> the community guide is at docs.ansible.com/community/ today
16:16:41 <acozine> aargh
16:16:49 <acozine> sorry, at docs.ansible.com/ansible/community/
16:16:50 <gundalow> COWSAYS NOP
16:16:51 <samccann> heh
16:16:57 * acozine needs more caffeine
16:17:10 <samccann> erm  still getting cowsay
16:17:12 <felixfontein> https://docs.ansible.com/ansible/latest/community/
16:17:19 <dmsimard> export ANSIBLE_NOCOWS=0
16:17:24 <samccann> yep, and thus versioned (latest)
16:17:55 <samccann> ok we are 45 minutes into the meeting... and not sure we've settled on anything.  Lots of good discussion... but I feel maybe it's time to say.. what next?
16:18:14 <abadger1999> Regarding ansible/developers and ansible-core/developers  (as well as some of the persona questions) maybe we should be thinking about a deper hierarchy?  Like docs.ansible.com == a library of the ansible ecosystem.  /{ansible,galaxy,developers} are individual books in the library.  and /developers/{ansible-core,ansible-collection} are chapters in the books.
16:19:41 <gundalow> oh, are personas first-class citizans?
16:19:42 <samccann> abadger1999: long term I think that's what folks want.  My question - what can we accomplish in the short term Jan/Feb deadline.
16:19:45 <abadger1999> A reader can take one book off the shelf at a time so when the reader is going to need two areas to be able to answer their question, the answer should be in the same book, even if they're in separate sections of that book?
16:19:46 <gundalow> citizens*
16:20:06 <acozine> yeah, i like that analogy - right now the books are per-product (Ansible, Tower) and the chapters are organized differently for each product
16:20:21 <abadger1999> <nod>  Yeah.  I'm thinking, in this model.... maybe developer and ansible-core-developer should not be in separate books
16:20:31 <acozine> I think the longer-term goal is to make the books per-persona
16:20:36 <abadger1999> separate chapters but the same book
16:21:11 <samccann> abadger1999 - doable on the dev guide as we can make them release-independent and just add 'added in `ansible-core.2.11` or `Added in Ansible 2.11` as needed
16:21:20 <abadger1999> Same with the user-creator personas.... there's enough overlap that they should be the same book but enough of a separation that they should be separate chapters.
16:21:34 <dmsimard> abadger1999: ++
16:22:18 <samccann> #info consider one dev guide, with separate 'chapters' for Ansible developer vs ansible-core developer.  Same with user-creater personas - not separate books, but separate sections within a book for example
16:23:20 <acozine> abadger1999: so if we imagine the URLs as reflecting the organizing principle you're suggesting, we'd have `docs.ansible.com/developers/` and `docs.ansible.com/other-user-name` and within those, chapters for each product?
16:24:26 <samccann> #topic Next Steps
16:24:35 <abadger1999> acozine: Yes.  that probably would be the completely logical endpoint of this.
16:24:37 <samccann> since e now have 5 min left. what do we do next to move this along?
16:24:41 <acozine> or possibly `docs.ansible.com/using_ansible/` and `docs.ansible.com/developing_ansible`?
16:25:25 <acozine> I like that approach; it's a big change from what we have now, but I think it will serve the community and customers well
16:25:33 <abadger1999> I don't know if it's doable since I haven't talked with Tower folks and such but it seems like it would be taking this principle to its logical conclusion
16:25:58 <acozine> abadger1999: I believe one of our mandates over the next year is to create AWX documentation
16:26:03 <abadger1999> Cool
16:26:33 <samccann> ok gentle reminder - we have limited time to make the split we know we have to make (ansible vs ansible-core).
16:26:57 <samccann> So I'd like us to decide which of the many things we've discussed today is NOT part of that shorttem goal
16:27:26 <dmsimard> the ansible vs ansible-core split is time sensitive whereas the personas thing isn't so I guess it speaks for itself
16:27:36 <dmsimard> nice to have vs must have
16:27:46 <bcoca> sanity senstive ...
16:27:55 <felixfontein> I guess moving the dev and community guide out is doable
16:27:59 <acozine> samccann: yep, how about our goal for the ansible vs ansible-core split is to have a non-versioned docs-set for developers alongside existing versioned docs, with content that starts to explain the differences?
16:28:18 <samccann> +1 for ^^
16:28:32 <acozine> we can talk about where the community pages fit best
16:28:38 <bcoca> devs will also need 'version senstive info' .. since there are changes to the facitlities they have access to
16:28:52 <samccann> yeah we handle that in the text itself.
16:29:00 <acozine> bcoca: yep, we'll have to go back to some kind of `added in version x` notation
16:30:07 <bcoca> i always add those in docs anyways
16:30:58 <dmsimard> it will also give us a bit more time to flesh out and get buy in/agreement for personas
16:31:27 <felixfontein> bcoca: it's helping collection developers a lot to have that info
16:31:28 <samccann> #info our goal for the ansible vs ansible-core split is to have a non-versioned docs-set for developers alongside existing versioned docs, with content that starts to explain the differences
16:31:30 <abadger1999> I think community pages are probably a chapter in the developer docs
16:31:45 <abadger1999> (I think partner docs are a chapter in the developer docs too, though)
16:32:10 <dericcrago> if we're talking about version indepedent docs, how difficult do we think it will be for someone that is say stuck on 2.9 for support reasons to follow?
16:32:14 <samccann> community should stay as separate. Plenty of community are not developers. Especially when it comes to docs prs
16:32:19 <felixfontein> partner docs yes, community docs... depends on which parts.
16:32:51 <felixfontein> also people wanting to report a bug, request a feature, are often not developers
16:32:55 <bcoca> devs and community are intersection
16:33:14 <samccann> dericcrago - version independent docs only work when there is not a lot of drift.  So there may be some things like 'Added in 2.10' etc
16:33:15 <acozine> I think ^^^ would be great questions to ask in the survey
16:33:22 <abadger1999> <nod>  but will a large number of community questions need to consult the developer docs for anwers?
16:34:17 <felixfontein> samccann: dericcrago: since many collection devs have to support multiple ansible versions, having version-independent docs with 'added/changed/removed in 2.xx' all over the place is pretty awesome
16:34:24 <abadger1999> How do I write a collection?  how do I write a collection that can make it into ansible?  <== you'd need information from both the general developer and the community space to answer that
16:34:32 <samccann> abadger1999: I see community as high level stuff.... but yeah, for 'opening a PR' - it should just point to developer details
16:34:45 <felixfontein> abadger1999: I guess they can just forward the people to the dev docs
16:35:00 <bcoca> are we adding 'all users' to this def of 'community'?
16:35:18 <acozine> break down "do you think of yourself as a developer" and then "how comfortable would you be reporting a bug/correcting the docs with a PR/whatever", maybe
16:35:20 <abadger1999> Yeah.. but that is not great....
16:35:44 <samccann> Community to me i stuff like these meetings etc.  And the basics of 'if you want to contribute... here's how'. With the details in other guides as needed
16:36:42 <gundalow> > how do I write a collection that can make it into ansible?  <== you'd need information from both the general developer and the community space to answer that
16:36:42 <gundalow> I'm OK with that
16:36:42 <gundalow> Also with intersphins we can link to different areas
16:36:48 <cybette> community docs could be like a portal/landing page to other docs (devs, user, meetings, wikis)
16:36:57 <abadger1999> imagine having to read a checklist of items in two location to build your collection and once in a while the two checklists have rules that seem to conflict.
16:37:29 <dericcrago> abadger1999 ++
16:37:40 <acozine> agreed, to me Community docs are "how do I get involved" at various levels including conferences/meetups, while Developer docs are "how do I fix this/extend this" at various levels - there's crossover, but community is broader
16:38:43 <abadger1999> <nod> If so.... then maybe there needs to be "community" sections inside of hte developer docs.
16:38:45 <acozine> samccann: maybe we should create a wireframe or proposed TOC or something as a basis for discussion
16:39:07 <felixfontein> acozine: for wireframe TOC
16:39:07 <samccann> #info next steps - create a proposed TOC etc for next week's discussion
16:39:08 <felixfontein> +1
16:39:37 <abadger1999> Here's how you develop a collection or plugin.  If you want to contribute this to the ansible package then you have these additional rules/changes to abide by.
16:39:40 <samccann> anything else before we close this meeting?
16:39:58 <acozine> abadger1999: yeah, that sounds good
16:39:58 <gwmngilfen> i'll work with acozine on some possible survey questions
16:40:02 <samccann> abadger1999 yep sounds good
16:40:23 <samccann> #action gwmngilfen and acozine to work on the docs survey
16:40:24 <acozine> #info next steps: gwmngilfen and acozine to work on a draft survey
16:40:25 <acozine> heh
16:40:29 <samccann> lol
16:40:34 <acozine> #undo
16:40:34 <zodbot> Removing item from minutes: INFO by acozine at 16:40:24 : next steps: gwmngilfen and acozine to work on a draft survey
16:40:38 <gwmngilfen> twice the work! /o\
16:40:44 <samccann> lol
16:40:52 <samccann> anything else?
16:41:12 <acozine> don't think so . . .
16:41:44 <samccann> ok gonna end unless someone pipes in fast
16:41:53 <acozine> thanks everybody!
16:42:05 <acozine> it's great to see so much support and interest
16:42:27 <abadger1999> Informational, since we're talking about deadlines
16:42:51 <abadger1999> Tentative schedule for 2.10: https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw
16:43:04 <abadger1999> Err 2.11
16:43:05 <samccann> #info Tentative schedule for 2.10: https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw
16:43:10 <samccann> #undo
16:43:10 <zodbot> Removing item from minutes: INFO by samccann at 16:43:05 : Tentative schedule for 2.10: https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw
16:43:24 <samccann> #info Tentative schedule for 2.11: https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw
16:43:46 <samccann> ok thanks everyone!
16:43:49 <samccann> #endmeeting