[ [Roles]] ](/ansible/community/wiki/[Communication) | [Reviewing]] | TODO ]

THIS PAGE IS OLD and no longer maintained. For questions, please use the Ansible forum.

Self-assessment checklist (draft)

A Working Group has many fronts to cover and some of them are more important than others. Below we have a list of things any Working Group can evaluate to see how they score compared to others, and what they could be working on.

Working Group status

• Does your Working Group have at least 2 active leads ?
  • Would it be beneficial if new leads were elected ?
• Is there regular activity in your Working Group ?
  • Are open issues and PRs being discussed regularly ?
  • Are design changes being discussed between members ?
  • Are there regular meetings or sprints to tackle issues ?
  • Do members actively review each others issues and PR's ? Are people mentored ?
• Are new members invited to help out in the Working Group ?
  • Often new members bring new ideas, but need to be mentored to become active
• Would other communication channels help improve the Working Group ?
  • Would an IRC channel or Matrix bridge help the WG's cause ?
  • Would an open agenda and regular meetings be of any use ?
• Are there any processes or tools your WG is using that would be beneficial to others ?
• Is your issue and PR backlog under control ?
  • Do all issues and PR have recent activity ?
  • What would be needed to speed up closing issues and PRs ?

Module status

• Does every module have an integration test that covers all aspects of the module ?
  • Even when the module cannot be automatically tested, having integration tests helps the WG to evaluate changes.
  • Does it cover idempotency and check-mode ?
  • Does it test error-conditions ?
  • Does it test special conditions or optional logic (e.g. backup) ?
• Do you have a module_utils library that shares codes between modules ?
  • Does it have an argument_spec definition that shares common module parameters ?
• Does check-mode actually cover all changes made, or is it just a stub exit-function at the top ?
  • Does check-mode behaves as closely as possible to a real run ?
  • Does it also return information as if it was run ? (Not always possible...)
• Are any of your modules listed to ignore certain tests (because they fail) ?
  • Did you check the validate-modules ignore list ?
  • Did you check the pylint or pslint ignore list ?
• For additional requirements when developing modules, see Ansible's Conventions, tips, and pitfalls documentation.

Documentation

• Do you have a doc_fragments section so that the common documentation is shared between modules ?
  • Does your doc_fragments include a notes: or seealso: section for all modules ?
• Does your module documentation have references to other documentation ?
  • Does it include seealso: references to other modules ?
  • Does it include seealso: references to other Internet documentation ?
• Does your module documentation include type information for every parameter ?
• Does your Working Group have a guide in the official Ansible documentation on how to use your modules ?
  • Including best practices and tips-and-tricks ?