Package README Standard

Every package repository should contain a README.md that explains what the package does, how it is installed, and how contributors should work with it.

The README is for humans. Keep Composer metadata in composer.json and QUIQQER package metadata in package.xml.

Recommended Structure

Use a predictable structure so developers, operators, and maintainers can find the same information across packages.

# Package Title

Short description of what the package provides.

## Features

- Important feature
- Another important feature

## Installation

Package name: `vendor/package`

## Development

Explain repository-specific checks, setup, fixtures, or package concepts.

## Support

Link to issues, source repository, and support contact.

## License

License identifier.

Installation Section

Include the Composer package name and keep the command short.

Package name: `vendor/package`

Operators can install packages through the QUIQQER console or through QUIQQER-integrated Composer. The README should not duplicate the full operator guide unless the package has special installation steps.

Development Section

Document package-specific work that is not obvious from the repository structure.

Useful topics include:

• package-specific concepts
• required fixtures or demo data
• special setup commands
• available Composer scripts
• coding or content rules for package-specific entities
• where to find package-specific developer docs

Do not put open work items into the README. Create issues for missing documentation, unclear behavior, or future improvements.

Support And Source Links

Add links that help people report and inspect issues.

## Support

- Source: https://dev.example.com/vendor/package
- Issues: https://dev.example.com/vendor/package/-/issues
- Email: support@example.com

Keep these links consistent with package.xml support metadata.

Practical Checklist

Before publishing a README:

• Explain the package purpose in the first section.
• List the Composer package name.
• Link to source and issue tracker.
• Document package-specific development steps.
• Keep user-facing claims aligned with package behavior.
• Move open work items and uncertain behavior into issues instead of the README.