diff --git a/.github/ISSUE_TEMPLATE/bug_report.yml b/.github/ISSUE_TEMPLATE/bug_report.yml index ca45d8c7..4bdb3295 100644 --- a/.github/ISSUE_TEMPLATE/bug_report.yml +++ b/.github/ISSUE_TEMPLATE/bug_report.yml @@ -7,6 +7,10 @@ body: attributes: value: | ## Before you submit... + + Search existing issues and pull requests first. Reuse an issue that + already tracks the same bug. If you plan to contribute a fix, open this + issue before your PR and comment with your intended approach. Please ensure you have: - Read the [installation guide](https://ifbars.github.io/S1API/docs/getting-started.html#installation-guide) diff --git a/.github/ISSUE_TEMPLATE/feature_request.yml b/.github/ISSUE_TEMPLATE/feature_request.yml index 65f81485..55ebcb4e 100644 --- a/.github/ISSUE_TEMPLATE/feature_request.yml +++ b/.github/ISSUE_TEMPLATE/feature_request.yml @@ -8,6 +8,11 @@ body: value: | ## Feature Request + Search existing issues and pull requests first. Reuse an issue that + already tracks the same request. If you plan to implement it, open this + issue before your PR and comment with your intended approach. Discuss + substantial API or behavior changes with a maintainer before implementation. + Keep this short if you want. You do **not** need to know how the API should be implemented. If you're not technical, just describe: diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 93f88b34..cf7689e8 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -1,3 +1,21 @@ +## Linked issue + + + +## Contributor checklist + +- [ ] I linked an issue opened before this PR, or explained an allowed exception above. +- [ ] I checked existing issues and PRs for duplicate or overlapping work. +- [ ] This PR addresses one focused problem or request. + ## Summary diff --git a/AGENTS.md b/AGENTS.md index f0342ad2..77adb12d 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -53,7 +53,17 @@ and document the migration impact in the PR. `S1API.Tests/` is the only test implementation that should be committed to this repository. Keep runtime and in-game smoke mods, launchers, harnesses, disposable saves or installs, logs, screenshots, and generated evidence local and ignored, including everything under `tests/Smoke/`. Do not add `.gitignore` exceptions for smoke-test sources. Record the scenario, commands, runtime matrix, and observed pass/fail evidence in the PR description without committing the smoke implementation or game-derived artifacts. ## Commit & Pull Request Guidelines -Write imperative, single-purpose commits; lightweight prefixes such as `fix:` or `feat:` appear in history and are encouraged. Target regular-game PRs at `stable` and beta-game PRs at `beta`. Include a short change narrative, reproduction or validation notes, and link any external issue. Screenshots or logs are helpful for UI or networking work. Never modify CI workflows without prior discussion. +Write imperative, single-purpose commits; lightweight prefixes such as `fix:` or `feat:` appear in history and are encouraged. Target regular-game PRs at `stable` and beta-game PRs at `beta`. Include a short change narrative, reproduction or validation notes, and link the tracking GitHub issue. Screenshots or logs are helpful for UI or networking work. Never modify CI workflows without prior discussion. + +Follow the issue-first workflow in `CONTRIBUTING.md`: search existing issues and +PRs, reuse or open a GitHub issue before a bug-fix, feature, or API-improvement +PR, and record the intended approach on the issue before implementation. Discuss +substantial API or behavior changes with a maintainer first. Use `Fixes #123` +for complete resolutions and `Refs #123` for partial work. A PR description is +not a substitute for the issue. Keep unrelated problems in separate issues and +focused PRs. Typo, formatting, and documentation-only changes that do not alter +API behavior may omit an issue with an explanation in the PR; other exceptions +require explicit maintainer approval. ## Release & Versioning Workflow Always follow [`VERSIONING.md`](VERSIONING.md) for any release, hotfix, tagging, branch-planning, or version-bump work. Treat it as the authoritative release policy. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 19806900..78d8fe78 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -8,6 +8,35 @@ Please read over the below in full to help you get started and set expectations - Do **NOT** alter my GitHub actions unless you have a good reason. I will close your PR and ban you from the project if malicious intent is found. +## Before Opening a Pull Request + +Bug fixes, feature requests, and API improvements must have a GitHub issue +opened **before** the pull request, even if you already have a fix ready. The +issue records the problem or request independently of the proposed implementation. + +1. Search [existing issues](https://github.com/ifBars/S1API/issues) and open pull + requests first. Reuse an issue that already tracks the same problem rather + than opening a duplicate. +2. If there is no matching issue, open a + [bug report](https://github.com/ifBars/S1API/issues/new?template=bug_report.yml) + or [feature request](https://github.com/ifBars/S1API/issues/new?template=feature_request.yml). + For bugs, include reproduction steps, expected and actual behavior, affected + versions, and the Mono or IL2CPP runtime. For requests, explain the use case + and what is missing today. +3. Comment on the issue with your intended approach before starting work so + contributors can coordinate. Discuss substantial API or behavior changes + with a maintainer before implementing them. +4. Link the issue in the PR description. Use `Fixes #123` when the PR fully + resolves it, or `Refs #123` when it only addresses part of the work. + +A PR description does not replace an issue. Bug-fix and feature PRs without a +linked issue will be asked to add one before review proceeds. Keep unrelated +bugs or requests in separate issues and focused PRs. + +Typo corrections, formatting, and documentation-only changes that do not alter +API behavior may be submitted without an issue; explain that exception in the +PR's linked issue section. Maintainers may approve other exceptions explicitly. + ## Prerequisites S1API is available to mod developers of all experience levels, but contributing game-facing changes assumes working familiarity with Schedule I mod development @@ -60,10 +89,10 @@ Ultimately, this just saves you time and gets your changes into the API faster. | MonoMelon | MelonLoader for Mono (alternate branch) builds | ## Proper Contributing Channels -All pull requests **must** go into `bleeding-edge` before `stable`. -If you make a pull request for `stable`, I **will** be changing it to verify build. +Target regular-game pull requests at `stable` and game-beta pull requests at +`beta`. For release and hotfix preparation, follow [VERSIONING.md](VERSIONING.md). ## Tracking Work & Issues -We maintain a [Trello board](https://trello.com/b/yuRuBpIg/s1api) where known issues and tasks that need to be done are tracked. -While the board is not always perfectly up to date, it should typically show the known issues in the project. -GitHub issues opened with us will typically be added to the Trello board and then archived once closed. +[GitHub issues](https://github.com/ifBars/S1API/issues) are the source of truth +for bugs and requests. Keep reproduction details, scope decisions, and related +PR links on the issue so the work remains easy to track across releases. diff --git a/README.md b/README.md index 8530a0a7..d345aa8b 100644 --- a/README.md +++ b/README.md @@ -70,4 +70,7 @@ If you want to do custom content specific to Mono or Il2Cpp, S1API can still ass ## Want to Contribute? This is a massive project with so many different areas to specialize in. If you're interested in contributing, please do! +For bug fixes, features, and API improvements, reuse or open a +[GitHub issue](https://github.com/ifBars/S1API/issues) before opening a pull +request, and link that issue in the PR description. Look over the [CONTRIBUTING.md](CONTRIBUTING.md) for guidance on code standards and the process.