woofmeow/straywild
woofmeow/straywild
3
5
Fork 2
Code Issues 40 Projects 1 Releases 43 Packages Wiki Activity Actions

Close project to unsolicited contributions

Browse source
This commit is contained in:
Alexander Sellite 2026-08-21 16:39:44 -04:00
parent f45550e46b
commit ba35db1015
4 changed files with 66 additions and 38 deletions
Download patch file Download diff file Expand all files Collapse all files

51
CONTRIBUTING.md
View file

@ -1,29 +1,32 @@
# Contributing
# Contribution policy
NETfishing is currently developed through focused changes on the repository's
active development branch. Coordinate scope with the project owner before
starting substantial work.
NETfishing is an owner-directed Woofmeow project and is not accepting
unsolicited contributions. Please do not submit pull requests, patches, code,
artwork, models, audio, writing, documentation, translations, designs, or
other implementation work. Pull requests are disabled for the official
repositories.
By intentionally submitting material for inclusion, contributors agree to the
applicable grants and representations in
[`CONTRIBUTOR-TERMS.md`](CONTRIBUTOR-TERMS.md). Maintainers must preserve an
affirmative record of that agreement. Contact the owners before submitting if
separate written terms are needed.
Issues remain available for reproducible bug reports and player feedback. An
Issue is not a request for contributed implementation, and attaching or
linking unsolicited work does not make it an accepted Project contribution.
The owners may occasionally invite specific work in writing before it is
created or submitted. [`CONTRIBUTOR-TERMS.md`](CONTRIBUTOR-TERMS.md) is retained
to document previously accepted contributions and govern expressly invited
work; it is not a standing invitation to contribute.
## Contribution forks
The [NETfishing Asset License](ASSET-LICENSE.md) permits a public source-control
fork to retain NETfishing assets when the fork is maintained in good faith to
prepare, test, review, or submit changes for possible inclusion in the official
project. Keep the hosting platform's fork relationship visible, preserve all
license and attribution notices, and do not publish general-audience builds or
use the fork as an independent game or distribution.
The [NETfishing Asset License](ASSET-LICENSE.md) contains limited permissions
for qualifying Contribution Forks. Those permissions do not promise review or
acceptance and do not override the policy above. Keep the hosting platform's
fork relationship visible, preserve all license and attribution notices, and
do not publish general-audience builds or use the fork as an independent game
or distribution.
Private test builds and temporary access-controlled test servers may be shared
with people directly participating in development or review of the proposed
contribution. Submission remains subject to `CONTRIBUTOR-TERMS.md`; permission
to maintain a Contribution Fork does not guarantee that its changes will be
accepted.
only as allowed by that license. Permission to maintain a Contribution Fork
does not authorize unsolicited submission or obligate the owners to review it.
## Change discipline
@ -36,13 +39,15 @@ accepted.
- Keep presentation-only systems out of save files and network messages.
- Store runtime assets under repository-owned paths; never reference a
workstation sync or temporary directory.
- Record the source and license of newly imported assets in
[`docs/ATTRIBUTION.md`](docs/ATTRIBUTION.md).
- Retain source, permission, and license evidence for newly imported assets.
Update [`docs/ATTRIBUTION.md`](docs/ATTRIBUTION.md) when the accepted work
adds or changes a distributed credit or third-party notice; do not add a
file-by-file inventory of ordinary project-owned assets.
- Do not assume the GPL code license applies to project assets; observe
[`ASSET-LICENSE.md`](ASSET-LICENSE.md) and third-party terms.
- Do not commit `.godot/`, test data, logs, captures, or build outputs.
## Before requesting review
## Before committing a maintainer change
```sh
git diff --check
@ -63,7 +68,7 @@ tests are supporting evidence, not a replacement.
- Do not mix generated build artifacts with source changes.
- Do not rewrite published release tags.
- Describe behavior, compatibility impact, validation, and asset provenance in
the review or release record.
the internal review or release record.
## Style

32
CONTRIBUTOR-TERMS.md
View file

@ -1,8 +1,13 @@
# NETfishing contributor terms
These terms apply to contributions intentionally submitted for inclusion in
NETfishing after these terms are published. They do not retroactively change
ownership of earlier work or replace a separately signed agreement.
NETfishing does not accept unsolicited contributions. These terms are retained
as the governing record for contributions previously accepted after their
publication and for specific future work that both Owners expressly invite in
writing before submission. They are not a request or standing invitation for
patches, pull requests, assets, or other material.
These terms do not retroactively change ownership of earlier work or replace a
separately signed agreement.
“Owners” means the two NETfishing co-owners who publish the Project as
Woofmeow and are publicly credited as Voyager and Endeavour. “Project” means
@ -80,15 +85,16 @@ separate written agreement signed by the appropriate parties.
## 7. Acceptance
A contribution is not accepted merely because it was posted, uploaded, or
discussed. The Owners or their authorized maintainers may accept, modify,
decline, or later remove it.
A contribution is not accepted merely because it was posted, uploaded, linked,
emailed, or discussed. Unsolicited material will not be reviewed or accepted.
The Owners or their authorized maintainers may modify, decline, or later
remove previously accepted or expressly invited work.
By intentionally submitting a patch, pull request, asset, or other material
for Project inclusion after receiving notice of these terms, you agree to the
applicable grants above. Maintainers should record the contributor’s
affirmative agreement in the pull request, issue, email, or another durable
written record.
For work expressly invited in writing, intentionally delivering the requested
material for Project inclusion after receiving notice of these terms records
agreement to the applicable grants above. Maintainers must retain both the
written invitation and the contributor's affirmative agreement in a durable
Project record.
If you cannot agree to these terms, do not submit the contribution; contact
the Owners to discuss a separate written arrangement.
Do not send unsolicited work. An owner invitation may instead specify a
separate written arrangement signed by the appropriate parties.

6
README.md
View file

@ -48,7 +48,7 @@ godot --path .
## Validation
The validation scripts isolate Godot's settings and application-data roots.
Run the fast, deterministic suite before submitting a change:
Run the fast, deterministic suite before committing a change:
```sh
scripts/run_validations.sh quick
@ -101,7 +101,9 @@ world and UI authoring, and testing are consolidated in
[TRADEMARKS.md](TRADEMARKS.md).
- Third-party materials retain their own terms; see the consolidated
[credits, notices, and provenance record](docs/ATTRIBUTION.md).
- Contributions are accepted under [CONTRIBUTOR-TERMS.md](CONTRIBUTOR-TERMS.md).
- Unsolicited contributions are not accepted. See
[CONTRIBUTING.md](CONTRIBUTING.md). Historical and expressly invited work is
governed by [CONTRIBUTOR-TERMS.md](CONTRIBUTOR-TERMS.md).
Material boundaries and binary-release requirements are recorded in that same
[`docs/ATTRIBUTION.md`](docs/ATTRIBUTION.md) reference.

