Relates to Proposal: Consolidating Ansible discussion platforms
Because quality of communication are vital for good package-content user and contributor experience, I suggest discussing, polishing, and merging the PR [Needs SC vote before merging] Collection requirements: add Forum-related reqs by Andersson007 · Pull Request #1703 · ansible/ansible-documentation · GitHub adding more Forum-related statements to the collection requirements.
Please take a look and share your thoughts.
@SteeringCommittee it’s time to vote on the PR. It ends on 2024-08-19
Let’s bring the discussion from GitHub here to the Forum 
I think it’s worth discussing it a bit.
On GitHub @gotmax23 raised the issue of whether we want to force collection maintainers to become active on the forum:
I don’t support requiring forum maintainers to make themselves individually available on the forum. Some maintainers may only wish to interact with users who have concrete bugs or feature requests via their structured issue tracker or have other reasons to avoid the forum, and I think that’s okay.
I think this would be better structured as a guide on a separate as to how collection maintainer maintainers can interact with the forum, not how they must.
@Andersson007 replied to this:
Thanks for the feedback!
User posts on the forum can actually reveal bugs or request features (even not intentionally).
IMO if maintainers want their collections to be in the package, they are expected to provide the best user/contributor experience possible not leaving their questions unanswered/concerned not addressed.
There are, of course, sometimes questions that are out of scope but we should react somehow anyway.
Being a maintainer of two of top-searched collections and resp subscribed to the tags, I wouldn’t say I get too much of info load from the forum (i’d say it’s rather rarer).
So if you’re subscribed to only your tag, it shouldn’t be a burden but even if there is, it’s actually good and a part of open source, and we should be committed as maintainers to communicate with our users and contributors on the Ansible default communication platform:)
I’ve been thinking a bit (on and off) about this for the last few days. I think it’s important to point out (like Andrei) that this is about maintainers for collections included in the Ansible community package, not about general collections. We can definitely expect more from such maintainers than from maintainers of collections not included in the package.
I think we have to discuss two things in more detail:
Why would maintainers (of collections being added in the future) object to participate in the Forum? This could be for different reasons; two that I can think of straight away are:
I’m not saying that it’s not OK to force maintainers to participate in the Ansible forum, but we need to acknowledge that this puts an additional burden on maintainers, and especially community maintainers (who might do this in their free time, without getting paid for it!) might not find this acceptable.
What to do with maintainers of existing collections who don’t want to participate in the Forum? Do we remove their collections from the package (assuming we accept this)? Or do we simply ignore them, or only consider this if we start searching for reasons to exclude a collection anyway? (We seem to often resort to the latter approach for new rules…)
Now coming to actual opinions - I tried to impartially sum up things so far
Regarding 1, I think this is quite related to Proposal: Consolidating Ansible discussion platforms. If we want to make the Forum the default communication platform for Ansible, I think it is reasonable to expect collections included in the community package to be present on the forum. While it might be “yet another forum” (the “official” forum for a service / product), we want the Ansible forum to be the main entrypoint for Ansible related questions, which often also tend to affect specific collections / services / products. Even if another forum might be a better place for a specific question related to a specific service / product. (Even if only someone replies to a specific question that it’s less an Ansible question but more a question about that service / product and should better be asked in the other forum.)
Maintainers should be subscribed to the Ansible forum anyway for “news for maintainers”, so I think subscribing to a tag that applies to your collection - that doesn’t mean you have to reply to every discussion with that tag! - isn’t that much of an additional burden.
I’m more worried about 2. We have ~100 collections included in the Ansible community package. We already have some issues with collections ignoring (for various reasons, I don’t want to make this sound accusational) our rules. I’d guess that for the actively maintained community collections the authors are probably mostly active on the forum anyway, but then we have a lot more collections on that list. I’m really not sure what we should do here, especially if maintainers actively refuse to take part in the forum. Using this reason to remove a collection from the package seems to be very petty.
@felixfontein thanks for summarizing and raising the quesions
Yes and no. Of course, maintainers don’t have to reply to every thread that has “their” tag. But I think it’s a valid opinion to see the forum as a “users helping users” place and, if there’s a real problem with a collection, people have to open an issue / PR in the repo. Don’t get me wrong, I think it would be valuable for maintainers to have a close look at the forum. But I’m not sure if we should enforce this. I don’t see how it could be helpful to make maintainers subscribe to “their” tags and they ignore all the threads.
I’m fine with the requirement to mention the forum, though. And maybe even to require a (new or already existing) tag for the collection. But ATM I think this is going a little bit too far.
Let’s try and see:) If users post related questions, it won’t harm to have maintainers subscribed. I’m sure there are a lot of responsible folks taking the requirements seriously:)
I think it’s possible to split this proposal into two parts:
In any case, I voted against the proposal since it combines 1 and 2, and I don’t think 2 is a good idea.
sure, having controversial things in fine, once this vote ends, anyone interested can submit another specific proposal for discussion and vote
given the recent discussion and after thinking about it longer I’ve changed my vote to No, i can’t agree with the forced interaction.
it’s also not practically enforceable even if we wanted to, the result of enforcement (removal from the package) doesn’t make sense if the collection is otherwise functional and meeting standards and the maintainer is active addressing issues and PRs.
If we say we’re not going to enforce it evenly and only apply it in extreme cases then I would again question why we need it at all.
Same here after reading the latest developments, I will agree with @felixfontein on the idea of breaking this into smaller pieces. There is the part we are likely going to agree with, and there is the other part, so let’s not lose the first because of the second.
I think it’s fine to be in there as a SHOULD, but MUST both places more emphasis on it than seems warranted and is inaccurate if it isn’t going to be enforced.
Thanks for the feedback! As now i see the opinions have shifted to the opposite direction 
, I’ve just made it SHOULD for maintainers to be subscribed. Please take a look at the commit and approve/suggest specific changes if needed.
Thanks for incorporating the feedback, @Andersson007. I am more open to this, as my main concern was requiring maintainers to make themselves available for support in another medium. but I still see setting up the group and links as creating extra work for maintainers, and having tags for every collection even if nobody is actively checking them seems counterproductive to me.
Also, I’m not sure the tag-per-collection model makes the most sense. For example, I don’t think the community.general collection should have its own group and tag named general.
Every new requirement is extra work, the question is always whether the extra work is worth the effort. I think here it is.
First, setting up a group is optional and not required.
Second, having one (or more) tags for a collection is generally helpful even if nobody (or no maintainer) subscribes to these: they allow to search for other discussions on the collection / its contents without having to rely on using the right keywords in the free-text search. This is quite an improvement for Ansible users IMO, and thus worth some (basically one-time) extra work for collection maintainers.
community.general and community.network are special in that most discussions on the forum for content in them, using the tag doesn’t make sense. It mainly makes sense when talking about the actual collection, or asking questions on the collection structure, the content for it, etc. IMO having a specific tag for these collections does make sense, but it should be used differently than for other collections.
(And there are situations when having a group for it at least temporarily could make sense as well. I didn’t request groups for any of “my” collections so far, only tags: Requesting a tag/forum group - #34 by felixfontein)
But there’s no tag-per-collection model, is there? As far as I can see, the suggestion currently allows to
reuse at least one of the existing tags
It looks like there’s also a suggested change to clarify this:
Multiple collecions can share a tag if they cover similar topics; for example,
amazon.awsandcommunity.awscould both use the tagaws.
Basically, I think this is a good idea because it gives users a more accessible way to ask questions and discuss things on a topic they’re interested in. I think a forum is easier to use than GitHub or Matrix for people who are not power users.
Additionally, I think this is a great opportunity to build communities of users who are helping each other. As I’ve said, a forum is easier to use than GitHub or Matrix.
“The right keyword” is surely just the collection name? Which will be a more reliable search than hoping that people actually bothered to use a tag.
@flowerysong if you search for “how to do xxx with amazon.aws” (resp. the relevant set of keywords for that, including amazon.aws) you might miss that it can be done with community.aws.
(Also we did have collections that were renamed in the past.)
(Also especially for plugins/modules with short names that were already present in Ansible 2.9, users still omit the collection name rather often. So searching by collection name won’t necessarily find these discussions either.)