# \[Vote ended on 2024-08-21\] Ansible 11 roadmap **URL:** \ **Category:** Project Discussions\ **Tags:** community, documentation, community-wg\ **Created:** [August 1, 2024, 5:42pm UTC](https://forum.ansible.com/t/vote-ended-on-2024-08-21-ansible-11-roadmap/7581 "2024-08-01T17:42:29Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![mariolenz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mariolenz/32/108_2.png) [@mariolenz](https://forum.ansible.com/u/mariolenz)\ **Post date:** [August 1, 2024, 5:42pm UTC](https://forum.ansible.com/t/vote-ended-on-2024-08-21-ansible-11-roadmap/7581/1 "2024-08-01T17:42:29Z")
I think we don’t have a roadmap for Ansible 11, so I’ve created a [PR](https://github.com/ansible/ansible-documentation/pull/1729) to suggest one. ---
**Author:** ![mariolenz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mariolenz/32/108_2.png) [@mariolenz](https://forum.ansible.com/u/mariolenz)\ **Post date:** [August 8, 2024, 3:43pm UTC](https://forum.ansible.com/t/vote-ended-on-2024-08-21-ansible-11-roadmap/7581/2 "2024-08-08T15:43:27Z")
Since I didn’t see any objections to my [PR](https://github.com/ansible/ansible-documentation/pull/1729), let’s vote on merging it and have a roadmap for Ansible 11. The vote will end 2024-08-21. _Poll ([view on site](https://forum.ansible.com/t/vote-ended-on-2024-08-21-ansible-11-roadmap/7581/2))_ _Poll ([view on site](https://forum.ansible.com/t/vote-ended-on-2024-08-21-ansible-11-roadmap/7581/2))_ ---
**Author:** ![mariolenz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mariolenz/32/108_2.png) [@mariolenz](https://forum.ansible.com/u/mariolenz)\ **Post date:** [August 21, 2024, 2:41pm UTC](https://forum.ansible.com/t/vote-ended-on-2024-08-21-ansible-11-roadmap/7581/3 "2024-08-21T14:41:15Z")
The vote ended and the suggested roadmap has been accepted with 7:0 votes from the SC and 1:0 votes from the community. Thanks all for voting! ---
**Author:** ![utoddl](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/utoddl/32/249_2.png) [@utoddl](https://forum.ansible.com/u/utoddl)\ **Post date:** [August 26, 2024, 9:01pm UTC](https://forum.ansible.com/t/vote-ended-on-2024-08-21-ansible-11-roadmap/7581/4 "2024-08-26T21:01:09Z")
I see where Ansible 11 will track Ansible-core 2.18 and its [planned work](https://docs.ansible.com/ansible-core/devel/roadmap/ROADMAP_2_18.html#planned-work). Can someone recommend where one can read up on some of that planned work? I’m particularly intrigued by “Data Tagging”; pointers toward any details would be welcome. I understand that in lots of tech dev, if you haven’t been “in the room” it’s hard to pick up from scratch; it’s likewise hard to bring others up to speed. It’s not like there’s a fly on the wall with a penchant for journalism who’s been recording it all as a gripping narrative. More’s the pity. So it may be that such docs simply don’t exist. And people are busy. Perhaps I should scale back my request to a suggestion: that maybe each planned work bullet could be expanded to a paragraph or two to very briefly outline its scope, expected benefit, etc. As it is, those who are deeply involved already know, so the extra detail is of no use to them. And for those who aren’t, the terse list as it exists is marginally informative at best. One is left to wonder who’s the target audience for the ROADMAP’s planned work list. Well, that came out less positively than intended. I do appreciate everyone’s efforts. ---
**Author:** ![jimi](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/jimi/32/3491_2.png) [@jimi](https://forum.ansible.com/u/jimi)\ **Post date:** [August 26, 2024, 9:24pm UTC](https://forum.ansible.com/t/vote-ended-on-2024-08-21-ansible-11-roadmap/7581/5 "2024-08-26T21:24:10Z")
The github board for the 2.18 roadmap is here: > **[ansible-core 2.18 • ansible](https://github.com/orgs/ansible/projects/138/views/1)** > > ansible-core 2.18 You can see what else we have planned for the release, but for “data tagging” the idea comes from the implementation of ANSIBLE\_UNSAFE which was introduced in 2.0 to try and keep track of (not surprisingly) unsafe data sources so they don’t cause mischief in the templating engine. That has turned out to be an imperfect solution, leading to many games of “whack-a-mole” with bugs and other security problems over the years. Data tagging is an implementation that does several things to improve upon the idea of ANSIBLE\_UNSAFE, but is essentially a very deep dive into many parts of the templating engine to maintain the chain of trust throughout templating. Ideally, once this is implemented internally, we hope to enable no\_log functionality by default, as we would be able to track data that came from secure sources such as a vault file, and ensure the contents of those variables are never printed to the screen. So that’s the 10,000 foot view of it 🙂 ---
**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\ **Post date:** [August 26, 2024, 9:32pm UTC](https://forum.ansible.com/t/vote-ended-on-2024-08-21-ansible-11-roadmap/7581/6 "2024-08-26T21:32:46Z")
From a module’s author point of view, what you can (eventually?) do with data tagging: 1. You can deprecate return values, so that if someone registers the output of your module and uses it, they will get a deprecation message. This wasn’t possible so far. 2. You can mark a return value as secret (no\_log). This in particular applies to values that have been passed into the module and are returned back; instead of replacing them with `VALUE_SPECIFIED_IN_NO_LOG_PARAMETER` or some other placeholder, it’s possible to return the real value with a `no_log` tag. I’m not sure whether this can already be done with the first implementation, but especially the first one was a thing that got me interested in this topic a looong time ago.