The public eliware/.github repository supplies default community health files for Eliware repositories.
It also supplies the public Eliware organization profile README.
GitHub uses an organization default when a repository does not provide a file of that type.
GitHub can use these defaults for repositories with any visibility.
The .github repository itself must remain public.
GitHub does not copy default files into target repositories or their clones. Each target repository owns its project rules, code, and settings.
This repository currently provides these shared files:
.github/ISSUE_TEMPLATE/release-checklist.ymlprovides a release checklist template.profile/README.mdprovides the public Eliware organization profile text.
This repository does not provide other default community health files.
GitHub uses a supported file from the target repository when that file exists.
For supported files with more than one valid location, GitHub checks .github/, the repository root, then docs/.
If the target repository has no matching file, GitHub uses the default from eliware/.github.
GitHub applies the same location order in this repository.
Issue templates follow a special rule.
If a target repository has a valid issue template or template configuration in its .github/ISSUE_TEMPLATE/ folder, GitHub does not use this repository's issue templates.
GitHub reads issue templates from the target repository's default branch.
Add a supported community file to a target repository when that project needs different guidance. Use a file location that GitHub supports for that file type. Keep project-specific rules in the target repository.
For a local issue template, add a valid template or config.yml to the target repository's .github/ISSUE_TEMPLATE/ folder.
GitHub then uses the target repository's templates rather than this repository's templates.
Use the release checklist to record readiness and link to release records. The checklist does not grant release or deployment authorization.
- Open the target repository's issue chooser.
- Select the release checklist when GitHub offers it.
- Set the issue type to Release when GitHub offers issue types.
- Record the repository, project owner, version, target, and release scope.
- Record the full candidate commit and project check results.
- Keep inspection and publication fields with their listed owners.
- Follow your organization's release process for roles, approval, and handoff.
For a GHCR release, the checklist asks DevOps to open and link a separate GitOps issue. Include the source SHA, image digest, image pin, and deployment request. DevOps closes the release checklist after publication and records deployment results on that issue.
If a release does not publish a GHCR image, select the matching checklist option. The GitOps steps do not apply.
If GitHub does not offer the checklist, check for templates or template configuration in the target repository. If the target repository needs a project-specific release checklist, maintain that checklist in the target repository.
GitHub shows profile/README.md on the public Eliware organization Overview page.
The README must remain in the profile/ folder of this public repository.
GitHub shows the public profile after a maintainer commits the file to the default branch.
If GitHub does not show a default file, check that the target repository has no file of that type in a higher-priority location.
If an issue template does not appear, check the target repository's .github/ISSUE_TEMPLATE/ folder for valid templates or config.yml.
If GitHub does not show the organization README, check that profile/README.md is nonempty and exists on the default branch.