docs: add payment-period communication policy (#500)

CONTRIBUTING.md

@@ -254,6 +254,25 @@ needed.
 
 Be respectful and constructive in all interactions. We follow the [Contributor Covenant](https://www.contributor-covenant.org/) code of conduct. Harassment, discrimination, or hostile behaviour will not be tolerated.
 
+### Payment-Period Communication
+
+Merging a pull request does **not** trigger or guarantee payment — approval is
+decided by the GrantFox evaluation process. During the payment evaluation period,
+contributors are expected to communicate professionally and to:
+
+- **Avoid spam and pressure.** Do not post repeated or duplicate payment-status
+  messages, tag maintainers to demand faster responses, or direct complaints at
+  reviewers because a merge did not result in immediate payment.
+- **Self-review first.** Before raising any payment concern, confirm your work
+  against the [Self-Review Checklist](docs/self-review-checklist.md), the
+  [Contributor Self-Assessment](docs/contributor-self-assessment.md), and the
+  [Evaluation Readiness Checklist](docs/evaluation-readiness-checklist.md).
+- **Raise genuine concerns once.** If a specific, evidenced concern remains,
+  post it a single time in the relevant thread and wait for a response.
+
+See the full [Payment-Period Communication Policy](docs/payment-period-communication-policy.md)
+for the complete expectations.
+
 ---
 
 *Happy building! If you have questions, open a discussion or leave a comment on the relevant issue.*

README.md

@@ -14,6 +14,7 @@ React Native Expo wallet for Stellar Testnet. The app aims to feel polished and
 - [Architecture Readiness Review](./docs/architecture-readiness-review.md) - Feature boundaries, duplicated state, SDK integration blockers, security-sensitive areas, and test gaps
 - [Issue Approval Readiness Checklist](./docs/issue-approval-readiness-checklist.md) - Fast pre-approval gate covering implementation completeness, tests, CI status, acceptance criteria, documentation, and known limitations, plus the reminder that a merged PR does not guarantee payment approval
 - [Evaluation Readiness Checklist](./docs/evaluation-readiness-checklist.md) - GrantFox contributor checklist for mobile issues, including tests, CI, screenshots, acceptance criteria, and the reminder that merge does not guarantee payment approval
+- [Payment-Period Communication Policy](./docs/payment-period-communication-policy.md) - How contributors should communicate during the payment evaluation period: no spam or pressure, self-review before raising payment concerns, and follow the GrantFox evaluation process
 - [Self-Review Checklist](./docs/self-review-checklist.md) - Quick checklist to run before opening a PR, covering feature completion, tests, CI, screenshots, and device/emulator verification
 - [Contributor Self-Assessment](./docs/contributor-self-assessment.md) - Pre-review form for confirming scope, test evidence, CI, documentation, limitations, and acceptance criteria
 - [Storage Guide](./docs/storage.md) - SecureStore vs AsyncStorage

docs/payment-period-communication-policy.md

@@ -0,0 +1,109 @@
+# Payment-Period Communication Policy
+
+## Purpose
+
+This policy sets clear expectations for how contributors communicate during the
+payment evaluation period for PocketPay Mobile issues. It exists to keep
+community channels useful, keep evaluators focused on reviewing work, and give
+every contributor a fair, predictable process.
+
+> **Merging a pull request does not trigger or guarantee payment.** Payment is
+> decided by the GrantFox evaluation process, not by the act of merging. Please
+> read this policy in full before raising any payment-related question.
+
+## Scope
+
+This policy applies to all community channels associated with PocketPay Mobile,
+including issue threads, pull request discussions, chat channels, and any
+GrantFox-managed communication spaces. It applies to every contributor working
+on a paid mobile issue.
+
+## Core Expectations
+
+Contributors are expected to:
+
+1. **Let the evaluation process run its course.** Merging is one step. The
+   [GrantFox Evaluation Readiness Checklist](./evaluation-readiness-checklist.md)
+   and the [Issue Approval Readiness Checklist](./issue-approval-readiness-checklist.md)
+   describe what evaluators look for and when. Approval depends on evaluator
+   review — not on how often a contributor asks about it.
+2. **Self-review before raising a payment concern.** Before posting about
+   payment, complete the self-review steps in the
+   [Self-Review Checklist](./self-review-checklist.md) and the
+   [Contributor Self-Assessment](./contributor-self-assessment.md). Most
+   payment questions are answered by confirming that the work actually meets the
+   issue's acceptance criteria, tests, and CI requirements.
+3. **Communicate professionally.** Keep messages respectful, specific, and
+   constructive, consistent with the project
+   [Code of Conduct](../CONTRIBUTING.md#code-of-conduct).
+
+## What Is Not Acceptable
+
+To keep channels usable for everyone, the following behavior is not permitted
+during the payment period:
+
+- **Repeated or duplicate messages** asking for a payment status update ("any
+  update?", "when will I be paid?", "please respond") across one or more
+  channels.
+- **Tagging maintainers or evaluators repeatedly** to demand a faster response.
+- **Complaints or pressure directed at maintainers** because a merge did not
+  result in immediate payment.
+- **Posting the same payment question in multiple channels** (issue, PR, and
+  chat) at the same time.
+- **Hostile, accusatory, or demanding language** toward reviewers, evaluators,
+  or other contributors.
+
+Repeated spam or pressure of this kind slows evaluation for everyone and may
+result in a message being removed, a warning, or — for persistent behavior —
+temporary removal from community channels.
+
+## Before You Raise a Payment Concern
+
+Work through this list first. In most cases it resolves the question without any
+message being needed:
+
+1. **Re-read the linked issue.** Confirm that your implementation matches the
+   requested scope and every acceptance-criteria item.
+2. **Confirm tests and CI pass.** A merged PR with failing or missing checks is
+   not evaluator-ready. See the
+   [CI Troubleshooting Guide](./ci-troubleshooting.md).
+3. **Complete the readiness checklists.** Run through the
+   [Evaluation Readiness Checklist](./evaluation-readiness-checklist.md) and
+   confirm every box honestly.
+4. **Check the stated evaluation timeline.** Evaluation happens on a defined
+   schedule, not immediately after merge. Allow the full period to elapse.
+5. **Confirm your PR description is complete.** It should link the issue,
+   describe what was tested, and include screenshots or recordings where the
+   change is visible.
+
+If, after all of the above, you have a genuine and specific concern (for
+example, evidence that an evaluation was missed), raise it **once**, in the
+relevant issue or PR thread, with the specific details attached. Then wait for a
+response before following up.
+
+## The GrantFox Evaluation Process
+
+Payment for mobile issues is governed by the GrantFox evaluation process, not by
+merge status. Approval depends on evaluator review, passing checks, adequate
+testing evidence, issue compliance, meaningful implementation, and overall
+quality. The relevant references are:
+
+- [Evaluation Readiness Checklist](./evaluation-readiness-checklist.md) — what
+  evaluators expect before the payment evaluation period.
+- [Issue Approval Readiness Checklist](./issue-approval-readiness-checklist.md) —
+  the pre-approval gate for implementation, tests, CI, and acceptance criteria.
+- [Contributor Self-Assessment](./contributor-self-assessment.md) — the form to
+  complete before requesting review.
+
+Following this process is the fastest and most reliable path to a fair
+evaluation. Messages that pressure or spam channels do not speed it up.
+
+## Summary
+
+- Merging does not mean payment. The GrantFox evaluation process decides
+  approval.
+- Do not spam, duplicate, or pressure maintainers about payment.
+- Self-review against the checklists before raising any payment concern.
+- Raise a genuine concern once, with specifics, in the correct thread — then
+  wait.
+- Keep every interaction professional and respectful.