[Needs SC vote before merging] Collection requirements: add Forum-related reqs

[Andersson007]

trafficstars

Related to https://forum.ansible.com/t/proposal-consolidating-ansible-discussion-platforms/6812/19

• Related forum topic is https://forum.ansible.com/t/forum-to-ansible-community-package-collection-requirements/7316 but any suggestions here now are welcome
• The PR refers to collection_template README Communication section. It's being changed now in https://github.com/ansible-collections/collection_template/pull/71 <- this is how it's going to look

[Andersson007]

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.

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:)

[Andersson007]

i've opened related polls, please vote

[felixfontein]

I've tried moving the discussion that @gotmax23 started to the forum (https://forum.ansible.com/t/7316/3).

[Andersson007]

Folks, does the commit https://github.com/ansible/ansible-documentation/pull/1703/commits/782edd350d9283bf67a0d100002af91966d33219 address your concerns? Please take a look and say what you think / suggest specific changes

[gotmax23]

To avoid fracturing the discussion further, I left my response to the latest proposal in the forum. Thanks!

[samccann]

@Andersson007 - once the last comment from @gotmax23 is resolved, it's probably worth pinging SC members individually here or in the forum to re-vote. Seems like many aren't aware and thus the vote is still heavily on the 'no'.

[Andersson007]

@Andersson007 - once the last comment from @gotmax23 is resolved, it's probably worth pinging SC members individually here or in the forum to re-vote. Seems like many aren't aware and thus the vote is still heavily on the 'no'.

yeah, committed the last comment, pinged the folks individually to take another look at the PR and the poll, thanks

[Andersson007]

rebased to get rid of the CI failure

[patchback[bot]]

Backport to stable-2.15: 💔 cherry-picking failed — conflicts found

❌ Failed to cleanly apply e8102e8f25d78fc76b2fc9cd886636496497b6bf on top of patchback/backports/stable-2.15/e8102e8f25d78fc76b2fc9cd886636496497b6bf/pr-1703

Backporting merged PR #1703 into devel

1. Ensure you have a local repo clone of your fork. Unless you cloned it from the upstream, this would be your origin remote.
2. Make sure you have an upstream repo added as a remote too. In these instructions you'll refer to it by the name upstream. If you don't have it, here's how you can add it:

   $ git remote add upstream https://github.com/ansible/ansible-documentation.git
   

3. Ensure you have the latest copy of upstream and prepare a branch that will hold the backported code:

   $ git fetch upstream
   $ git checkout -b patchback/backports/stable-2.15/e8102e8f25d78fc76b2fc9cd886636496497b6bf/pr-1703 upstream/stable-2.15
   

4. Now, cherry-pick PR #1703 contents into that branch:

   $ git cherry-pick -x e8102e8f25d78fc76b2fc9cd886636496497b6bf
   

   If it'll yell at you with something like fatal: Commit e8102e8f25d78fc76b2fc9cd886636496497b6bf is a merge but no -m option was given., add -m 1 as follows instead:

   $ git cherry-pick -m1 -x e8102e8f25d78fc76b2fc9cd886636496497b6bf
   

5. At this point, you'll probably encounter some merge conflicts. You must resolve them in to preserve the patch from PR #1703 as close to the original as possible.
6. Push this branch to your fork on GitHub:

   $ git push origin patchback/backports/stable-2.15/e8102e8f25d78fc76b2fc9cd886636496497b6bf/pr-1703
   

7. Create a PR, ensure that the CI is green. If it's not — update it so that the tests and any other checks pass. This is it! Now relax and wait for the maintainers to process your pull request when they have some cycles to do reviews. Don't worry — they'll tell you if any improvements are necessary when the time comes!

🤖 @patchback I'm built with octomachinery and my source is open — https://github.com/sanitizers/patchback-github-app.

[patchback[bot]]

Backport to stable-2.16: 💚 backport PR created

✅ Backport PR branch: patchback/backports/stable-2.16/e8102e8f25d78fc76b2fc9cd886636496497b6bf/pr-1703

Backported as https://github.com/ansible/ansible-documentation/pull/1762

🤖 @patchback I'm built with octomachinery and my source is open — https://github.com/sanitizers/patchback-github-app.

[patchback[bot]]

Backport to stable-2.17: 💚 backport PR created

✅ Backport PR branch: patchback/backports/stable-2.17/e8102e8f25d78fc76b2fc9cd886636496497b6bf/pr-1703

Backported as https://github.com/ansible/ansible-documentation/pull/1761

🤖 @patchback I'm built with octomachinery and my source is open — https://github.com/sanitizers/patchback-github-app.

[Andersson007]

thanks everyone for making the original proposal much better!