117 lines
6.1 KiB
Markdown
117 lines
6.1 KiB
Markdown
# Adopting And Updating The Policies
|
|
|
|
This guide is for agents and maintainers incorporating policies from
|
|
[Standard Repository Policies](https://gitea.maximumdirect.net/eric/policy)
|
|
into another repository. To edit the upstream templates themselves, use the
|
|
[contributor guide](development.md).
|
|
|
|
## Select A Baseline
|
|
|
|
Select an upstream commit and read the policies relevant to the requested work.
|
|
Use a revision containing the [project grant](../COPYRIGHT) and the reference
|
|
assets you intend to use. Record its full commit identifier; a moving branch
|
|
name is not an adoption baseline. No package manager or automatic update service
|
|
is required.
|
|
|
|
Preserve existing downstream decisions and unrelated changes. Adoption is a
|
|
local customization task, not authorization to add every capability, document,
|
|
restriction, or release gate mentioned in the templates.
|
|
|
|
## Copy And Customize
|
|
|
|
1. Copy applicable documents from `docs/policy/` to the same downstream location.
|
|
Follow each template's adoption instructions and remove its `Base Policy
|
|
Template` section afterward. Create supporting documents when they have useful
|
|
content for an existing responsibility, rather than filling an empty outline.
|
|
2. Tailor architecture to the actual project. Preserve the author's selected
|
|
license and existing application contracts. Do not infer new product behavior
|
|
from policy examples.
|
|
3. Retain each document's `Base Policy Version` and set `Last Updated` to the
|
|
local adoption date. Add `Upstream Source` metadata linking to that specific
|
|
document at the selected commit. Retain this provenance in future edits.
|
|
4. Create or update the downstream `docs/development.md` reading guide. Use
|
|
[agents/AGENTS.md](../agents/AGENTS.md) as the basis for the downstream root
|
|
`AGENTS.md`, merging its orientation links with existing instructions.
|
|
5. Add the attribution and document-license scope described below. Review the
|
|
resulting local rules for consistency with the project's actual workflows.
|
|
|
|
A source link has this shape; substitute the selected full commit and filename:
|
|
|
|
```text
|
|
https://gitea.maximumdirect.net/eric/policy/src/commit/UPSTREAM_COMMIT/docs/policy/testing.md
|
|
```
|
|
|
|
## Attribute Copied Policies
|
|
|
|
Use the [canonical attribution entry](../examples/licensing/policy-attribution.md)
|
|
in the downstream `docs/oss/attribution.md`. It is an entry fragment to insert
|
|
beneath that document's existing title, not an additional document title.
|
|
|
|
- Replace `UPSTREAM_COMMIT` with the selected full commit in all three URLs.
|
|
- Adjust the `Material:` sentence to identify the files actually copied. Keep
|
|
“adapted for this repository” for customized documents; use “copied without
|
|
modification” for unchanged copies. For a mixture, identify which are adapted.
|
|
- Preserve supplied creator, copyright, license, and warranty-disclaimer notices,
|
|
including the link to upstream `COPYRIGHT`. Retain indications of prior
|
|
modifications as the documents evolve.
|
|
- Copy [CC-BY-SA-4.0.txt](oss/licenses/CC-BY-SA-4.0.txt) into the downstream
|
|
`docs/oss/licenses/`. The entry's relative license link assumes that location.
|
|
|
|
This entry is the project's recommended attribution arrangement for copied or
|
|
adapted policies. Its short material statement identifies scope and modification
|
|
status; do not add research narratives or compliance commentary.
|
|
|
|
Keep customized policy documents under CC-BY-SA 4.0 in this standard adoption
|
|
workflow. Identify that scope in the downstream `COPYRIGHT`, for example:
|
|
|
|
```text
|
|
Policy documents adapted from Standard Repository Policies remain licensed
|
|
under CC-BY-SA-4.0. See docs/oss/attribution.md for the affected material,
|
|
upstream credit, and license links.
|
|
```
|
|
|
|
The application's own code retains its selected license. Copying a policy does
|
|
not select a new license for unrelated code or documentation. These instructions
|
|
implement the [project grant](../COPYRIGHT); they do not add a requirement to
|
|
publish private work or send modifications upstream. Other arrangements
|
|
permitted by the license remain available.
|
|
|
|
## Use Reference Assets
|
|
|
|
Create actual `COPYRIGHT` and attribution files using the upstream
|
|
[application](../examples/licensing/application/COPYRIGHT),
|
|
[library](../examples/licensing/library/COPYRIGHT), and
|
|
[attribution](../examples/licensing/attribution.md) examples. Read the
|
|
[OSS policy](policy/oss.md) for their format and placeholder substitution rules.
|
|
Original example formatting is available under CC0 as specified in
|
|
[COPYRIGHT](../COPYRIGHT); using that formatting alone does not require an
|
|
attribution entry for this project.
|
|
|
|
Keep links to these examples in the adopted policy pointed at upstream commits.
|
|
Do not populate the downstream `examples/` directory with this collection.
|
|
Copy the applicable standard license texts into the actual local license files;
|
|
retain their wording and their own terms. Those copies remain necessary under
|
|
the House Format even though example documents stay upstream.
|
|
|
|
## Update Deliberately
|
|
|
|
Compare the previously recorded upstream files with a selected newer revision.
|
|
Apply relevant changes while preserving local decisions; do not overwrite
|
|
customized documents wholesale or treat every upstream recommendation as a new
|
|
local requirement.
|
|
|
|
Update `Base Policy Version` when adopting a newer template version and update
|
|
`Upstream Source` to the revision actually incorporated. Change `Last Updated`
|
|
when revising the local document. Keep the material description, modification
|
|
status, and attribution links accurate. If documents use different upstream
|
|
revisions, retain each file's exact source metadata and include the necessary
|
|
commit-specific source and notice links in the single project attribution entry.
|
|
Do not change a source reference to a version that was merely reviewed.
|
|
|
|
Ordinary review should check the resulting rules, attribution facts, and affected
|
|
links. A commit-based adoption record is sufficient; no recurring synchronization
|
|
check, release gate, or separate license approval is required. Agents following
|
|
this documented arrangement need additional clarification only for a concrete
|
|
circumstance it does not cover. User instructions govern whether changes are
|
|
committed or published.
|