Overview
The org's issue trackers are ~95% the maintainer's own development flow (447 issues closed in 90 days, 427 of them ours), so a user arriving with a question, a help request or a scientific-analysis ask lands in a wall of internal traffic. This task decides where users go instead, keeps the development flow where the tooling expects it, and teaches the Ears (the community conductor) to hear the new surface.
Plan
- Decision document
PyAutoMind/policy/community_surface.md: one Discussions hub (PyAutoLens, promoted to org-level), the dev flow stays on per-repo issues, bug reports with a reproducer stay issues, everything else is a Discussion.
- The Ears (
pyauto-brain community) scan and triage the hub's Discussions alongside external issues and PRs; the Brain board shows unanswered threads with one-tap triage chips.
- Migration manifest for the six user-filed feature threads that belong in Ideas (native "Convert to discussion", which keeps authorship; no API can do it) and the follow-up prompts it spawns: the migration itself, the README/issue-template Support text across the user-facing repos, and the pyautolabs.github.io front door.
Detailed implementation plan
Affected Repositories
- PyAutoMind (primary) — policy document, follow-up prompts, lifecycle
- PyAutoBrain — community conductor (scan + triage over Discussions), board rows, skill body, GitHub access notes
Branch Survey
| Repository |
Current Branch |
Dirty? |
| ./PyAutoMind |
claude/github-issues-community-migration-512ndl |
clean |
| ./PyAutoBrain |
claude/github-issues-community-migration-512ndl |
clean |
Suggested branch: claude/github-issues-community-migration-512ndl
Implementation Steps
- Write
PyAutoMind/policy/community_surface.md answering the five questions of the prompt, with the measured API facts and the migration manifest.
- Extend
PyAutoBrain/agents/conductors/community/_community.py: list the hub's discussions (REST repos/<hub>/discussions), awaiting-response detection, discussion refs in triage; tests in tests/test_community_conductor.py.
PyAutoBrain/board/_board.py: discussion rows in the Community section (md + html).- Docs: the conductor's
AGENTS.md, skills/community/community.md, bin/pyauto-brain description (regenerate the command surface), skills/GITHUB_ACCESS.md Discussions rows.
- File the follow-up prompts under
PyAutoMind/draft/.
Key Files
PyAutoMind/policy/community_surface.md — the decisionPyAutoBrain/agents/conductors/community/_community.py — the EarsPyAutoBrain/board/_board.py — the board's Community section
Original Prompt
Click to expand starting prompt
PyAutoMind/draft/research/pyautobrain/community_surface_users_vs_dev_flow.md — "Community surface: separate where users ask questions from the AI development flow". Original request: "Given how much GitHub issues bulks out, should users put questions and whatnot elsewhere? Should all my AI dev work move elsewhere? Issues doesn't feel suited to building a community. Basically how should we make it so that people can come to the PyAutoLens and other repos with questions, which could be bug reports or help with code but may also be asking for help with scientific analysis. Community basically, should we keep github issues what they are now a huge development flow? I feel like all the stuff I do and where users come in to chat and ask questions need to be separate."
Overview
The org's issue trackers are ~95% the maintainer's own development flow (447 issues closed in 90 days, 427 of them ours), so a user arriving with a question, a help request or a scientific-analysis ask lands in a wall of internal traffic. This task decides where users go instead, keeps the development flow where the tooling expects it, and teaches the Ears (the community conductor) to hear the new surface.
Plan
PyAutoMind/policy/community_surface.md: one Discussions hub (PyAutoLens, promoted to org-level), the dev flow stays on per-repo issues, bug reports with a reproducer stay issues, everything else is a Discussion.pyauto-brain community) scan and triage the hub's Discussions alongside external issues and PRs; the Brain board shows unanswered threads with one-tap triage chips.Detailed implementation plan
Affected Repositories
Branch Survey
Suggested branch:
claude/github-issues-community-migration-512ndlImplementation Steps
PyAutoMind/policy/community_surface.mdanswering the five questions of the prompt, with the measured API facts and the migration manifest.PyAutoBrain/agents/conductors/community/_community.py: list the hub's discussions (RESTrepos/<hub>/discussions), awaiting-response detection, discussion refs intriage; tests intests/test_community_conductor.py.PyAutoBrain/board/_board.py: discussion rows in the Community section (md + html).AGENTS.md,skills/community/community.md,bin/pyauto-braindescription (regenerate the command surface),skills/GITHUB_ACCESS.mdDiscussions rows.PyAutoMind/draft/.Key Files
PyAutoMind/policy/community_surface.md— the decisionPyAutoBrain/agents/conductors/community/_community.py— the EarsPyAutoBrain/board/_board.py— the board's Community sectionOriginal Prompt
Click to expand starting prompt
PyAutoMind/draft/research/pyautobrain/community_surface_users_vs_dev_flow.md— "Community surface: separate where users ask questions from the AI development flow". Original request: "Given how much GitHub issues bulks out, should users put questions and whatnot elsewhere? Should all my AI dev work move elsewhere? Issues doesn't feel suited to building a community. Basically how should we make it so that people can come to the PyAutoLens and other repos with questions, which could be bug reports or help with code but may also be asking for help with scientific analysis. Community basically, should we keep github issues what they are now a huge development flow? I feel like all the stuff I do and where users come in to chat and ask questions need to be separate."