Aqw echoed dev

docs/phase-2-30-day-plan.md

@@ -0,0 +1,102 @@
+# Phase 2 30-Day Organic Outreach Plan
+
+This plan assumes zero traction, no paid budget, and no automation.
+
+## Before Day 1
+
+- Create recommended GitHub labels.
+- Enable GitHub Discussions if ready to respond.
+- Configure discussion categories.
+- Create at least 5 starter issues from [phase-2-starter-issues.md](phase-2-starter-issues.md).
+- Prepare a private tracker using [phase-2-outreach-tracker.md](phase-2-outreach-tracker.md).
+- Confirm public demo credentials and warning language are current.
+
+## Week 1: Setup and Warm Review
+
+Goals:
+- Publish first starter issues.
+- Publish welcome discussion if Discussions is enabled.
+- Ask 3 to 5 trusted people for bounded review.
+
+Actions:
+- Create starter issues manually.
+- Post the welcome discussion.
+- Send 1 or 2 educator review requests.
+- Send 1 or 2 developer onboarding review requests.
+- Track responses privately.
+
+## Week 2: First Direct Outreach
+
+Goals:
+- Begin targeted outreach to specific communities.
+- Avoid mass posting.
+
+Actions:
+- Contact 2 educators or educator groups.
+- Contact 2 developer/open-source people or groups.
+- Contact 1 HBCU department, student group, or faculty contact.
+- Ask for one bounded action: review one flow, test setup, or suggest one better contact.
+- Convert any concrete feedback into issues.
+
+## Week 3: First Sessions and Issue Conversion
+
+Goals:
+- Run or schedule one small demo walkthrough or asynchronous office-hours thread.
+- Convert feedback into visible work.
+
+Actions:
+- Hold one 30-minute demo walkthrough or create an asynchronous GitHub Discussions office-hours thread.
+- Invite 2 to 3 reviewers, not a broad audience.
+- Create issues for repeated feedback.
+- Update starter issue list if some issues are too vague.
+
+## Week 4: Review, Refine, and Decide Next Step
+
+Goals:
+- Measure what happened.
+- Decide whether to continue, narrow, or pause outreach.
+
+Actions:
+- Review outreach tracker.
+- Count replies, feedback quality, issues created, and contributor interest.
+- Thank participants who opted into follow-up.
+- Update README/docs if repeated confusion appears.
+- Decide whether to expand outreach or run a second small cohort.
+
+## Minimum Daily Routine
+
+On outreach days, keep it small:
+
+1. Review tracker for next follow-up.
+2. Send up to 2 thoughtful messages.
+3. Respond to any replies.
+4. Convert one actionable feedback item into an issue or note.
+5. Stop before outreach becomes spammy.
+
+## First 10 Target Audience Types
+
+1. Black K-5 educators.
+2. African-American studies educators.
+3. Black homeschool group organizers.
+4. HBCU education faculty.
+5. HBCU computer science faculty.
+6. HBCU NSBE or student developer groups.
+7. Black software developer communities.
+8. Open-source contributors focused on education, civic tech, or accessibility.
+9. Africa-focused education technology contacts.
+10. Caribbean studies, diaspora studies, or community learning organizers.
+
+## Zero-Traction Success Metrics
+
+Track practical early indicators:
+
+- 10 to 20 thoughtful outreach messages sent.
+- 3 to 5 replies.
+- 2 to 3 demo reviews.
+- 1 educator review session or asynchronous thread.
+- 1 developer setup review.
+- 5 starter issues created.
+- 3 actionable issues created from feedback.
+- 1 potential contributor or reviewer willing to stay in touch.
+
+Do not treat stars, likes, or impressions as the main success metric in the first 30 days.

docs/phase-2-community-launch-workflow.md

