-
Notifications
You must be signed in to change notification settings - Fork 144
Checklist
[ Roles | Communication | Reviewing | Checklist | TODO ]
THIS PAGE IS OLD and no longer maintained. For questions, please use the Ansible forum.
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.
- 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 ?
- 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.
- 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 ?
This Wiki is used for quick notes, not for support or documentation.
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
Plugins:
httpapi