diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 9f45a73..bd222d2 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -136,6 +136,10 @@ follow the [Documentation Style Guide](docs/docs-style-guide.md) for Testnet wording, avoiding production claims, placeholder values, command formatting, and linking between docs. +## Payment-period conduct + +Before raising a payment-status question on an issue or PR, self-review against the **[Contribution Quality Gate](docs/contribution-quality-gate.md)** and confirm your PR template and `make verify` output are complete. See the **[Payment-Period Conduct Guidance](docs/payment-period-conduct.md)** for what to check first, what to avoid (repeated questions across threads, public escalation before self-review), and how this repository's review relates to GrantFox's own evaluation and payment process. + ## Security-sensitive contributions Changes involving balances, access control, signatures, storage, upgrades, or external calls are security-sensitive. Describe their risks and assumptions clearly in the pull request. diff --git a/README.md b/README.md index a925845..f5e4599 100644 --- a/README.md +++ b/README.md @@ -214,6 +214,7 @@ stellar-pocketpay-contracts/ - [Admin & Emergency Mechanism Threat Model](docs/admin-pause-threat-model.md) – Security analysis of malicious admin, compromised admin, accidental pause, and blocked-withdrawal scenarios. - [Failure Mode Catalogue](docs/failure-mode-catalogue.md) – Summary of safe-failure behavior, expected errors, affected functions, and related tests for vault operations. - [Traceability Table Guide](docs/traceability-table.md) – Standard format for mapping PR changes to issue acceptance criteria, with worked examples. +- [Payment-Period Conduct Guidance](docs/payment-period-conduct.md) – Expectations for how contributors raise payment-status questions, and how GrantFox's evaluation process relates to this repository's review process. --- @@ -279,6 +280,8 @@ Every pull request must use the **[PR template](.github/PULL_REQUEST_TEMPLATE.md - Confirmation that `make verify` passes (or equivalently `cargo fmt --check`, `cargo clippy --tests -- -D warnings`, and `cargo test --workspace`) - CI green before requesting review +Before asking about payment status on an issue or PR, read the **[Payment-Period Conduct Guidance](docs/payment-period-conduct.md)** — it explains how to self-review first and how this repository's review process relates to GrantFox's own evaluation process. + Quick start: ```bash diff --git a/docs/payment-period-conduct.md b/docs/payment-period-conduct.md new file mode 100644 index 0000000..94cba23 --- /dev/null +++ b/docs/payment-period-conduct.md @@ -0,0 +1,29 @@ +# Payment-Period Conduct Guidance + +This document sets expectations for how contributors communicate about payment status on GrantFox-sourced issues in this repository. It exists because community channels become harder to use for everyone when the same payment question is repeated across multiple threads instead of being resolved through the normal review process. + +## Before asking about payment status + +Check your own submission first: + +1. Re-read the issue's **Acceptance Criteria** and confirm each box is actually satisfied by your PR, not just attempted. +2. Run through the **[Contribution Quality Gate](contribution-quality-gate.md)** — implementation, testing, documentation, and CI sections all included. A PR that fails this gate is not yet ready to be evaluated, and evaluation delays traceable to an incomplete PR are not a maintainer or GrantFox responsiveness issue. +3. Confirm your **[PR template](../.github/PULL_REQUEST_TEMPLATE.md)** is filled in completely, including the `Closes #N` reference, the traceability table, and confirmation that `make verify` passes. +4. Check whether CI is green. A red CI run on your PR will hold up review regardless of how the underlying work looks. + +If all of the above are true and the PR has been open for a while with no maintainer response, a single, specific comment on the PR or issue — referencing the PR number and what's outstanding — is the right way to follow up. + +## What to avoid + +- **Repeating the same payment question across multiple issues, PRs, or channels.** One clear follow-up is enough; the review and payment queue is processed on its own schedule, not accelerated by repetition. +- **Escalating publicly before checking your own work.** If the quality gate above hasn't been fully worked through, raise questions about the review itself, not about payment timing. +- **Treating a pending or "Maybe Rewarded" label as an entitlement dispute.** These labels reflect GrantFox's own evaluation process (see below), not a commitment made by this repository's maintainers. +- **Off-topic complaints about unrelated contributors' payment status.** Keep discussion scoped to your own submission. + +## How GrantFox evaluation works, from this repo's side + +This repository's maintainers review pull requests for correctness, test coverage, and adherence to the standards in [CONTRIBUTING.md](../CONTRIBUTING.md) and the [Contribution Quality Gate](contribution-quality-gate.md). Maintainer approval and merge are necessary steps, but GrantFox — not this repository — owns the campaign's evaluation, scoring, and payment process for each issue. Questions specifically about payment amount, timing, or eligibility belong with GrantFox's own support channels, not this repository's issue tracker. + +## Tone + +Disagreements about scope or review feedback are a normal part of open source. Keep them professional: describe what you did, point to the specific acceptance criterion or checklist item in question, and avoid repeated or escalating messages on the same topic. Maintainers and other contributors are more likely to respond quickly to a single, well-scoped comment than to a thread of follow-ups.