ansible-community / awesome-ansible Goto Github PK

The Default Labels in this Project are not "awesome" we should add Labels that are actually useful for an Awesome List :)

Some items on the list are Supported by Red Hat, should we highlight that?

Other projects are Maintained by Red Hat, should they be highlighted?

I've not looked at enough other lists to see what they do.

Take a look at similar awesome listing that uses automation for listing popular and trending items: https://github.com/pawamoy/best-of-mkdocs

Maybe we should make use of the same solution to maintain our listing?

Is this repo still being maintained? Seems like the addition was four months ago, and there are pull requests outstanding since Dec.

If not, happy to start maintaining at https://github.com/IronTooch/awesome-ansible

Should we tweet (could use the official Ansible Twitter account) when new items are added?

Original Post: https://www.reddit.com/r/ansible/comments/7ts02d/an_awesome_list_of_ansible_resources/dtf92v4/

Links to add:

• https://gist.github.com/marktheunissen/2979474
• https://codepoets.co.uk/2014/ansible-random-things/
• https://www.stavros.io/posts/automated-large-scale-deployments-ansibles-pull-mo/
• https://serversforhackers.com/c/running-ansible-programmatically
• http://blog.ippon.tech/ansible-tips-and-tricks/

Would you be interested in adding ansible-later to your list? It's a fork of ansible-review with some benefits and an alternative best practice checker to ansible-lint.

Regards
Robert

We should switch our default branch to main, to adhere to the Awesome List Guidelines: https://github.com/KeyboardInterrupt/awesome/blob/main/pull_request_template.md
other Issues might emerge as well.

Once all requirements are met, lets create a PR to add awesome-ansible to the awesome repository.

The travis.ci pipeline is broken, we should add a Github Action to replace it.

Q: Are there any great Actions for awesome lists, like Markdown Linters and stuff?

Title says it all, we should comb trough the Links Resources and Repositories to identify those that are stale, or no longer maintained.

Criteria could be:

• The project explicitly states it is no longer maintained, deprecated or superseded.
• The project does not show any activity in the last 18 month.
• The link is dead.

Add a PR Template to the repository.

I would like to start a discussion on the Topic of Quality standards, and Contributing Guidelines.

Currently the Contributing Guideline welcomes "everything" and it was up to me to get a feel for what makes an awesome addition, and what might better be rejected.

I do not like the Idea of Gatekeeping, and thous I would like these Quality Standards to be a general rule of thumb, and not a list of hard criteria every addition must meet.
Also I would not want criteria like a minimum star count on Github as having many stars is often a good indicator for something cool, but not every project with a lot of stars is necessarily awesome, or still actively maintained, you get the Idea!

I propose the following Quality Standards and updated Contributing Guidelines, and would like to get your Thoughts on it.

Thanks a lot!
^C

Contributing Guidelines:

• Search previous suggestions/issues before making a new one, to avoid duplicate suggestions.
• Make an individual pull request for each suggestion.
  • Use the following format: - [Title](link) - Description.
    • Link should preferably point to the GitHub repo of a project.
    • Keep descriptions short and simple, but descriptive.
    • Descriptions should not be marketing taglines.
    • Descriptions should not be title-case.
    • Start the description with a capital and end with a full stop/period.
    • Remove any trailing whitespace.
    • Don't mention Ansible in the description as it's implied.
    • Each item should be limited to one link.
    • Please avoid redirection (careful with http vs https!).
  • ℹ: The formatting is linted by the CI Pipeline. If it fails, please check your formatting.
• If you submit a project that is similar to an existing project in the list, please point out how it's different.
• New categories or improvements to the existing categorization are welcome.
  • Add the category description.
  • Add the category title to Table of Contents.
• A pull request should be 100% ready and should adhere to all the guidelines when you open it.
• Check your spelling and grammar.

Quality Standards:

• The submitted Project/Tool:
  • should be more than 30 days old.
  • should be actively maintained.
  • should be compatible with the latest supported Ansible version.
• Tutorials, Videos, Courses, Blog Posts and Opinions:
  • should use/follow modern Ansible paradigms.
  • should not teach things that are deprecated in the latest supported Ansible version.