Proposing a New "Red Hat Partners" Category for the Ansible Forum

Project Discussions
, , , , ,
1

Hi everyone,

I’d like to propose a new category on the Ansible forum and get feedback from the community.

During the Contributor Summit session in Ghent, I shared an update about the Community and Partner Engineering team at Red Hat. As part of that I gave an overview of the Red Hat partners and how they are part of the Ansible community ecosystem.

To be clear, when we say Red Hat partners we’re specifically talking about ISV partners who create supported or certified collections. You can find the overview that we gave of Red Hat partners in the Ansible community in our forum post about Contributor Summit.

As part of the discussion we also got feedback from our contributors and community members about the lack of transparency around the certification process. It’s true that much of that information lives outside the forum, which means it is easy to miss and harder to discuss openly. We’d like to change that.

We’re proposing a new Red Hat Partners category that is dedicated to content related to the certification process and partner ecosystem. The intention is to use the category for announcements about certification requirement changes as well as technical details and guidance relevant to the certification process.

For example, announcements and other posts in the Red Hat partner category will include content such as:

  • Upgrading test coverage for Python versions to stay aligned with Red Hat Ansible Automation Platform lifecycle changes.
  • Announcing and discussing new certification requirements.
  • Upcoming changes to the certification tooling, such as new Ansible Lint versions that introduce checks against new rules.
  • Highlighting common issues that partners face with the certification process and tips on how to address them.

Currently these announcements are made via email without a mechanism for reply or discussion. We saw with the core 2.19 templating changes that having discussions in the forum (such as this thread and this thread) was helpful to everyone. We were able to build up a library of resources that all collection maintainers, including Red Hat partners, found useful.

Alongside the new category, we’d also like to introduce a red-hat-partner tag. This tag will help us cross-reference and organize content relevant to partners. For example, we can use the tag to flag threads in the Collection Development category as relevant to partners.

We want to be clear that the new category proposal is not intended to replace or compete with the Collection Development category. All discussion related to collection development, best practices, tooling, CI/CD, general Q&A belongs in the Collection Development category and should stay there. The new Red Hat Partners category is specifically scoped to certification and the partner program. Partners will also be able to watch the category and get emails about updates. The tag is there to bridge the gap when there’s overlap.

The certification process affects a meaningful part of the community and it benefits everyone when the process is visible and open for participation.

Before we go ahead, we want to hear from you:

  • Does this seem like a useful addition to the forum?
  • Do you think having a separate partners category is unnecessary fragmentation?
  • Do you have concerns about the boundary between the proposed partner category and the existing Collection Development category?
  • Are there any suggestions on naming or structure?

Thanks for taking the time to read this. We look forward to the discussion.

5 Likes
Some thoughts from CfgMgmtCamp about collection testing tools
2

Are you proposing a new top level category or a sub-category like the Collection Development category?

1 Like
3

Great question! I was hoping we’d get into this detail because there are some important differences between top-level category and sub-category. There’s a balance we need to figure out.

We want to keep posts relevant to Red Hat partner collections distinct from community collections to avoid confusion.

For example if we want to highlight technical reasons for a new rule in the certification process, we don’t want community maintainers to get the impression that the rule applies to the Ansible community package inclusion requirements.

We also don’t want to go too far and give the impression that the forum is an “official” Red Hat support channel. The scope for using the forum for Red Hat partner communication is limited to technical concerns around collection development and maintenance.

If a partner needs help with their Red Hat account in some way, that is not appropriate or relevant to the forum. We won’t approve and will delete any such posts (while providing assistance through the “official” channels). This is a forum for community participation, not a place to get product support.

The goal is to bring partners closer to the community so folks can get visibility into the certification process. We also want partners to collaborate here like anyone else to participate in discussion and help each other out.

I could also create a poll to decide if A we create a partner category or not B we add a top-level category or sub-category. It’d be great to get some more discussion first and hear what people think before we put it to a vote.

1 Like
4

As a Debian and Ubuntu user I must admit I don’t have a view either way :wink: .

1 Like
5

@chris That’s a good point.

If we think about some of the recent topics that Red Hat has emailed Partners about that might help give a sense of the forum structure.

1 Like
6

I think it’s a good idea, this will make it easier for community members to see what is happening in the partner realm (which has been a problem in the past, see in particular this thread: Improve collection maintainer communications about community package release schedule)!

3 Likes
7

Thanks for the feedback so far. To help give an idea of the content for the proposed partners category, it might be useful to share some updates to the certification process that we’ve recently been communicating to partners.

Note that I’ve provided an abridged version of the details below. These are just examples of the type of posts that we’d like to share in a partners category / sub-category.

Updates to Ansible Core and Python version compatibility

Red Hat Ansible Automation Platform is ending support for Ansible Core 2.15 and Python 3.11.

As a result, compatibility with Ansible Core 2.16 as the minimum required version will be a mandatory prerequisite for collection certification or validation. Likewise certified and validated collections must be tested against Python 3.12 to ensure compatibility with AAP.

This transition is driven by critical technical and lifecycle milestones, as follows:

  • Following the lifecycle for AAP 2.4, support for Ansible Core 2.15 is reaching End of Life for Critical Security Fixes. For reference, see Table 1.1 - Current AAP and Ansible Core lifecycles on the Red Hat Ansible Automation Platform Life Cycle page.
  • AAP is rebuilding on Python 3.12 to facilitate upgrades from Django 4 to Django 5.2 LTS and come into tighter alignment with the RHEL Python lifecycle.

