diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 04bf682..d849328 100644 --- a/CONTRIBUTING.md +++ b/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.* diff --git a/README.md b/README.md index e76a321..76ebead 100644 --- a/README.md +++ b/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 diff --git a/docs/payment-period-communication-policy.md b/docs/payment-period-communication-policy.md new file mode 100644 index 0000000..8604e21 --- /dev/null +++ b/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.