Every item on this list will require judgement by the Testcontainers core maintainers. Exceptions will sometimes be possible; items with should are more likely to be negotiable than those items with must.

Default docker image

• Should be a Docker Hub official image, or published by a reputable source (ideally the company or organisation that officially supports the technology)
• Should have a verifiable open source Dockerfile and a way to view the history of changes
• MUST show general good practices regarding container image tagging - e.g. we do not use latest tags, and we do not use tags that may be mutated in the future
• MUST be legal for Testcontainers developers and Testcontainers users to pull and use. Mechanisms exist to allow EULA acceptance to be signalled, but images that can be used without a licence are greatly preferred.

Module dependencies

• The module should use as few dependencies as possible,
• Regarding libraries, either:
• they should be compileOnly if they are likely to already be on the classpath for users' tests (e.g. client libraries or drivers)
• they can be implementation (and thus transitive dependencies) if they are very unlikely to conflict with users' dependencies.
• If client libraries are used to test or use the module, these MUST be legal for Testcontainers developers and Testcontainers users to download and use.

API (e.g. MyModuleContainer class)

• Favour doing the right thing, and least surprising thing, by default
• Ensure that method and parameter names are easy to understand. Many users will ignore documentation, so IDE-based substitutes (autocompletion and Javadocs) should be intuitive.
• The module's public API should only handle standard JDK data types and MUST not expose data types that come from compileOnly dependencies. This is to reduce the risk of compatibility problems with future versions of third party libraries.

Documentation
Every module MUST have a dedicated documentation page containing:

• A high level overview
• A usage example
• If appropriate, basic API documentation or further usage guidelines
• Dependency information
• Acknowledgements, if appropriate
• Consider that many users will not read the documentation pages - even if the first person to add it to a project does, people reading/updating the code in the future may not. Try and avoid the need for critical knowledge that is only present in documentation.