A GitHub repository template for new Ansible projects.
This template gives you the basic recommended (and in some instances required) files for your new Ansible community project.
This template includes sample files for the following:
- Content in docs/ - A docsite template for your project that you are encouraged to use to provide a consistent experience to users and contributors across Ansible ecosystem projects. A website built from this template with mkdocs is available on ReadTheDocs.
- README.md - This file. It should describe the project and list the documentation site, when available, and how to reach the project team (Matrix room, if available and Ansible forum tags).
- LICENSE.md - The project license. We recommend GPLv3.
- CONTRIBUTING.md - The basics for contributing to your project. If your project has a docsite, refer to the docsite contributor guide from this CONTRIBUTING.md file.
- SECURITY.md - (optional) How to report security issues for your project.
- CODE-OF-CONDUCT.md - A link to the Ansible code of conduct. Do not change this.
- DCO - The Developer Certificate of Origin. Do not modify this text.
You can open a GitHub issue to request changes or directly open a PR for small changes or enhancements.
Make sure the following sections are present in your project's
README.md
Put you mission statement in here. Example follows.
At the your project name, our mission is to produce and maintain simple, flexible,
and powerful open-source software tailored to your project purpose.
We welcome members from all skill levels to participate actively in our open, inclusive, and vibrant community.
Whether you are an expert or just beginning your journey with Ansible and your project name,
you are encouraged to contribute, share insights, and collaborate with fellow enthusiasts!
If your project doesn't belong to GitHub orgs controlled by Red Hat, refer to a CoC violation complaint raising mechanism relevant to your project.
We follow the Ansible Code of Conduct in all our interactions within this project.
If you encounter abusive behavior violating the Ansible Code of Conduct, please refer to the policy violations section of the Code of Conduct for information on how to raise a complaint.
If your project has a docsite, this section should refer to a corresponding docsite section that contains the following information as on the docsite index template page. If your project is not present on the Ansible forum yet, please check out the existing tags and groups - use what suits the project. If there is no appropritate tag and group yet, please request one.
Join the Ansible forum:
- Get Help: get help or help others. Please add appropriate tags if you start new discussions, for example the
YOUR TAGtag. - Posts tagged with 'your tag': subscribe to participate in project/technology-related conversations.
- Refer to your forum group here if exists: by joining the team you will automatically get subscribed to the posts tagged with your group forum tag here.
- Bullhorn newsletter: used to announce releases and important changes.
- Social Spaces: gather and interact with fellow enthusiasts.
- News & Announcements: track project-wide announcements including social events.
For more information about communication, see the Ansible communication guide.
If you want to report a bug or request a new feature, please:
- Search in the issues for similar reports/requests.
- If there are already no such issues, open a new one by clicking the
New issuebutton.
Use one source of truth: it can be a contributing section on project docsite or CONTRIBUTING.md. If you have a docsite, use it.
To learn how to contribute to this project, see the Contributor guidelines.
If the project doesn't have the guide, please add it to mitigate the entry threshold for new contributors. If it's not applicable, remove the section.
Do you have a fix and want to submit a ready-for-merge pull request? See the Getting started development guide.
Please replace the content in the sub-sections below with information relevant to your project. If you have the same information covered on the project docsite, refer to the corresponding docsite pages instead.
To determine a software version number when releasing, this project uses the Semantic Versioning Specification to convey meaning about what has been modified from one version to the next.
Describe your release policy and maintenance timeline in this section or refer to a corresponding docsite page.
We maintain each major release version (1.x.y, 2.x.y,...) for two years after the next major version is released.
Here is the table for the support timeline:
1.x.y: released 2020-11-17, EOL2.x.y: released 2022-02-10, supported until 2025-06-093.x.y: released 2023-06-09, current
Embed a link to a project changelog into here.
For release notes, see the changelog.
Update this section with relevant information and URLs. If the project has a docsite, include this information in the docsite.
The process of decision making in this project is based on discussing and finding consensus among participants.
We, Refer to your forum group here, use the forum posts tagged with TAGNAME for general announcements and discussions. If you have something on your mind, just create a post and let's find the best solution together!