[Discussion]: Quality Standards and Contributing Guidelines

[KeyboardInterrupt]

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.

[samccann]

Hey @KeyboardInterrupt - coming in over a year later, but we had a related topic on this at ansible-community/community-topics#220

I'm the docs lead for the Ansible core docs (aka docs.ansible.com). I think the guidelines above are great and perhaps worth putting in the contributing guidelines.

Since I'm not technically savvy enough to know if a new tool is worth adding, maybe a part of this set of guidelines is that each PR is brought up in the docs or community working group meetings to get another set of eyes on it before we merge?

[KeyboardInterrupt]

Hey @samccann, life threw me into a whirlwind, and I had to take a hiatus from most online communities and activities. Ready to jump back in now, though!

I'd be super grateful for extra sets of eyes on the list. What's the drill for presenting something like this in our working group meeting? Attending in person is a rarity for me, so if there's an asynchronous option, that would be ideal.

greetings!
^C

[samccann]

Hey @KeyboardInterrupt ! Can you open a forum topic instead? That's where we've been having discussions now across all the Ansible projects. It allows other people to see what's happening and get involved without having to follow a bunch of different repositories.

[gundalow]

I feel the forum.ansible.com could really help here, as we have a huge amount of people looking at it.

The forum supports Markdown, so @KeyboardInterrupt it you want, you could just copy your original message and add a link to this repo as your first forum post.

I agree with your comment that making this process asynchronous is best (ie without meetings)