Should we revamp the tools and programs page?

Project Discussions
, , ,
1

The Tools and Programs page feels dated and in conflict with Awesome Ansible.

We also decided some time ago that most new tools etc should go to awesome ansible.

So, I’m thinking we should trim down this Tools and Programs page to only what is in our github orgs at this point to make the decisions easier on what goes where. (ansible, ansible-community, ansible-collections orgs).

I also propose we put this page under Steering Committee control. This puts a gate on PRs so we don’t accidentally merge a PR that doesn’t belong, and also gives us flexibility and a decision-making body in case there are cases where we do want to add a tool to this page that is outside the listed github orgs.

1 Like
2

Good spot, and I like your idea

Assuming others approve, if someone wants to add a CODEOWNERS file for the relevant directories to ping the Steering Committee that would be great.

1 Like
3

It looks like this is part of the Ansible Collections Contributor Guide, so it might make sense to put it under SC control. Not only to avoid accidentally merging PRs, but also to make clear that it’s our responsibility to maintain it / keep it healthy.

Apart from this, I see several issues with this page. For example, I think we don’t need the popular editors section. There are dozens, if not hundreds of editors. We can’t document all of them. BTW are Emacs, PyCharm, Sublime, vim and Visual studio code really that popular? Who decided this? I personally use vim a lot, but is it really that popular nowadays?

Another issue is outdated tools. For example, jctanner’s Ansible Tools hasn’t seen a commit since 4 years.

And there are also duplicates that are already mentioned in Awsome Ansible, like Ansible Lint and Molecule.

I think there’s a lot to discuss. Thanks for starting this topic!

1 Like
4

The proposal and what’s mentioned in the comments so far SGTM

I’ve created a PR [Needs SC review] community/other_tools_and_programs.rst: update by Andersson007 · Pull Request #2284 · ansible/ansible-documentation · GitHub, PTAL to keep the ball rolling

5

Let’s ensure that awesome-ansible had all these links (and subsections for each text editor) BEFORE we merge the the ansible-documentation PR

Should we add CODEOWNERS in the same PR?

6

@gundalow , as we are not sure as the projects are still maintained (i picked one and it doesn’t work + the last commit was 6 years ago), instead of moving them i would suggest opening issues in their repos to ask maintainers to add their projects to awesome ansible if relevant. What do you think?

7

While I agree some of the repos maybe old, that’s pushing the work to the many individual maintainers of the tool when we’ve made this problem (by refactoring the docs)

Let’s get a PR raised against awesome ansible and we can review there

8

I prefer @Andersson007 approach, at least for projects we KNOW don’t work. Why add them to Awesome Ansible if they don’t work? That is part of the reason to move these tool recommendations under SC control, so that we raise the bar on what we are recommending.

For known-good tools, yes, let’s open the awesome ansible PR as well.

1 Like
9

OK, let’s add the things we know are likely good.

1 Like