You're in the right ballpark. NB: I work(ed) on AWS Docs, shipped docs for AWS Device Farm and AppSync in a past role. (these statements are my opinion and expe

You're in the right ballpark. NB: I work(ed) on AWS Docs, shipped docs for AWS Device Farm and AppSync in a past role. (these statements are my opinion and experience. I won't speak for the whole company) It's a mixture of politics and fatigue. The vast majority of the Markdown content in these repos isn't the source that AWS Docs works from. Internally, it's a separate content authoring language that is XML-based called ZonBook (though that gets hidden in all but the PDF metadata) that gets run through an XSLT transform. A single user guide can require 4..5 git repos to build. This means that for any non-trivial change, there is a ton of legwork to re-implement that change in XML, rather than markdown. For some changes, this can be made worse by the ergonomics of the system being less than ideal, and that's for a user guide alone. The process for any sort of API documentation fix is a totally different one built using a different set of tools that have a completely separate build pipeline. Compile times for some documentation packages can be in the hours. I won't speak for the whole team, but sometimes this just gets grating. The compilation time for one book I worked on was into the two and a half hours for the Markdown output, which was incomplete. The cause of that incompleteness is that there's a lot of features of ZonBook that don't map to Markdown: XML entities are constantly abused to in lieu of templates and to keep branding correct (for instance, after the [AWS brand in China](https://www.wsj.com/articles/amazon-banned-from-using-aws-logo-in-china-trademark-ruling-11609841232 https://www.wsj.com/articles/amazon-banned-from-using-aws-lo...) was muddled about, it wasn't as much of a pain in the long run), but also the lack of support for nested paragraphs in tables and arbitrary styling in Markdown puts a bit of a damper on some of the things that writers had been given. This all culminates in a general lack of interest in moving away to something Markdown derived since there are so many things that don't map to markdown at all that would need to be added for these features to make sense, and lots of these features are essential to the way the docs are managed at a meta level. I won't get into the general feeling that Legal doesn't trust GitHub (being owned by the largest competitor, there's a lot of speculation about that -- internally there's a "hold Microsoft at knifepoint" sort of opinions that seep out from the edges) and would rather not interact with it at all.