15
docs/README.md
View file

@ -34,6 +34,12 @@ and resources. These documents describe boundaries, policy, and maintenance
procedures; they should not duplicate changing constants or inventories that
can be derived reliably from the project.
The same rule applies to credits. `ATTRIBUTION.md` records creators, licenses,
and durable contribution families. It does not attempt to mirror every current
asset filename or private intake-directory layout. Planned or unincorporated
work is not described as shipped, and repository paths are included only when
they help recipients locate a distributed third-party work or license.
## Files intentionally kept at the repository root
The following are entry points or governing legal documents rather than
@ -46,6 +52,10 @@ general project documentation, so they remain at conventional root paths:
- `TRADEMARKS.md`
- `CONTRIBUTOR-TERMS.md`
`CONTRIBUTING.md` records that unsolicited contributions are not accepted.
`CONTRIBUTOR-TERMS.md` remains a governing legal record for previously
accepted and expressly invited work, not an invitation for new submissions.
Third-party font license texts stay beside their font files under `ui/fonts/`
so the licensed files and their original notices cannot drift apart. Build
scripts collect those legal files and the authoritative attribution record
@ -58,3 +68,8 @@ update the appropriate reference above and link to its heading when source
comments need more context. Player-facing package instructions belong only in
`README-PLAYTEST.txt`; source and scripts remain authoritative for command-line
usage.
Before adding a literal project path to prose, verify that it exists in the
same revision and that readers actually need the path. Prefer a stable owner,
interface, or resource type over a directory listing. A path or Git author is
never evidence of creative authorship.