Skipping Ansible Lint rules

The community and partner engineering team are planning to update certification requirements to disallow adding a skip_list to Ansible Lint configurations. We plan to start working with partners to address Ansible Lint violations on a phased approach that prioritizes rules to avoid errors or unexpected behaviour such as the following:

  • ignore-errors can hide failures and can be quite dangerous. To address this violation, we suggest reviewing each instance to see if it can be replaced with failed_when or changed_when error handling.
  • schema[meta] and schema[vars] violations can cause runtime failures or unexpected behaviour. This is essential to the integrity of the collection metadata and must be fixed before the next release.
  • var-naming[no-reserved] could cause errors that are not obvious and potentially breaks functionality.
  • fqcn[action-core] and fqcn[keyword] are important for overall reliability and forward compatibility.
2 Likes
8

@SteeringCommittee what do you think about it?

2 Likes
9

I’m wondering if a new sub-category under Project Discussions , next to Project Discussions > Collection Development would work?

10

Potentially but there might be other posts relevant to partners only that do not fit in the Project Discussions category. Would we then need an additional partners sub-category under News & Announcements ?

It seems like a top-level category would give us some flexibility in the scope that might be handy in future.

FYI: I’m planning to speak with @gwmngilfen about this topic and get his insights. He might chime in here since I’ve pinged him. But I’ve got a 1:1 this week and this is top of my agenda.

1 Like
11

I think it’s a good idea @oranod.

  • It would provide more transparency into the partner “realm” (I like how you put it @felixfontein) which was feedback we received during the CfgMgmtCamp Contributor Summit.
  • We could share updates for partners and have that be visible to the community too.
  • IMHO it makes sense to have a “Top Level” category because it would provide more flexibility for the future (if needed).
  • Having partners look at the forum would give them more visibility to see active conversations in Project Discussions - Ansible and Collection Development - Ansible. They could participate if they wanted, provide ideas, feedback and even contribute back to tooling. Partners have engineers who are collection maintainers too and they use the same tooling as the community. It just makes sense in my mind.
1 Like
12

I like the idea of having a sub category under “Project Discussions”. But a broader one called “Partners” or “Enterprise Users” or something.

13

I would suggest creating a top level category to avoid fragmentation in case (and it’ll probably be the case) it’ll get wider than just be about collection development

14

Was thinking about it some more. Maybe we should use only a tag for Red Hat partners and not create a unique category, whether top-level or subcategory.

We borrowed from the organizational strategy from the Fedora forum. This post from Matthew Miller as well as this post give some food for thought.

You can watch tags just like you can categories. So we don’t have to have a category as a mechanism for partners to subscribe to relevant posts in the forum.

15

These are two really good writeups, which if folks have the time I do recommend reading.

A post having multiple tags is a really powerful feature, and as Don reminds us, you can subscribe to any combination of (sub-)categories or tags.

A lot of forum posts are relevant for Community & Partners, so being able to add multiple tags to represent this avoids duplication.

16

Hi again, so I did catch up with @gwmngilfen about this. In some of my earlier posts in this thread I feel like I was trying to express a risk that Greg was able to capture really succinctly.

We want to bring partners into the forum and increase transparency because there is enormous benefit to everyone. At the same time we definitely want to avoid disruption and confusion. I think that has been the main reason for proposing a new category, either top-level or sub-category.

Maybe this gives the impression of Red Hat partners as a special group, which opens up the risk of becoming creating a 2-tiered community. That would not be a good outcome.

Perhaps a sensible way to start is creating a partner section under News & Announcements at the same level as News & Announcements > Ecosystem Releases

One of the types of communication we’d like to post on the forum are partner announcements. We have a news category so let’s start there. If it turns out we actually do need a partner category then we can create it later.

For collection development topics, maybe we should just start with a red-hat-partners tag in the Project Discussions > Collection Development sub-category? We proposed a new tag anyway. And, because you don’t always notice tags on posts, the Community and Partner Engineering team can also adopt some standard boilerplate text for partner posts to make that clear and avoid confusion.

What do folks think?

2 Likes
17

I have been lurking in the shadows on this one until now - this idea seems to be the best so far, IMHO. I was concerned about the “2-tiered community”, so I think this use of tags (and that specific subcategory) sounds like a good compromise.

2 Likes
18

Hey everyone,

Thanks again for the discussion here. I was talking about it with @gundalow and @Andersson007 and we thought it’d be good to bring this to a vote.

I’ll start with a summary of our plan. We want to bring Red Hat partners into the forum to encourage open participation and increase transparency for the community. To support those goals we propose the following:

  • Create a new red-hat-partner tag.

  • Create a new “Red Hat partners” sub-category under News & Announcements.
    We’ll use this for notifications for partner specific topics, such as raising awareness of changes to the certification process. Having a specific sub-category clearly distinguishes partner posts from other announcements.
    Note that this new sub-category is not intended to replace existing communication channels but to provide the community with transparency on certified and validated collection updates and announcements where it is appropriate.

  • Ensure that any posts in the Collection Development sub-category are clearly identified in the title and body in cases where it is needed to avoid uncertainty or confusion.

Please share your thoughts in the poll below. We plan to close this poll by Friday, March 13, although we might leave it open for longer if it looks like folks need more time to respond. Thank you!

  • Current plan sounds good
  • Use a red-hat-partner tag only without a distinct sub-category under News and Announcements
  • I think another approach is better (please reply and explain)
0 voters
2 Likes
The Bullhorn #220