Improve ansible-collections issue templates

[mariolenz]

When someone opens an issue I often miss the information what version of the collection is used. The one that comes with ansible or a different version installed via galaxy? Maybe this question should be part of the template.

What do you think?

context: ansible-community/collection_bot#29 (comment)

[dmsimard]

o/ I've transferred this to the right repository so we can chat about it at our next meeting.

In essence, the proposal is to add a field in the default ansible-collections issue template to ask about the version of the collection used as well as how it was installed.

[mariolenz]

In essence, the proposal is to add a field in the default ansible-collections issue template to ask about the version of the collection used as well as how it was installed.

Exactly. You see, if someone using ansible 2.10.4 opens an issue for a collection, it's quite a difference if it's version 1.3 of the collection that comes with this ansible version or the latest and greatest 1.14 from galaxy.

I have a feeling that I ask this question a lot (for example here) and if others do, too, it might be a good idea to make it part of the template.

[dmsimard]

We discussed this in the meeting today and agreed it was a good addition to the issue template.

We should open a PR against https://github.com/ansible-collections/.github/blob/main/.github/ISSUE_TEMPLATE/bug_report.md to add the question. There should be a small snippet of text that explains how to retrieve the information, for example ansible-galaxy collection list and ansible-galaxy collection list <namespace>.<collection>.

[mariolenz]

We discussed this in the meeting today and agreed it was a good addition to the issue template.

We should open a PR against https://github.com/ansible-collections/.github/blob/main/.github/ISSUE_TEMPLATE/bug_report.md to add the question.

I've opened ansible-collections/.github#4 to address this. Thanks for your help @dmsimard!

[felixfontein]

Since the PR needs to be discussed at the meeting, this should stay open so we will actually discuss it :)

[mariolenz]

@felixfontein

Since the PR needs to be discussed at the meeting, this should stay open so we will actually discuss it :)

I'm mostly working on community.vmware and wouldn't have closed an issue just because a PR exists. But since this issue is in ansible-community/community-topics and the PR is in ansible-collections/.github (a different repo), I thought I can close it here. Any discussions could take place in the PR, after all. But I'm fine with keeping this issue open, it's your open issue ;-)

Btw, would it be possible to add Fixes: ansible-community/community-topics#23? Well, I just did but would this issue be automatically closed when ansible-collections/.github#4 is merged? Does this work across repos?

[felixfontein]

Any discussions could take place in the PR, after all. But I'm fine with keeping this issue open, it's your open issue ;-)

The PR probably needs approval from the community meeting, so it's better to track it here. Anyway, it's Ansible community's issue, not mine ;)

Btw, would it be possible to add Fixes: ansible-community/community-topics#23? Well, I just did but would this issue be automatically closed when ansible-collections/.github#4 is merged? Does this work across repos?

Good question. I know it works accross repos in the same namespace, but I'm not sure whether I've seen it accross namespaces yet. I guess we'll find out :) (It also depends on who merges it - the person needs sufficient rights in both places.)

[mariolenz]

But I'm fine with keeping this issue open, it's your open issue ;-)

Anyway, it's Ansible community's issue, not mine ;)

I didn't mean your personal issue, but your ansible-community/community-topics issue ;-P

Btw, would it be possible to add Fixes: ansible-community/community-topics#23? Well, I just did but would this issue be automatically closed when ansible-collections/.github#4 is merged? Does this work across repos?

Good question. I know it works accross repos in the same namespace, but I'm not sure whether I've seen it accross namespaces yet. I guess we'll find out :)

Yep, let's find out :-)