Goal
Define and apply a consistent repository presentation/governance baseline across the repositories currently involved in the LibreCode/LibreSign automation work.
This covers repository metadata visible in GitHub as well as repository-level contributor/agent guidance.
Scope
Initial repositories:
LibreCodeCoop/release-toolLibreCodeCoop/github-workflowsLibreCodeCoop/github-governanceLibreCodeCoop/.githubLibreSign/libresignLibreSign/documentation
The policy should be reusable for additional active repositories later.
README baseline
Every active repository should have a useful root README.md.
The README is a concise project entry point. Its job is to explain:
- what the repository/project is;
- what problem it solves;
- who it is for;
- why it is useful;
- how it relates to adjacent LibreCode/LibreSign projects when that relationship matters;
- where to go next for documentation, contribution and security information.
Keep the README intentionally small. It must not become the project's technical documentation.
Do not place detailed architecture, configuration schemas, full command references, CI internals, release procedures, troubleshooting guides or implementation notes in the README. Put those in dedicated project documentation and link to them from the README when useful.
Do not add a license section merely to restate the project license. Licensing is already represented by the repository's top-level license file, REUSE/SPDX metadata and package/repository metadata. Only mention licensing in the README if there is an unusual user-facing condition that cannot be understood from those standard sources.
Do not rewrite repositories whose README already meets this standard simply to make formatting uniform.
Current README assessment
LibreCodeCoop/github-governance: already strong and appropriately focused; no rewrite required.LibreCodeCoop/github-workflows: already strong and appropriately focused; no rewrite required.LibreCodeCoop/.github: its short README is appropriate for an organization configuration repository; expand only if responsibilities materially grow.LibreSign/libresign: outside this cleanup unless a separate product/content review identifies a real problem.LibreSign/documentation: may remain focused on the documentation project and how to reach/build the documentation.LibreCodeCoop/release-tool: requires a concise business-focused README during repository bootstrap.
Repository metadata baseline
Every active public repository should have:
- a concise description;
- an appropriate website/homepage when there is a canonical public project or documentation URL;
- meaningful GitHub topics;
- an explicit, machine-detectable license;
- repository-local
AGENTS.md when AI/agent contribution guidance is relevant.
Avoid leaving newly created public repositories with empty GitHub metadata.
Hacktoberfest
Add the GitHub topic:
to all active repositories in scope where external contributions are welcome.
For the current work, this topic should be present on all repositories listed above.
Do not confuse GitHub topics with Git tags/releases.
Topics
Topics should describe the repository accurately and help discovery.
release-tool
Suggested topics:
hacktoberfest
php
cli
phar
release-automation
github-actions
nextcloud
nextcloud-app
semantic-versioning
changelog
keep-a-changelog
librecode
github-workflows
Suggested topics:
hacktoberfest
github-actions
github-workflows
automation
ci
reusable-workflows
nextcloud
librecode
github-governance
Suggested topics:
hacktoberfest
github
governance
github-actions
automation
rulesets
security
librecode
LibreCodeCoop/.github
Suggested topics:
hacktoberfest
github
organization
github-actions
community
librecode
LibreSign repositories
Preserve existing useful topics and ensure hacktoberfest remains present.
Do not replace a richer existing topic set with a minimal standard list.
Description and website
Descriptions should explain the repository purpose in one sentence and avoid internal-only wording.
Suggested initial values:
LibreCodeCoop/release-tool
Description:
Production-grade PHP CLI and PHAR for planning and automating reproducible software releases.
Website:
Use the canonical documentation/project URL once published. Do not invent a placeholder website.
LibreCodeCoop/github-workflows
Keep/refine the existing description:
Reusable, testable GitHub workflows for LibreCode projects and downstream integrations.
Website:
Point to the canonical public documentation if/when a dedicated page exists.
LibreCodeCoop/github-governance
Description:
Declarative, testable GitHub repository governance and ruleset automation for organizations.
Website:
Use the canonical public project/documentation URL if available.
LibreCodeCoop/.github
Description:
Shared GitHub organization profile, community files and workflow catalog for LibreCode Coop.
Website:
https://librecode.coop/
LibreSign/libresign
Keep existing project description/website unless a separate product decision changes them.
LibreSign/documentation
Description should explicitly identify it as the source for LibreSign public documentation.
Website:
https://docs.libresign.coop
Licensing
Licensing must be explicit and detectable by GitHub and REUSE where applicable.
Do not force one license across repositories of different content types.
Code / automation repositories
For LibreCode code/automation repositories, use the project-approved SPDX identifier consistently in:
LICENSE;REUSE.toml;- file SPDX headers;
- Composer/package metadata where applicable.
Current governance repositories already use AGPL-3.0-or-later in SPDX/REUSE metadata. New code repositories such as release-tool should follow the same policy unless a deliberate licensing decision says otherwise.
GitHub should detect the license correctly. If GitHub reports no license even though SPDX headers exist, add/fix the top-level license file.
Documentation repository
LibreSign/documentation already uses a Creative Commons license. Preserve its documentation-specific license unless a separate explicit relicensing decision is made.
Do not silently migrate documentation to the code license.
AGENTS.md
Use the exact filename:
not agent.md.
Each repository where agents may work should have a concise repository-specific AGENTS.md.
It should define at least:
- repository purpose and architectural boundaries;
- what files are generated or must not be edited manually;
- required quality gates;
- local test/lint commands;
- licensing/SPDX expectations;
- Git/GitHub safety rules;
- whether the repository is source-of-truth, generated catalog, consumer integration, etc.;
- links to authoritative cross-repository architecture/issues when applicable.
Do not copy the very large LibreSign AGENTS.md verbatim into smaller repositories. Keep each guide proportional to that repository.
For release-tool, AGENTS.md must explicitly reference the architecture/tooling contracts tracked by LibreCodeCoop/github-workflows#70, #78 and #82 until those contracts are fully migrated into repository documentation.
Current audit
| Repository |
Description |
Website |
Topics |
License detected |
AGENTS.md |
LibreCodeCoop/release-tool |
missing |
missing |
none |
missing |
missing |
LibreCodeCoop/github-workflows |
present |
missing |
none |
not detected |
missing |
LibreCodeCoop/github-governance |
missing |
missing |
none |
AGPL-3.0 detected |
missing |
LibreCodeCoop/.github |
missing |
missing |
none |
AGPL-3.0 detected |
missing |
LibreSign/libresign |
present |
present |
rich set incl. hacktoberfest |
AGPL-3.0 detected |
present |
LibreSign/documentation |
missing |
present |
incl. hacktoberfest |
documentation license present but GitHub reports NOASSERTION |
missing |
This is an initial audit and should be rechecked when implementing because repository metadata can change outside Git.
Governance / automation
Evaluate whether repository metadata can be declared and reconciled by github-governance instead of maintained manually in the GitHub UI.
A good long-term model would allow organization/repository configuration to declare:
- description;
- homepage;
- topics;
- selected repository features where appropriate.
The governance engine can then detect drift and apply/review changes consistently.
Do not put license content or AGENTS.md text into GitHub repository settings; those remain version-controlled repository files.
Definition of done
- all repositories in scope have meaningful descriptions;
- websites/homepages are set where canonical URLs exist;
hacktoberfest is present on every repository in scope;- repository-specific topics are present without removing useful existing topics;
- code repositories have explicit, GitHub-detectable licensing and REUSE/SPDX compliance;
- documentation licensing remains explicit and appropriate for documentation;
- all relevant repositories have repository-specific
AGENTS.md;
- all active repositories have an appropriate root
README.md focused on purpose, value and navigation rather than technical detail;
release-tool is not left as an empty/unidentified repository;- metadata drift automation through
github-governance is implemented or a follow-up issue is created with a clear contract.
Goal
Define and apply a consistent repository presentation/governance baseline across the repositories currently involved in the LibreCode/LibreSign automation work.
This covers repository metadata visible in GitHub as well as repository-level contributor/agent guidance.
Scope
Initial repositories:
LibreCodeCoop/release-toolLibreCodeCoop/github-workflowsLibreCodeCoop/github-governanceLibreCodeCoop/.githubLibreSign/libresignLibreSign/documentationThe policy should be reusable for additional active repositories later.
README baseline
Every active repository should have a useful root
README.md.The README is a concise project entry point. Its job is to explain:
Keep the README intentionally small. It must not become the project's technical documentation.
Do not place detailed architecture, configuration schemas, full command references, CI internals, release procedures, troubleshooting guides or implementation notes in the README. Put those in dedicated project documentation and link to them from the README when useful.
Do not add a license section merely to restate the project license. Licensing is already represented by the repository's top-level license file, REUSE/SPDX metadata and package/repository metadata. Only mention licensing in the README if there is an unusual user-facing condition that cannot be understood from those standard sources.
Do not rewrite repositories whose README already meets this standard simply to make formatting uniform.
Current README assessment
LibreCodeCoop/github-governance: already strong and appropriately focused; no rewrite required.LibreCodeCoop/github-workflows: already strong and appropriately focused; no rewrite required.LibreCodeCoop/.github: its short README is appropriate for an organization configuration repository; expand only if responsibilities materially grow.LibreSign/libresign: outside this cleanup unless a separate product/content review identifies a real problem.LibreSign/documentation: may remain focused on the documentation project and how to reach/build the documentation.LibreCodeCoop/release-tool: requires a concise business-focused README during repository bootstrap.Repository metadata baseline
Every active public repository should have:
AGENTS.mdwhen AI/agent contribution guidance is relevant.Avoid leaving newly created public repositories with empty GitHub metadata.
Hacktoberfest
Add the GitHub topic:
to all active repositories in scope where external contributions are welcome.
For the current work, this topic should be present on all repositories listed above.
Do not confuse GitHub topics with Git tags/releases.
Topics
Topics should describe the repository accurately and help discovery.
release-tool
Suggested topics:
github-workflows
Suggested topics:
github-governance
Suggested topics:
LibreCodeCoop/.github
Suggested topics:
LibreSign repositories
Preserve existing useful topics and ensure
hacktoberfestremains present.Do not replace a richer existing topic set with a minimal standard list.
Description and website
Descriptions should explain the repository purpose in one sentence and avoid internal-only wording.
Suggested initial values:
LibreCodeCoop/release-tool
Description:
Website:
Use the canonical documentation/project URL once published. Do not invent a placeholder website.
LibreCodeCoop/github-workflows
Keep/refine the existing description:
Website:
Point to the canonical public documentation if/when a dedicated page exists.
LibreCodeCoop/github-governance
Description:
Website:
Use the canonical public project/documentation URL if available.
LibreCodeCoop/.github
Description:
Website:
https://librecode.coop/LibreSign/libresign
Keep existing project description/website unless a separate product decision changes them.
LibreSign/documentation
Description should explicitly identify it as the source for LibreSign public documentation.
Website:
https://docs.libresign.coopLicensing
Licensing must be explicit and detectable by GitHub and REUSE where applicable.
Do not force one license across repositories of different content types.
Code / automation repositories
For LibreCode code/automation repositories, use the project-approved SPDX identifier consistently in:
LICENSE;REUSE.toml;Current governance repositories already use
AGPL-3.0-or-laterin SPDX/REUSE metadata. New code repositories such asrelease-toolshould follow the same policy unless a deliberate licensing decision says otherwise.GitHub should detect the license correctly. If GitHub reports no license even though SPDX headers exist, add/fix the top-level license file.
Documentation repository
LibreSign/documentationalready uses a Creative Commons license. Preserve its documentation-specific license unless a separate explicit relicensing decision is made.Do not silently migrate documentation to the code license.
AGENTS.md
Use the exact filename:
not
agent.md.Each repository where agents may work should have a concise repository-specific
AGENTS.md.It should define at least:
Do not copy the very large LibreSign
AGENTS.mdverbatim into smaller repositories. Keep each guide proportional to that repository.For
release-tool,AGENTS.mdmust explicitly reference the architecture/tooling contracts tracked by LibreCodeCoop/github-workflows#70, #78 and #82 until those contracts are fully migrated into repository documentation.Current audit
LibreCodeCoop/release-toolLibreCodeCoop/github-workflowsLibreCodeCoop/github-governanceLibreCodeCoop/.githubLibreSign/libresignLibreSign/documentationThis is an initial audit and should be rechecked when implementing because repository metadata can change outside Git.
Governance / automation
Evaluate whether repository metadata can be declared and reconciled by
github-governanceinstead of maintained manually in the GitHub UI.A good long-term model would allow organization/repository configuration to declare:
The governance engine can then detect drift and apply/review changes consistently.
Do not put license content or
AGENTS.mdtext into GitHub repository settings; those remain version-controlled repository files.Definition of done
hacktoberfestis present on every repository in scope;AGENTS.md;README.mdfocused on purpose, value and navigation rather than technical detail;release-toolis not left as an empty/unidentified repository;github-governanceis implemented or a follow-up issue is created with a clear contract.