Hi, this is a followup from previous discussion at ConfigMgmtCamp. I discussed with @gundalow please let me know if you find this useful.
Proposal: Improving Bullhorn Content Quality
I propose presenting Bullhorn content in a more story-driven format. This would follow a predefined structure using elements like charts, maps, links, infographic, and tables to present information in a clearer and more engaging way. Such a format would make the content easier to understand, more visually appealing, and better suited for sharing on social media. We can experiment on this format and if successful, create a template for future posts.
Execution
To implement this, we would need to design and adopt a structure along with clear usage guidelines. The structure can be shaped with input from Ansible contributors to reflect how they want to consume Bullhorn content.
Benefitstothe Community/Audience
This approach would help readers quickly grasp the essence of an event or update. Even non-users could get a concise overview of the topic and its practical impact, which could also support broader promotion and outreach.
Technical benefits for the Ansible ecosystem
• Provides a consistent, structured format for presenting technical updates across Bullhorn editions
• Makes release notes, collection updates, deprecations, and roadmap items easier to track and understand.
I’ve prepared a full fledged post which shows my experience attending Ansible track in CfgMgmtCamp this year. While the structure can be modified/discussed/tweaked, I hope this will spark some discussion on how we can make the content more useful/appealing.
Mixed feelings here. Without seeing what exactly the new format is going to look like, it is hard for me to have any opinion on the change.
As of the current format, it serves my needs as-is: I get the announcements, not all of them I want/need to know deeply, but I will have seen them and they usually have links to topics in the forum if I want to know more. And of course the news of releases of Ansible (core and ACP) and collections is very welcome.
I am struggling to envision what the story-driven format would look like: if it means the same information with more narrative around it, personally I would not be very keen, but TBH I am not sure. Just my $0.02
I think one thing that might help is copying a recent Bullhorn entry from News & Announcements > Newsletter and replying to this thread with what it could look like.
The Ansible package includes ansible-core and is a batteries-included package that provides a curated set of Ansible collections. See the Ansible roadmaps for future release plans.
Ansible package 13
Ansible package
command
Release Notes
Ansible 13 Porting Guide
contributor
13.3.0
python3 -m pip install ansible==13.3.0 --user
(ansible-build-data/13/CHANGELOG-v13.md at 13.3.0 · ansible-community/ansible-build-data · GitHub)
(Ansible 13 Porting Guide — Ansible Community Documentation)
Second version looks a bit more informative to me. Maybe links to github, rather than pypi should be included.
Just my opinion, but second one looks less cluttered and bit more informative. I mean 70+ minor changes (i was tired counting)! This is impressive and requires a shout out!
Other collection updates also can be rewritten similar way.
And I agree these changes look very nice and are definetely positive improvements.
Also ansible==specific version doesn’t include ansible-core==another specific version, but ansible-core>=another specific version,<next major version. I think that’s an important distinction.
Sub-headings as in name/title of the collection that we are highlighting? If so, I am preparing another reply tomorrow that takes into account the suggestions/comments I have got so far.
The Ansible package includes ansible-core and is a batteries-included package that provides a curated set of Ansible collections. See the Ansible roadmaps for future release plans.
Ansible package 13
Ansible package
command
Release Notes
Ansible 13 Porting Guide
contributor
13.3.0
python3 -m pip install ansible==13.3.0 --user
(ansible-build-data/13/CHANGELOG-v13.md at 13.3.0 · ansible-community/ansible-build-data · GitHub)
(Ansible 13 Porting Guide — Ansible Community Documentation)
12.3.0 (CHANGELOG.md) is a regular feature and bugfix release with 70+ minor changes, six bugfixes, and one new filter module. 11.4.4 (CHANGELOG.md) is a regular bugfix release.
I’ve been focusing on improving the content quality of the Bullhorn release, and I would really appreciate it if you could take a look and share your feedback.
Please also let me know if there’s anything else I can contribute to or help with.
I’m no native speaker, but “major new releases” sounds a little bit unfortunate to me. At first, I confused this with “new major releases” and than realized that this is not about major releases at all.
I suggest to substitute the “major” with something else (main, important, published…) or simply drop it completely (“New releases”).
(I was looking at this again since I’ll be writing a new one for this quite soon )
For accessibility reasons link titles should kind of identify what they link to. Neither “12.3.0”/“11.4.4” nor “CHANGELOG.md” is thus a great title. The main reason I was using community.general 12.3.0 as the link title to the changelog was to avoid these issues.
If we also want a Galaxy link, how abount something like this?
I don’t know if this would be a good idea, but thought it might be worth to throw into the discussion.
Anyway, if link titles should kind of identify what they link to I think it would be a good idea to use Release Notes. The file is CHANGELOG.md but if you look at it the title is Release Notes.
I wondering who actually needs the Galaxy links? You only need it if you want to download the collection tarball from there directly IMO. I think the changelog is more useful, that’s why I put it first.
)