@@ -0,0 +1,108 @@
+# Phase 2 Community Launch Workflow
+
+This workflow opens the first community surfaces manually and carefully. It does not contact anyone by itself.
+
+## Manual GitHub Discussions Setup
+
+Repository owner steps:
+
+1. Open the GitHub repository.
+2. Go to `Settings`.
+3. Scroll to `Features`.
+4. Enable `Discussions`.
+5. Create or confirm these categories:
+   - Announcements
+   - Introductions
+   - Q&A
+   - Educator feedback
+   - Contributor help
+   - Roadmap
+   - Show and tell
+
+Before posting:
+- Create labels from [github-community-setup.md](github-community-setup.md).
+- Create starter issues from [phase-2-starter-issues.md](phase-2-starter-issues.md).
+- Confirm the public demo guide is current.
+
+## First Welcome Discussion
+
+Use the welcome post from [phase-2-outreach-assets.md](phase-2-outreach-assets.md).
+
+Suggested category: `Announcements` or `Introductions`
+
+Pin it if GitHub allows.
+
+## First Demo Walkthrough Plan
+
+Audience:
+- educators
+- developers
+- community organizers
+- trusted reviewers
+
+Length: 30 minutes
+
+Prep:
+- Confirm demo login works.
+- Keep [public-demo.md](public-demo.md) open.
+- Have starter issues ready.
+- Prepare a note that the demo is shared and not for real learner data.
+
+Agenda:
+
+1. 3 minutes: mission and current stage.
+2. 5 minutes: public landing page and README.
+3. 10 minutes: student demo flow as `normalstudent`.
+4. 5 minutes: teacher or admin surface if audience needs it.
+5. 5 minutes: contribution and feedback paths.
+6. 2 minutes: ask for one bounded follow-up action.
+
+Follow-up:
+- Share the feedback issue template.
+- Convert concrete feedback into GitHub issues.
+- Ask whether reviewers want recognition before public credit.
+
+## First Office Hours Plan
+
+Format options:
+- GitHub Discussions thread for asynchronous office hours.
+- 30-minute video call if there is enough interest.
+- One-on-one setup help for a first contributor.
+
+Boundaries:
+- Keep it to one topic: setup, demo review, or starter issues.
+- Do not promise immediate fixes.
+- Do not collect private student or school data.
+- Do not ask attendees for broad unpaid curriculum work.
+
+Suggested structure:
+
+1. State current project stage.
+2. Answer setup or demo questions.
+3. Point people to one relevant starter issue.
+4. Record unresolved questions as issues or discussion follow-ups.
+
+## First Educator Review Session Plan
+
+Scope:
+- Review one learner flow, not the entire curriculum.
+
+Length: 30 to 45 minutes
+
+Prep:
+- Share [public-demo.md](public-demo.md).
+- Share [community-trust.md](community-trust.md).
+- Clarify that participation is optional, bounded, and unpaid unless otherwise stated.
+- Ask whether feedback may be credited.
+
+Questions:
+- What learner age or context are you imagining?
+- What felt useful or promising?
+- What felt unclear, culturally off, inaccessible, or age-inappropriate?
+- What would need to change before classroom use?
+- What source, activity, or facilitation support is missing?
+
+Follow-up:
+- Summarize feedback in a GitHub issue if appropriate.
+- Mark historical/source concerns separately.
+- Ask before naming the reviewer publicly.

docs/phase-2-feedback-triage.md

@@ -0,0 +1,85 @@
+# Phase 2 Feedback Collection and Triage
+
+Use these questions and rules to turn early feedback into useful work without overclaiming readiness.
+
+## Educator Feedback Questions
+
+- What grade band or learner context are you imagining?
+- Which demo role, route, lesson, or activity did you review?
+- What felt useful for learners?
+- What felt confusing or too advanced?
+- What felt culturally strong?
+- What felt culturally off, thin, or overgeneralized?
+- What source, activity, image, prompt, or teacher support would help?
+- What accessibility or learner-support concerns did you notice?
+- What would you need before using this in a classroom, homeschool, or learning group?
+- Are you comfortable being credited if this feedback leads to a visible change?
+
+## Developer Feedback Questions
+
+- Could you understand what EchoEd is from the README?
+- Could you identify how to run frontend and backend locally?
+- Did `CONTRIBUTING.md` make the first contribution path clear?
+- Did `ARCHITECTURE.md` help you find the relevant files?
+- Were starter issues clear enough to begin?
+- Which setup step was confusing?
+- Which test or validation command was unclear?
+- What would make the first PR easier?
+
+## Demo Feedback Questions
+
+- Which role did you try?
+- Was the demo credential warning clear?
+- Was it obvious where to start?
+- What part of the navigation was confusing?
+- What made the project feel trustworthy?
+- What made it feel unfinished or risky?
+- What one change would most improve the first impression?
+
+## Triage Categories
+
+Classify feedback as one of:
+
+- `bug`
+- `documentation`
+- `accessibility`
+- `curriculum`
+- `historical accuracy`
+- `onboarding`
+- `demo`
+- `roadmap`
+- `discussion follow-up`
+- `no action`
+
+## Triage Rules
+
+- Create a GitHub issue when feedback is specific, actionable, and not already tracked.
+- Add to the roadmap when feedback is useful but larger than a small issue.
+- Use GitHub Discussions when feedback is exploratory or needs community input.
+- Mark as `historical accuracy` when source, framing, geography, dates, people, or interpretation are questioned.
+- Mark as `accessibility` when feedback affects keyboard use, screen readers, readability, color, mobile layout, or cognitive load.
+- Use `no action` only when the feedback is not actionable, is outside scope, or duplicates a tracked issue.
+
+## Overclaiming Guardrails
+
+Do not say:
+- classroom-ready
+- historically reviewed
+- educator-approved
+- culturally complete
+- production-ready
+
+Use more accurate language:
+- early demo
+- ready for bounded review
+- needs educator feedback
+- needs historical/source review
+- contributor-ready for small issues
+
+## Recognition Check
+
+Before public credit, ask:
+
+```text
+Would you like to be credited if this feedback leads to a visible change? Options: yes, no, or ask me first.
+```