Skip to content
This repository has been archived by the owner on Jun 10, 2024. It is now read-only.

Checklist

Sandra McCann edited this page Dec 7, 2023 · 9 revisions

[ Roles | Communication | Reviewing | Checklist | 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) ?
  • 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 ?

(ARchived) Working groups

Working groups are now in the Ansible forum

Ansible project:
Community, Contributor Experience, Docs, News, Outreach, RelEng, Testing

Cloud:
AWS, Azure, CloudStack, Container, DigitalOcean, Docker, hcloud, Kubernetes, Linode, OpenStack, oVirt, Virt, VMware

Networking:
ACI, AVI, F5, Meraki, Network, NXOS

Ansible Developer Tools:
Ansible-developer-tools

Software:
Crypto, Foreman, GDrive, GitLab, Grafana, IPA, JBoss, MongoDB, MySQL, PostgreSQL, RabbitMQ, Zabbix

System:
AIX, BSD, HP-UX, macOS, Remote Management, Solaris, Windows

Security:
Security-Automation, Lockdown

Tooling:
AWX, Galaxy, Molecule

Communities

Modules:
unarchive, xml

Plugins:
httpapi

Wiki

Roles, Communication, Reviewing, Checklist, TODO

Clone this wiki locally