Some thoughts:
1. Policy makers think they write policy in English (or other human language). But more and more it is the software.
2. "policy engines" aren't going to cut it - we need to introspect code to decide what the code does - and translate that back to policy.
3. at my work the best solution i have got is using unit tests to explain what the policy is based on test comments - and again that's using english and again it's terrible ("best")
I think the real solution is both wider software literacy so that discussion happen "in code" and code that is more like policy (composable functional languages are thus likely to be useful here)
But great to hear you are taking any steps at all - would an HN letter writing campaign to your ministers help?
I love some of the collaborative nature of Microsoft Teams and CRDT editing Word/Excel, but I'm usually pretty remote. Text over a tenuous WAN connection is ideal.
I work at a government agency and I was /just today/ getting them to review and approve Git and VS Code for our staff use - and pandoc. A couple years ago we never would have gotten open-source software approved. I wish I knew of an equivalent to SELinux or AppArmor for Windows so they could lock down things a semi-trusted application can do. VS Code will be used in a few different departments, but I mostly want it to help those unfamiliar with Git and its CLI (Git Graph is nice).
There's a trick out there to first convert things like Word documents to Markdown, and then do a diff of that intermediate output: https://hrishioa.github.io/tracking-word-documents-with-git/
Pandoc can only do so much. I'm trying to convince my part of the gov to put policy documents we disseminate to staff in a git repo, so we can track who did what and why (based on commit messages). This will be a big step, but thankfully one part of our org is already moving toward version control for IT and data analytics so I'm proposing this and suggesting we hop on their bandwagon. Momentum.
There's a Word template that we commonly use for legal purposes where it gives you line numbers and you write text to align with the numbers. When reviewing it's easy to say "change line 23 to read ....". This - for example - will not translate well through pandoc because the numbers and the text are separate text elements.
There's a market for making pandoc better. Visually translating how elements "flow" from 1 format to another, instead of simply transpiling XML to Markdown.
I'm still excited thinking in a year I might be able to git-blame the legal department for things. Or see a diff from 1 administration to the next.